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

• Read this FAQ page for a list of frequent proposals and the responses to them.
• 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, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

This talk page is automatically archived by Werdnabot. Any sections older than 7 days are automatically archived to Wikipedia:Village pump (proposals)/Archive. Sections without timestamps are not archived.

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.

Friends List Or Activity Group

One User Should Be given the freedom to have friends of the same interests,that will ultimately result in the broadness of wiki as more and more information is gathere.

Individual Comic Book Pages

I do not know if pages that discuss individual issues of comic books are wanted. For my own personal reference, I have made summaries of many comic books, and was considering posting them. Pages for comic series, i.e. Detective Comics, exist, but individual issue pages, i.e. Detective Comics #27, do not. Are these wanted, or not? --TheCoolestDude 16:11, 7 May 2007 (UTC)

Most likely non-non-notable. Maybe ask Wikipedia:WikiProject Comics about what has happened before with any such articles, an example of which is Dragon Ball Z: Volume 1. It should be better to combine individual summaries into the main article, as long as it doesn't get too long. –Pomte 21:54, 11 May 2007 (UTC)

I am dubious about articles for individual TV episodes, or fictional characters, see WP:FICT, which i generally support; and this seem less desirable than those. i would think this would be a bad idea except in some extraordinary circumstances (if a particular issue is very famous, perhaps because it sold for a very high sum, or was very different from other issues and had significant mainstream media coverage). But normally i don't see why mentions in an article about the series isn't sufficient. There are other wikis where more detailed coverage might be plausible. DES ^(talk) 22:02, 11 May 2007 (UTC)

I think starting a page on Detective Comics 27 with a summary and prices it's sold for would be a valuable addition to Wikipedia, but I think the vast majority of comic-books are not individually notable and as such probably shouldn't be added. -Halo 19:52, 13 May 2007 (UTC)

As far as doing page on individual books, i say go for it! I would suggest making a "Notable Issues" Section or something similar on the series page, and have links to those issues where a summary would be desirable... Just my two-cents, but I hope it's worth something! Tylerofmaine 17:55, 17 May 2007 (UTC)

IIRC, according to Wikipedia's notability policy, if a publication has over a certain number of copies published, then it is notable. So, if there are more than 5,000 copies of a comic book distributed, then it is notable. And if it's notable, it has a place on Wikipedia. The Transhumanist    20:18, 19 May 2007 (UTC)

Request for consensus: External Links => Incline Citation Bot

• In many wikipedia articles, there are external links after a sentence which is used in a number formating (so the external link has no extra info attached to it); example [1].

• Would it be possible for a bot to remove "[" replacing with "<ref>" and remove "]" replacing with "</ref>"?

• After that the bot would search if there is <references/> in the article.

• If it cannot find it, the bot would make a new sub-section "==References==" and place "<references/>" below that.

• The bot would have to make a list from the last dump of all the mainspace articles, and perform the operations (hopefully it will get over within one week).

• Example Nonvolatile_BIOS_memory

--Paracit 23:24, 19 March 2007 (UTC)

In my view, end of section references are preferable when there is a textual description of the reference. For a pure html link, the reference section just obscures matters, requiring an extra click-through. However, putting raw links into a reference section might encourage people to change them to proper citations. That's a testable proposition, and if it's true this would be a good idea. Derex 00:12, 20 March 2007 (UTC)

Some editors might consider it controversial to change an inline link to a cite.php reference. Even if it encourages adding full citation info, some will view this as a short term detriment, by making the link one step removed. Gimmetrow 01:34, 20 March 2007 (UTC)

It is possible to create such a bot and not very complicated actually. But I share the concerns mentioned above. Maybe you should see if you can reach a consensus in a discussion on this question at WP:CITE. Perhaps this has already been decided on and you can provide a link to it? I'd be interested in helping with the bot / programming it, if there's such a common agreement. I suggest continuing to talk about a bot when we are sure your suggested changes are supported by the community. — Ocolon 08:33, 20 March 2007 (UTC)

I've run across other articles where an editor has manually (I assume) converted embedded links to references/footnotes, without adding anything else. I suppose that encourages editors to work the references to improve them; I'm not sure (because I didn't systematically follow up over the months) that anyone actually did.-- John Broughton (♫♫) 01:33, 29 March 2007 (UTC)

I would almost suggest to just be bold, and manually do a few articles and see the reactions. Do the links get improved? Do you end up just annoying people? etc. —— Eagle101 ^{Need help?} 04:03, 2 April 2007 (UTC)

Check this out so many external links converted to inline citations:

http://en.wikipedia.org/w/index.php?title=Clinical_depression&diff=118654983&oldid=118576074

--Parker007 21:14, 4 April 2007 (UTC)

I agree that the Clinical depression article *did* benefit from converting the external links to inline citations. A problem that this conversion did not address is that the reference sections contain a lot of raw link text that ought to be replaced by useful 'metadata' in the form of authors, titles and complete names of publications. (Each raw link could be replaced by a citation template, and the link itself could be filled into the 'url' field, so the citation would be clickable). Someone could go through manually and fix that. Another more general problem is that this article seems to be overwhelmed by its excessive references. Wikipedia is not a directory or a bibliography. Not sure what your tool could do about that, but it might suggest to us that manual fixup can do things that a bot cannot. EdJohnston 16:43, 8 April 2007 (UTC)

Request for consensus, please. --Paracit 06:44, 20 April 2007 (UTC)

It would be helpful if a click on a citation which is a bare URL went to a screen that prompted for the rest of the citatation metadata as an encouragement to get it collected. I dissent in part from EdJohnson that the Wikipedia is a not a bibliography. The Wikipedia only has credibility or encyclopedic authority to the extent that it can reference the secondary sources which compose the articles. After all, the article authors are not experts but anonymous compilers of information available in secondary sources which are attributed and can be verified. Something which appears first or only in the Wikipedia is called original research. patsw 12:31, 20 April 2007 (UTC)

Proposals such as this should be discussed at Wikipedia:Village pump (proposals); consensus on on a talk page is not usually considered adequate justification for highly visible bot operations. CMummert · talk 12:39, 20 April 2007 (UTC)

Request for consensus, please. --Paracit 21:09, 20 April 2007 (UTC)

Bad idea. Raw number external links are not an ideal form, but hiding them behind a ref tag isn't the answer, they need to be replaced with properly formatted citations. That's not really a bot task. Night Gyr (talk/Oy) 21:59, 20 April 2007 (UTC)

I too have misgivings about the idea - whilst I personally would like to see all inline html links replaced by properly cited footnotes, this would be against current guideline of forcing a change of footnote/citation style - see WP:Footnotes#Converting_citation_styles which states "Converting citation styles should not be done without first gaining consensus for the change on the article's talk page.". So whilst I would dearly personally like this, I would bow to the wider community's relunctance for this.

Minor point from WP:MOS, surely "References" are used for sources researching the whole topic, whereas what we are addressing here are footnotes supporting or elaborating on specific points. Hence the <references/> tag (despite its name) should be under a "Footnotes" or "Notes" section. David Ruben ^Talk 22:42, 20 April 2007 (UTC)

I've used [2] type links in the bodies of articles deliberately on several occasions. A semi-automated bot maybe, but not automated. LukeSurl 00:03, 21 April 2007 (UTC)

Define what you want done. Automatic or semiautomatic doesn't matter if nobody knows what is acceptable. Under what conditions is a direct Wikipedia link useful as a direct reference? Usually Wikipedia is not a reference. (SEWilco 05:05, 21 April 2007 (UTC))

It's worth pointing out that bare URLs are an acceptable reference style, so long as they are complemented by full citations in a separate reference section. Christopher Parham (talk) 00:35, 21 April 2007 (UTC)

What's your point? A bot can also create missing citations. (SEWilco 05:05, 21 April 2007 (UTC))

The point is that how will a bot recognize between bare URLs used incorrectly and correctly used embedded citations. Christopher Parham (talk) 07:19, 21 April 2007 (UTC)

The simplest test is to look for the same URL in both the article text and in a citation. If the place where citations are listed does not have a URL, then that URL does not have a citation. (SEWilco 00:33, 22 April 2007 (UTC))

This strikes me as a bad idea too. I think there are times when an editor wants to link to an outside source inline without sticking it in a footnote. --Selket ^Talk 06:50, 22 April 2007 (UTC)

A detailed citation is required; see WP:CITE. For example, if you don't document the title of the web page which you are linking to then it becomes much harder for someone to clean up your link when the page gets moved on the external server. (SEWilco 04:13, 23 April 2007 (UTC))

This is a very good idea, take Tar_sands for example, where instead of a reference section it has external links after the sentence. I strongly support this proposal. --Khunter 16:16, 24 April 2007 (UTC)

I also strongly support this proposal. References via external links look messy, and really aren't that standardized. If you look at most featured articles, you will find that they all use the footnote method. Seems like a great idea to me. Tim.bounceback^{(review me! | talk | contribs | ubxen)} 21:38, 16 May 2007 (UTC)

This cannot be an automatic process, in articles such as Enzyme kinetics the square brackets are used to denote concentration, eg "At low concentrations of substrate [S], the enzyme exists in an equilibrium between both the free form E and the enzyme–substrate complex ES; increasing [S] likewise increases [ES] at the expense of [E], shifting the binding equilibrium to the right." A bot would replace this correct formatting with ref tags. TimVickers 00:21, 5 May 2007 (UTC)

A bot should not. [ES] is not an external link, and you can see Wikipedia does not show it as a link. An external link has to have "http:" or another protocol after the opening bracket. (SEWilco 05:41, 6 May 2007 (UTC))

this is a useful proposal in the case where an article has a mix of ref-style citations and inline external links. in these cases one style should be used - ref-style. i have tidied-up mixed up articles like this several times, and it is invariably an improvement, encouraging further ref-style citations to be added by other editors. 86.31.103.208 12:43, 6 May 2007 (UTC)

Support - Standardization is good. I would just say either require human intervention before proceeding to edit/replace a [http://link with] text in it & make sure it ignores the contents of the external links sections. MrZaius^talk 16:19, 9 May 2007 (UTC)

Oppose; this is a bad idea for all the reasons above. This is the sort of change that almost always requires a human hand. (A citation with no details is no better than a numbered link, and not all numbered links are citations.) — The Storm Surfer 20:55, 11 May 2007 (UTC)

Oppose; Reference adding is by nature a human task. On the other hand, if you want to tag external links outside of reference/external links sections with some small ^{[Inline citation format needed]} type template, that might be OK. Nihiltres^(t.c.s) 21:03, 11 May 2007 (UTC)

Proposed change to "Template:Unreferenced"

{{Unreferenced}} is a high-profile template that is currently used on thousands of different articles. I tried to start a discussion on the talk page to make an edit that I think might actively prompt people to go hunting for sources. However, due to concerns that it might constitute advertising and due to the high-visibility of the edit, it was suggested to bring the discussion here.

Here is my original proposal:

I was wondering if the template could include links to the three big search engines (Yahoo, MSN and Google) to prompt people to start searching for sources. I chose those three search engines, because those are the search engines that Wikipedia already chooses to use as part of its searching system: see http://en.wikipedia.org/wiki/Special:Search?search=googleblat

I've created a proposal so that people can see what I mean before implementing anything: Template:Unreferenced/Proposal

The template essentially plugs the article name into the search engine as a search term. Could lead to useful results, or at least represent a good starting point to refine the search terms used...

I suggest keeping the discussion here rather than putting it on the template talk page. Looking forward to comments.GDallimore (Talk) 13:07, 2 May 2007 (UTC)

If worded carefully, this might be a useful change. It would have to be very carefully worded to avoid advertising though. What sort of language were you thinking of? ~ ONUnicorn^{(Talk|Contribs)}problem solving 18:00, 2 May 2007 (UTC)

Oh, I see the link to your proposed wording. I don't care for that language - it does sound advertisy and makes it look like only internet sources are required. How about something more along the lines of "You can help! Google, Yahoo and MSN might be good places to start." Though I still think that's a little ady. ~ ONUnicorn^{(Talk|Contribs)}problem solving 18:03, 2 May 2007 (UTC)

I don't like it. It sends the wrong message - Internet sources should not be used exclusively, and are indeed generally somewhat unreliable. Nihiltres^(t.c.s) 18:22, 2 May 2007 (UTC)

Maybe a template can be created to search http://www.worldcat.org/ and then be added to Template:Unreferenced alongside the Internet search engines. --Iamunknown 18:29, 2 May 2007 (UTC)

Most readers know how to use general search engines so linking to them isn't very helpful. More specific ones that they may not be familiar with, such as Google News and Google Scholar, should be much more useful for finding reliable sources. The template currently links Wikipedia:WikiProject Fact and Reference Check. Instead of linking one specific WikiProject, there should be a central page on referencing with convenient links to other pages like Wikipedia:Newspapers and magazines request service and Wikipedia:WikiProject Resource Exchange. –Pomte 19:53, 2 May 2007 (UTC)

I actually don't find Google Scholar to be all that helpful as I usually only get abstracts rather than full text of the papers. But I like the idea of pointing to resources that can be used to find potential sources, and maybe pointing to resources that can help them figure out the how of citing ones sources in Wikipedia (something like Wikipedia:Citation templates). We don't want the template to get too crowded though. Maybe we should put together a page of links that are helpful for finding sources and link to that page. It could link to the "big three" search engines, Google Scholar, and more specific things like Chronicling America, and internal links like to the citation templates. However, that would eliminate the usefulness of the posters original idea, which was to format the links in such a way that clicking automatically takes you to relevant search results. ~ ONUnicorn^{(Talk|Contribs)}problem solving 20:10, 2 May 2007 (UTC)

I've made a couple of changes to the wording of the template. This isn't intended as final, but is just a first stab at softening the wording. Maybe a fourth link could be added to the list of other resources that are being suggested.GDallimore (Talk) 21:47, 2 May 2007 (UTC)

Had a thought and made a couple more edits to {{Unreferenced/Proposal}}. It now uses exactly the same wording as the Wikipedia search screen and includes a possible way to link to an article that suggest other resources. That article should include at the top "your local library" or something. :) GDallimore (Talk) 21:59, 2 May 2007 (UTC)

To me Search for "article title" on Google, MSN or Yahoo!, implies the search will result in finding Reliable sources which is far from the case. If an editor knows what a reliable source is they will know where to find it. If they don't know there is no reason to point them towards a million unreliable sources. Jeepday (talk) 02:54, 3 May 2007 (UTC)

The template already includes a link to explain what reliable sources are. If people find unreliable sources, they'll be removed, that's the way Wikipedia works, but at least it will prompt people to start looking. GDallimore (Talk) 08:57, 3 May 2007 (UTC)

Take a look at today's featured article, William Monahan. Almost every reference in it is an Internet reference, with online articles by the Boston Globe and other reliable sources. The Internet is invaluable for articles about relatively recent things, people and events so it's hardly a useless thing to do to include links to search engines to be able to find whether it was the Boston Globe or the New York Times that printed an article about Mrs Jane Untermyer and her unusually large cat. GDallimore (Talk) 09:59, 3 May 2007 (UTC)

not wise. Internet sources are notoriously unreliable. Further, this sends the message that online sources are more important than offline sources (the reverse is usually true), and that just using the internet to source your article is sufficient. 86.31.103.208 12:59, 6 May 2007 (UTC)

Somewhat disagree with the last comment. Internet transcriptions of reputable sources (newspaper articles, scholarly documents) should always be online if at all possible. Its all very nice to put a book as a reference, but 99.9% of all Wikipedians (and even 99% of all Wikipdians watchlisting the article) are unlikely to posess said book. Online sources are a good way to add to the hard-to-check other references.

As regarding the original proposal, may opinion is: do NOT provide direct links, but the idea of linking to a main search help page on Wikipedia is a good one. Just don't clutter up the template too much. MadMaxDog 10:14, 7 May 2007 (UTC)

I think this would most result in people adding bad sources (especially Wikipedia mirrors!) to articles that have no sources, and then the unreferenced template will be taken out, and there'll be no way to identify the articles. — 128.119.127.137 21:17, 11 May 2007 (UTC)

Terrible idea. We don't need to tell people how to search for sources. If anyone looks at one of the search engine links and thinks "OH WOW! I never thought to do this before!", they aren't the type of person I would want editing Wikipedia. --- RockMFR 19:18, 13 May 2007 (UTC)

There are {{find}} and {{search}} templates, however I would suggest they are better placed on talk pages. Addhoc 12:21, 19 May 2007 (UTC)

Merging New contributors' help page and Editor assistance into Help desk

I propose to merge Wikipedia:New contributors' help page and Wikipedia:Editor assistance into Wikipedia:Help desk. The reason for this is due the more or less similar activities:

• All three have a help desk with possibility for users to leave a question on how to use the wiki, although the Help desk is the most established.
• All three deals with "how-to" type questions; anyone asking for factual stuff is directed towards the reference desk
• In addition, the new contributor's page and the help desk also mentions/links to the {{helpme}} and the IRC client.

There's really not a point in having three similar pages dealing with (as far as I can see) support mainly targeted at new users, and it would probably be better for Wikipedia if we were to have one single page instead of three. Could also be better for those interested in contributing through helping other users.

Also, this would mean the creation of #wikipedia-help and #wikipedia-en-help channels instead of using the current #wikipedia-bootcamp on IRC, as has already been suggested by some of the users on #wikipedia-bootcamp. The current bootcamp channel will be forwarded to one of the new channels. Bjelleklang - talk Bug Me 00:30, 4 May 2007 (UTC)

• BTW, listed this discussion in the merge tags for all the three relevant pages, as well as a note on Wikipedia:Proposed mergers. Bjelleklang - talk Bug Me 00:48, 4 May 2007 (UTC)

• Addition as of May 19: Over the past weeks there has been quite a lot of arguments both for and against this proposed merger, and as it currently stands I've been convinced that there's absolutely no consensus to merge any of them, and as a result I've decided to withdraw the this proposal. Bjelleklang - talk Bug Me 16:57, 19 May 2007 (UTC)

• I disagree with the merger. Strongly. I think differentiating the pages (by linking them on the main help page as different links, as I have done), is necessary. New users: (1) may be intimidated by the technological jargon of the original Help Desk, (2) receive answers that may be hard to grasp given the extreme use of acronyms and abbreviations for answers, and (3) few users (especially new ones) read the backlog of questions as most present singularly unique questions. I look at having two different pages the way a school teacher looks at differentiated instruction. Teaching everyone with the same resource might be practical and more clear cut, but students have divergent needs and skills sets so instruction needs to be different. If there's a problem here, it seems to me that the two pages need to be further differentiated so they better address the divergent needs of different users. SkipperClipper 02:59, 4 May 2007 (UTC)
• Merging WP:NCH was already discussed, but I don't see how Wikipedia:Editor assistance is mergeable. It has more in common with the Adopt-a-User program than with the help desk, so if it has to be merged, I'd suggest it's merged with the adoption program instead. - 87.209.70.231 04:46, 4 May 2007 (UTC)

• Disagree. As SkipperClipper mentioned above, the three pages are like two teachers teaching the same idea with different resources. Moreover there are several major differences among the projects:
  1. HD deals with questions in a single-thread Q-A manner. Old discussions are archived automatically after 5 days. A second follow-up action or response is unlikely. On the other hand, both NUH and EA works in the form of a personal follow-up.
  2. EA and HD is for everyone, while NUH is specialized for newcomers.
  3. Processes in HD and NUH are more well-defined, while EA is comparatively casual.

  Owing to these differences in working principles and style, I believe the three projects should survive individually. --Deryck C. 04:56, 4 May 2007 (UTC)

• Comment: As far as I can see, WP:EA does nothing different from the other two pages mentioned; on the requests page people leave their questions, while other users reply, also keeping follow-ups in the same page. That's more or less exactly the same as HD or NUH. As for the level of expertise on the users seeking help I can't really see a that big difference with EA compared to HD! Both pages have questions ranging from brand new and inexperienced users to those with more experience and more advanced questions.

If the original intention of EA was more coaching-thing than traditional Q&A, this should be empathized much more instead of focusing on the Q&A. As an alternative to the Q&A, both NUH and HD links to an online IRC client as well as the {{helpme}} template; the latter primarily for users to put on their userpages in order to get help from a more experienced editor directly. EA has no such alternatives, and only focus on Q&A. I also don't understand the problem of mixing questions from inexperienced users with other questions from somewhat more experienced users; this has been done on all three pages, although there is generally a lower level of expertise required to answer questions on NUH. If it turns out that the differences are really small, why not expand one of the projects instead of having three different? Bjelleklang - talk Bug Me 10:24, 4 May 2007 (UTC)

Reply: if a Wikipedia project page can solve a problem, why bring it offsite to IRC, complicating things? Moreover, EA is not just Q&A; it also lets people discuss stuff. See some more complicated cases out there. It's just the simple cases that look like Q&As. --Deryck C. 14:40, 4 May 2007 (UTC)

• Disagree, and would note that a failed (and I mean failed, only one person supporting) merger proposal happened around a month ago. EA's been working just fine as a separate project, let's leave it alone. Seraphimblade ^{Talk to me} 11:46, 4 May 2007 (UTC)
• I'm not convinced there's enough of a difference between WP:NCH and WP:HD to keep them separate, but the arguments I've heard to prevent the merge seem reasonable. The problem is that WP:NCH is not that well-known; new users often find the Help Desk instead, and NCH doesn't have as many users answering. So maybe better advertisement, rather than merging, is the solution. --ais523 12:53, 4 May 2007 (UTC)
• Disagree. ASSIST is working nicely as it is, and is performing an additional role in getting newbies' heads around policy, so that they actually do what they're meant to, rather than get the AMA to wikilawyer for them. Moreschi ^Talk 14:20, 4 May 2007 (UTC)
• Disagree with the merge, but perhaps some sort of restructuring of the New contributors' help page, I keep both watchlisted, but the problem with the NCHP seems to be that it's not very well publicized, maybe it would help to add a few more links to it in the various banners and page headers designed for new users--VectorPotential^Talk 14:25, 4 May 2007 (UTC)
• Agree in part - I concur with ais523's comment about the need to promote the WP:NCH page properly; but it suffers from alarge degree of redundancy, so it should be merged. I have only recently begun to monitor it because I didn't even know about its existence, but it suffers from very low traffic. I and at least one other editor raised the same point in the previous merger discussion. WP:EA, however, should not be merged, but its intended use needs to be emphasised and/or repositioned to reflect the differing nature of the assistance on offer. I often work one-to-one with new editors about specific queries/issues and WP:EA is the ideal forum for their requests. As such, it needs to be promoted properly, described clearly, and easy to locate. Adrian M. H. 16:13, 4 May 2007 (UTC)

• Comment - I would also like to point out that too much merging may result in excess strain being placed on the Help Desk during busy periods, and if that happens, some questions will slip by unanswered and questioners will only find it that bit harder to find their questions. Adrian M. H. 16:17, 4 May 2007 (UTC)

• Agree in part - I think that WP:HD and WP:NUH should be merged while WP:EA should remain. WP:HD and WP:NUH are the same set-up and used for the same purpose. I think having these two is redundant. If someone is at the mall and needs help they go to the help kiosk; the system we have now sends the new shoppers one place and the established shoppers somewhere else. I don't think that WP:EA should be included in the merge simply becuase it does more than answer questions. WP:EA is used for resolving disputes and is a more personal aid. In summary, I strongy agree that WP:HD and WP:NUH are merged to one page (after all new users come to the help page all the time), and I feel that WP:EA remain as its own page. Scottydude _talk 17:07, 4 May 2007 (UTC)
• Agree in part - WP:HD and WP:NUH should be merged while WP:EA should remain per above. Agree that WP:NUH has low traffic and so could be merged to streamline our procedures, while WP:EA is working ok and merging could over-load WP:HD. Addhoc 23:18, 4 May 2007 (UTC)

• I definitely support the merger of NUH and HD, EA is an essentially an unnecessary fork of the Adopt a user program (or perhaps just the same thing with less "cute" title). Maybe they should be merged. —The preceding unsigned comment was added by John Reaves (talk • contribs) 23:24, 4 May 2007 (UTC).

• NOTE: (As stated earlier) I have added a separate link on the Help:Contents page. I think this may increae stie traffic. If other locations are warranted, that fine. SkipperClipper 03:57, 5 May 2007 (UTC)

The less confusing conflicting help channels for newbies (and oldbies), the better. 86.31.103.208 13:02, 6 May 2007 (UTC)

Extra comment: One current advantage of EA over HD is that the traffic in EA is not too high so discussions are relatively coherent and easy to follow. Promoting on Help:Contents is good, but beware that excessive advertising could lead to overcrowding of EA, which is not good for this lightweight ask-and-help project. --Deryck C. 15:30, 7 May 2007 (UTC)

• Disagree - I am a rather new contributer, and I read everything on the NCHP, sometimes learning new things about Wikipedia in small steps. I tried to read HD also, but most of the questions were too difficult. It's nice for a new wikipedian to have a safe place where you don't have to be afraid that your question is too stupid.
  Just read the way NCHP starts: "A place to get help with editing and finding your way around Wikipedia", compared to HD: "Read this first!...Please check the Very Frequently Asked Questions Page before asking a question here!" You notice the difference in tone?
  No please, keep NCHP for us newcomers! Lova Falk 13:49, 8 May 2007 (UTC)

As demonstrated, newcomers do not expect as complicated and serious a thing as help desk. Something extra should be designed for them. --Deryck C. 07:17, 9 May 2007 (UTC)

• Disagree. If I were to say to merge one of them somewhere else, it would be WP:EA, but even that carries considerable overhead for no real benefit, so meh. The Help desk and the New contributors' help desk have different methodology objectives, so they should remain separate entities. Titoxd^{(?!? - cool stuff)} 00:01, 12 May 2007 (UTC)
• Agree in part. This is the matter of difference in names. The Help desk and the New contributors' help page serve just the same purpose in practice. Given that more than half of the questions at the Help Desk come from the newbies, I believe this page is not too complicated. So WP:HD and WP:NUH should be merged while WP:EA should remain. PeaceNT 12:24, 13 May 2007 (UTC)
• Merge, same thing. Same difference. "Dare to diff", they did... but now they should "face the diff." --CyclePat2 01:23, 17 May 2007 (UTC)
• Comment/disagree – Since my earlier comment and !vote, I have found myself contributing regularly to NCH and much less often to the Help Desk; this is partly due to limited wiki-time to be shared around, but also because the NCH has shown itself to be a good place to go into more detail with more time to do so. The questioners typically get more attention and I and other respondents often follow up requests with one-to-one help if they need it, which they quite often do. The NCH seems to be a place where newbies can answer their questions and get their answers in a more relaxed and less hurried way than the often-busy Help Desk, where questions are usually (with the honourable exception of Teratornis) dealt with more contritely. What may be seen as the NCH's weakness is actually its strength. I am increasingly against the idea of a merger. Adrian M. H. 21:22, 17 May 2007 (UTC)
• STRONG DISAGREE: the NCH is for - let me empesize it - NEW wikipiedians. The Help Desk is for the more advanced wikipiedians. And I have to agree with Adrian M. H. about the difrences between the two. A merger would only make things worse, therefore I do not want the NCH to be merged. End of. --Adam Hillman 06:14, 19 May 2007 (UTC)
• Disagree Both HD and NCH are sprawling by their very nature; EA is relatively manageable. If I had to wade through all the correspondence that is present in the others, my participation would be scaled back dramatically. --Aarktica 16:34, 19 May 2007 (UTC)
• This proposal has now been withdrawn, as further discussion isn't going to get us anywhere. Thanks to everyone who has participated, I hope that the arguments presented here has helped those (inluding me) that didn't really see any issues as to why they shouldn't merge. Bjelleklang - talk Bug Me 17:12, 19 May 2007 (UTC)

Clarifying binary prefixes in MediaWiki templates

Would anyone object if I edited the MediaWiki templates MediaWiki:searchsize, MediaWiki:size-gigabytes, MediaWiki:size-kilobytes, MediaWiki:size-megabytes, and MediaWiki:longpageerror to use the binary prefixes KiB, MiB, etc. as per Wikipedia:Manual of Style (dates and numbers)#Binary prefixes? These messages are used to refer to the amount of storage used by articles, and disk storage is an area where these prefixes cause the most confusion. Krimpet (talk) 18:17, 4 May 2007 (UTC)

Since no objections have been raised, I've gone ahead and made the change. Krimpet (talk) 04:31, 7 May 2007 (UTC)

T'was reverted, and for the record I agree with the reversion. Carcharoth 23:28, 9 May 2007 (UTC)

I think the templates should use whichever abbreviation is accurate. I also think the templates should use binary amounts. — The Storm Surfer 01:25, 14 May 2007 (UTC)

Kilobytes, Megabytes, etc. is accurate, standard, and does refer to binary amounts, as it always has. —Centrx→talk • 21:03, 16 May 2007 (UTC)

It is not true. Kilobytes, megabytes etc are ambiguous and inaccurate when used to express binary capacities because the standards define them as decimal. They did not always refer to binary amounts. Binary prefixes are appropriate here, except if you prefer common usage rather than unambiguity (this is a valid argument but I don't think that reflecting "common usage" is more important than unambiguity in an encyclopedia). The same discussion is taking place there WT:MOSNUM. Of course I don't agree with the reversion. Sarenne 22:01, 16 May 2007 (UTC)

No, kilobytes, megabytes, etc. mean 1024 everywhere except in specific situations where hardware sellers are trying to make money by misleading people. "Bytes" is not an SI unit. There is nothing unambiguous about "kibibytes" to the vast majority of readers; it is instead more confusing or considered a typo. —Centrx→talk • 03:27, 17 May 2007 (UTC)

I think binary prefixes are appropriate here. In case people do not know what they are, wikilink them to the appropriate explanatory article. We should strive to be as accurate as possible, and saying KiB is a lot more accurate than KB, because KiB unambiguously means 2^10 whereas KB could mean either 2^10 or 10^3, which are not the same number at all. --Cyde Weys 01:36, 14 May 2007 (UTC)

If a word is so novel that even technical people would need to look it up to understand that it was not a typo, then the word is not appropriate. Wikipedia is not the place for neologisms, and Wikipedia is not the place to promulgate invented standards. —Centrx→talk • 21:03, 16 May 2007 (UTC)

"Invented"? It's IEEE 1541 for God's sake. Should we not use the metric system either because it's just "invented"? Or more relevant, what about ISO 8601, which we do commonly use on Wikipedia? Standards exist for a reason. --Cyde Weys 21:40, 16 May 2007 (UTC)

The metric system was invented more than two hundred years ago and is in overwhelmingly common use today. If this were 1800, then no we should not have used the metric system. Even today, Wikipedia does not exclusively require the "standard" metric system in articles. Regarding ISO 8601, it looks to me like the default dating everywhere on Wikipedia is Time, Day Month Year not Year-Month-Day-Time and in fact the use of ISO 8601 is specifically discouraged in articles in the Manual of Style because it disrupts the prose for the vast majority of readers, who being anonymous do not have date preferences set. Regarding standards in general, Wikipedia is not a vehicle for promulgating new standards, especially ones that are not even accepted by specialists in the field for which they were created. It is not the business of Wikipedia to be the sole publisher to require these terms; it is not the business of Wikipedia to use terms so unfamiliar to its readers, not even used by specialists, that every use must necessarily include a clarification for what is ultimately a very basic term; it is not the business of Wikipedia to be the vanguard of a standard long before others, even industry magazines and academic journals in the field. —Centrx→talk • 03:27, 17 May 2007 (UTC)

The key problem here, though, is that using the SI prefixes in a binary sense is ambiguous. A better comparison to circa 1800 would be if we were to simply use the term "inch"; back then, there were English inches, French inches, etc. all in common use. Simply the term "inch" for all of them would be ambiguous, especially if we used different inches in different articles; to be accurate and unambiguous we'd explicitly state which unit we're talking about. Krimpet (talk) 04:24, 17 May 2007 (UTC)

If you care to look at WP:MOSNUM it does say "editors should refrain from changing prefixes from one style to the other" and if you look at WT:MOSNUM you'll see the consensus was reached to write KB which is in line with the common majority accepted use of that term. Also if you look at the IEEE Computer Society Style Guide it also says to use KB. Fnagaton 22:05, 18 May 2007 (UTC)

There is no such consensus.

Which units to use in Mediawiki templates should follow the decision that is made on the MoS. Don't re-debate everything here. It's already been debated and re-debated a few hundred million bazillion times on WT:MOSNUM. Whatever decision we make for articles will apply to Mediawiki messages, too.

The consensus has been demonstrated by the results of the poll in WT:MOSNUM and the subsequent changes made to WP:MOSNUM, to deny that there is consensus for that is silly. Fnagaton 10:55, 19 May 2007 (UTC)

And anyone who cares about the use of such prefixes on Wikipedia might want to express their interest in mediation, though there are so many people with opinions I don't know how a simple mediation is going to solve this. — Omegatron 00:20, 19 May 2007 (UTC)

No, the manual of style is not some iron-clad rule, and the other parts of the manual of style about not rampantly changing styles is more applicable and has much wider consensus than your binary prefix experiment. —Centrx→talk • 04:48, 19 May 2007 (UTC)

Wikipedia should find more places to use kibibytes until it gets reported on The Colbert Report just like Truthiness -- SWTPC6800 03:33, 19 May 2007 (UTC)

Force Abolishing Of Anon Edits

Currently, all those who oppose anonymous editing are forced to continue with the status quo, in order to prevent their hard work from slowly deteriorating. Much work that is not closely watched over does deteriorate. Having read the perennial proposals page, I believe that we constitute a significant fraction, if not the majority. If properly organised, we and all sympathisers of this hitherto-ignored population of Wikipedians could force the powers that be to take us seriously and stop frittering our time and effort. If a date was set and widely advertised inside and outside Wikipedia, everyone who supported this stance could boycott Wikipedia for one week and leave the rest to deal with the vandalism. If we took it further, we could log out and vandalise pages ourselves (don't get mad, keep reading), the idea being that the Wikipedia bigwigs couldn't ignore us any more and realise that without us, the editors that they continue to abuse, Wikipedia is nothing. We'd force them to respect our time, and prevent anonymous editors from occupying so much of it. After the week, the most sensible thing to do would be to revert all articles to their status one week previous. Of course, if the necessary change was implimented before the boycott, it would not need to happen. Wikipedia is bigger than the people who created it.

Would anyone be interested in helping to organise such a thing? I'm fully aware how radical this sounds but I'm only trying to help Wikipedia and its editors in the long-term. --Seans Potato Business 16:12, 12 May 2007 (UTC)

This is a perennial proposal, and has good reasons for rejection. Nihiltres^(t.c.s) 16:41, 12 May 2007 (UTC)

Read m:Foundation issues, the ability of anyone to edit articles without registering is not up for debate, it is mandated by the foundation. I agree with this mandate too. ^High_InBC^{(Need help? Ask me)} 16:46, 12 May 2007 (UTC)

If we were to do anything to reduce crap, I'd tend to instead set mainspace page creation to only autoconfirmed users. A lot of anonymous edits are poor or vandalism, but I've seen a lot that are good and helpful too, especially in aggregate. I entirely support continuing to allow anonymous editing. Seraphimblade ^{Talk to me} 16:50, 12 May 2007 (UTC)

I just looked at the latest 500 contributions of all three of you, and notice that the majority of these edits are in templates, talk space and userpages. I don't think that it's fair for you to condemn those who want to work on ARTICLES to an eternal struggle with vandals, when you yourselves don't suffer the ill effects. --Seans Potato Business 17:22, 12 May 2007 (UTC)

If you really looked at my latest contribs, you should probably also see a lot of edits in user talk with summaries such as "nn-warn" - newly created users creating articles inappropriate for various reasons. I'm fighting vandalism too, just the majority of the article space edits you were talking about are from tagging inappropriate articles that have been deleted - those deleted contributions don't show up. It further emphasizes the point that abolishing anon editing would destroy more than it would achieve - destroying all positive anon contribs while at the same time allowing vandals to simply use hundreds of throwaway accounts. I'm sorry if my rebuke seems harsh, but I do a lot of work in the article namespace to tag inappropriate articles, and your accusation feels particularly insulting to me. Nihiltres^(t.c.s) 17:31, 12 May 2007 (UTC)

I just looked at the top 20 anon edits in recent changes. I hit rollback on 5 of them; the other 15 looked fine, and most were actually constructive. If you block all anons, the vandals are likely to continue by registering usernames (making them even harder to stop), and the constructive edits are more likely to stop. (For reference: [3] [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20] [21] [22]). --ais523 17:38, 12 May 2007 (UTC)

By comparison, only about half of the top 20 edits by non-anons in Recentchanges were to article-space, and were about as useful as the anons' by comparison (it was the same sort of changes), although only one was the addition of a spamlink. In the meantime, an anon reverted vandalism to my user talk page. I suspect that if all anons were banned, we wouldn't have much of an encyclopedia by now. (By the way, you might want to compare Citizendium, another wiki encyclopedia that does ban anon edits, to Wikipedia.) --ais523 17:45, 12 May 2007 (UTC)

Problems with Citizendium: 1) They want to start from scratch - Six years back in time 2) Wikipedia already has nearly 100% "market-share" 3) They appear to have questionable ideas regarding how to copyright their content. What I want is 2007 Wikipedia minus the vandalism (registration with confirmed email address) and everything that goes with it (a lot more than meets the eye). I don't see the point in discussing this, since according to m:Foundation issues, this policy is beyond debate. My call for editors in agreement stands - we'll use a way that doesn't involve debate. --Seans Potato Business 18:05, 12 May 2007 (UTC)

Then fork Wikipedia, which you're perfectly entitled to and the project provides database dumps to allow you to do so. -Halo 01:47, 23 May 2007 (UTC)

Our core aim is to be a free encyclopedia that anyone can edit. What you mean is, basically, force semiprotection to every single article, a fact that prevents "anyone" from editing. Our strength is that anyone, anywhere, can fix a typo or correct a fact in a couple of seconds. It is up to everyone to prevent that fact from being our weakness as well.

Since you talk about organizing, create a Wikipedia:Obligatory registration or similar essay, and link to it from as many pages as you can find (besides village pump, noticeboards, help desks, Wikiprojects, etc), and see if the community agrees or not. Since I am against the idea of restricting edition (which has brought me problems for always giving second opportunities to even vandals), if I were to create such essay, it would be considered a point. However, if you believe that is the solution to many of our problems, don't let us stop you from starting that discussion. -- ReyBrujo 18:00, 12 May 2007 (UTC)

Seans Potato Business, if you look a little closer at my contribs you will see that I am directly effected by the vandal problem. I have also done plenty of work in the article space, and even if I did not my opinions are just as valid. ^High_InBC^{(Need help? Ask me)} 17:59, 12 May 2007 (UTC)

In addition to anonymous editing being the foundation of all Wikimedia projects, also consider a more practical matter: if registration were required, all vandals would just start registering accounts to vandalize. Krimpet (talk) 18:10, 12 May 2007 (UTC)

I am also against abolishing anon edits. As an article writer I see first hand the benefit of anon edits in correcting typos and copy edits. Of course I also see the spam ELs and vandalism but admittedly they are easier to pick out and revert when they come from an IP. In my watchlist, IP contributions stick out and I make it a point to look over them. If everyone had to register it would be harder to isolate these potential vandalism edits for closer scrutiny. Agne^Cheese/^Wine 18:14, 12 May 2007 (UTC)

Anons are the largest group of wikipedia editors, and IIRC produce most wikipedia content. If forced to choose, I would ban all registered users first. ;-) --Kim Bruning 18:25, 12 May 2007 (UTC) (Anons also produce most wikipedia mess, but that's what you get for being the largest group of editors ;-))

Gather supporters and spur on more debate: sure, go ahead. Log out and intentionally cause vandalism to articles to prove a point: I will pursue you just as I pursue every other vandal: be they IP or registered; regardless of a user's past beneficial contributions. Good editors know how to go about raising their concerns, and intentional vandalism is not the way. --Bossi (talk ;; contribs) 19:26, 12 May 2007 (UTC)

This discussion has been going on for a long time. However, we have another option against vandalism : semi-protection. If we loosen the guidelines on semi-protection a little bit, it would certainly stop a lot of vandalism. Certainly all those articles that are as good as finished, could be semi-protected. Practically all changes on those articles just consist of vandalism. I’ve tried this out on a few articles (such as Apple, Rose, Leaning Tower of Pisa) that were vandalised one or more times on a daily basis and it helps a lot. JoJan 08:36, 13 May 2007 (UTC)

There are plenty of good-faith edits (though not necessarily the greatest quality of edits) by anons and I think content is very hard to come by, so any sort of good-faith edit can be worked upon and should be welcomed. x42bn6 Talk Mess 17:57, 13 May 2007 (UTC)

The reason for vandalism is simple: Anyone can edit and can see their change go live immmediately. Nothing can be more attractive to someone who wants to see that they can have an impact on the world, even if only temporarily. "Anyone can edit" is a "office policy", meaning that Jimbo Wales would need to change his mind on this one. I really don't see that happenning anytime soon.

The other option is not to have the edits "go live" immediately. One possibility is this business of "approved versions" that is being tried out in the German Wikipedia, but I am not sure of the status of that. It would show an "approved version" by default, but an editor could still go into the article and edit the current version at will. I am not sure if this works much to discourage the vandals or not, as the vandals edit does "make it in" to Wikipedia. I have also called for review of edits by anons and new users to no avail. Another idea is to require an e-mail exchange to verify an edit. This would force a vandal to "sign" their edit, but once again people have expresed concerns about inconveniencing the anons. Personally I feel that an anon doing a legitimate edit will be happy to put up with review or confirmation as long as they told up front what is going on and why. The process cannot be too onerous, but some bar is needed so that a vandal just does not find Wikipedia worth the bother.

BTW - I do have another suggestion: Immediately ban ANY editor engaging in blatant vandalism for at least two weeks. If it is so blatant that a bot can detect it, then you are probably catching the vandal when they are active. --EMS | Talk 01:56, 14 May 2007 (UTC)

I strongly disagree with any suggestion which prevents IP addresses from editing Wikipedia. Why? Well:

• The vast majority of people wanting to ban anons are people who do vandal fighting or regularly check watchlists, and are generally the people who see the worst side of IP contributions. They're inherently biased.
• The vast majority of edits by IPs are genuine, and much of the genuine content from Wikipedia was by people editing using IP addresses.
• It's inherently unwiki-like, and creates artificial restrictions on who can edit.
• It's easier to "see" the fruits of vandalism rather than genuine content, making the problem seem worse than it is.

I also disagree with anyone who inherently talks about "increasing punishment". This doesn't work:

• Many genuine editors will get hit in the cross-fire
• Promoting and extending already overly harsh bans isn't a good idea
• It doesn't work in real life with the "death penalty", why the assumption it will work on Wikipedia? -Halo 02:02, 23 May 2007 (UTC)

Also, part of the appeal and initial draw of Wikipedia is the fact that anyone can edit. I remember reading through the project about 4 years ago, long before I registered an account, and fiddling around with copyediting and such. Just because SOME anonymous IPs vandalize doesn't mean all do. There are plenty of usernames on this site that vandalize as well. Jmlk17 20:08, 23 May 2007 (UTC)

Lower the tolerance on vandalism by anons

The problem about stopping anons from editing articles is that the majority of anon edits are constructive. So it will not be fair for the well behaving majority. So, another idea will be to lower the tolerance for anonymous IPs. Make it so that they can be blocked after just 1 warning, rather than the final warning. If the IP address is shared, urge any innocents to create an account. On the other hand, allow the admins to actively track the IP address of any users with fewer than 50 edits. Then it can be immediately known whether it's someone who creates an account just to cause trouble after his IP's been blocked.--Kylohk 19:40, 14 May 2007 (UTC)

• Strong support - Lowering the tolerance is very much needed. I gets to be much less fun if you are stopped almost as soon as you get started. I have also called for a vandalism-revert flag to be added edit page so that people can point out vandalism to the admins. The two combined would no doubt curtail vandalism quite a ways. --EMS | Talk 20:11, 14 May 2007 (UTC)
• Support – With a caveat. Certainly, that would make it easier to limit their activities and halt the bored children and casual mischief makers. I have a slight concern that this might result in more blocks being carried out, which would add to the admins' workload. That is in addition to the possible increase in malicious accounts and Agne's point about spotting IPs in one's watchlist. Adrian M. H. 20:33, 14 May 2007 (UTC)
• Support I also agree. Four warnings and often more gives the vandal too much lenience. A quicker block will better stop the fun and multiple IP users may quicker as well. I don't think that extremly blatant vandals will ever become useful and must be stopped much sooner. Testers should perhaps recieve more warnings. Reywas92^Talk 20:30, 14 May 2007 (UTC)
  • Comment I'm not sure that I care to distinguish between testers and vandals all that much other than to perhaps give the non-malicious testers a shorter block. In both cases people are looking to see what they can do, and the quicker you lower the boom the better. (However some cases, such as when the tester quickly reverts their own edit, can and should be excused with little more than a warning.) As for Adrian's concerns about workload: I suspect that this will decrease workload by stymying vandals before they get a sense of power and start treating the vandalizing of Wikipedia as a game. --EMS | Talk 02:55, 15 May 2007 (UTC)

Comment Looks like we are getting close to a consensus. If it is reached, I guess we can place it in the talk page of WP:VANDAL.--Kylohk 18:16, 15 May 2007 (UTC)

Done. See Wikipedia_talk:Vandalism#Lessening_the_tolerance_for_vandalism. --EMS | Talk 02:37, 16 May 2007 (UTC)

• Strong oppose - seems like a slippery slope and prone to abuse, and lots of people genuinely trying to submit genuine will get hit in the crossfire, particularly people who "mean well". I also dislike the implication that people who make anonymous genuine edits will not do it from the same IP that would commit vandalism. Whatsmore, it may encourage the continuing practise of heavy-handed anon-IP blocks of "indefinite" over minor vandalism rather than the 24-hours deserved -Halo 01:44, 23 May 2007 (UTC)

Immediate blocks won't do much. Most vandalizing IPs only do it once or twice, and by the time you block them they'll be done. Night Gyr (talk/Oy) 05:39, 23 May 2007 (UTC)

This policy would never work in my opinion. There are far too many anonymous IPs that have multiple users. I recall how 300,000+ users from Singapore were blocked because someone didn't notice how they shared the same IP, and someone was using it to vandalize. Jmlk17 20:10, 23 May 2007 (UTC)

An idea for a new link format

Links currently can be of two forms:-

• [[xxxx]] = link to page xxxx, display xxxx
• [[xxxx|yyyy]] = link to page xxxx, display yyyy.

But sometimes a link format [[xxxx|yyyy|zzzz]] = "link to page xxxxyyyy, display xxxxzzzz" would be useful, e.g. [[incinerat|ion|ed]] would link to incineration and display incinerated without having to repeat the whole of a page name which may be long. Anthony Appleyard 20:19, 14 May 2007 (UTC)

Not a bad idea, but also why not just make a redirect from incinerated to incineration (which is apparently currently the case)?↔NMajdan•talk 20:24, 14 May 2007 (UTC)

Some editors seem to take a dislike to links that make use of a redirect and change them as they would a link to a disambiguation page. I don't mind them at all (notwithstanding any possible increase in server load, which I'll leave to experts to comment on). Adrian M. H. 20:41, 14 May 2007 (UTC)

I think that although this proposal may have some merit, it's not a very intuitive system - I don't think it would help much in practice. Oh, and there's another link format: [[zzzz:xxxx (yyyy)|]] = link to page zzzz:xxxx (yyyy), display xxxx, if "zzzz:" is a namespace. Works without either of "(yyyy)" or "zzzz:" too. Nihiltres^(t.c.s) 01:57, 15 May 2007 (UTC)

Support - It's not intuitive, but it's not difficult to use either. If it is documented well people will catch onto it and use it. There is a need for it. --EMS | Talk 02:58, 15 May 2007 (UTC)

Oppose; I think we should reserve this syntax for something more useful. I actually had a really good idea as to what that would be, but it's slipped my mind. — The Storm Surfer 04:38, 15 May 2007 (UTC)

Oppose; covered already by redirects and the [[xxxx|yyyy]] notation. Nihiltres^(t.c.s) 20:44, 15 May 2007 (UTC)

Oppose; no point. ^High_InBC^{(Need help? Ask me)} 22:43, 15 May 2007 (UTC)

Oppose; same as The Storm Surfer, even though it's neat. Sorry. ~EdBoy^[c] 02:01, 16 May 2007 (UTC)

Oppose; this saves a handful of keystrokes, and in the process provides still anothing thing for new editors to learn how to understand when they come upon it. The benefit to a few doesn't seem to be worth that cost. (In general, the issue of added complexity is not considered nearly enough). Notinasnaid 08:39, 16 May 2007 (UTC)

Oppose; I don't even like links like [[thi]]s or [[even (this)|]]. I'd trade a few keystrokes and a little visual clutter for a consistent and easy-to-learn one-rule syntax any day. Dcoetzee 13:33, 18 May 2007 (UTC)

Strong Oppose; It would take me a bit of time to get used to and I'm sure others would not appreciate changing it when it really doesn't do much. Jmlk17 20:13, 23 May 2007 (UTC)

Start informal campaign to purge Wikipedia of bad grammar/spelling

It might be a good idea to get people to volunteer to occasionally scrub Wikipedia of some common grammar and spelling mistakes. For instance, I just fixed several pages of "protray" spelling mistakes when "portray" was meant (still several pages to go). I picture a place where people can sign-up to monitor some common grammar/misspelling problems. If two or three people each volunteer to monitor each proposed mistake (it would only take a couple minutes every month or so per person), Wikipedia's quality might improve dramatically. I've noticed that people or bots must already fix many common errors but finding typos that have apparently never been searched for isn't very difficult. Userboxes could be made to identify volunteers and to locate others of the same task. They might say "This user makes sure 'portray' is spelled correctly." etc. I've been a grammar/spelling gnome for a while now and I've noticed that many of the pages I correct are low visitation pages that go months between edits. The higher visitation pages get people frequently checking of their spelling. Global spelling fixes tend to fix typos that would otherwise linger for a long time. I'm aware of the problems of blindly fixing "typos", which is why I think a person should monitor each spelling/grammar fix. My idea is an organized version of that. Probably would let somebody else implement. Jason Quinn 03:02, 15 May 2007 (UTC)

The AutoWikiBrowser can help you with this. –Pomte 03:08, 15 May 2007 (UTC)

Thanks. (that was quick!) I was wondering if something similar in function to my idea already existed. Jason Quinn 03:11, 15 May 2007 (UTC)

Coincidentally the other day I typed "occurence" in the search box, and Wikipedia reports an astonishing 122,808 hits. That's a huge amount of work. I wondered if there was any automated way all these could be fixed. The problem is that there may be a very few cases when "occurence" is correct (e.g. in a literal quote, probably with "sic", or when the misspelling is being discussed). The program would have to be clever enough to identify these. Matt 11:15, 15 May 2007 (UTC).

Actually, on further investigation it seems that this figure is incorrect. I think that Wikipedia search is for some reason also picking up instances of "occurs" and other legitimate variants. Matt 11:33, 15 May 2007 (UTC)

It's also because our search box sucks. ^demon^{[omg plz]} 03:39, 22 May 2007 (UTC)

Automatic spelling-correction programs aren't permitted because there would be too high a risk of false positives. Manually-assisted spelling correction problems (i.e. where it asks a human whether to correct on each 'occurence') are permitted, and I think several of them are being used. --ais523 11:28, 15 May 2007 (UTC)

You might also be interested in Wikipedia:Typo, a department that acts rather like what you've suggested. --ais523 17:11, 15 May 2007 (UTC)

One reason why full automation would be wrong is that the incorrect information may be a quote. It would be absolutely wrong to correct spelling or grammar in a quote (unless the quote is inaccurate, something requiring detailed reading of sources). (But adding [sic] can be a good thing). In talk pages and user pages it would be just wrong. 08:35, 16 May 2007 (UTC)

Avoid movement in pages

Yesterday's Picture of the day, Image:Translational motion.gif, was extremely distracting; it may well have caused problems for users with cognitive disabilities. It appears to breach WAI-WCAG Web Content Accessibility Guideline number 7.3: "Until user agents allow users to freeze moving content, avoid movement in pages". I suggest a policy that all such images should use a still image, or text, to link to the animated version, with a prior warning. (prior discussion: Wikipedia talk:Picture of the day#Animation, Wikipedia talk:Accessibility#Animated Picture of the Day) Andy Mabbett 21:34, 15 May 2007 (UTC)

I agree with this. I don't like animation on pages unless I specifically want it. This allows people who want to see the animations see it and those who don't can see a static page. Perhaps we could have a user setting to have the animated or still version of images load by default on the article pages. Koweja 21:42, 15 May 2007 (UTC)

I'm with you 100%. But, as I often find in the course of my work, it can be hard to convince people of the importance of accessible web standards. Adrian M. H. 21:43, 15 May 2007 (UTC)

I agree on general principle, but sometimes an animation is essential. For articles on horse gaits for instance, a series of still images just doesn't do the subject justice. A looped vid or animation is the most powerful informative tool on the page in a case like that. If you require a link, I guarantee it will get missed. So I agree with making it policy, but it needs to be clear that it's avoid movement, not a across-the-board ban on animation. VanTucky 22:22, 15 May 2007 (UTC)

Of course an outright ban would be bad, I would just like a choice in when we see the animation. You can even make it default to showing animations and users have to check something in their settings to see stills w/ a link to the animation. That'll help prevent people from missing it if we made no-animations the default settings. Maybe even a bar on top of the page if there are animations and the user has animations disabled. Koweja 22:35, 15 May 2007 (UTC)

Sounds good. VanTucky 22:37, 15 May 2007 (UTC)

Warn people about the moving picture but keep it because some people enjoy them and the people who do get seizures from movement dont have to look because they know that the moving picture will be there.adambear8888 19:13, 24 May 2007 (UTC)

I think that some applications may warrant moving images. This should be left to editorial control. ^High_InBC^{(Need help? Ask me)} 22:42, 15 May 2007 (UTC)

Can you give an example of a page where it's more important to show (rather than link to) a moving image, than to respect the meeds of users with disabilities? Andy Mabbett 11:58, 16 May 2007 (UTC)

Can't we just create a JS/CSS system where 2 images are preloaded, and then you need to click like a "play" image before the animated image is shown? I think it's possible we just need to find the right place to place the .js Sounds simple and doable. It should still be used with the greatest reserve and stuff, just like any other animated gif we have now, but it would address some of the concerns mentioned above I think. --TheDJ (talk • contribs) 12:59, 16 May 2007 (UTC)

That would involve always sending both images and using up bandwidth. As you're using JS anyway, maybe replacing the image using DOM manipulation would make more sense? --ais523 13:03, 16 May 2007 (UTC)

I just did some testing. we only need a special version of the table collapse scripting. My tests show that hidden elements are loaded when needed, not upon page load in Safari and Firefox. I think it would be relatively easy to change the table collapse code in some code that will switch between a "play" image or the "animated" image. --TheDJ (talk • contribs) 13:53, 16 May 2007 (UTC)

I cordially invite you to run a test on the GIF page, which has two three useful but potentially distracting animations. Being able to see the effects would enable people to gauge whether it would be a good idea to implement this feature and doing so on a page heavily devoted to GIF animation might bring some more knowledgeable people into the discussion. GDallimore (Talk) 14:07, 16 May 2007 (UTC)

(edit conflict) The other problem with using display:none-like code is that it breaks an accessibility guideline itself; see Wikipedia:hiddenStructure. With DOM manipulation code, it'd be possible to degrade in a more graceful manner for ancient browsers (e.g. have the 'play' link take the user to the image description page for the animated version). --ais523 14:09, 16 May 2007 (UTC)

Click the image to see the animation. The only drawback seems to be I can't get the image to resize, but maybe I just haven't figured out how to do that yet.

As I outlined on Wikipedia talk:Picture of the day, this capability already exists on MediaWiki with the following syntax: [[Image:Animated.gif|thumb=Still frame.png]]. howcheng {chat} 21:08, 18 May 2007 (UTC)

3 comments copied from Wikipedia talk:Accessibility#Animated Picture of the Day

Could you perhaps clarify the problem with an example or two? What kind of disabilities are affected by animated images? Do the images at Earth#Orbit and rotation and Engine#Modern need to be removed/made-static and have a warning added? Every other animated image on the site?

The only example I can think of that makes obvious sense to make static/warn about, is Strobe light, which is of course linked to from Photosensitive epilepsy. Though possibly its small size makes even that ignorable.

We simply need more to go on, than "is extremely distracting" and "may well cause problems".

Finally, it's the Picture of the Day, it's meant to be distracting! --Quiddity 23:22, 15 May 2007 (UTC)

"We simply need more to go on, than "is extremely distracting" and "may well cause problems". " Indeed, which is why I cited WCAG.

"Do the images at Earth#Orbit and rotation and Engine#Modern need to be removed/made-static and have a warning added?" - Yes. Andy Mabbett 12:04, 16 May 2007 (UTC)

They make JAWS behave more sluggishly (with all modern versions of JAWS I have including the latest one). This is because when the JAWS rendering engine sees a change in a page, it thinks it is a new page and tries to redraw it. This tech support bulletin is slightly relevant, though things have improved since it was written. For what it's worth, I just turned off animations in Internet Explorer - it can be done easily through the tools menu - and sluggishness at the article Earth disappeared. I had never thought of that before I read this conversation and I haven't found anything in the JAWS documentation about non-flash animations. I like the way the picture of the day section works on the main page and I have no objections to animated images being featured as long as they are not directly displayed there. However, in actual articles, I think only static images should be displayed directly. Graham87 12:43, 16 May 2007 (UTC)

end of copy

The WCAG 1.0 Guidelines you cited are from 1999, and the draft for 2.0 appears to have removed that particular element of advice on general animated images. Possibly because it is indeed now possible to disable them within all major browsers (firefox, IE, opera).

The Strobe issue is addressed by WCAG 2.0 Guidelines #2.3 - Seizure (Working Draft). It should indeed be made-static.

Apart from that, I'm still unsure who exactly is being affected by this? Who are we going to be helping by removing what is, to most, useful content? --Quiddity 18:04, 16 May 2007 (UTC)

The WCAG guidelines v1.0 are still current; version 2.0 is being re-drafted because they were not accepted by the wider community. Andy Mabbett 21:56, 16 May 2007 (UTC)

But the 1.0 guidelines were developed during the heyday of blinking-rotating-animated interfaces, the monstrosities of geocities and flashturbation. The spirit of the intent was not aimed at removing single useful animations from an encyclopedic page.

You keep arguing the abstract point and tangential concerns, and I keep asking for concrete examples. Who are we going to be helping by removing what is, to most, useful content? Is there a single disability that is seriously affected by the image at Horse gait#Gallop? --Quiddity 01:25, 17 May 2007 (UTC)

"But the 1.0 guidelines were developed during the heyday of blinking-rotating-animated interfaces, the monstrosities of geocities and flashturbation. The spirit of the intent was not aimed at removing single useful animations from an encyclopedic page." - can you cite some evidence to support that claim, or are you just expressing a personal opinion? Andy Mabbett

Call it common sense, call it personal opinion. The web has changed just a little bit in the last 8 years; to ignore that, and the original context, would be foolish. --Quiddity 19:00, 22 May 2007 (UTC)

Common sense as a method of argument is a logical fallacy. The kinds of disability affected by movement or flashing have not changed in that period. Andy Mabbett 12:15, 23 May 2007 (UTC)

"Who are we going to be helping by removing what is, to most, useful content?" - Straw man. No-one is asking to remove useful content; I'm suggesting that where that content is animated, and this breaches WCAG 1.90 guidelines, it's preceded by a simple but clear warning; to help anyone and everyone who is distarcted or made ill by such images, such as people with cognitive disabilities, attention issues or types of dyslexia. I'm not an expert on those issues, but the people who drafted WCAG 1.0 were. Are you? Andy Mabbett 22:21, 21 May 2007 (UTC)

Well, attention issues makes sense. But reducing the utility of the 'pedia for everyone else requires overwhelming need, and frankly I'd like to see an actual complaint from someone suffering a problem first. Similar to the spoiler tag controversy - supposedly noone has been able to find a valid complaint about a lack of spoiler tags yet.

The likelihood that a reader will not click through to an animated image is quite high. Conversely, I find the animated images useful because they capture my attention when I'm scrolling down a page - an animated image will often be the item that makes me curious enough to read that section.

My only suggestion would be for you to draft what you envision as an appropriate policy/instruction-set for animated images, so we can have an example of what you want. Apart from that, I think howcheng's answer above covers the problem adequately.

The last line at Wikipedia:Image use policy#Displayed image size already suggests that "Inline animations should be used sparingly". That's where any changes would go, and a note should be left on its talkpage pointing to this discussion (or move it all to there). --Quiddity 19:00, 22 May 2007 (UTC)

That guideline is being ignored, or circumvented; presumably because "sparingly" is a weasel-word. Andy Mabbett 12:15, 23 May 2007 (UTC)

Image:Roodlicht.gif I support this proposal. Image:Dainsyng.gif Krimpet (talk) 01:56, 17 May 2007 (UTC) Image:Roodlicht (reversed timing).gif

There should be a ban on enforced viewing of moving images. They are distracting. Distraction was also mentioned for removal of movement at Pan Am Flight 103. Non-stop images are the worst. Distracting work colleagues or calling attention to the use of Wikipedia at work can also be a bad thing. Currently, the only options to avoid unrequested moving images are to scroll away or close the page. Neither option is good. I see no reason for a total ban on moving images (the horse gait example is great) just on unrequested image movement. Thanks for bringing this up. Editore99 12:44, 17 May 2007 (UTC)

Users who should not be loading Wikipedia from work are not our concern. Unrequested moving images are no greater a concern than sexually explicit images, and we already know how that discussion goes... without concrete descriptions of the harm to be incurred, this needs to be a page-by-page consensus on whether animation is warranted. At most, a guideline for some of those reasonings so they can be more globally applied (though I suspect we already have one, somewhere). -- nae'blis 14:33, 17 May 2007 (UTC)

"Unrequested moving images are no greater a concern than sexually explicit images" - I've heard of sexually explicit images inducing moral outrage, but never epilepsy. Andy Mabbett 09:52, 18 May 2007 (UTC)

You need to show the evidence that all moving images trigger epilepsy, or concede that not all moving images are bad. -- nae'blis 14:41, 18 May 2007 (UTC)

Given that I've never claimed that "all moving images trigger epilepsy"; no, I do not. Andy Mabbett 14:52, 18 May 2007 (UTC)

Given that you think Earth#Orbit and rotation and Engine#Modern need to be made static, I think we need a more clear view of your criteria then. -- nae'blis 15:00, 18 May 2007 (UTC)

My "criteria" is adherence to WAI-WCAG Web Content Accessibility Guideline number 7.3: "Until user agents allow users to freeze moving content, avoid movement in pages". Andy Mabbett 15:15, 18 May 2007 (UTC)

Do you have any answers for my questions/statements 8 comments up (Beginning: "But the 1.0 guidelines were...")? --Quiddity 16:57, 18 May 2007 (UTC)

"Users who should not be loading Wikipedia from work are not our concern." You do not speak on behalf of me so the word our is not appropriate. Editore99 12:04, 18 May 2007 (UTC)

Let me rephrase that, then: "There has never been a consensus that Wikipedia should be edited with an eye toward the concern of users who should not be loading the encyclopedia from work." Whether or not you personally have a concern about such, it's not a goal or policy of the encyclopedia. -- nae'blis 14:41, 18 May 2007 (UTC)

Thank you for rephrasing it. I understand your point and agree that the issue has not arisen before. Editore99 18:20, 18 May 2007 (UTC)

I strongly object to this proposal. One of the most powerful features of Wikipedia is the ability to insert moving pictures into the articles. Such moving pictures often make for a far easier-to-understand exposition of a principle than would 1000 words.

Can it be misused? Of course. And I'm sure we'll see that. But properly used, it greatly improves the accessibility of information in our encyclopedia. I look forward to the day when, for example, our tiger article shows video of tigers in motion and not just a few static images.

Atlant 17:11, 21 May 2007 (UTC)

I look forward to the day we have a video of a tiger on Wikipedia, too. But I want it to star playing when *I* say so, not the page's authors. This concurs with the findings of every usability study worth its salt. Andy Mabbett 22:23, 21 May 2007 (UTC)

Above there was an inquiry as to whether moving or blinking images cause actual problems for soemone. i have been presnet when blinking computer images caused a serious epileptic seziure in another person -- and let me tell you significant harm was done. I'll go into detail if anyone wants. Now most moving images are not in the least likely to cause seizures, any policy about those must rest on other grounds. but images with significant area blinking or changing color on a regular basis such as Image:status.gif can indeed cause a problem. DES ^(talk) 21:16, 22 May 2007 (UTC)

I don't really want to sound insensitive here, but what do we imagine coming next? A ban on police and ambulance lights? You can never be politically right enough, right? Motion sickness is a more regular phenomenon than epileptic fits, but that shouldn't get us to want a ban on passenger airplane flights. I personally have a problem with cathode ray tubes, which makes my eyes hurt bad after every Wikipedia session. I am sure there are millions of other people who has a similar problem. So what do we ban - cathode ray tubes or the Wikipedia or both? Please, banning something is a serious measure, think long and hard before you propose it. It's easy to start banning things, for one reason or another, all with a good intention - smoking, abortion, slash-and-burn agriculture, euthanasia, polygamy, inter-religion marriage - whatever. But, when we start stretching things, where do we stop? Before we all go and ban something as little as a blinking image, we might end up becoming either a bureaucracy or an authoritative regime - both highly against our fundamental principles. Please, think again. I don't think this discussion should be about seizures, value of moving images or bandwidth. It should rather be more about principles and ideologies. Aditya Kabir 16:13, 23 May 2007 (UTC)

Please avoid slippery slope as a method of debate. Andy Mabbett 14:46, 24 May 2007 (UTC)

There is a difference between a government banning soemthing in real life, and a website adopting a policy of what images it will and won't use -- anyone who doesn't like wikipedia's policies is free to find a wiki with different ones. There is also a significant difference between the harm done by a seizure and by motion sickness, and there is also a difference in the oppertunity of a potential victim to anticipate and avoid the problem -- people generally know when they are about to get on a vehicle that may cause motion sickness. In many jurisdictions the design of flashing lights for emergency vehicles has been altered to reduce the chance of seizures -- and the positive benefit provided by such lights is IMO rather higher than that provided by flashing images on wikipedia not behind a link. DES ^(talk) 17:10, 24 May 2007 (UTC)

Please, avoid an intention to stop a method of argument that is quite popular in areas as diverse as macro-economics, criminal law, mechanics, and public health. And, please, if you really want to advise someone to leave Wikipedia if the policies is not suitable, then stop discussing them and start hurling people out of the community. We discuss policies that we like or don't like, and try to build a consensus (that includes non-existent policies that have a potential to become). If you don't like the way Wikipedia operates, I guess, you can leave it and start one Wiki on your own, with complete liberty to drive people out. Now for the slippery slope, I'd like to ask a simple question - do we go out banning stuff left and right and act like a stiff bureaucracy? Or do we depend on the editors to work towards a great encyclopedia, and try out a system that politely asks people to make careful use of blinking images? I stand for the second route (I have already removed one blinking image I was using, and that didn't need a banning policy). Cheers. Aditya Kabir 17:19, 25 May 2007 (UTC)

Evidence

• A presentation on Chronic Fatigue which notes the harmful effects of movement on web pages. Andy Mabbett 18:55, 25 May 2007 (UTC)

• More. To support the above on Photosensitive epilepsy, I am adding the following research findings (Harding, Graham; Photosensitivity: a vestigial echo?, The first Grey Walter lecture; International Journal of Psychophysiology, 1994, volume 16, pages 273-279.):

• About one in 4000 individuals has photosensitive epilepsy. Repetitive flashing lights may induce seizures in these individuals. The flash frequency of concern is from 5 Hz to 70 Hz, with most individuals only susceptible in the range of 15 Hz to 20 Hz.
• A flashing strobe (or a close combination of multiple strobes sequenced together) must not be programmed to flash in the 5 Hz to 70 Hz frequency range.
• Slower flash rates, and randomly flashing lights are not known to be a cause of photosensitive epilepsy.
• Point sources of light are much less likely to induce seizures than a diffuse source of light which covers a large part of a person's field of vision.
• To induce a seizure the light must be present in the center of the field of vision as opposed to the periphery.
• Reducing brightness or increasing distance between a photosensitive viewer and the light source is effective for preventing photosensitive epileptic seizures.
• Lights flashing in the distance, even in the frequency range of concern, are not known to cause seizures when in the presence of other lights of a more natural or chaotic nature.
• The probability of inducing a seizure is greatly increased (by up to a factor of ten) if the light source is arranged in a regular pattern, such as a raster scan image. (This would be far more difficult to accomplish with the DMX Multi-Strobe Brik than with say, a television image.) Stated another way, avoid adding spatial contrast (pattern) to temporal contrast (flickering).

It is also widely known that seizures in photosensitive individuals may be triggered by events like:

• Flickering or rolling television images
• Certain video games
• Computer monitors
• Alternating patterns of different colors

The Web Content Accessibility Guidelines 1.0 proposes the following remedies to the threat:

• Allow users to control flickering, avoid causing the screen to flicker
• Allow users to control blinking, avoid causing content to blink
• Allow users to freeze moving content, avoid movement in pages
• Provide the ability to stop the refresh, do not create periodically auto-refreshing pages
• Provide the ability to stop auto-redirect, do not use markup to redirect pages automatically. Instead, configure the server to perform redirects.

There also have been evidence that Epileptic Seizures can be self-induced, like looking at the sun and blinking rapidly. May be it naturally follows that an outright ban would be a too simple minded solution. I propose that we develop a start button for moving/flashing/blinking images, and incorporate that into the coding for such images. May be a bot can help. There is no evidence to tell us that people who may be able to provide with such images of great educational value are also adept enough in writing codes that incorporate a "start" button. Aditya Kabir 04:34, 26 May 2007 (UTC)

• Post Script As for seemingly cute but actually quite silly images like Image:Status.gif (not that I mind the silly, I used the image myself), which has no educational value whatsoever - they can always go. There already is a deletion debate going on, and it doesn't warrant a high-handed policy/guideline at that.

Overhaul of article assessment

See WP:ASO.

American, British, etc. idiom template

There appears to have been many debates over British v. American, etc. spelling. The proposal to minimize this debate is:

1. Create a template such as {{idioms | American=color British=colour}}
2. Allow users to control which version they see based on their Monobook.js file
3. When a new account is created, set the default using one of the following systems
   1. The country the IP block resolves to
   2. Set American English as the default since it is probably more common among 'pedia users
4. Example 1, one current solution: Color (or colour, see spelling differences) is the visual perceptual property corresponding in humans to the categories called red, yellow, white, etc.
5. Usage would then be: {{idioms | American=Color British=Colour}} is the visual perceptual property ...
   1. British English speakers would see "Colour is the visual perceptual property..."
   2. American English speakers would see "Color is the visual perceputal property..."
   3. Other variants could be added. The list of allowed idioms would probably need to be controlled through the template page to avoid vandals adding 'humorous' idioms.

Antonrojo 12:51, 17 May 2007 (UTC)

There's a good reason not to do this in the example you give - it can be useful to know the different spellings that are used (without having to edit the page to see the template).

Could the servers handle the huge number of template calls that this would require for a Wikpedia wide roll-out? Dunno the answer to this.

What might be an idea is to use a template along those lines for the first example of a particular word in an article and the template works so that, if a person then rolls their mouse over the word, the other spellings could pop-up. That might solve both my issues with the idea. Don't know if there are others, though. GDallimore (Talk) 15:08, 17 May 2007 (UTC)

I had not considered either of those issues. A 'no idiom' setting that displays all idioms could be an option though I do not know what this would look like. Regarding the server load, the fact the template simple substitutes text rather than generating graphics, tables, etc. might avoid that problem.

Also, a user over at Talk:Yoghurt just informed me of a similar template {{sp}}. Antonrojo 15:56, 17 May 2007 (UTC)

I don't think this is necessary. Spelling differences are minor and not confusing to anyone. If people are that offended by seeing a different spelling than their own then they should just get over it. As for words with different meanings/not used in on version of English, then a synonym can be used instead. Koweja 15:59, 17 May 2007 (UTC)

{{ADCE|year}} (which appears as Template:ADCE to you; if you haven't customized your monobook.css, it displays both) never really caught on (only one transclusion, and it's in userspace). I don't expect this would either. --ais523 16:00, 17 May 2007 (UTC)

I personally do not think that it is necessary. The {{sp}} template does not seem to be in popular use (I haven't encountered it before), so I somehow doubt that this would be used either. Besides, spelling like this is but a trifle. -- Cielomobile ^{talk / contribs} 23:40, 17 May 2007 (UTC)

A possible solution would be the previously suggested rollover idea. If users are really that concerned with the spelling, they could roll over the disputed word, click on it, choose their spelling preference, and all subsequesntly accessed wiki pages could use that spelling, unless the integrity or accuracy of the article is reliant on the local spelling of the word. For instance, if the term 'autumn' was used in an article, the alternative 'fall' could be presented. Unless a song lyric, quote, or other literary work or such like was being quoted, then of course, the original word would stay, without alternative language preferences being offered.

If you were to create a template that didn't alter the appearance of the words unless the user set up their monobook preferences, this could be ok. I would drop any suggestion that US spelling should be the default though. Addhoc 12:25, 19 May 2007 (UTC)

I'm an American, and I don't believe the colour, nor the centre of anything really matters. We speak the same language, so it's all good in the end. :) Jmlk17 20:15, 23 May 2007 (UTC)

Hit counter for every article in Wiki.

I feel a hit counter has many advantages:

1. May serve as a measure of 'popularity' for an article.
2. It motivates contributors to do more on the article if they know that it is popular.
3. May serve as a measure of 'reliable content' if it is accessed by many people.
4. Acts as a reward to the author because so many people read his/her article.
5. And many more that I can't think of right now in this quick post.

I don't know wheter it is appropriate for Wiki but for example 'planetMath' do have it.
Also, a hit counter wouldn't be appropriate for the 'Main Page' as the articles differ frequently.
Just to add another, a hit counter for each article may be used one for each year in order to assess its time evolution. Edyirdaw 14:20, 17 May 2007 (UTC).

This is not feasible on Wikipedia because of the server load it can incur. You may be interested in some aspects of Special:Statistics. -- nae'blis 14:27, 17 May 2007 (UTC)

We do have this though.↔NMajdan•talk 14:28, 17 May 2007 (UTC)

And what is more, if that was visible on every article, it would make it easier for vandals to target either the very popular pages for maximum exposure, or the least viewed pages for the best chance of going unnoticed. Bad idea. But to answer your points:

1. It is not a contest.
2. I have no desire to concentrate on mainstream and/or popular articles. Quite the opposite.
3. I doubt if very many of "my" creations are high-traffic (often quite obscure) but they are still reliable. 100% I hope.
4. Same answer as 1 and 2. I'm not in it for the glory.

Adrian M. H. 21:04, 17 May 2007 (UTC)

I think it would just end up becoming a popularity contest or a vanity issue for far too many users. Jmlk17 20:14, 23 May 2007 (UTC)

Don't the server logs already have the necessary data? If not, tracking this data wouldn't demand a lot of resources and it would address the primary criticism of Wikipedia

And measuring updates as a proportion of hits(views) would avoid a popularity contest while providing a measurement of reliability. See post below about measuring the reliability of an article

I Agree With You,The Wiki Should Must Accept This Proposal.Good Idea

SunnyIndia 09:35, 26 May 2007 (UTC)

Strong oppose. Because of quite a few reasons:

1. Wikipedia is an encyclopedia, and encyclopedic content can't or shouldn't be judged by popularity
2. It is only natural that Linda Lovelace will always have more hits than The Old Man and the Sea (check here to see that latest films and human organs have way more hits than almost any of the featured content
3. There is no reason that accuracy or authenticity will draw more hits than human vanity and well circulated behavior patterns
4. This would actually promote Wikipedia:WikiProject Pornography over Wikipedia:WikiProject Countering systemic bias very strongly (it roughly translates into a typical Big Mac becoming more imprortant than 1 billion Chinese people, just because the Chinese visit the English much less than the average American)
5. In a world where MySpace is way more popular than BBC how can we suppose that "popularity" is a measure of "reliability"? (Hitler was very popular when he won the election, but was he reliable?)
6. Instead of addressing the primary criticism aganist Wikipedia it will aggravate the criticism deeply, with a possibility of turning an encyclpedia into a farce of popularity parade
7. And, of course, for all of the reasons already stated above

Very, very bad idea. Aditya Kabir 20:18, 26 May 2007 (UTC)

Vandalism warnings template syntax

As I've increased the number of pages on my watchlist, I've been seeing and reverting vandalism more often, and thus using the warning templates more often. However, I occasionally forget to add my signature to the warnings, making it look rather odd if HagermanBot doesn't come around. I'd like to know: would it work to add a ~~~~ to the coding for the warning templates? Nyttend 15:45, 17 May 2007 (UTC)

It could be made to work, but then there'd be loads of instances of double-sigging warnings. Also bear in mind that some users don't sign with the four-tilde abbreviation, but instead use a script, or copy-and-paste it in, or even type it out manually. --ais523 15:50, 17 May 2007 (UTC)

Apparently a bunch of users were adamntly against having the signature included inside the template. Ask at Wikipedia talk:WikiProject user warnings for specific past discussions. –Pomte 03:58, 21 May 2007 (UTC)

British/English

In my opinion British and English are 2 different things depending on the subject matter. English LAW and English LANGUAGE are two seperate and easily distinguished matters. I refer to, as one of possibly many Wikipedia examples, the subpoena article, extract pasted here in parenthesis (The subpoena has its source in English common law and it is now used almost with universal application throughout the Anglo-American common law world. However, for Civil proceedings in England and Wales, the term has been replaced by witness summons, as part of reforms to replace Latin terms with easier to understand English terms.) The link in question in in bold. To the uninitiated or layman, this could be confusing. I therefore propose that all links featuring the word 'English' with a reference to England as a country (law, culture etc but NOT language obviously) could have a (GB) suffix attached, so the previously highlighted link would read 'English(GB) common law', so to distinguish that 'English' means 'originated in England ' rather than be possibly confused with the English language, that is obviously used worldwide.

The alternate proposal is that 'American English' should be described by the term 'American', while 'British English' should be described by the term 'English'. Neither proposal is realistic. Addhoc 12:28, 19 May 2007 (UTC)

Also, hasn't this been as issue around here for quite some time? Even down to spelling (colour vs. color, centre vs. center, etc). I think that if it is readable and grammatically correct, it doesn't matter which version the article is in. Jmlk17 20:05, 23 May 2007 (UTC)

How could English common law possibly be confused with the English language? Incidentally, of course British and English are two different things - one refers to Britain and one to England! -- Necrothesp 14:10, 27 May 2007 (UTC)

Bring back the Horror collaboration of the month?

Wikipedia:Horror_collaboration_of_the_month was a valuable page that helped improve several articles greatly, and bring about some featured articles. I'm not sure how I can see why it was made historical - the horror wiki project still lists it as active on its main page. Could some other Wikipedeans chime in and say whether it could be brought back or not? Thanks Desdinova 23:34, 17 May 2007 (UTC)

If you can find other people who are interested in collaborating for horror articles, by all means get together and improve an article. That page was marked historical, I believe, because interest in the collaboration abated acutely. It seems as though modeling the page after WP:ACID may have caused its decline, since the ACID model is based on a significant amount of traffic. I have no problem with resurrecting the collaboration, so long as people are interested in working on the articles. Gracenotes^T § 03:38, 18 May 2007 (UTC)

Thank you! I'll see what I can drum up! Desdinova 10:35, 18 May 2007 (UTC)

Good luck! Jmlk17 02:51, 25 May 2007 (UTC)

Index to important talk page discussions proposal

Has it ever happened to you that you had some idea about a guideline, policy, or wikipedia process only to later discover that three years ago 500 people already thoroughly discussed the issue? Have you ever been frustrated at the annoying tediousness of digging through archives in search of a debate you remember happened there?

Well, my solution is simple. Let's create a Wikipedia:Index to important historical debates (or whatever name is better). It would be an alphabetical list organized by topic and description. An example entry would be:

• Main page - non-free images on, [links go here]; layout [more links]; selection of content on, [yet more links] etc.

The index would be very incomplete at first, but in typical wikipedia fashion, I expect it to grow and become very useful, especially as Wikipedia continues to develop and people start forgetting older discussions. It would also solve the problem (with which we are all familiar) that there is no set talk page for discussions of any number of issues, and debates have sprawled throughout the wikipedia namespace. What do people think of this? Any other suggestions? nadav 11:14, 18 May 2007 (UTC)

that sounds like a good idea, but I think it might be better implemented on the project talk page instead. If I'm looking for historical AfD discussions, I'll probably be looking at WT:AFD first. howcheng {chat} 20:51, 18 May 2007 (UTC)

Yes we can do that instead. In any case, this will take a lot of work. It might be best to create a formal wikiproject for this, so we can have templates and everything, say WikiProject Discussion Indices.

As further proof that this index is needed, I have just discovered that Radiant, in her infinite wisdom, has already thought of this a long time ago and created Wikipedia:Centralized_discussion/Conclusions. See, now I wish I had access to the index earlier so I could've checked discussion of this issue and not reinvented the wheel! nadav 11:25, 19 May 2007 (UTC)

• Why thank you! I think what you're looking for is really CAT:G. Many important discussions are preserved as guidelines (if they had a practical outcome, at least). >Radiant< 13:42, 21 May 2007 (UTC)

Edit Summary link

Can we have the Edit Summary link open in a new window. A couple of times I've gone to put in my edit summary after a long edit and ended up losing everything because I clicked in the wrong place. Thank you, C0N6R355^talk_contribs 17:03, 19 May 2007 (UTC)

In most browsers, you can get your edit back if you click on 'back' immediately. I also agree that new-window opening on links in the interface for the edit window would be useful, but it would require a software change. --ais523 11:11, 20 May 2007 (UTC)

I've done the same thing, and, while it is a pain in the butt, it doesn't happen often enough to me to vote for a change in software. Jmlk17 20:16, 23 May 2007 (UTC)

Biography Barnstar award

It seems odd to me that maybe one of (if not the) biggest projects out there, WikiProject Biography, doesn't yet have a Project-specific barnstar. If nothing else, the amount of work required in keeping such a project running seems to me to merit at least the potential of such an award. Unfortunately, I, who have trouble hitting the right key let alone making images, am probably not the best person to try to create it. But, taking the obvious approach here, maybe the File:Crystal personal.png could be superimposed over the center of a barnstar? John Carter 18:25, 19 May 2007 (UTC)

How does Image:Biographystar.png look? Mr.Z-mantalk¢ 18:48, 19 May 2007 (UTC)

Twenty-three minutes from proposal to existence?!? I am stunned and very grateful for the speed of the response, and I think it looks wonderful. Does anyone know of what further steps (if any) have to be undertaken for this to be approved? John Carter 18:57, 19 May 2007 (UTC)

(I had nothing better to do) I'm dropping a message now on the Project talk page about it. The old barnstar approvals page was marked as histroic recently, so now the project just has to decide what to do with the image. Most are put into templates so they can easily be subst'd on user talk pages. Mr.Z-mantalk¢ 19:04, 19 May 2007 (UTC)

Hiding Footnotes/References/Notes

As you all know, most articles have references, notes or footnotes at the end of the article. But some articles have a massive list such as Spider-Man 3 and Virginia Tech massacre. They take up a lot of room, so perhaps, could we start using the hide tag:

{{hidden begin|header=header}}

{{hidden end}}

to hide it, to save space? Just a thought. — « hippi ippi » 05:27, 20 May 2007 (UTC)

I don't think you'd get any benefit, they're tucked away at the end after all the content anyway. As for spider-man 3, that article has too many references, many of them are used only once to cite little things that are probably covered in any of the other reasonably complete references. I'd like to see some consolidation and pruning going on to make it less crowded. Night Gyr (talk/Oy) 05:40, 20 May 2007 (UTC)

This has been tried in the past, and as I recall if they are hidden by default it breaks the footnotes -- i.e. when you click on a footnote you are not taken to the reference. Christopher Parham (talk) 20:56, 20 May 2007 (UTC)

Oh... okay. There goes my (unoriginal) idea. Ok then, I'll live. — « hippi ippi » 10:58, 21 May 2007 (UTC)

I agree with Night's comments. To be honest, I'd rather see a huge list of references then see an article with a huge amount of whitespace. As Night said they are tucked away at the bottom, so I don't see any good reason why they should be hidden. –Sebi ~ 09:53, 25 May 2007 (UTC)

Watchlist Categories

I currently have 115 items on my Watchlist. What I think would be useful would be a way to group items into categories such as Radio, TV, Wikipedia (pages like this for example), Education, Computing etc.

The you could select the category and see if any changes have been made to set pages rather than having a long list of changes. pjb007 14:27, 20 May 2007 (UTC)

Here's a "low-tech" way to do it. Create alternate accounts, such as User:Pjb007a, User:Pjb007b, and so forth, and put on the user page a link to your main account. (This is permitted per WP:SOCK.) Then create a separate watchlist for each user account. YechielMan 16:16, 20 May 2007 (UTC)

Only 115 items? This survey might interest you then. Adrian M. H. 17:17, 20 May 2007 (UTC)

That sounds like an interesting userscript project. I guess it would be a major PITA to design a even marginally efficient way to store and retrieve dataset<->location pairings though (especially with bigger watchlists where this would be most useful). -- Seed 2.0 19:58, 20 May 2007 (UTC)

Use related changes to achieve a similar effect to what you're saying. Place links to all the articles that you would want in one group on a user subpage, and when you're viewing that page and click "related changes" in the toolbox, you'll see a watchlist-type pages as if only those pages were on the watchlist. —METS501 (talk) 21:47, 20 May 2007 (UTC)

It seems like a good idea, if it was in a user script, and not something that is default in your watchlist. I would prefer categorising by namespace but even then it would only be useful if you have a high amount of articles in your watchlist. –Sebi ~ 10:09, 25 May 2007 (UTC)

Unsupported Characters

Hey, new user here.

Numerals and letters of alphabets, Latin or otherwise, are included in the database. For example, there is a search result for the keyword (perhaps it could be called a key-letter!) 'D', whereas characters such as ':' and ';' are unsupported and have not any results. Why not change that? There are links to pages started with that particular prefix, but what if someone actually wants information on the character ':' used for punctuation?

If one Googles ':', there is no result, which somewhat surprised me, but when one Googles 'punctuation symbols', there are 967,000 hits (the first one, of course, is the Wikipedia article).

Discuss. Any suggestions or comments? — Preceding unsigned comment added by Obssessedlinkfan (talk • contribs) 18:13, 20 May 2007 (UTC)

It's not necessarily that easy to change. Allowing colons in the search box would require a major technical change to how linking is done, which will cause a lot more trouble than being unable to search for ':' ever will. -Amarkov moo! 18:20, 20 May 2007 (UTC)

Cascading Protection on copyvio

Should {{copyvio}} be put on a cascading protected page so that all pages that have copyvio template on it can only be edited by admins, since the template says not to edit it until an admin fixes the problem? --R ^ParlateContribs_@ (Let's go Yankees!) 21:30, 20 May 2007 (UTC)

That wouldn't work, since cascading protection works the other way - if the template was cascade-protected then only the pages that were transcluded onto the template page itself would be protected.

Also, even if this was possible, it still shouldn't be implemented because it would mean that anyone could go around protecting whatever pages they felt like just by putting {{copyvio}} at the top of them. Tra (Talk) 21:40, 20 May 2007 (UTC)

I know protecting the template wouldn't do anything. I said put the template on a cascading protected page. --R ^ParlateContribs_@ (Let's go Yankees!) 00:03, 21 May 2007 (UTC)

Sorry, I must have misunderstood you. Putting the template on a cascading-protected page would have the same effect on the template as cascade-protecting the template itself. The template would be locked from editing but other pages that transclude it would be unaffected.

Unless you're suggesting that the pages with the copyright problems themselves are cascade-protected individually in addition to the template being added. If that is the case then there probably wouldn't be any need for the protection to be cascading - just normal protection should be enough. Tra (Talk) 00:22, 21 May 2007 (UTC)

To clear this up: if template A is transcluded on page B, cascade-protecting page B will protect template A, but cascade-protecting template A does nothing to the protection status of page B. (In other words: what Tra said.) --ais523 10:05, 21 May 2007 (UTC)

Wiki-automation. Update facts from their source pages automatically on other pages using author-defined variables.

This was an e-mail sent to Wikipedia by me. I do not know how Wikipedia works in terms of code, but I had this idea that could help:

"While reading the Oprah Winfrey wiki, I read "Although blacks are 12% of the U.S. population, Winfrey has remained the only black person wealthy enough to rank among America's 400 richest people nearly every year since 1995."

I immediately questioned the statistic, and had the idea that perhaps that "12%" should be automatically updated by the US census wiki.

Such as, on the US census wiki, variables could be defined by the authors and then used by other wikis. So, say that on the US census wiki you have a variable for total US citizens, and total black US citizens. The Oprah Winfrey wiki authors could use those variables in their wiki to come up to the percentage automatically. That way, when the US census wiki is updated, the Oprah Winfrey is automatically updated as well.

This may be a poor example, but the idea would save a lot of time and bring accuracy to more wikis.

Sincerely, Daniel Matthews"

My concern is that massive transclusion of data would greatly facilitate vandalism - change one variable and you would vandalize many pages simultaneously. The solution for many critical templates on Wikipedia has been to protect them - see for example {{!}}, a prominent metatemplate. Protecting such numbers in any similar system would undermine the openess of the wiki, which is a major problem - free editing is one of the five pillars. Nihiltres^(t.c.s) 03:42, 21 May 2007 (UTC)

However, this sort of transclusion is occasionally done anyway. --ais523 10:08, 21 May 2007 (UTC)

If your writing includes a statistic that can date easily in many places, you're doing it wrong. That would be better phrased with a specific point in time attached to both her wealth and the black population number. Night Gyr (talk/Oy) 14:53, 21 May 2007 (UTC)

that is true, but says nothing of articles that are discusing present conditions. -ΖαππερΝαππερ ^Babel_Alexandria 18:08, 21 May 2007 (UTC)

When discussing present conditions, you still give a date. Like today's date. Then it can be updated as needed. Carcharoth 01:54, 23 May 2007 (UTC)

Merger proposal regarding pokemon articles

As the existence of things like WP:POKEMON and Wikipedia:Poképrosal can attest, there has been some resistance to the fact the all 493 individual pokemon have their own articles, even though many of them will never garner much more information than they have now. After several months of discussion, many members of the related project (WP:POKE) have agreed upon a way to merge many of the articles. To prevent split discussions, all wikipedians are invited to review and comment on the guidlines proposed at WP:POKE/Layout. -ΖαππερΝαππερ ^Babel_Alexandria 17:49, 21 May 2007 (UTC)

Internal article references

Hello.

I notice that your articles can make reference to other articles. However, the other articles make no reference to the referencing articles.

For example. The article on Strategic lawsuit against public participation (SLAPP) (http://en.wikipedia.org/wiki/SLAPP) makes reference to the Oprah Winfrey page (http://en.wikipedia.org/wiki/Oprah_Winfrey), but the Oprah Winfrey page provides no indication that it is being referenced from the SLAPP article.

I have written applications that make such two way linking the norm. Yet Wikipedia seems not to support it.

Just a suggestion.

Kurt Christensen

Kurt... if you click on "What links here" in the toolbox panel, it will show all the articles that reference the one you are in. Blueboar 19:35, 21 May 2007 (UTC)

Video on Wikipedia

Hi all. Someone has proberly come up with this before but how about wikipedia has short videos on educational subjects like an egg hatching or the different earthquake types. If we did this it would be comparable to microsoft encarta. Of course there would be problems like people uploading irrellevent stuff or working out who should have the powers to upload the correct videos but if we got past that it would be an even better encyclopedia with people seeing how it really happens and for those people who learn from watching rather than just reading!Wiki.user 19:47, 21 May 2007 (UTC)

You may be interested in the Video policy on Meta-wiki. Nihiltres^(t.c.s) 20:42, 21 May 2007 (UTC)

Uploading of videos is allowed and encouraged. You have to use Ogg Theora, though. Night Gyr (talk/Oy) 23:30, 22 May 2007 (UTC)

Ability to gauge quality of information

A simple way to gauge the quality of the information in an article, or more accurately the extent to which the information is accepted, would be to measure the number of edits in proportion to the number of visitors. The theory is that the greater the number of people viewing the article the more opportunity there is to make corrections. Therefore, an article that is viewed by many but edited by few contains widely accepted information. However, an article that contains many edits in proportion to the number of viewers contains more dynamic and less accepted information. A more static article is expected to be more accurate.

These measures would need to be constrained to a period of time. For instance, the number of viewers and editors could be from the past day, week or month. An analysis of the frequency of edits of existing articles would likely reveal an optimal period of time based on the article total lifespan. For example, the quality of information in an article that is only a month old may be measured by activity in the past two weeks, whereas an article that is a year old is measured based on activity in the past month. There are lots of options for determining the time frame.

The resulting metric could be represented as a rating (low, med, high; 1-5; etc) near the title of each article to indicate to users the reliability of the information they are reading. Metrics could also be produced for each independent block of an article to give a more granular measurement since the blocks are edited independently of one another.

Unfortunately, due to server resources, we don't track the number of visitors to each page. —METS501 (talk) 00:35, 22 May 2007 (UTC)

The server logs should contain the number or requests for each page. If Wikipedia has customized those log files it wouldn't require a great deal of resources to track this info - 65.196.71.3 14:57, 25 May 2007 (UTC)

A new Term to Coin

I wish to establish a new term in the tradition of terms that have entered the world vocabulary such as "politically correct" and "environmentally correct". The term is "carbon correct" to be used to suggest that efforts and disourse to reduce or offset carbon emissions is often a complex problem with many competing variables. Or the term could be used sarcastically to disparage the claims of those who say they can drive their SUVs without guilt because they have purchased carbon offsets without knowing whether such offsets are effective or efficient or preferable to alternative means to reduce carbon release.

submitted by scarman50

This page is for proposals related to Wikipedia, not general proposals about life. However, I think that we generally refer to things like you are talking about as "green" or "Environmentally friendly". —METS501 (talk) 00:34, 22 May 2007 (UTC)

Wikipedia is not the place to establish new terms or usages for terms. Even if lots of us liked your term "carbon correct", it would be a neologism... a new coinage of a word or term... and we aren't supposed to use neologisms in Wikipedia. Before we can use it here, you would need to demonstrate that it has been widely used in the world beyond Wikipedia. Blueboar 14:33, 22 May 2007 (UTC)

I don't believe this is the right place for you to try and coin a new term in language. Jmlk17 20:22, 23 May 2007 (UTC)

Intersecting Categories

Does anyone know of an easy way to cross-reference two categories? As in, I'm looking for all articles related to biochemistry that need cleanup, or the like. Besides, of course, skimming through the actual categories. Someguy1221 00:15, 22 May 2007 (UTC)

Yes, this feature is available as "List comparer" in AutoWikiBrowser. —METS501 (talk) 00:31, 22 May 2007 (UTC)

Category intersection is a perennial feature request that may actually get implemented if someone can figure out how to manage the server load it will create. -- ☑ SamuelWantman 23:08, 26 May 2007 (UTC)

AIC Hazzard 2; Request

AIC is meant for users to go to to post a new article so other wikipedian's can help in the making of the article. I have some requests for the article.

1- A protective covering for the articles posted on the AIC. the articles are supposed to be incomplete or have nothing more then just a structure for others to follow, or else it doesn't really need other's help, but this can cause delection tags to appear. So a protective cover against delection might be needed.

2- multiple links so people can find out about AIC. AIC needs people to post new articles on it, and AIC MUST have wikipedians to help the new articles.

3- AIC can be found only by typing it's name in {Article in Construction} but other names for people to find it by would be very helpful, names including AIC, AC, what ever comes to mind.

These requests are very important to the future of this article. — Preceding unsigned comment added by Nikro (talk • contribs) May 22, 2007 (UTC)

Perhaps navigation to AIC should be offered as an option on the No page with that title exists page. -- Boracay Bill 01:27, 22 May 2007 (UTC)

Deleted

My two articles, AIC and Scientific Beliefs were delected without my knowing of it. AIC was treatened once, but the poposal to delete the article failed, AIC had nothing in it that gone against the policys, and there wasn't a project/article similar to it. AIC's threat was stop, so they place a speedy deletion on it. and Scientific Beliefs was on AIC, meaning it was incomplete, still being worked on and they placed a speedy deletion on it before it could be completed. Please do something about this, and if possible, bring back my articles, mainly AIC, it was not disobeying the policies in any way! — Preceding unsigned comment added by Nikro (talk • contribs)

Scientific Beliefs was redirected to Science. Looking at the article that you created - [23] - this article doesn't exactly appear to have been ready for prime time. Anything in article space needs to be such that if a reader looked at it, they would see it as something of encyclopedic quality, not just as an outline of an article. Also, please see our policy on original research. Wikipedia is not the place for your own views or interpretations - ideas in articles need to be attributed to a reliable source. As for AIC, it seems to have been discussed above. Self-referential topics or "meta" topics are kept out of article space. Instructions on writing articles or project coordination topics all go in Wikipedia: space. --BigDT 13:31, 22 May 2007 (UTC)

It looks as if the editor actually wanted to start a list such as List of scientific theories. Although there was a lot of WP:OWN in the original article ("don't change structure unless you absolutely have to") it could be an interesting project that wouldn't have been WP:OR. I personally would view it as completely impossible task to create such a list but if someone else wants to give it a go, I think it could make an encyclopedic article. GDallimore (Talk) 13:40, 22 May 2007 (UTC)

Nikro... I mentioned this above, but will do so again here. If you have an idea for an article, and want it "protected" from deletion while it is "incomplete" (ie you are still working on it), create a sub-page attached to your user page, and work on it there. You can transfer it to the main article space once you think it is complete. Also, please note that once an article is placed in mainspace, it is inappropriate to call it "my" article... it belongs to all of us. Blueboar 14:45, 22 May 2007 (UTC)

Image sizing

There's been considerable discussion at Wikipedia talk:Manual of Style#Images regarding bot removals of thumbnail size tags from articles. There appear to be three broad schools of opinion at present:

1. Thumbnail sizes are inherently evil because they override user preferences - including those of people with accessibility issues e.g. visual impairment. People who want to change from the default 180px should get an account and set their preferences accordingly.
2. Removing thumbnail sizes is evil. Very few readers even consider getting an account (remembering that only a very small percentage of readers become editors, and relatively few editors become account holders). We should size images so that they're easily legible to the vast majority of visitors. That often means that they need to be bigger than 180px.
3. Thumbnail sizes are a necessary evil at present because the MediaWiki 180px default size is too small for the average display. On a 1024x768+ screen (most modern PCs), 180px images are little better than postage stamps and are overwhelmed by the text. The minority of users who require small (or very large) images might be easily encouraged to register an account; we shouldn't handicap the encyclopaedia just to cater to the visually-impaired, etc., many of whom are probably already familiar with making accessibility adjustments during their internet usage. The default thumbnail size should be increased to, say, 220px, to reflect the larger average display size of modern computers.

I'm pretty much in agreement with #3. It strikes me that, ideally, two changes would please most people here:

1. Increase the default image size somewhat.
2. Allow thumbnail sizing for odd-aspect-ratio images and change the software so that user preferences override article image sizes, rather than vice-versa (is there already a setting for this somewhere?).

Opinions from a broader audience would be welcomed. Cheers, --YFB ¿ 23:25, 22 May 2007 (UTC)

• My opinion is that there should be a software solution. Editors should have the ability to make some thumbs larger (maps, paintings with small details) and some smaller (simple diagrams, etc.). Users should have an ability to set preference to see thumbs larger (if they have good monitors and Internet connections) or smaller. I would suggest syntax like [[image:..|thumb|150%|...]where the size is set as a percentage to the default image size set in user preferences. If user set default to 300px, the image would be shown as 450px, If user set the default to 100px, the image would be shown as 150px, etc. For now, I would recommend to use fixed sizes then it matter: the image clearly should be shown in the size above 180px or clearly in the size bellow 180px. Otherwise we should use defaults sizes Alex Bakharev 07:07, 23 May 2007 (UTC)

It seems to me that rather than setting pixels, the best solution would be to allow editors to set the proportion of the width of the article space that an image would take up (say 5% 10% 20% and so on) which would be uniform regardless of the monitor size. That would allow editors to set a page layout that would be constant regardless of the viewing device. Although I am not a technical person and so have no idea whether this is feesible or not. G-Man * 19:21, 23 May 2007 (UTC)

Yes, it is possible with CSS. Dynamic page layouts, by the way, can never be truly consistent. Adrian M. H. 20:52, 23 May 2007 (UTC)Just to clarify: it would take a change in the wiki image syntax to accept anything other than pixels. It fails to respect the surrounding div with any other measurement.

I like the idea of percentages. I wonder how hard it would really be to change it. ~ ONUnicorn^{(Talk|Contribs)}problem solving 20:20, 25 May 2007 (UTC)

I think it's worth mentioning a function similar to Alex Bakharev's idea has been implemented already (just a few days ago): [[Image:...|thumb|upright|...]] will display the thumb at 75% of the thumb width; this is supposed to be used for unusually high images. This factor can be changed, e.g. [[Image:...|thumb|upright=0.6|...]] uses 60% and widths are rounded to the nearest multiple of 10. (I'm not sure whether this is documented anywhere on en.WP yet--I couldn't find it.) --Dapeteばか 22:33, 26 May 2007 (UTC)

Naming conventions (Indic)

Wikipedia:Naming conventions (Indic) should not be tagged as "inactive". It is being actively linked to as guideline. It was tagged as "historical" because there was no "active debate". I find this strange, because the absense of debate does not necessarily mean the page is obsolete. It may also mean, incredibly, that there is consensus and the page is stable. dab (𒁳) 07:01, 25 May 2007 (UTC)

You appear to be correct. Be bold and remove the inactive tag! YechielMan 13:50, 25 May 2007 (UTC)

Good advice Yechiel...only by being bold can this project keep growing and changing as much as it has the potential to. Jmlk17 20:49, 25 May 2007 (UTC)

Multiple tags

I've seen a few articles lately that have multiple cleanup tags, and clog up the page alot. Could we possibly discuss a new template that could have multiple cleanup tags all merged into one cleanup tag. I am not proposing that we create a combination template for all possibilities of combinations of cleanup tags (e.g. {{unreferenced-or}}, {{unreferenced-npov}}, etc) but like This article does not {{{1}}} and is not {{{2}}}. or similar. Please discuss pros and cons of this idea. –Sebi ~ 10:01, 25 May 2007 (UTC)

I'm not in favor. I think it's helpful to list each problem separately because it makes it easier to read through them, and it's simple to remove one tag while keeping the others, or to add a new one. If you are concerned about visual clutter - and that is a valid concern - I wonder if there's a way to shrink some of the templates, as was done with Template:Uncategorized. YechielMan 13:48, 25 May 2007 (UTC)

I'm opposed as well. Not all articles need to have multiple tags. Some just need a slight wikify, while not needing to be references. It's a big step to make a page sport many different tags, and it should be a complete mess in order to do so. Jmlk17 20:51, 25 May 2007 (UTC)

See {{Articleissues}}, which was kept at TfD. –Pomte 21:13, 25 May 2007 (UTC)

Reliability noticeboard proposed

See Wikipedia_talk:Reliable_sources#Reliability_noticeboard for a proposal about a new noticeboard, a kind of RfC for discussion of reliability of specific sources.-- _{Piotr Konieczny aka Prokonsul Piotrus | talk}  17:24, 25 May 2007 (UTC)

Unclear status of Wikipedia:Reliable sources/examples

This useful page seems partially forgotten, and has no clear status, I have labelled it with 'proposed'. See also my comments at relevant discussion page about how it ties to aspects of WP:ATT/FAQ.-- _{Piotr Konieczny aka Prokonsul Piotrus | talk}  17:32, 25 May 2007 (UTC)

Edit summaries

Currently, the limit for edit summaries is 200 words. Perhaps that can be extended to 300 (or 400, for that matter) words. The reason is that sometimes, people want to provide more detailed summaries; they have to use abbreviations because of the short limit. Universe=atom^{•Talk•Contributions•} 18:28, 25 May 2007 (UTC)

I dont't know, bu I believe that is characters, not words. Reywas92^{TalkHow's my editing?} 19:24, 25 May 2007 (UTC)

I think perhaps an expansion to 250 might be in order. But 400 words in quite a lot of writing for an edit summary in my opinion. Jmlk17 20:52, 25 May 2007 (UTC)

Actually, 250 is the maximum edit summary length that MediaWiki accepts. For some reason, the edit form's textbox has its maximum length set to only 200. The number can easily be altered with JavaScript, or even better, in the software itself. Gracenotes^T § 03:07, 26 May 2007 (UTC)

Actually the current maximum is 200 characters, not words. There is no minimum. I was only thinking of having the max extended. Universe=atom^{•Talk•Contributions•} 17:55, 26 May 2007 (UTC)

I would like a maximum higher than what it is at the moment, if technically feasible (250 is just below 255, so there may be reasons why it was chosen). Increasing the edit-summary-box maximum would be helpful; I'm fed up of having to edit my edit summaries just to make them shorter.

New template for global perspectives task force

I am posting here to let the community know about the creation of a new template that is being used by the Global perspectives task force of the Project on countering systemic bias. This template will be placed on talk pages to let editors know that the task force is actively working to improve the global perspective of an article. In that sense, the template will work in concert with the existing cleanup templates, which are typically put on article pages. I am not 100 percent sure this is the right place to announce this new template, so I welcome suggestions of other places I should post this information. I also welcome any questions or comments about the template or the global perspectives task force. Thanks! --Mackabean 20:21, 25 May 2007 (UTC)

Sandbox name?

What would everyone think of changing the name of the sandbox? Right now, Sandbox gets nothing but vandalism. There are plenty of warnings that this article is not the place to play around, but people do so anyway. No article exists by the name of Edit test area, so if we renamed the sandbox to Wikipedia:Edit test area and made Edit test area a protected redirect, that might cut down on the mainspace test edits. --BigDT 22:58, 25 May 2007 (UTC)

I don't agree personally. I think Sandbox is a cool name, and it is meant to be a test area anyway, so why does it matter if someone adds some junk to it? It is reverted almost immediately anyway. Jmlk17 23:21, 25 May 2007 (UTC)

You misunderstand. The article Sandbox gets vandalism because people go there looking for Wikipedia:Sandbox. The problem isn't people vandalizing the page in Wikipedia: space - the problem is people vandalizing the article. --BigDT 23:25, 25 May 2007 (UTC)

It doesn't seem like that much vandalism. If it gets higher, just semi-protect. As people usually using it have just created an account, semi-protection will work, since editors must be autoconfirmed to edit semi-protected pages, and if I remember right, auto-confirmation takes 4 days. Any other people doing editing tests probably know they're at the wrong page. --R ^ParlateContribs_@ (Let's Go Yankees!) 23:56, 25 May 2007 (UTC)

We could introduce some sort of message that appears when you are editing the article stating "If you are making a test edit, please use Wikipedia:Sandbox" or similar. –Sebi ~ 00:05, 26 May 2007 (UTC)

Also, we can't keep reverting test edits on the article without letting the test editors be notified that they are at the wrong page. The small italic note at the top of the article doesn't seem to suffice. –Sebi ~ 00:10, 26 May 2007 (UTC)

Template for byte quantities

The current WP:MOSNUM, regarding binary prefix, recommend to "stay with established usage, and follow the lead of the first major contributor to the article." and also suggest that "The use of parentheses for binary prefixes "Example: 256 KB (KiB)". As WP:MOSNUM state , "There is currently no consensus as to whether common binary prefixes or the IEC-recommended prefixes should be used in Wikipedia articles.". That lead to chronic edit war and lengthy arguments. The acceptance of the IEC notation has been slow, both in the industry and in the public at large, and it is reasonable to think that is will still take significant time, years in not decades, before the usage is settled.

This proposal attempt to eliminate few of the most commons objections raised during the debates on this topic. These are, in no particular order

• Wikipedia is an encyclopedia and therefore exactitude and precise standard conformance are paramount
• Wikipedia is the reflect of the world as it is not as it 'should' be.
• Legacy hardware have all their reference materials written using usual notation therefore IEC notation are confusing
• Non-specialist user is confused when seeing S.I prefix used with a different value than their expected meaning

and of course, at the end of the day, a lot of the arguing is motivated by a very strong force : personal taste.

The following templates Template:KiB Template:MiB Template:GiB Template:TiB are proposed. They take 2 positional parameters. The first one is the size itself, a number. the second is an optional unit.

For example: If an editor has no preference he would defer to the template, which should reflect the then current consensus. In this current version of the tempalte version that would give: {{KiB|16}} -> 16 KB (KiB)

If an editor whish to use the traditional notation, he would use {{KiB|16|KB}} -> 16 KB

A benefit of the few extra characters is that it make apparent to any other editors that the editor knew that KB was a binary prefix in this context, and that he belive that it still should be represented as traditional notation.

But the main feature of these templates is that they are wirtten in such a way that a user can customized his environment in order to see these units in his favorite representation.. Indeed, thanks the good work of User:Mike Dillon, a small piece of javascript can be used by any user who want to see only his favorite notation.

for example:

var byteSuffixes = {
    "kib": "KiB",
    "mib": "MiB",
    "gib": "GiB",
    "tib": "TiB"
};
importScript('User:Mike Dillon/Scripts/byteQuantities.js');

to have only IEC unit displayed or

var byteSuffixes = {
    "kib": "KB",
    "mib": "MB",
    "gib": "GB",
    "tib": "TB"
};
importScript('User:Mike Dillon/Scripts/byteQuantities.js');

to have only traditional unit display.

Note that it will not impact the place where the unit HAS to be one way or the other for the article to make sens, like for instance in binary prefix, since only the text using the template will be impacted.

The proposal is as follows:

• That these template be mentionned in WP:MOSNUM
• That on pages relating to legacy hardware/software, the main editors be encouraged to use them in order to indicate the consensus on the page and to clarify to other editor that the choice of unit is purposeful and not an oversight.
• That editors in general do not fight the usage of such template, so long as their introduction do not change the normal appearance of the page (that is without any javascript helpers)
• That the existence of the technique based on javascript be mentioned so that user that have a strong opinion on the matter can satisfy their preference.

The current form of the Template is not necessarely part of this proposal. The only characteristic of the template that are part of the proposal is the use of the class attribute in order to make the javascript substitution technique works cleanly. -- Shmget 03:52, 26 May 2007 (UTC)

Images

Would someone please be kind as to find some good images for an article I made and an article I Wikified. The article are:

My created article- Gold Coast Art Centre.

The edited article- Gold Coast City Art Gallery.

Please find very suitable, good images for both this articles. Please contact me at my Talk page if you've replied to this request.

§→Nikro 15:29, 26 May 2007 (UTC)

Place {{reqphoto}} on each talk page and/or add a request for each article at Wikipedia:Requested pictures. Adrian M. H. 19:49, 26 May 2007 (UTC)

Good luck...also, this probably wasn't the right area to go looking for image requests, as Adrian was kind enough to give you a template and links. Jmlk17 21:31, 26 May 2007 (UTC)

WelcomeBot

A new type of welcomebot proposal is being discussed here.

More convenient way to discuss recent edits with other users

Currently it is not very convenient for users to identify and discuss recent edits in an article. I have a few proposals to make the "peer review" process easier, so that more readers will read and comment on recent contributions:

• To find recent edits, you currently need to go to the history page and do a comparison with a previous version. This could be facilitated by having a direct link to show changes made in the "Last 7 days" and "Last 30 days". Some edits would need to be flagged as vandalism, to prevent them showing up again 7 days later in the comparison.
• After discovering an edit that requires discussion, you currently have to start a section on the talk page, and explain which edit you're talking about. It would be much easier to have a link from the History page, allowing you to create a discussion automatically (or to take you to a pre-existing discussion). Readers of the discussion could then click a standardized link to see a "before/after" comparison for the corresponding edit, so everyone knows exactly which content they are discussing.
• When submitting an edit for an article, a user should have the option of creating a corresponding discussion thread. This would be helpful if the user feels that some improvement could be made to the new content, or if it is likely to prove controversial. It would also be courteous to give other users the opportunity to comment after removing unwanted material from the article.
• Comments posted in a discussion should drawn automatically to the attention of the user who made the corresponding edit.

Mtford 02:00, 27 May 2007 (UTC)

New forum-based format for talk pages

This proposal is related to my previous one about discussion of edits.

Wikipedia currently uses the same type of interface for editing both articles and talk pages. This seems illogical, as talk pages are not encyclopedia articles - they are forums. Most other forums on the web (e.g. Google Groups) use a thread-based format, in which contributions are automatically signed and users can only edit their own posts. In Wikipedia talk pages, it is often difficult to see where one user's comments end and another user's begin. Any indentation or insertion of comments between previous posts must be done manually, and there is no standard style for this; often in a complex multi-user discussion it is hard to tell which comment a user is responding to. Why not implement something similar to Google Groups?

Mtford 02:29, 27 May 2007 (UTC)

I think every agrees this is a good idea, and development is underway (m:LiquidThreads). It might take a while to be implemented.--Commander Keane 08:51, 27 May 2007 (UTC)

I may be alone here, but I actually believe the current talk page system is ideal. Since it is identical to the article system, working off of the blank slate of "anyone can edit" rather than delineated "threads", talk pages are able to function as the article's workshop, not only for discussion of how to improve the page but for actually hammering out the details right there as well.

I cannot see how a switch to a forum-like system could be implemented without either losing a lot of our ability to work on talk pages (rather than chat on them), or creating yet another meta-article namespace for banners, drafts, article status information, and everything else talk pages currently do. I additionally expect that the not-so-sparse layout of a forum system would annoy me to no end anyway, and believe that it would serve only to turn Wikipedia talk pages into forums, places for random chatter about a subject, rather than workspaces. In short, oppose. --tjstrf talk 09:10, 27 May 2007 (UTC)

Who is everyone? Some self-appointed group of guardians? I agree with tjstrf - this is completely unnecessary and a perfect example of change for change's sake. The talk pages are not for chat, as are fora, but for discussion about the articles. Wikipedia should not morph into yet another chatroom. There are quite enough of those on the web already. -- Necrothesp 13:54, 27 May 2007 (UTC)

Two very sensible editors, there. I strongly oppose this silly idea. What we have now is very clutter-free, very flexible, and easy to use (most fora are not particularly user-friendly). Adrian M. H. 16:57, 27 May 2007 (UTC)

See my essay User:Dcoetzee/Why wikithreads are bad for a host of reasons why we don't want to use wiki for talk pages. To answer the practical question of how to hammer out details, that can either be done on a temporary page or the individual posts could be written using wiki syntax. There's no reason to go to the unmerciful trouble of formatting our threads using wiki formatting rather than just embedding wiki formatting inside them. Dcoetzee 17:09, 27 May 2007 (UTC)

Weighted Random Article Link

I enjoy the "Random article" link on the left navigation menu, but it takes some clicking before it conjures up an article of interest. Mostly, it seems to pull up small stubs. I'd like to see a "weighted random" link that pulls up a random page selected by popularity - i.e. any page that has 100 times more visits will be 100 times as likely to be chosen as one that has only ever been viewed by its creator.

I have to imagine the wiki software has a page hit counter somewhere.