Jump to content

Wikipedia:Village pump (proposals)/Archive 45

From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Build in a list-comparer for categories.

Yes, I know I can just tee up AWB and use its list-comparer if I want to see what articles can be found in two categories, but I'm thinking of the masses who use Wikipedia on a purely piecemeal basis to research stuff. bd2412 T 04:32, 12 March 2009 (UTC)

This sounds like a job for toolserver. You might try bugging User:X! or User:Bjweeks who have a lot of tools on toolserver and might be able to make a client facing tool for people. MBisanz talk 08:22, 12 March 2009 (UTC)
The lack of Wikipedia:Category intersection is a long standing complaint. There are technical issues that make a general solution difficult. A partial solution now exists in search. One can use multiple iteration of the search keyword incategory:, i.e. search for '+incategory:"Suspension bridges" +incategory:"Bridges in New York City"', etc. to find pages that are in multiple categories. Dragons flight (talk) 17:07, 12 March 2009 (UTC)
Maybe it's my lack of technical savvy - I just don't see why it should be hard to do. The AWB listcomparer does it quite easily, why not just plug that exact code into a button on every category page? I realize that this is a tech issue, I hoped to gauge community support here before taking it up with the devs. Obviously, however, we've been down that road before. bd2412 T 17:58, 12 March 2009 (UTC)
Dude! Have you even looked at Wikipedia:Category intersection. Why the hell do I bother writing an implementation?! --Dschwen 18:11, 12 March 2009 (UTC)
 Done for the really lazy people: http://toolserver.org/~dschwen/intersection/ (so you don't have to read that page. --Dschwen 18:13, 12 March 2009 (UTC)
Don't get me wrong, I appreciate the tool, I'm just thinking of something for the masses - the people who don't edit Wikipedia, and only use it casually, who are unlikely to come across your excellent tool unless they happen upon a conversation like this one, or unless (and here's what I'm aiming for) it's built into the generic category page. bd2412 T 03:34, 14 March 2009 (UTC)
Yeah, that proposal comes up about every month (mostly on the mailing lists). The gist: with the current categorization scheme, which requires deep indexing (crawling of sub categories) this is a highly non-trivial problem (put lots of strain on the db). And I'd argue if people aren't really needing it, it should not be a high priority. My tool can be found through Wikipedia:Category intersection, so I'd think if people need it they could find it, and yet its usage is disappointingly low. --Dschwen 15:35, 14 March 2009 (UTC)

RfC at WP:SPOILER

A RfC has been request to determine whether the Spoiler guideline (WP:SPOILER) should be changed to exclude plot details that some consider to be spoilers from the lead section of an article. --Farix (Talk) 14:05, 14 March 2009 (UTC)

RfC @ Notability (web)

Requesting comment on a policy decision with Notabiliy (web). --Kraftlos (Talk | Contrib) 03:02, 15 March 2009 (UTC)

Anti-blanking rule

I propose an anti-blanking rule so that any reduction of a large article to a few lines would be blocked. This blanking (diff) of the main page FA of today should not have had to be manually reverted. Smart people have probably already come up with logic to address the corner cases but if I had to spend 1 minute thinking about a rule, it would be that articles greater than ~10K in size can't be reduced to under ~1K; and such restrictions could be tightened up more for FA articles. Tempshill (talk) 23:16, 9 March 2009 (UTC)

It might not be a good idea. Imagine: one user adds lots of irrelevant text (or patent nonsense, or something like that) to a stub. Wouldn't such rule prevent another user from repairing the damage? --Martynas Patasius (talk) 23:57, 9 March 2009 (UTC)
No, this is a bad idea as it would impair subjects trying to removed BLP violations about themselves who do not know the editing rules, see [1] and Wikipedia:Requests_for_arbitration/Badlydrawnjeff#Summary_deletion_of_BLPs. MBisanz talk 00:11, 10 March 2009 (UTC)
I think these three objections are pretty easy to fix. 1. Lots of irrelevant text added to a stub would still be subject to "undo" and reverts. 2. and 3. An attempt to (essentially) blank a page would be rejected with a rejection page stating, You've been prevented from removing a large amount of text from this article because experience has shown that such removal is usually vandalism. If you are trying to remove information in an article about yourself, please contact our "Problem With Biography Of Living Persons" staff via e-mail.
Actually, there seem to be even more possible exceptions that cannot be worked around easily... For example, what if an article has to be redirected or merged into another one? And what if much of an article's text has to be split somewhere else? And would it apply to the talk pages or Wikipedia namespace (archiving does remove lots of text)? --Martynas Patasius (talk) 00:58, 13 March 2009 (UTC)
Good points. Redirects and merges would all get blocked. Possible options would be to actually allow the blanking if it's replaced with a valid redirect - I assume that 99% of blanking vandals are unfamiliar wtih redirects - or implement a queue of "probable blanking edits" that an admin would have to approve before the edit is applied. Removing a lot of text to go into a subarticle could use the queue also, though I think an effective blanking filter would target 90% text removal and I think splitting an article would not approach 90%. Talk pages probably wouldn't apply. Tempshill (talk) 17:35, 13 March 2009 (UTC)
Some version of this would seem extremely likely once the abuse filter is online. Dragons flight (talk) 19:07, 10 March 2009 (UTC)
The problem that led to this proposal is currently being handled quite efficiently. Usually, such massive blankings are reverted by bot. -- Blanchardb -Me•MyEars•MyMouth- timed 20:33, 10 March 2009 (UTC)
Yes, and that bot's logic can be placed in the abuse filter so the bad edits (that would be automatically removed anyway) aren't allowed to occur in the first place. I don't know exactly what criteria the bot is using, but it seems quite effective. Dragons flight (talk) 22:27, 10 March 2009 (UTC)
Note that the Abuse filter isn't a complete replacement for antivandal bots. It can do math and some string operations. Its not a full programming language. Mr.Z-man 19:59, 11 March 2009 (UTC)
This is true, but I think the blanking logic (at least the examples I've seen) is simple enough to implement in the filter. (Unlike the page move logic BD2142 suggests above, which could only be partially accomplished with the current filter code.) Dragons flight (talk) 21:00, 11 March 2009 (UTC)
We already have a policy against disruptive editing, I don't think we need a policy for each type. Blanking is easy to undo, we can use common sense when deciding how to deal with it. I don't think blocks for this should be automatic. Automatic reverting is just fine(as long at the automaton does not edit war). Chillum 15:11, 13 March 2009 (UTC)
Auto-reverting is certainly a perfectly fine solution as opposed to a pre-emptive block. Tempshill (talk) 17:35, 13 March 2009 (UTC)

For the record, a redirect requires an absolute minimum of fourteen characters: # r e d i r e c t [ [ x ] ] . Even the smallest possible template requires five characters: { { x } } . So far as I know, there are no single-character templates that could legitimately constitute the content of a mainspace page. We should at the very least prevent an edit that reduces a mainspace page to four characters or less, because there is simply no legitimate reason why any mainspace page would ever contain fewer than five (and, realistically, fewer than thirteen) characters. This will deter vandals whose mode is to click "select all" and then "delete" and "Save page". bd2412 T 22:20, 13 March 2009 (UTC)

This would stop page authors blanking their own new articles (typically leading the use of CSD-G7), which is a useful way of removing some of the less helpful new pages. Blank pages do not stay that way for long, as either Cluebot spots them or they head the list of short pages. --Rumping (talk) 12:03, 16 March 2009 (UTC)
Should be easy enough to implement the rule only where someone other than the person doing the blanking has edited the article. bd2412 T 12:10, 16 March 2009 (UTC)

Wikipedia:SandBook?

This new book thing seems nice, but I'd quite like to have a play around with it without ruining anything already in place (e.g. accidentally deleting existing Wikipedia:Books/Foo pages or flooding Wikipedia:Books/ with new ones); hence, can a WP:SB-type page be created for assembling, saving and disassembling test books? Thanks! It Is Me Here t / c 18:19, 14 March 2009 (UTC)

You could just as well use a user subpage. Right? §hepTalk 19:08, 14 March 2009 (UTC)
A general sandbox would be better in the long run, though, so that more casual users might be able to take advantage of it too. It Is Me Here t / c 18:17, 15 March 2009 (UTC)

New tag to indicate number of edits (and by whom)

This is NOT an idea I am suggesting for all the large number of articles in the English Wikipedia, just an idea which I am suggesting for a select number of articles which get edited frequently. Perhaps we could have a tag to say how often that article has been edited in the past four months or so. The same tag could also say whether these edits are by users who are anonymous editors or users who have confirmed uesrpage names, and how many of these edits are by the former, how many by the latter. There seems to be an unspoken assumption that edits are less likely to be works of Wikipedia: Vandalism if they are done by users with usenames than they are done by those with mere IP addresses, so maybe this would help us to appreciate whether an article is likely to have had recent vandalism edits, or has been edited by reliable and trustworthy users. Certainly the assumption that users with userpages rather than users who just give IP addresses appears to be behind Wikipedia: Protection policy. ACEOREVIVED (talk) 21:07, 12 March 2009 (UTC)

The thought behind (semi-protection policy is that newer users are more likely to be vandals; that's true of newly created user accounts as well as IP addresses (which don't necessarily have a single owner over time).
More to the point, if you click the "history" tab for a page, you'll find a link (at the top) for "Revision history statistics". That appears to be the sort of information you're suggesting would be useful. I'm not at all convinced that it would be - knowing, for example, that 43% of the edits to an article were by IP editors implies what, exactly? In any case, I don't think this information should be available directly on an article page; that would distract readers, most of whom wouldn't understand it (the number of readers of Wikipedia compared to the number of editors is roughly 1000 to 1). -- John Broughton (♫♫) 16:57, 17 March 2009 (UTC)

Search tweak

Proposal for a search tweak. I was looking for the legal term "stay" and typed "stay (law)" in the search field and clicked Go. I was brought to the Search page where none of the 20 top search results was what I was looking for. I then went to the stay article, which is a disambig page that did indeed have a link to the article I was looking for: Stay of execution.

My proposal: If someone types "word1 (word2)" in the search field and clicks Go, and there is no "word1 (word2)" article, but there is a "word1" article, then the Search results' first result should be the word1 article. Leave all the other results in the list; just insert the "word1" article as result #1.

I acknowledge this search tweak only benefits users who are already familiar with the Wikipedia convention of using a parenthetical to distinguish topics. Tempshill (talk) 17:29, 13 March 2009 (UTC)

Comment I don't know what you mean. When I search "stay (law)" I get 1. Automatic stay 2. Stay of execution. I think the search engine searches the text and finds the most relevant with nearest occurrences between stay and law. Don't see the problem --Diaa abdelmoneim (talk) 16:04, 14 March 2009 (UTC)
I was referring to when the user clicks "Go", not "Search". Tempshill (talk) 17:11, 17 March 2009 (UTC)

Install DynamicPageList extension

After looking through WikiNews, I was impressed by the DynamicPageList extension, and it looks like it would be useful here. It is like a "smart" version of the <categorytree> tag, in that it can show articles in one category, but only ones that are not in another, or show a list in a different order, or many other things. It seems like it would be a benefit here. What do others think? Xclamation point 17:29, 15 March 2009 (UTC)

New proposal for Wikipedia: What Wikipedia is not

I have a new proposal what we might decide to have in Wikipedia: What Wikipedia is not. How about a section here entitled "Wikipedia is not a series of book, television, radio programme, film or music reviews"? We could include something to the effect of "Material on a new film (for example) should be neutral, stating the film's director and cast, but not offering a critique of the film, as this would fail NPOV. We might also add that there could be place somewhere on the web for review-type articles, but Wikipedia is not that place. ACEOREVIVED (talk) 21:35, 15 March 2009 (UTC)

Proposed trial implementation of flagged revisions

It is proposed to run a trial of Flagged Revisions at Wikipedia:Flagged protection and patrolled revisions. The proposal is divided in two parts:

  • Flagged protection: an article can be 'protected' by an administrator so that the version viewed by readers by default is the latest flagged version. This is a modified version of the original flagged protection proposal.
  • Patrolled revisions: a 'passive' flag used to monitor articles, especially blps, for vandalism, blp violations, pov pushing, etc, that can be used for all articles, but has no effect on the version viewed by readers.

The proposals are independent but supplement each other. They involve the creation of a 'reviewer' usergroup. This implementation can support secondary trials. The main trial should run for two months, then a community discussion should decide the future of the implementation. Cenarium (talk) 22:33, 15 March 2009 (UTC)

I strongly support this proposal. {{Nihiltres|talk|log}} 05:07, 16 March 2009 (UTC)
Seems reasonable to me. --MZMcBride (talk) 05:21, 16 March 2009 (UTC)
Thanks for your supports. There are still details to work out on the talk page (before the likely inevitable poll), where we can centralize discussion. I added this to WP:CENT. Cenarium (talk) 15:38, 16 March 2009 (UTC)
The inevitable poll is now active. {{Nihiltres|talk|log}} 18:08, 17 March 2009 (UTC)

translating references in other languages

I'm proposing adding a google/msn/yahoo translation link to references that are in other languages. Maybe ask for bids from yahoo google and msn about which one would be used for translation. --Diaa abdelmoneim (talk) 09:44, 17 March 2009 (UTC)

Image Renaming rights for Autoconfirmed Users

I'm proposing that any autoconfirmed users be given the File (aka Image) renaming/moving rights. The reasons for this inculde:

(a) There is no more risk involved in this compared to the users having the rights to move articles and templates like they already do.
(b) For files that have the function abused, they can be protected the same way as any other article/template that experience this.
(c) This can also reduce the "backlog" at {{Rename media}} as well, which currently contains about 2509 transclusions. Peachey88 (Talk Page | Contribs) 12:22, 17 March 2009 (UTC)
I'm guessing Brion enabled it for sysops only because the feature isn't that extensively tested in a production environment. So enabling it for sysops only is more of a controlled large-ish scale test than an attempt to prevent abuse. Mr.Z-man 16:08, 17 March 2009 (UTC)
I do not know about autoconfirmed, but this feature should be given also to bots. Ruslik (talk) 16:36, 17 March 2009 (UTC)
I propose we hold off on this until the bugs get sorted out. Right now, there are some pretty major bugs with image redirects that mean three out of my four bots won't work right. --Carnildo (talk) 21:53, 17 March 2009 (UTC)
Yes, for bot's, but from the bugs i've seen at VP:T theres no issues for users that wish to do it, and we can easily tell the B.A.G. not to approve any bots for this task. 203.25.140.97 (talk) 01:21, 18 March 2009 (UTC)

All CSD-tagged pages should be marked as patrolled

  • Problem: Pages/articles tagged for speedy deletion are not marked as patrolled, resulting in the duplication of human time.
  • Causes: "Manual" CSD-tagging; (non-admin) resurrection of previously deleted pages, complete with CSD tags.
  • Proposed solution: I would think that this is fertile ground for bots, though for maximum time savings the bot would have to check every edit for the addition of SD templates and react quickly (like Cluebot does with vandalism).

I would like to propose the above here in the open, because I'm aware that a large number of editors, including some very dedicated to the task, patrol pages and I would like to know what they think. AFAIK, it is within the bounds of bot technology, so what is really needed is good reasons why (or circumstances when) pages shouldn't be tagged as patrolled (which you are more than welcome to list below so I can feel really stupid! ;) ) - Jarry1250 (t, c) 19:53, 17 March 2009 (UTC)

Agreed - Twinkle automatically patrols any page if the user tags it for deletion using the "csd" utility, btw. ╟─TreasuryTag►contribs─╢ 20:02, 17 March 2009 (UTC)
Twinkle currently only does so if you're coming from the new page log, and it can't patrol it unless bugzilla:15936 is worked on. --Amalthea 21:34, 17 March 2009 (UTC)
I don't see where the bug comes into it, mine works fine... :p ╟─TreasuryTag►contribs─╢ 19:05, 18 March 2009 (UTC)
(ec) I could add this to my current CSD enforcment BRFA if there is community consensus for it. —Nn123645 (talk) 20:03, 17 March 2009 (UTC)

Voluntary Review Page for New Articles

How about a page where [primary new] users could post their article ideas, and get guidance/seek consensus from members of the community if the subject meets the criteria, and, if so, what to do to prepare reliable, independent sources for the article. This would help to reduce the backlog of speedy deletion candidates by well-meaning writers, and would reduce the backlog at AfD. I'm not sure if this exists or not. Any thoughts? Jd027talk 02:17, 18 March 2009 (UTC)

See Wikipedia:Requests for feedback and WP:AFC. MBisanz talk 09:59, 18 March 2009 (UTC)
Jd027, consider yourself a really intelligent guy for hitting AfC on the head without even knowing it existed! ;-) - I probably never would've come up with it, personally. Well done :-) ScarianCall me Pat! 10:08, 18 March 2009 (UTC)
Actually, neither of the suggested links is for article ideas by registered editors. But we do already have a page for exactly that: Wikipedia:Drawing board.
In general, it's always a good idea, for new proposals, to check the Editor's index to Wikipedia. In this case, you would have found the Drawing board link within the topic "New articles". -- John Broughton (♫♫) 19:03, 18 March 2009 (UTC)
Hey, good enough for me. Thanks everyone for the comments. They're appreciated. Jd027talk 22:24, 18 March 2009 (UTC)

Requested new category feature

(following on from Wikipedia:Help_desk#categories) I would like to request a new category feature - so that a category can appear at the bottom of a page (ie as a link to the category in the 'category box'), but not have the page be added to the category listing.

The reason for this is due to some articles having multiple possible titles - which 'belong' in different categories. Currently the accepted method is to categorise the redirect pages, which works, except the linking is unidirectional - eg the page appears in the category listing but the category does not appear on the readers page.

I see two possibilities as a solution:

  • Keep the current method as described at Wikipedia:Categorizing redirects and add the ability to add categories to a main page as described above (eg non listed ones)
  • Alternatively a new categorisation method eg [[Category:categoryname|sortname|NameAsItAppearsInTheCategoryListing]] (the third field solving everything.)

(I believe this has been requested before).Thanks very much.FengRail (talk) 12:58, 18 March 2009 (UTC)

Portal tags: should they be nonprintable

When printing articles, we currently exclude Wikipedia elements such as the sidebar, navigational boxes and the like. Should portal tags be non-printable? --—— Gadget850 (Ed) talk - 14:09, 13 March 2009 (UTC)

Yes, IMO. We can do this by adding the "noprint" class to {{portal}}. Happy‑melon 16:15, 14 March 2009 (UTC)
 Done --—— Gadget850 (Ed) talk - 13:10, 19 March 2009 (UTC)

Dash-fixing bot

How would it be to have a bot that automatically corrects double-hyphen dashes to correct em dashes? —Jchthys 16:54, 21 March 2009 (UTC)

That's the sort of thing that AWB is good for. There may be some situations where the double hyphen is intended (for example, in the C programming language). So it takes a human to double-check it. — Carl (CBM · talk) 17:34, 21 March 2009 (UTC)

Namespace for books

The book extension being now available, users can create books through Special:Book, currently either in their userspace or in subspace of Wikipedia:Books. As discussed at WP:AN and Wikipedia talk:Books, this system generates inappropriate pages such as attack and spam pages, as it's very easy to create a page through Special:Book, then edit it. So it's proposed that instead of storing community books in subspace of Wikipedia:Books, they are stored in a specific Book: namespace. This would allow to detect and review new books using Special:NewPages, search books, use special system messages... Specific CSDs could also apply to this namespace, see discussion at WT:CSD#G13 Books, and the entire namespace could be noindexed. Cenarium (talk) 18:50, 3 March 2009 (UTC)

  • Oppose - Wikipedia doesn't need another namespace, and it doesn't need "books" as such a vital operational function etc. I don't see what's wrong with the current system... ╟─TreasuryTag►contribs─╢ 19:05, 3 March 2009 (UTC)
    The problem is that 106 books have been created in project space in a few days, and 52 of them have been deleted (admin link). So basically, one book out of two is inappropriate, and as the number of books rise, it'll become more and more difficult to detect inappropriate pages (attack, spam, copyvios, ...). Putting them in a namespace would be the only solution to get track of them correctly, but it's too much time and effort, and resources invested for very little gain, so I think we should altogether disallow book creation in project space, and only create a few example books for readers. Cenarium (talk) 17:38, 4 March 2009 (UTC)
  • Oppose any further implementation of "books" until we stop promoting the sales of the books. PediaPress stands a lot to gain from this and Wikipedia itself gets kickbacks from it. Wikipedia isn't a business and shouldn't sell anything. Themfromspace (talk) 23:17, 3 March 2009 (UTC)
  • Oppose - We don't need such a namespace. We can apply B# CSDs even without a separate namespace - we don't have a Redirect: namespace. עוד מישהו Od Mishehu 07:46, 4 March 2009 (UTC)
  • Support. Actually kinda does make sense. ViperSnake151 13:01, 4 March 2009 (UTC)
  • I actually agree that books aren't essential at all, but then we should rethink to disable the automatic creation of books in project space that I've proposed here. Otherwise, we won't be able to properly detect inappropriate books. Cenarium (talk) 14:10, 4 March 2009 (UTC)
  • Support this will help regulate Books. as a side note, I still don't see how Books will improve navigation in the wiki, we already have categories (and sub categories), see also sections, and wikilinks in the article. Books will only split these efforts into even more pages. --Nezek (talk) 18:02, 4 March 2009 (UTC)
  • Oppose This proposal is premature. Currently we only have around 60 books on subpages of WP:Books—not enough to justify a new namespace. Ruslik (talk) 19:47, 4 March 2009 (UTC) Week support The number of books has increased, but it may be still too early to create new namespace. Ruslik (talk) 19:11, 15 March 2009 (UTC)
  • Support. Namespaces are cheap, and considering that many of the books will be used by new users, a bunch of extra weird stuff in the URL and page title will just confuse them. Usability is what matters here. I don't buy Cenarium's arguments; tracking problematic books of equal difficulty in both locations. Dcoetzee 00:47, 5 March 2009 (UTC)
I don't understand what you mean, I said it would be easier to track books if they had their own namespace. Cenarium (talk) 18:37, 5 March 2009 (UTC)
  • I started this discussion to see what was the views of the community on this, but developers will certainly require a strong consensus and more than a few dozens pages to create a namespace, especially after the table namespace. An early solution to this problem is to restrict the creation of books in project space to autoconfirmed users, which is under implementation. We can reconsider the creation of a namespace at a later date. Cenarium (talk) 18:37, 5 March 2009 (UTC)
  • Support this would make searching for books much easier and logical. Instead of writing Wikipedia:Books/Cambodia you'd write Books:Cambodia. The Books system is entirely out of the scope of project pages, article pages and template pages. Having their own namespace would be more logical and intuitive. --Diaa abdelmoneim (talk) 18:55, 9 March 2009 (UTC)
  • Support, but not as the default location - Just like article space, I'd like to see the ability to create and maintain books in userspace under a different set of rules to the mainspace. I believe that books should only go here if they are moved by the author, or specifically created there. — neuro(talk) 20:38, 9 March 2009 (UTC)
  • Comment: Putting these books in their own namespace does seem like a good idea in terms of organising the 'pedia. I'm not too keen on the existence of the books to begin with at the moment and I feel they need to prove themselves first. If they do add to the project then I will support the creation of a new namespace for them, if they just turn into a fad or something trivial then their is no point in cluttering the place up and in that case I'd oppose this. -- Cabe6403 (Talk•Sign!) 20:43, 9 March 2009 (UTC)
  • Oppose The books featurre is much too small for its own namespace. It would be unnecessary. Reywas92Talk 00:28, 10 March 2009 (UTC)
  • Support - No need for all this drama just for one silly namespace. Glacier Wolf 02:06, 10 March 2009 (UTC)
  • Support as clear demarkation for a unique type of content. --Der Wohltempierte Fuchs (talk) 18:31, 10 March 2009 (UTC)
  • Support As I can see the amount of books created increasing dramatically over the next year or so, I think a separate namespace is the way to go. §hepTalk 21:40, 10 March 2009 (UTC)
  • Support, makes a lot of sense. Exactly what I would expect to see namespaces used for. Powers T 13:06, 11 March 2009 (UTC)
  • Support, makes sense to me. Lankiveil (speak to me) 08:18, 12 March 2009 (UTC).
  • Support The Help and MediaWiki namespaces all have under 1,000 pages, so size isn't an issue. And given the way this feature can be expanded and used by anyone, a namespace would be very useful in managing it. MBisanz talk 08:20, 12 March 2009 (UTC)
  • Support - I don't see any significant issues here. –Juliancolton Tropical Cyclone 14:35, 13 March 2009 (UTC)
  • Question when can this be implemented and who would implement it? As I can see there is consensus on creating the namespace, so is there an admin to apply it?--Diaa abdelmoneim (talk) 06:49, 17 March 2009 (UTC)

Allow show preview when uploading images

I propose that show preview be enabled when uploading images. The reason for this is, it's very easy to mess up the templates and or FUR for new users. Instead of previewing the uploaded image this image file:Your image here.PNG could be show instead. --DFS454 (talk) 14:47, 23 March 2009 (UTC)

The magnifying glass button next to the upload file button provides a preview of text for new Image/File pages. —Ost (talk) 15:38, 23 March 2009 (UTC)
I don't see it --DFS454 (talk) 16:10, 23 March 2009 (UTC)
I'm sorry. I think it's a wikEd function that remains even if disable wikEd and don't reload the Edit page. It does appear that there is no preview if you don't use wikEd. —Ost (talk) 17:07, 23 March 2009 (UTC)
Ah right I see. I guess that makes this proposal pretty redundant. --DFS454 (talk) 21:33, 23 March 2009 (UTC)

To avoid wikipedia being forked to a "At last, a one-paragraph briefs encyclopedia"..

..I propose keeping opening paragraphs less that 1 book. There are articles that takes 3 to 5 fat paragraphs to get to contents. --AaThinker (talk) 19:55, 23 March 2009 (UTC)

This appears to be covered by the guideline Wikipedia:Lead section. Dcoetzee 20:01, 23 March 2009 (UTC)

Bot detagging of Category:Wikipedia featured articles in other languages - a good idea?

WikiProject Echo, which appears to be inactive (I inquired on the talk page today), has tagged tons of articles with {{FAOL}}, indicating that there is a foreign language FA from which content might be translated. The problem is, these tags have been applied indiscriminately, with--for instance--it being suggested that we translate United Kingdom from Tamil Wikipedia. It appears that all articles identified as FAs at a certain date were tagged, without consideration as to whether the other article is actually better than ours. We already have a way of tracking whether foreign-language FAs exist - the little interwiki star icon. We also have a system for tagging requested translations (e.g. {{Expand Spanish}}, which has a fa=yes parameter). Of course, it might be profitable to search for articles that genuinely should be translated, but doing so from scratch would be much faster than analyzing all the currently tagged articles. I propose that these all be removed by bot, but wanted to get others' opinion before placing this at WP:BOTREQ. I'll post a message at WP:ECHO seeking input here. Calliopejen1 (talk) 01:41, 12 March 2009 (UTC)

The thing is, maybe an editor fluent in Tamil and English very well could improve the English United Kingdom entry with information from the Tamil version. I think this is sort of a case of WP:AINT. The tags being there certainly don't hurt the project in any way, and an enterprising editor very well may improve the article with these other language FAs. Evan ¤ Seeds 02:12, 12 March 2009 (UTC)
Seriously? Have you looked that the standards Tamil Wikipedia has? And who is likely to want to improve articles on the UK - editors in en.wiki or ta.wiki? And even if the Tamil article was sourced, do we want sources in Tamil for an article about the UK? Calliopejen1 (talk) 12:15, 12 March 2009 (UTC)
Well, no, I can't say I have looked at the Tamil standards, as I don't speak Tamil. And if the sources are good sources that provide something that English sources can't, yes, we do want them. Now yes, in this case it's unlikely that anything the Tamil wikipedia can offer the English one much about the UK, but so what? There's just a not very useful tag. If someone who speaks Tamil looks at their and determines that it doesn't have much to add to en.wiki's United Kingdom, then there's no problem with removal of the tag, but this doesn't mean that all of the tags should be systematically removed. (And in fact, looking at the article myself, it doesn't look like it can offer much to the English version directly: no inline sources, and AFAICT, no specific sources at all, just generic websites [parliament.uk, for example]) Anyway, the point about the general case remains: it's quite reasonable to say that an FA in another language can be used to improve upon an English article. It may not stick with all languages, or with all articles, but I think it's a pretty reasonable assumption. Evan ¤ Seeds 12:44, 12 March 2009 (UTC)
If we want to categorize all foreign FAs indiscriminately, why not just use {{FA link}} to create categories? This tag doesn't seem to add any value to that template. Calliopejen1 (talk) 12:51, 12 March 2009 (UTC)
Because {{FA link}} is a permanent structure (unless the foreign language FA is delisted), whereas these tags should most certainly not be permanent. How these would optimally work is that an editor would see the tag, assess whether the foreign FA actually has content that can improve upon the English version, and either add in the better content himself and remove the tag, or remove the tag due to the foreign FA not having any better content. Evan ¤ Seeds 13:04, 12 March 2009 (UTC)
But as a matter of practice, these don't get removed. The Tamil UK request has been on the article's talk page since 2005. Calliopejen1 (talk) 14:08, 12 March 2009 (UTC)
While our standards for FA may be higher than some other Wikipedias, I believe it is quite likely that some FAs in other Wikipedias are better than our non-FA (even if GA) version. It's probably a good thing that there's a category where people who can translate from Tamil to English can find the articles which are FA in Tamil but not in English. The bot has no way of knowing which article is actually better; however, I think the benifits from the mass tagging is more than the problems from false positives. עוד מישהו Od Mishehu 06:11, 12 March 2009 (UTC)
Except that the problem is that EVERY fa was tagged with this! I would estimate a "false positive" rate of 95%, especially among smaller languages. If we want every FA to be tagged with a banner like this, we could always re-add them by bot. Of course, a removal bot has no way of knowing which are better, but removing them all would be more accurate than keeping them all. This is part of an initiative I have taken to overhaul and consolidate our translation systems. Tagging these with a standard tag would allow all the articles to be categorized in the same schema. (See Category:Articles needing translation from foreign-language Wikipedias.) Normally I might try to use AWB and just replace these with the new tags. But since the tagging is totally worthless and misleading as a general matter, I don't think I should do this. Calliopejen1 (talk) 12:14, 12 March 2009 (UTC)
To provide an example of how useful these tags are, I translated Trabancos River (now a good article) from Spanish and would have had no way to find this article without the faol tag, barring trawling es:Wikipedia:Artículos destacados. Sure, the tags may not be useful in all cases, as in the Tamil Wikipedia-United Kingdom example, but in many cases they are. All the tag and resulting category does is inform us that the article is featured in x language. So you want to translate into English from x? But you find that the featured article is crap? Move along to another. There's no harm and much utility in these tags. By contrast, it would be harmful to remove all these tags. They don't just just inform people that the article is featured in another language but they help germinate the idea of translation. Of course I happily agree that it would make the identify-a-good-translation-target task easier if the tags were applied with more discrimination. However, you aren't proposing any winnowing process, just removal. Take a look at Mi'kmaq verses de:Mi'kmaq which I found in seconds after looking at the master category. How would anyone know that there it might be a very good idea to visit the German version to improve this article without the tag? Finally, I'm also not sure there aren't other reasons besides translation that might make having all articles featured in other languages tagged in this way useful—even Tamil's version of United Kingdom. Since English is spoken by so many, it's quite possible a Tamil language speaker will find the Tamil Wikipedia version of United Kingdom, see that the Tamil version is featured but not as good as the English version, and go improve it. We owe comity to all language versions.--Fuhghettaboutit (talk) 12:57, 12 March 2009 (UTC)
I agree that it is useful to have translation requests. I make this proposal as someone who has applied probably thousands of translation requests and is trying to make the translation system as easy and useful as possible. I have been going through other languages' FAs and setting them up for translation, e.g. February 1963 Iraqi coup d'état. I just think the current system is a failure and should be started from scratch. Also, using tags here as a way to somehow encourage translation to Tamil seems like the wrong approach. (And if that were the case anyways, we should be tagging articles that are even worse in Tamil, not the articles that are already FA there.) Calliopejen1 (talk) 14:07, 12 March 2009 (UTC)

Mmm there are a lot of ones that are invalid. I think they need removing, it shouldn't have to be done manually. Dr. Blofeld White cat 13:59, 12 March 2009 (UTC)

My favorite FA is lmo:Grupp 4 de la taula periòdica. I had a look because I wanted to improve the Group 4 elements article and I thought that chemistry is the same allover this small planet. The good thing is that you lose only a few seconds and than you do not translate a article of that quality to improve the english one.--Stone (talk) 18:57, 18 March 2009 (UTC)
Mention of WikiProject Echo in new wp:HSITES just got me interested, and i found my way here. I just browsed through one category and find it very helpful, allowing me to consider which article i might transfer from that language. Calliopejen1 could organize some manual review, one language at a time, out of WikiProject Echo. If the original categorizing was done once and not updated, perhaps it should be updated now, to remove articles no longer FAs in the other language and to add more recently designated FAs. But it seems wrong to rip out these categories by bot. doncram (talk) 16:01, 24 March 2009 (UTC)

Genre troll noticeboard

Proposal: A noticeboard in WP space is required to report and deal with the overwhelming number of SPA genre trolls/IPs that make rapid and persistant POV genre changes. I would suggest that such a noticeboard would be modelled on WP:3RRN for efficiency and "cleanliness".
Problem: There is a major genre troll problem on music articles which I describe in more detail here.
How would it work: The community would submit mini-reports of users who fit a specific and well defined criteria (e.g. genre changes without discussion, POV edit summaries ("I think they sound like this..."), no sources used or offered etc. etc.), and others in the community would act on it as they see fit.
How would the community deal with the genre trolls: As I outlined in my essay, many of these "trolls" are new users who would perhaps benefit from a gentle note (and a welcome template) to guide them in the right direction. Persistant "offenders" would, just like how we deal with vandals, receive a stronger warning, which would lead to blocking if the situation did not improve.
Existing forms: Myself and a few others already use User:Utan Vax/Genre troll IPs as a "base of operations" to keep tabs on known genre trolls. This page is only effective up to a point: 1) It needs a wider audience and support from the community. 2) There needs to be more than just one admin (me) going through it and making decisions.
Background reading: User:Realist2/Genre_Warrior
Any thoughts, suggestions, and/or criticisms are very much welcome. Thanks and kind regards, ScarianCall me Pat! 17:50, 12 March 2009 (UTC)

Per this discussion, I endorse the proposal and encouraged Scarian to bring the issue here. There is a systemic problem with the infobox of music related articles, it seems to attract thousands upon thousands of Genre Warriors, very much like flies are attracted to poo. There is one very easy method of resolving the problem, remove the genre parameter from the infobox. It was done, but there was a revolt. Most agree there is a severe problem, but no-one could agree upon how to curb it. And so, it seems, we need to be more proactive. As a side note, protecting articles from genre trolls is time consuming. Editors have to watchlist multiple article and mass revert. Our time could be spent better elsewhere. We need a solution. — R2 18:11, 12 March 2009 (UTC)
Oppose, seems redundant to the Administrator's Noticeboard. ViperSnake151 21:50, 12 March 2009 (UTC)
Oppose - This seems like an incredibly over-specific noticeboard. Not only is it for a specific type of article, but for a specific part of those articles. I would be worried with such a focus on one thing that the majority of users don't care about that it would become entirely run by a small group of people and turn into a little cabal making up their own rules, except it would be in a Wikipedia: namespace page, so it would look "official." I also agree with ViperSnake151, is there any reason why the current noticeboards are unable to handle this? Mr.Z-man 23:43, 12 March 2009 (UTC)
Support - I think this is an overdue suggestion. Posts regarding this sort of article trolling usually get ignored at the regular administrator notice board because at first glance they simply look like a content dispute. IP trolling and single purpose accounts like this example link are very common and having a dedicated noticeboard for them would be beneficial. Fair Deal (talk) 00:14, 13 March 2009 (UTC)
Mr.Z-man, I think you're wrong about the little cabal thing. Do you have previous experience of that? Can you show me something that would prove to me that that projection would actually occur? It seems like an assumption of bad faith, in my opinion. Re: ANI. How many genre trolls have been reported to ANI? Do users even know if it's acceptable to bring such an "apparently" "small" "thing" to ANI? Did you join in the discussions at Wikipedia talk:WikiProject Music and see the sheer amount of users struggling with genre wars? Maybe you don't know how big the problem is because you just edit a completely different area of Wikipedia? ScarianCall me Pat! 01:06, 13 March 2009 (UTC)
I deal with genre warriors all the time, I have brought the issue up at ANI once and the post was ignored. People who don't edit music articles don't understand how disruptive it is. — R2 01:57, 13 March 2009 (UTC)
My sentiments exactly! ScarianCall me Pat! 02:03, 13 March 2009 (UTC)
And if the reports are made on a separate noticeboard that's somehow going to change? No, it'll just get less oversight by putting it on a separate page. As for the cabal thing, it happens a lot with smaller to medium-sized wikiprojects. The project talk pages are populated almost entirely by people who agree with each other on everything related to the project. There were similar problems with WP:CSN which eventually led to it being shut down. It was given 5 months to improve after concerns were initially raised, it didn't, so it was closed. If the discussions are held on a more visible board, they at least get reviewed by more people even if they don't comment. The hostile response to my comment seems to confirm my opinion. I oppose your proposal, so you accuse me of acting in bad faith (do I have some reason to dislike you? Am I supposedly supporting the "genre trolls"?) and basically tell me that my opinion is worthless ("Did you join in the discussions...", "Maybe you don't know...", "... you just edit a completely different area..."). If you don't want opinions, don't ask for them. Mr.Z-man 03:53, 13 March 2009 (UTC)

(Outdent) In order of what you wrote, Z-man:

  • Re: "...separate noticeboard..." - There are a very large amount of music articles out there with disputes over genres every single day. The idea aims to streamline and avoid the larger noticeboards for efficiency; not for some little bit of supposed power.
  • Re: "...cabal thing..." You're using results orientated thinking. Whilst not necessarily a bad thing; it cements the mind set: "If it's happened before then it will happen again." Is what you're saying, right? You flip a coin 10 times and it lands on heads every single time. What's the chance of it landing on tails?
  • Re: "...populated almost entirely with people who agree with each other..." That's an odd statement to use to support your argument. How is it wrong for people to agree with each other? It's a subjective observation anyway.
  • Re: "...hostile response..." - No, sir, you are mistaken. You came here. You said "...I would be worried... it would become entirely run by a small group of people and turn into a little cabal making up their own rules..." - If that's not hostile in itself then I don't know what is. I believe my reaction to be perfectly well balanced and perfectly natural. If I "contradicted" (You haven't, really) one of your ideas I would not expect you to be happy about it, would I? I spent a long time writing this and you expect me to be pushed over and not be, in your own words, "hostile"?
  • Re: "...basically tell me that my opinion is worthless..." - I did not in any way suggest that and I find it rude that you would come to that conclusion. If I'm looking for support for an idea, would I go and insult the very people who could make it happen? It's just not logical, friend! :-) ScarianCall me Pat! 15:45, 13 March 2009 (UTC)
Okay, you asked my for evidence, then when I provided it, you say that this isn't something that can't be predicted with evidence, and that things like noticeboards should be treated as purely random events that are better predicted using probability. This isn't a coin toss, its people. People act in predictable ways. So when they repeatedly do one thing, it only makes sense to assume that given the opportunity, they will do it again, not that they will do the opposite just to change things up.
Its not a problem when people agree with each other. It can be a problem when they agree about everything. They create guidelines that may not have the best interest of Wikipedia in mind, they overwhelm deletion discussions for articles in the project, etc.
Your reaction is well-balanced??? You accused me of acting in bad faith because I disagreed with you! How on earth is that well-balanced? If that's your natural response to disagreement, you really need to work on your people skills. Mr.Z-man 18:04, 13 March 2009 (UTC)
Predictable? Yes but only in fixed events where predictability is actually measurable. What I'm saying is that your "evidence" (your words, not mine), is wholly subjective. You need to interpret it to be evidence. Interpretation requires a subjective perception. Your interpretation is not fact. You think ANI is predictable? Where ever you go you'll meet cabals... in life, on Wikipedia, in a pet shop... where ever. They're unavoidable. This makes complaining about them futile. But, you cannot prove that they will exist on this noticeboard. Like I said above, results orientated thinking is wrong.
"...they overwhelm deletion discussions..." I know you're only using that as an example but it's a poor one at best. Most Projects routinely scan AfD's for articles relating to their project and then advertise the deletion discussion page to stir up support. If you have a problem with this widely used practice then you can bring it elsewhere. I wouldn't associate that with cabals at all. It's contributors looking after articles that are in their field of interest.
Superfluous use of questions marks; agitated at all, Z-man? I never once accused you of bad faith because you disagreed with me. How utterly ridiculous would I look if I did that? :-) - I accused you of bad faith because instead of saying: "Whilst I appreciate that you guys wish to help solve a tough quandary such as genre trolls; this isn't the medium to do it in. My reasons for stating this are..." etc. You came and you said: "...I would be worried... it would become entirely run by a small group of people and turn into a little cabal making up their own rules..." - That is bad faith. You're automatically assuming that users will be up to no good. Deny it again, friend. Then you try to avoid that by providing scant, subjective, and purely perceptive evidence. You simply can't justify your argument, sir.
Re: My reaction: Please reread what I have written, friend. I've stayed calm. I've put forth my objections to your objections in a polite, civil, and erudite manner. I think this is becoming a case where you're grabbing at straws to make me seem like I have no idea what I'm talking about. You generalise people too easily. I do look forward to your reply, Z-man. ScarianCall me Pat! 18:41, 13 March 2009 (UTC)
Just because you say it politely doesn't mean its not condescending. My opinion is expressed, your disagreement is noted. Mr.Z-man 22:14, 13 March 2009 (UTC)
  • Oppose The bickering here is not a good sign. Best to try again to eliminate the root cause by amending the infobox. Such categories in infoboxes are inherently POV-pushing and so are improper. Are ABBA MOR, disco, pop or what? Ask a silly question ...? Colonel Warden (talk) 18:48, 13 March 2009 (UTC)
  • Support Having already witnessed several IP genre trolls in short short period of time that I have been on Wikipedia this evening I feel this dedicated noticeboard would be a valuable service. The best alternative would be to simply remove the genre field altogether. But until something that bold is attempted a noticeboard strictly for this sort of negative edit habit should be in place. Wether B (talk) 19:49, 13 March 2009 (UTC)
  • strong support This is a very good proposal. GripTheHusk (talk) 01:31, 14 March 2009 (UTC)
  • SUPPORT! - brilliant idea!! The Real Libs-speak politely 12:32, 15 March 2009 (UTC)
  • Oppose. Such a noticeboard would be needless bureaucracy. Changing information (especially sourced information) and repeatedly replacing it with wrong or POV information without providing a source is already labeled as vandalism and dealt with as such. There's no need for a separate process to deal with this. - Mgm|(talk) 10:13, 17 March 2009 (UTC)
  • Weak support, with comment - Have you considered using WikiProject Music as a starting point? Perhaps instead of a noticeboard specifically for genre trolls, a slightly wider net could be cast to deal with issues specific to music articles that might require the attention of an administrator. --Gimme danger (talk) 05:33, 19 March 2009 (UTC)
  • Strong Oppose too specific. Aaron Schulz 10:02, 19 March 2009 (UTC)
  • Support This is a good idea. In my experience, editors who engage in this kind of behavior are often involved in other vandalism, so it would be a good idea to keep an eye on them. Nick-D (talk) 07:22, 20 March 2009 (UTC)
  • Support I recently had a run-in with an editor who insisted that Silence of the Lambs was not a horror movie, among other genre changes he was insisting on (some with good reason). This would have been a very handy place to take the discussion.--SarekOfVulcan (talk) 17:24, 20 March 2009 (UTC)
  • oppose terrible idea. Most of the people who would be reported here would just be people with a different POV. Any serious problems can be managed via normal channels. --Cameron Scott (talk) 17:46, 20 March 2009 (UTC)
  • Support - Genre disputes are sometimes brought to ANI, and they often get a puzzled reaction there. It would be better to have a board that was watched by people who regularly edit music articles. If the self-selected audience for the noticeboard turns out to misuse their power, the community can step in to address the problem. EdJohnston (talk) 01:53, 25 March 2009 (UTC)

Bot?

I know this idea may sound silly, but I've had Panic at the Disco on my watchlist since I requested a histmerge (that was denied, sadly enough), and people are constantly deleting the well-referenced "emo" from the infobox. What about creating a tag with the pre-approved genres and having a bot automatically revert them? There'd be a comment telling people not to change it there. It would only be genres that are well-referenced and discussed on the talk page, and they would be listed somewhere un-editable (either a separate list or a .js subpage, if it is a .js it could just be transcluded, but that wouldn't stop people from adding around it). If there is consensus and it is referenced an admin would change the tag.

Indicating that an article is part of a book

Users are creating many books on Wikipedia-Books. The books aren't actively integrated with articles on Wikipedia so I wanted to suggest having in the Create a book toolbar an indication that "This page is included in the ... book". This would boost readers awareness of books and include the general topic this page is part of. --Diaa abdelmoneim (talk) 11:57, 20 March 2009 (UTC)

Strongly oppose - Articles would soon be cluttered up with thousands of tags like that! --Orange Mike | Talk 13:11, 20 March 2009 (UTC)
Comment I am a bit confused by this whole "Create a book" on the toolbar thing. It seems like a side track to the idea of building an encyclopedia. Chillum 01:48, 21 March 2009 (UTC)
Oppose as a means for advertising particular books, and as a means of leading encyclopedia readers into a book which may not be NPOV or serve for some personal agenda. Wikipedia articles should try to keep the reader in the mainspace as much as possible. ThemFromSpace 15:18, 21 March 2009 (UTC)
Oppose per Themfromspace. ╟─TreasuryTag►contribs─╢ 15:22, 21 March 2009 (UTC)
Oppose ThemFromSpace makes a very good point. Chillum 15:25, 21 March 2009 (UTC)
Suggestion — Why not simply a tag that says "This article has at least one book associated with it"? --Izno (talk) 18:38, 21 March 2009 (UTC)
Or perhaps the negative would be a better idea: "This article does not have a book associated with it. Start one!", or something to that effect. --Izno (talk) 18:44, 21 March 2009 (UTC)
Which returns us to the point raised by Chillum: to what extent is encouraging editors to create books related to building an encyclopedia? -- John Broughton (♫♫) 01:14, 25 March 2009 (UTC)

Automatic G8'ing for talk pages

(I am surprised this hasn't been raised before, or has it?) G8 is, it seems to me, automatically applied to the talk pages of deleted articles. "Automatically" would then suggest to me that a bot could be created to save everyone time and energy, probably by automatically tagging pages after x minutes from the main article's deletion. - Jarry1250 (t, c) 07:56, 23 March 2009 (UTC)

"Secret" adminbots have been run for this for a long time. --MZMcBride (talk) 07:58, 23 March 2009 (UTC)

Although it does indeed "seem to you", and to me, that this is usually applied automatically; G8 should in principle not be applied automatically, as it contains an exclusion for "pages useful to the project"; a list of examples is provided at WP:CSD. So it's not safe to delete these without human intervention. Happy‑melon 08:32, 23 March 2009 (UTC)

Unfortunately, and in violation of our bot policy, these are routinely deleted automatically anyway, as MzMcBride notes. Algebraist 14:06, 23 March 2009 (UTC)
Well, we'll stick to policy and keep as-is then (it's a worthy exception). - Jarry1250 (t, c) 18:12, 23 March 2009 (UTC)

The problem is that if we want to apply G8, the only serious option is adminbots. There are too few admins to burden them with this sort of massive chore. The same is true for things like unused unfree images. But adminship requests for bots fail pretty much systematically so people are just running "secret adminbots" which are not really that secret. It's not a healthy way of doing things but the opposition to adminbots is philosophical and I think a few people are happy with a don't ask, don't tell situation. Pascal.Tesson (talk) 00:54, 25 March 2009 (UTC)

Are you aware that we now have 6 officially approved adminbots and a process for approving them? There's no good reason for "secret adminbots" anymore. Anomie⚔ 01:16, 25 March 2009 (UTC)
Or, if you will, this is a WP:IAR situation; such bots are run for the good of the project. -- John Broughton (♫♫) 01:11, 25 March 2009 (UTC)

Headings, subheadings, and sub-sub headings - text size etc

I'm finding that the heading system possibly could do with a 'tweak'.

The problem I have is that headings such as ===Sub topic=== is not (to my eyes) sufficiently distinguished from ====minor topic===== - ie in the text they look like identical heading levels.

I'd like to suggest that the 'four equal signs' headings be reduced a point or two in size, or something similar.

(Also what purpose ='god' quality heading= - why is it supported when never used?)

Thanks.FengRail (talk) 13:58, 14 March 2009 (UTC)

The h1/"god" header is the page title. Happy‑melon 15:44, 14 March 2009 (UTC)
And they are used inside pages, too, at WP:HD for example. Algebraist 13:42, 17 March 2009 (UTC)
I think it should be like this
Heading 1/2

Heading 3

Heading 4

Heading 5
And stop doing underlines at Heading 5. ViperSnake151 15:10, 14 March 2009 (UTC)
Can you really see that 200% header being used in real articles? I can't. Happy‑melon 15:44, 14 March 2009 (UTC)
I agree it looks big, personally I'm happy with it - up to heading level 4, which I think should be smaller. If anyone wants to use heading 5, then I would guess that would simply equate to bolded text? plus a new line...FengRail (talk) 15:59, 14 March 2009 (UTC)

We don't use the sub-subheads often enough to worry about them, in my opinion. Something that gets into that level of splitting shouldn't be listed in the TOC at the top, which is what what differentiates headings from bolding one you get to the subsubheads. DreamGuy (talk) 17:33, 14 March 2009 (UTC)

you know, I've never liked the visuals of wikipedia headings. for one, the first subheading is visually more prominent than the major heading, which often throws me off. for another, I keep expecting to see subsections indented, or somehow visually distinguished, to give a better 'at-a-glance' sense of the structure of the article. I know in academic writing, it's common (I think this is MLA style) to have major section headers centered, bolded, largish font, minor section headers flush left and bold on a separate line, and then subheaders indented, bold and italic, as the first word in the line where the text begins. that 's clearer to me in part because I'm used to it, but I also think it's just plain clearer. since web pages have more in common with academic manuscripts that with the much more complex layouts of paper encyclopedias, wouldn't it be better to adapt one of the academic header formats? --Ludwigs2 18:48, 15 March 2009 (UTC)
But Wikipedia is not a paper encyclopedia. ViperSnake151 19:19, 24 March 2009 (UTC)
For the record, I happen to agree that there is not sufficient differentiation between the level three and level four headers. I've thought as much for a long time. It's also kind of odd that level three and four headers are bolded text and the higher headers are not. Gatoclass (talk) 23:54, 25 March 2009 (UTC)

I hope this is the right place for this discussion. 2009 Malagasy political crisis is currently on the front page (in the news), and after having looked at the article, a large section of the references are to AFP which is hosted with Google. Google offers this service to news publishers, and I believe others such as Associated Press also use the hosted news service. This is great, however, in terms of our project it is a bad thing, because "Wire service articles hosted on Google pages are available for 30 days from when Google received the article on the wire. After the 30-day period, wire articles will no longer be available on Google News." This has the effect of articles, such as the Madagascar article linked to above, in 30 days of publication of the hosted news being prone to WP:LINKROT; which in this case is massive linkrot. The linkrot has the effect that the article becomes unverifiable in its current state, and then after 30 days from date of publication, searches for live links have to be undertaken; obviously this is a massive waste of editor resources and time. With online sources which I believe may in future go dead, I will use WebCite to archive and provide a link. Unfortunately, this is not possible with Google hosted news, as they have "noarchive" in the meta tags, rendering a service such as WebCite or the Wayback Machine useless to even obtain a copy of the page. Google states that news archive search isn't affected by this service, and that the Google hosted news also will not show up in archive searches. I would guess that most articles hosted by Google are available via other sources, such as this Google hosted news being available at France24.com, except it appears the France24.com link is cacheable. With the WebCiteBOT proposal looking like it will go ahead, if the France24.com link were to go dead in future, we would still be able to view it via WebCite. It is because of this, that I believe we should be blocking linking to Google-hosted news in the interests of long-term verifiability. --Russavia Dialogue 22:11, 18 March 2009 (UTC)

Why not, instead, a bot that notifies whoever posted the link that they should get a better one? And/or a bot that posts a note on the article talk page that the google news source link is going to go bad, and would someone please fix it? I ask because it seems to me better to accept a link that is going to go bad than to pop up an error message (probably one that doesn't clearly explain the problem), leading a lot of editors to either post nothing at all (worst) or post information without any link at all (not so good). -- John Broughton (♫♫) 01:21, 19 March 2009 (UTC)
(edit conflict) I used an article from afp.google.com in an article back in November 2007, WebCited it, but haven't yet used the webcite because the link is still live. Looking at the current version of the article and a randomly selected AFP article from 2009 Malagasy political crisis, I see no standard exclusion applied to either; the "noarchive" in there appears to be specific to Google's own crawler.
Did you even try WebCite? It worked here. Anomie⚔ 01:26, 19 March 2009 (UTC)

Sounds like a job for the abuse filter, which can provide a message saying "please use a better link" (and then still accept the edit if save page is clicked again). --NE2 01:23, 21 March 2009 (UTC)

Links to a service that reproduces other works and then expires them 30 days later? I think we can do without that. I agree that the abuse filter can politely explain why that type of link is a bad idea and how to find a more stable copy. Chillum 01:48, 21 March 2009 (UTC)
OTOH, the citation is to the news article, not to the website it happens to be on. The link to the website is just a convenience. The warning for the proposed abuse filter rule should be written with that in mind, so as to not discourage the addition of the source just because no (semi-)permanent link can be found. And, contrary to the original poster's claim, WebCite does currently work on these particular links; once WebCiteBot is completed the WebCite archive will be created automatically, at which time the proposed abuse filter rule may as well be deactivated. Anomie⚔ 02:35, 21 March 2009 (UTC)
That is a valid point. We should not throw away a reference because the link is bad. I don't know how intelligent the abuse filter is. Could it allow the edit but give the user a message about the link? Could it add the link to a backlog somewhere for people search out a better link? Chillum 02:46, 21 March 2009 (UTC)
I know it can do the first (use the "Trigger these actions after giving the user a warning" option without using "Prevent the user from performing the action in question"). The "Tag the edit for further review" option should be able to do the second, but I don't know how exactly that works. Anomie⚔ 02:55, 21 March 2009 (UTC)

Could someone describe the details of the link pattern that expires? Dragons flight (talk) 06:44, 21 March 2009 (UTC)

  • As long as there is additional information in the reference, it should be trivially easy to retrieve it from another source that keeps wire stories up for longer. - Mgm|(talk) 11:15, 21 March 2009 (UTC)
The pattern is (a) the link is to a page in the news.google.com domain and (b) nothing else (title, author, date, etc.) is provided within the <ref> tags - just a naked url (or, alternatively, just a bracket on each side of the url). -- John Broughton (♫♫) 01:18, 25 March 2009 (UTC)

Please do not block edits with these links. Then we would lose the text that the user was about to add as well. Sure, they could remove or fix the link and submit again, but probably won't. A bot that retrieves the news title and date, and notifies somewhere would be great. --Apoc2400 (talk) 18:38, 25 March 2009 (UTC)

I was thinking just a warning message linking to the page on link rot and such. ViperSnake151 20:26, 25 March 2009 (UTC)

Editnotice for creating new pages

I propose that when a new page is being created that an edit notice should list some basic principles of what and what not to create. I went ahead and created a rough version which you can feel free to change.


Details

  • Could limit it to appear only for unautoconfirmed users .
  • Could use an opt out system, for registered users.

Any thoughts? --DFS454 (talk) 17:27, 13 March 2009 (UTC)

I think it's probably too scary. We really don't want to frighten 'em off. - Jarry1250 (t, c) 17:32, 13 March 2009 (UTC)
See Wikipedia:Village pump (technical)#Fyi on per-article edit notices for updates on editnotices. --—— Gadget850 (Ed) talk - 18:25, 13 March 2009 (UTC)

I would not think the above template would be the best one for this. As Jarry1250 says, this one is rather scary - I would certainly concur that the bit about being blocked may scare new users. Also, I think some of this may detract new users because it is too laden with jargon - using terms such as "wikimarkup language", for example. I am not in principle against having a template for new articles, but I certainly think the language needs to be simplified. I am glad that you said, DFS454, that we can feel free to change the above template - surely if we are to have such a template, it should be written in more accessible and less intimidating language. ACEOREVIVED (talk) 21:40, 15 March 2009 (UTC)

WP:Don't bite the newcomers, and don't scare them off with ominous notices. --Cybercobra (talk) 01:31, 17 March 2009 (UTC)

  • OK I've taken your feedback and come up with this. I removed the bold and the block remark. I replaced the warning symbol too. Bear in mind the reason the other one came off excessivley BITEY was because of the amount of attack pages and spam that wikipedia normally gets. --DFS454 (talk) 17:13, 17 March 2009 (UTC)
Well, I do think it's an improvement (I've tweaked the wording slightly re grammatical pedantry and removed the WP'ism from the last item). So now we can get round to the much more important discussion about where we should use the editnotice, if at all (are editnotices now deprecated or something?). - Jarry1250 (t, c) 17:36, 17 March 2009 (UTC)

This seems a lot better to me (I agree with Jarry1250 that it is an improvement) - far less intimidating, and much less laden with complex Wikipedia-speak. I can only really say here that I wish to agree with Jarry1250's last comment. ACEOREVIVED (talk) 20:46, 17 March 2009 (UTC) I think we have quickly reached consensus that if we are to have such a template, the second would be better than the first suggestion. Perhaps, if technology permits this,we could say it would only be for non-autoconfirmed users.However, what must be decided now is whether people wish to support or oppose this idea. ACEOREVIVED (talk) 22:22, 18 March 2009 (UTC)

Why not use the lead text from Wikipedia:Your first article? It seems to be stable and accepted. --—— Gadget850 (Ed) talk - 13:11, 19 March 2009 (UTC)
Whichever we choose, don't forget to use the standard editnotice layout; it's easiest through {{editnotice}}. Happy‑melon 08:36, 23 March 2009 (UTC)

This already exists and is not an editnotice. See: MediaWiki:Newarticletext. --MZMcBride (talk) 09:02, 23 March 2009 (UTC)

Fair point but I don't think it's sufficient. Because it's larger than the text more people will take notice of it and follow its advice. Could also use the text from Wikipedia:Your first article as Gadget850 suggests --DFS454 (talk) 09:08, 23 March 2009 (UTC)

Could we please not have more instruction creep? it just makes people not read the instructions at all. --Apoc2400 (talk) 18:47, 25 March 2009 (UTC)

Is this necessary? I know CSD is always backlogged, but does that really mean we're being so overwhelmed with bad new articles that we need a notice like this to keep them from making them? Will this solve any problem that can't be solved by speedying blatantly bad articles (and giving the creators the big notice on their talk page)? From my experience, probably at least half (random statistic, I know) of bad articles that get created are by people who are not going to be paying attention to this notice anyway—people who are goofing around, people who want to promote themselves no matter what the rules say, etc. So my question is basically, is there a problem that needs to be solved, that can't be solved by current CSD practices, and that would be solved by this? rʨanaɢ talk/contribs 21:30, 25 March 2009 (UTC)

  • I didn't anticipate that, you are right though. If someone is "hell bent" on promoting their site/product a notice will probably not stop them.--DFS454 (talk) 12:56, 27 March 2009 (UTC)

Wikipedia:Date formatting and linking poll

The above link leads to a community poll regarding date linking on Wikipedia. The poll has not yet opened, but the community is invited to review the format and make suggestions/comments on the talk page. We need as many neutral comments as we can get so the poll runs as smoothly as possible and is able to give a good idea of the communities expectations regarding date linking on the project. Ryan PostlethwaiteSee the mess I've created or let's have banter 19:41, 21 March 2009 (UTC)

Given the utter closed-mindedness of some replies here, I doubt this will really do any good. BTW, your "Statement for [autoformatting]" section forgets to mention that it would remove the need for stupid "dateformat" parameters on various templates, and your "Statement against [autoformatting]" is full of FUD and ends with a logical fallacy. But I'm not going near that talk page, I don't have the patience to deal with certain parties there. Anomie⚔ 00:50, 22 March 2009 (UTC)
"closed-mindedness"? That's a rather generous assessment. Mr.Z-man 02:26, 24 March 2009 (UTC)
Well, we are supposed to assume good faith ;) Anomie⚔ 11:58, 24 March 2009 (UTC)

Note The first phase of this poll will start on 30 March. Dabomb87 (talk) 03:57, 28 March 2009 (UTC)

Double redirects - what's going on?

There was a discussion at Wikipedia:Village pump (proposals)/Archive 44#Double redirects in which there was general support for keeping $wgMaxRedirects as at least 2, but it's been changed back to 1. What's up? --NE2 18:16, 26 March 2009 (UTC)

It hasn't been changed. It always was set to 1, there was just a bug that meant it behaved like it was set to 2. That bug has now been fixed. Here is the request to set it to 2; Brion's latest comment was that 'This is one we probably want to start on test, pre-announce, and have people poke it a bit.' Algebraist 18:25, 26 March 2009 (UTC)

WP:CSD rename discussion

A discussion is ongoing over renaming WP:Criteria for speedy deletion to WP:Criteria for summary deletion. All contributions welcome. Happy‑melon 14:28, 27 March 2009 (UTC)

Wikipedia:Mergers for discussion

I have created a discussion on the policy village pump about a proposed process called Wikipedia:Mergers for discussion. One of it's goals is to be a complimentary process to AfD, as well as assist in complicated or controversial mergers. Interested editors should comment there, or on the process' talk page. --NickPenguin(contribs) 04:57, 26 March 2009 (UTC)

Good idea - I have wondered myself whether, as well as discussing articles which have been suggested as cases of deletion,we should have similar discussions about whether certain articles should be merged (I would not equate deletion with merging). ACEOREVIVED (talk) 20:00, 28 March 2009 (UTC)

Well if somebody removes the "merged" content from the second article (because they don't want it there or because the page is already too long without it), it does ultimately amount to a deletion. The only benefit I see to making the "merge" tag more bureaucratic is improved attention to GFDL attribution requirements. — CharlotteWebb 11:57, 29 March 2009 (UTC)

Suggestion for a new welcome template

Hi. I've been busy over at en.wikinews, and I noticed that they have an interesting welcome template they send out. I like it, as it is informative, yet doesn't overload the user with too much information at once. The message is available here. Perhaps we should incorporate the layout of their welcome template for use in Wikipedia? ♪Tempo di Valse ♪ 14:07, 26 March 2009 (UTC)

See WP:PEREN#Use a bot to welcome new users. -- John Broughton (♫♫) 01:09, 29 March 2009 (UTC)
No, this is not a proposal to have a bot do it, you misunderstood me. I was suggesting that we modify the current {{Welcome}} template to make it similar to Wikinews' tabbed layout (but still send them out manually, as we usually do). ♪Tempo di Valse ♪ 01:38, 29 March 2009 (UTC)
that is a lot prettier, I'll grant you. maybe make a userspace draft and take it up over at {{welcome}}? I'd support it. --Ludwigs2 01:50, 29 March 2009 (UTC)
EDIT: looking a little closer, we'd probably have to stea... err, borrow some of wikinews' CSS classes and javascript functions, because I don't think Wikipedia currently has support for tabs. that would be kind of cool in and of itself, though... the javascript for implementing something like this should be pretty minimal (functions that hide and show divs), but... --Ludwigs2 02:02, 29 March 2009 (UTC)
WP doesn't have support for tabs? I could have sworn I saw them somewhere earlier. Would it be difficult to copy the javascript and CSS functions? ♪Tempo di Valse ♪ 02:13, 29 March 2009 (UTC)
actually, now that I think about it there are tabs used in places - top of the window, for one. I haven't looked at the code very closely so I don't know if those are adaptable. I haven't seen this particular kind of CSS/content tab structure anywhere on wikipedia, though it might be there somewhere (and there's similar things implemented, like collapsible tables). the code isn't difficult to copy (or create, for that matter), but there's more complex issues about whether it's useful or desired on wikipedia, or whether it would muck with other code already being used. probably need a developer (or at least a wikipedia code junkie) to answer that. --Ludwigs2 03:31, 29 March 2009 (UTC)
No need to change {{welcome}}, the wikinews template is too simple and fluffy for a generic hello. We have a WHOLE BUNCH of welcome templates here and you're welcome to create your own (even a user subpage will work). For instance I use {{welcomeg}}, but the welcome template as a staple would be a battle to change. §hepTalk 03:39, 29 March 2009 (UTC)
Fluffy??!?? --Ludwigs2 22:44, 29 March 2009 (UTC)

v, d , e on templates

Don't know if it is technically possible but if so, I think it would be a good idea to remove the little v, d and e letters from templates by default. They would appear only when logged in or if changed in the preferences. This makes sense to me as it bears very little relevance to the reader, and although I would still consider the templates confusing it would aid users by removing one place for them to go wrong. Darryl.matheson (talk) 16:58, 27 March 2009 (UTC)

But not all readers are logged-out, and not all logged-out users are readers rather than editors. The links are designed to be as minimal and unintrusive as possible, hence the three letters. How do you know that removing them will aid readers? Do you have evidence, or is it just an assumption? If you personally want to hide the links, you can add the line
.navbar {display: none;}
To your monobook.css. But I don't think the making-readers-and-editors-see-different-views-of-the-same-page route is a road we want to go down. Happy‑melon 17:11, 27 March 2009 (UTC)
Darned either way. Without the edit links, we will get queries about how to figure out the template to edit. --—— Gadget850 (Ed) talk - 17:16, 27 March 2009 (UTC)
The fact is that the vast majority of users of Wikipedia do not edit and users who are not logged in are unlikely to edit a template in any case because they are more likely to be new editors. If an unregistered user wanted those links displayed then they could change their preferences, I actually use the links quite a lot but I just think they are not relevant to most users. Darryl.matheson (talk) 17:26, 27 March 2009 (UTC)
The same could be said about much of the interface; even if it's going a bit far to say we should hide the edit tab, certainly most of the sidebar is useless to readers; should we hide that as well? Every reader who clicks on a link that takes them into the 'backstage' is a reader who could potentially be intrigued enough to become a fully-fledged editor, that's why we don't hide any of this stuff. It's not our place to decide what users do and do not want to see. Happy‑melon 17:38, 27 March 2009 (UTC)

These links should at least be marked as a blatant self-reference. We should not assume that every mirrored copy of an article which containing a navbox will be on an editable web-site, or that any separate page will exist for the template itself, etc. Thus in Template:Navbar

class="noprint plainlinksneverexpand navbar"

should be changed to

class="noprint plainlinksneverexpand navbar selfreference"

to help facilitate automatic removal of the "v•d•e" links on mirror sites, most of which will not want this. — CharlotteWebb 12:26, 29 March 2009 (UTC)

History with deleted versions

Hello. I think that pages that exist but was deleted in the past, should have deleted versions in the history tab. For example, the list could look like this:

  • (cur) (prev) 22:31, 2 November 2004 FrontFrog (talk | contribs) (undo)
  • Deletion log 13:17, 30 October 2004 Maxwell (talk | contribs) (Maxwell has restored article: Request of Lord Protector.)
  • Deletion log 22:40, 14 September 2004 SuperUser (talk | contribs) (SuperUser has deleted article: Somekind of nonsence.)
  • (cur) (prev) 22:31, 14 September 2004 Angela (talk | contribs) (undo)
  • (cur) (prev) 22:29, 14 September 2004 Grunt (talk | contribs)

--Janezdrilc (talk) 12:59, 29 March 2009 (UTC)

The deleted revisions are currently available to admins; this seems to work quite well as it prevents an BLP (etc) infringements, but allows for demands of information on request. - Jarry1250 (t, c) 14:58, 29 March 2009 (UTC)

watchlist for all versions of wikipedia

I contribute to several wikipedia language versions. It would be nice if I could have a common watchlist for all of them.Shep (talk) 14:03, 29 March 2009 (UTC)

See T5525 on a 'global watchlist'. Not currently available within the software. Cenarium (talk) 14:29, 29 March 2009 (UTC)

Wikipedia:Date formatting and linking poll now open

The date linking and formatting poll is now open. All users are invited to participate. Ryan PostlethwaiteSee the mess I've created or let's have banter 23:00, 29 March 2009 (UTC)

To all users, or just administrators only? ;) Someone forgot to unprotect it... Anomie⚔ 23:04, 29 March 2009 (UTC)
Doh! Ryan PostlethwaiteSee the mess I've created or let's have banter 23:06, 29 March 2009 (UTC)

Add a tab to allow viewing the code without going into edit mode

This may well be a frequently-discussed proposal, but I can't think of a good way to search for it (as seen by my own clumsy title here). If it has been discussed before, I'd of course be grateful for a link that would let me see the facts and arguments on both sides.

What I'd often like as an editor is to see the (plain-language) code of a page without wanting to edit it or risking an accidental edit. Sometimes I want to copy a complete reference, the format of a table or the title of an image, or just to see how something was constructed, without having to risk changing the code accidentally or having to go through the steps of opening and closing an unnecessary edit process (perhaps causing a completely-needless edit conflict).

I can see a slight disadvantage in adding an extra "View" tab on page-tops that are already filling up with other tabs, but I think the advantages might be worth the cost. (I don't understand the technology behind Wikipedia, but perhaps it would also be easier on the system to have slightly-fewer prompts to be ready to upload new edits.)

—— Shakescene (talk) 05:15, 27 March 2009 (UTC)

Use Special:Export or just hit the back button on your browser once you've finished checking/copying the code. Graham87 10:17, 27 March 2009 (UTC)
Actually, I just hit the "Article" tab. But I'd still prefer to be able to view how the article's written without even entering "Edit" mode when I don't want to and running the risk of changing the code (or creating an Edit conflict) by mistake. —— Shakescene (talk) 20:13, 27 March 2009 (UTC)
An edit conflict will not occur unless you have actually hit the "save page" button below the edit window. If you want to avoid accidentally saving a page, I suggest you go to Special:Preferences and look under "Editing" for the line marked Prompt me when entering a blank edit summary. This will make it practically impossible to save accidentally, as you will have to enter an edit summary to get the page to save. ♪Tempo di Valse ♪ 20:47, 27 March 2009 (UTC)
I do that, too (so I shouldn't have raised these secondary reasons in the first place); but I just don't like opening "edit" in the first place when it's unnecessary to do so and I just want to see the code. (And other editors won't know all these tricks.) —— Shakescene (talk) 21:08, 27 March 2009 (UTC)
Here's the problem: Every time we add another tab or other feature, the page looks even more challenging to new editors. That you're uncomfortable doing something that has zero risk (because of how you have set your preferences) seems a very minor reason to add yet another feature. Sure, inexperienced editors don't know the "trick" about an automated warning when there is a blank edit summary, but then, inexperienced editors typically don't want to see wikitext unless they are actually considering changing that text.
Besides which, if you or someone else do make a mistake and save a change that you do not want, it's pretty trivial to revert that change. -- John Broughton (♫♫) 01:01, 29 March 2009 (UTC)
It's also pretty trivial to not make the mistake in the first place if his suggestion is implemented. I don't think a tab-for-everybody would be a good thing, but throwing together tabs with javascript is simple, and other scripts already do that (such as Huggle). The problem is that the OP lacks a suitable way to hook into a "view" screen rather than an "edit" screen.
For example, when an anon tries to edit a semi'd page or a non-admin tries to edit a fully-protected page, they get a screen like the OP wants. What would be nice is to be able to change the url of a page to "view" the code; something like this instead of like like that (note the ends of the URLs). I doubt the change would be difficult. There's probably something like that already, but that would have to be accessed through the API, if it even does exist. --Izno (talk) 04:12, 29 March 2009 (UTC)

Thanks for the feedback; it allowed me to clarify the possible reasons better in my own head.

First (if I correctly understand an unspoken implication of at least part of Izno's posting), I think it would definitely be desirable — if such a tab were available (either by default or through User Preferences) — that it resemble the "Watch/Unwatch" tab in being only available to and us[e]able by Registered Users. Clutter and confusion to new readers and editors is certainly one of the possible drawbacks I could see in an extra tab.

Second, I can be a bit more articulate about why I think such a tab might be useful to me even after having done a couple of thousand edits. One reason is a bit abstract, and the other pretty specific.

(A) On the more general level, whenever I (or I presume most people) are on line, there's a certain level of attention and anxiety required to avoid sending or receiving something unintended, just as one is more relaxed composing a hand-written letter than in making a telephone call or sending an e-mail. There's far less chance of a sudden lapse or hasty misunderstanding if one has to go through the steps of writing, revising, folding, addressing, stamping and depositing a letter. Even though (for the technical reasons mentioned above) there's little chance of a serious or irreparable error in editing Wikipedia, every unnecessary doubt or hesitation in the back of one's mind that can be lessened is attention that can be brought to something more important.

(B) The practical situation that makes me wish for a "View" tab is this: When I'm copying a footnote, image, format, colo[u]r code, link or statistic from one article to another (e.g. an election return or the full bibliographic entry for The Encyclopedia of New York City between New York pages), I almost always have more than one browser tab or window open in "Edit" mode, even though (being at least partially sane) I usually want to edit only one of those pages at one time. This can be particularly tricky if (say) one footnote or link seems clearly better than the other, and I'm pasting over previous text. Although it's never got[ten] so far as to cause any noticeable damage, I've sometimes caught myself in the middle of pasting the "bad" footnote or link over the good one, i.e. the exact opposite of my intention. If, in the middle of constant jumping between windows, I could see all the code I need while only being able to edit one page, it would make the process far surer and easier for me. —— Shakescene (talk) 07:50, 29 March 2009 (UTC)

Eh just use &action=raw. — CharlotteWebb 12:07, 29 March 2009 (UTC)

OK, I'll bite; not being a techie, I have only the faintest, foggiest notion of what that might mean or how I could use it. —— Shakescene (talk) 18:01, 29 March 2009 (UTC)
What that means is if you click on the edit tab of a page then look at the URL in your address bar, you will find that it contains the text &action=edit. If you replace that with &action=raw and press enter, you will be prompted to download a file. If you download that file and open it with Notepad, you will see the wikitext of the page. Tra (Talk) 19:12, 29 March 2009 (UTC)

Here's some code that will give a view tab next to the edit tab. It uses the api so it does have the disadvantage of there being a lot of code you won't understand before and after the source code of the page. 

//Tab to view source

addOnloadHook(function() {
if ( document.getElementById( "ca-edit" ) ) {
addPortletLink("p-cactions", "http://wiki.riteme.site/w/api.php?action=query&prop=revisions&rvprop=content&format=txtfm&titles=" + wgPageName, "View", "ca-view", "View source", "" , document.getElementById( "ca-history" ));
}
});

To use this code, go to Special:MyPage/monobook.js, click the edit tab, copy and paste in the code and save the page. Then press Ctrl + F5 to clear your cache. Tra (Talk) 19:12, 29 March 2009 (UTC)

Or I could hit "Select All" (Control-A), "Copy" (Control-C), open Notepad (or, for longer articles, Wordpad) and paste the text onto that (which I've done in the past when I've wanted to use the Find & Replace function to change repeated wikilinks, formats or color codes). If this thoughtfully-provided code is something I'd have to paste onto each page each time after I've already opened it in Edit, I'm not quite sure of the advantage. Perhaps if could paste it onto the URL of the main Article (/Project Page/Template/...) View instead of pressing the "Edit" tab, it might work as a fix. —— Shakescene (talk) 20:52, 29 March 2009 (UTC)
I'm not sure you're completely understanding what you have to do to use this code. I'll try and explain it a bit clearer.
To install the code (this only needs to be done once), follow these steps:
  1. Select the code I wrote above and press Ctrl + C.
  2. Click on this link then click 'create this page'.
  3. Click in the edit box and press Ctrl + V.
  4. Click 'Save page'.
  5. Press Ctrl + F5.
Once you have installed the code, you will see a 'view' tab on each page on Wikipedia. If you click on this tab, you will see the source of that page, along with some extra code which you won't understand.
If you're still not sure what this all means and you would rather I installed the code for you, please say so. Tra (Talk) 18:23, 30 March 2009 (UTC)

Wikipedia to have audio readout of whole article.

I was thinking if wikipedia had a complete audio read out of the article i would not have to read it. I know youtube has something similar and thougght it would give wikipedia more appeal.

Some articles already have this; see Wikipedia:Spoken articles. However, the recordings are made manually so it's difficult to cover a lot of articles. Tra (Talk) 22:48, 30 March 2009 (UTC)

List of reliable/unreliable sources

I'd like to suggest having a noticeboard or a list of sources that can/cannot be used on Wikipedia. This seems urgent with the many sources that get contested on FACs and FLCs where reviewers ask about the reliability of the sources. If there was a list of sources that can be used on Wikipedia it would be easier to check a sources' reliability. This would also make a central hub for sources a user can research to improve his topic. I'd suggest a bot that adds all references an FA or FL has to this list. Users would also add websites they think are reliable, which if contested would go on reliability review. A user posting an FAC or FLC would have the option to check his sources before posting it. The list would of course have a subcategories with each topic like newspapers, magazines, blogs and websites (to be decided on). Official websites of companies don't have to be on these lists as they assert their own reliability. For example: someone doesn't know if www.techradar.com is reliable or not, he goes on the page of websites and finds it to be reliable or not. This would make checking reliability much easier and would have many future uses. I'm not suggesting Wikipedia:VPR/Perennial#Define_reliable_sources but just a list of reliable, already on Wikipedia:Reliable sources/Noticeboard discussed sources to make research and reliability easier.--Diaa abdelmoneim (talk) 08:49, 17 March 2009 (UTC)

A hole in the above would be if a normally unreliable source were to make an exception and write a few really great, well-researched pieces with references, good enough to be considered a reliable source. Conversely, a normally reliable source might have a blog-like column that's unreliable. Both situations would have users on the wrong side of the argument using your noticeboard as ammunition for their arguments. Tempshill (talk) 17:14, 17 March 2009 (UTC)
We don't judge reliability at the page level (whether something is well-research and well-cited); we judge based on whether the site does fact-checking, its overall reputation, use of expertise, etc.). In your first example, an editor should follow the references; in the second, it's an issue of dealing with incorrect information or information that contradicts other reliable sources.
I think this is worth further discussion, though I wonder whether it's really worth it, given the literally millions of websites out there, and the archives search function for the noticeboard. And if there were a list, I think a strong argument could be made to semi-protect it, so that any established editor who posts inappropriately there risks being called out for such an action.
Finally, you might want to post at Wikipedia talk:Reliable sources/Noticeboard; the editors who read that page regularly are probably the ones most capable of commenting on this proposal. -- John Broughton (♫♫) 18:32, 17 March 2009 (UTC)

I think a list could be helpful, but I think we'd have POV pushers and spammers constantly screwing with the list. But then at least the battle over decidin such things would be limited to one plae instead of spread out over countless talk pages. Any bot trying to label reliable sources would be completely impractical and problematic, however. DreamGuy (talk) 13:56, 18 March 2009 (UTC)

There is really a spectrum of how reliable a source is - it is not always black and white. For example, I write articles about historical events. A newspaper article may be a terrific source for modern reaction to those events. The same newspaper (or same article) would not necessarily be appropriate for a description of the events themselves. For the description, I should first consult books or papers written by historians who have actually researched the events. It very much depends on the source and how it is used, and there is such a wide variety of sources that it is not really possible to categorize them all. Karanacs (talk) 14:50, 18 March 2009 (UTC)

Such a list could still be useful. I remember once almost using The Huffington Post as a source, because I thought it was the local newspaper in some town called Huffington. --Apoc2400 (talk) 18:42, 25 March 2009 (UTC)

It's going to be an awful battleground. You'll get cabals trying to get a general ban on sites that don't suit their point of view. Probably they'll succeed at least some of the time. I think the potential bad of this outweighs the potential good. I think it's probably better to keep these battles isolated and spread out. -- Ong saluri (talk) 19:30, 31 March 2009 (UTC)

Use the globe as a favicon

There have been several proposals to change the favicon in the past, with people seeming unhappy with this basic (and now very old) design. See /Archive_29#Favicon_improvement and /Archive_35#New_favicon, there are also some murmurings in relation the the Wiktionary logo discussion that it'd be nice to have a different favicon from Wikipedia. As the globe is used by most other Wikimedia projects when linking to Wikipedia (see b:Template:Wikipedia-inline), and it is the logo for the project, it seems silly not to use it as a favicon. Conrad.Irwin (on wikt) 15:47, 29 March 2009 (UTC)

The globe doesn't shrink to favicon sizes well. I greatly like the simplicity and clarity of the current favicon. If there were an icon to be tweaked, I'd suggest changing the icon used for the iPhone and iPod Touch slightly, but that's a different discussion. {{Nihiltres|talk|log}} 17:56, 29 March 2009 (UTC)
This is roughly what the globe would look like when shrunk to favicon size. It's far less identifiable than the current "W". --Carnildo (talk) 22:23, 29 March 2009 (UTC)
You should probably use one of the versions without words at the bottom for a fair comparison: Not that any of those are much better so small. Anomie⚔ 23:01, 29 March 2009 (UTC)
Too many other sites use globes. And their globes can use more color to be more distinctive. -- SEWilco (talk) 23:08, 29 March 2009 (UTC)
I prefer the miniaturized globe. It would make it a lot easier to tell Wikipedia apart from other Wikimedia sites. The miniature globe doesn't have to look perfect; you just have to be able to tell what it's supposed to be. —Remember the dot (talk) 01:53, 31 March 2009 (UTC)
On my monitor the "miniaturized globe" is just another fuzzy gray sphere. --Carnildo (talk) 22:37, 31 March 2009 (UTC)

New featured content

I have put forward a proposal for Featured redirects. Any comments at the proposal's talk page would be welcome. —  Tivedshambo  (t/c) 05:09, 1 April 2009 (UTC)


MediaWiki:Revertpage

I have made a proposal at MediaWiki_talk:Revertpage#AES. -- IRP ☎ 02:21, 1 April 2009 (UTC)

I deal oftentimes with the removal of external links that I don't see as meeting our external link guidelines and oftentimes these removals are contested. This oftentimes happens on smaller, out-of-the-spotlight pages in which it's hard to get an outside conversation going. The debate is oftentimes with newer users who don't understand the guidelines, and users with a conflict of interest who want the links up for promotional purposes. When discussions with these users come to a stand-still and edit-warring begins, I find it hard to bring the debate to a larger audience in an attempt to find a consensus. With spam there is WT:WPSPAM, with sources there is WP:RSN, with BLPs there is WP:BLPN, but there is no place for external links in themselves. WP:RFC can be about anything content related, and oftentimes RfCs are slow to develop, when a quick consensus about an application of the guidelines is all that external link problems need.

I'd like to start up an external links noticeboard, to create a forum for the discussions over individual external links on Wikipedia. This would be different than WT:EL, which is about the discussion of the guidelines proper. This would be a board in which editors would try to find consensus in disputes involving external links; what should be linked to, and what shouldn't be linked. I think this would be a quick and efficient way of handling many debates on the far-corners of Wikipedia, as the problems can be brought to a central noticeboard for uninvolved editors to look at. Themfromspace (talk) 14:12, 12 March 2009 (UTC)

I like the idea. Often times it's not really spam per se and it'd be worth linking to if WP *did* allow no real limit to ELs. So a place to say "hey would you come look and see if you think this is worthwhile" without having to goto the blacklist or spam board... ♫ Melodia Chaconne ♫ (talk) 14:46, 12 March 2009 (UTC)
Another advantage would be the specific examples/discussions editors could use when researching similar links. Flowanda | Talk 19:44, 12 March 2009 (UTC)
Seems like a good idea since it is divorced from the concept of only "spam", but rather all merit topics. I expect it would be a place with a lot of headaches, but still it makes sense to have a place to centralize headaches. 2005 (talk) 02:44, 13 March 2009 (UTC)

Yes, I can see the wisdom behind this - having a noticeboard to discuss the disputes about what should be in an external link. I have a question, though. Did you mean that this would be to discuss what should go on the page of external links guidelines, or to discuss the sub-heading under "What Wikipedia is not" which says "Wikipedia is not a repository of external links"? Or is there something on Wikipedia (which I have yet to see myself) to the effect of a category entitled "Pages with disputed utility to their external links"? ACEOREVIVED (talk) 22:24, 12 March 2009 (UTC)

Most of that is handled now at WT:EL. I don't think that the volume is high enough on that page to justify creating yet another bureaucratic forum. Aceorevived, the category you're looking for is Category:Wikipedia external links cleanup. WhatamIdoing (talk) 00:12, 13 March 2009 (UTC)

Please be aware that any organized body of deletionists will require the organization of a body of contributors: This isn't the answer. Discussion is. I'm not sure how many groups of contributors Themfromspace is edit warring with today, so I'll just touch on the conflict that I'm involved with. Attempts at discussion are ongoing at three locations: Themfromspace's talk page, Roguebfl's talk page, and the Reliable Sources Noticeboard. This would be number four. Roguebfl, A Quest For Knowledge, and I have open questions for Themfromspace. I think we deserve answers. BitterGrey (talk) 04:10, 13 March 2009 (UTC)

Reposting from the previous board where Themfromspace sought to recruit outside support, as opposed to discussing changes... [2]BitterGrey (talk) 04:10, 13 March 2009 (UTC)

Themfromspace has concluded that the link to understanding.infantilism.org gives "undue weight to minority views". (Or, at least that is what he wrote before.) He has been asked repeatedly to be specific about what underrepresented majority he is concerned about.[3][4]. If he's willing to be specific about what views he thinks are being left out, a compromise can probably be reached.BitterGrey (talk) 04:26, 12 March 2009 (UTC)
...Themfromspace, the assertion about simply enforcing Wikipedia policies is discredited by the link you repeatedly left in place[5][6]. Here you are trying to assert that understanding.infantilism.org might be a little biased. The link you repeatedly left in place was clearly labeled as both an open wiki (#12 on the list of links to be avoided) and not in English. (Windelwiki might be an excellent resource. Since I can't read German, I don't know.) Paraphilic infantilism is a medical condition (Diagnostic and Statistical Manual of Mental Disorders, Fourth Edition, Text-Revised. Washington, DC, American Psychiatric Association, 2000, pg 572-573) and those who have it have a right to exist and to be understood. I would imagine this viewpoint could seem off-center to one who openly frequents Encyclopedia Dramatica[7]. Now, are you going to let us in on the secret? Who is this 'majority' that you are edit warring on behalf of? ...BitterGrey (talk) 04:26, 12 March 2009 (UTC)
BitterGrey, just to clarify, you're unhappy with Themfromspace for removing your pro-paraphilia website from the ==External links== section of Paraphilic infantilism, correct? WhatamIdoing (talk) 05:09, 13 March 2009 (UTC)
"pro-paraphilia?" Do you think Themfromspace's underrepresented majority view is some anti-paraphilia postion? This is a discussion that Themfromspace should have at least tried to engage in before warring and recruiting.
I'm unhappy that he was edit warring with another editor and trying to recruit the help of others, as opposed being willing to discuss his actions. To avoid a conflict on interest, I have not joined in the edit war myself. I have, however, joined in the discussion. Please note that I have made multiple disclosures about being the maintainer of that website (specific to this conversation: [8],[9]) and have avoided making any changes to the external links list. BitterGrey (talk) 06:22, 13 March 2009 (UTC)
Thank you very much for hijacking this discussion that had nothing whatsoever to do with your particular link. I started it in part because I realised that there was no place to go to discuss links like yours. The reliable sources board isn't appropriate, nor is the article's talk page as there aren't many people there familiar with the guildelines. Please take this elsewhere as this board isn't the place to discuss your particular link. If there was an external links board, on the other hand..... Themfromspace (talk) 11:24, 13 March 2009 (UTC)
Since he didn't mention a thing about all this in his initial post, you have no real bases for bringing all that up here. I don't see any reason you can accuse him of 'recruiting' in some negative sense. ♫ Melodia Chaconne ♫ (talk) 11:26, 13 March 2009 (UTC)
My apologies if I spent too much time detailing a specific example. The point is that in at least one case, Themfromspace sought support elsewhere instead of engaging in discussion. The post here followed directly after his not getting support from the Reliable Sources Noticeboard, and that discussion was specific to this example. (By the way, there is one person from that board who asked a question and I think deserves an answer.) Themfromspace didn't inform me about that discussion either. I stumbled across it in a change log, and it was an unpleasant surprise. I'll concede that it is possible that the discussion here was triggered by some other edit war that he is currently involved with, as opposed to the example. Exactly how many edit wars is he currently involved with? And how many of those also could have been resolved by engaging in discussion there? BitterGrey (talk) 13:26, 13 March 2009 (UTC)
This isn't a referendum on my behaviour at all. Stop bringing me into this. This is discussion about the creation of a noticeboard. I won't respond to any more posts from you on this board. Themfromspace (talk) 14:00, 13 March 2009 (UTC)
Actually I think it is extremely relent. Does you proposed noticeboard exist to discuss and resolved differences, or is it merely a flag for "watch these pages to remove stuff I disagree with" if it the former it a good idea, if the later it a bad idea that will only bring more damage to Wikipedia reputation Roguebfl (talk) 16:17, 13 March 2009 (UTC)
To bring this back to the requested discussion...I have a question based on WhatAmIDoing's comment about existing resources. I wonder if one reason for the low volume at the WP:EL talk page is because it's a talk page instead of a noticeboard. I've looked through the EL's talk page and archived discussions before, but I would never consider posting a request about a website or conflict because it's not clear to me that that's what the page is for. Flowanda | Talk 03:09, 14 March 2009 (UTC)
Exactly, WT:EL is the talk page for the guidelines themselves and the talks there are about the wording of the guidelines. We have a noticeboard for BLPs, ethnic conflicts, fiction, fringe theories, original research, copyvio, and spam. Why not one for external links? Themfromspace (talk) 17:52, 14 March 2009 (UTC)

Support. WT:EL isn't at all intended for this. Let's set up a noticeboard and see what happens; if it turns out to be very problematical (can't see why) or redundant (ditto), then it's easy enough to shut it down. -- John Broughton (♫♫) 16:46, 17 March 2009 (UTC)

'Common sense' has to be promoted more

Sometimes people become so fanatical into requiring sources to an article that it makes it look ugly and b) it makes you suspect we're talking about politics, people that's just don't like some common sense stuff and become entrenched into a 'sources hunt'. For example, in digg it is sourced that "there is suspicion that some people bury [vote down] articles they don't like politically". Come on, seriously, of course people downvote things they don't like politically, that's more common sense than gravity working on earth. --AaThinker (talk) 09:51, 24 March 2009 (UTC)

Your quote does not exist in the article. What is in the article says considerably more (it mentions a "Bury Brigade", implying that there is some organized clique of users who do this, and says that this is (according to one commentator) 'one of the site's major problems'), is not obvious, and needs sourcing. Algebraist 12:53, 24 March 2009 (UTC)

Please remember that, along with the principles of NPOV and no original research, WP: Verifiability is one of the fundamental principles of Wikipedia. This does not mean that everything on Wikipedia must be capable of being proven (after all, very few statements are); it means that claims should be backed by evidence through source citation, whether through citation of references in journal articles, in books or on the Web. I am not sure why you consider that having a long list of references at the end of an article would make the article "ugly"; after all, academic textbooks, journal articles, undergraduate and Master's level dissertations and indeed, Ph.D. theses would have lists of references appending them. Also, remember that what is common sense to one personl may not be "common sense" to another person - quite often, one might think that something is sense, but not COMMON sense (if by the term one means that the majority of the population will think that way). ACEOREVIVED (talk) 21:32, 29 March 2009 (UTC)

WP:V only requires that sources be provided for material that is potentially controversial or likely to be challenged. People seem to forget this. OrangeDog (talk • edits) 19:27, 1 April 2009 (UTC)

Minor edits

I hope this isn't a recurrent topic (I don't watch pump discussions that much anymore). In a current RfA, a candidate received criticism for his incorrect marking of edits as minor and I was wondering why we still keep that feature around. I think it's a remnant of the early days of the wiki but here are a few reasons why we should just disable the whole thing. Among the good reasons:

  • Most editors don't use it when editing. If an edit is marked as minor, chances are it's because the editor has "mark as minor by default" in his preferences.
  • Newbies don't know how to use it. Not because they're dumb but because it's not really something they worry about or even know about.
  • Few editors use it consistently and those who do provide good edit summaries. No real gain.
  • No one in their right mind would toggle minor edits off their watchlist. If you do that, then any vandal marking their edits as minor flies under the radar. Also, watchlists now provide the size of the diff which is often a better indicator when you know that the editor can be trusted.
  • Does anyone really see the bold m in the history? Frankly, I don't and it can only be useful if you trust that everyone uses that feature carefully and with consistency. And of course, that's not the case.
  • It's occasionally a source of strife. As in the RfA above or in other contexts where person X accuses person Y of marking an edit as minor although it isn't. This wouldn't really be a concern if the minor edit feature was of any actual use to anyone, but since it's not...

Thoughts anyone? Pascal.Tesson (talk) 00:42, 25 March 2009 (UTC)

I'm inclined to agree with you that Wikipedia would be better off with the simplification of removing this functionality. It's a feature that depends on widespread knowledge and widespread compliance, and that simply isn't going to happen. But: how much work would be for developers to remove minor edits not only from the edit screen but also as a filtering option on many special pages? -- John Broughton (♫♫) 01:05, 25 March 2009 (UTC)
Simply turning it off as an option when editing would be trivially simple. Removing it entirely from the software would be a bit more work; there's at least 14 files that contain "minoredit" not counting all the message files or any maintenance scripts. There's also columns in the revision, archive, and recentchanges tables to store minor edit information. Mr.Z-man 01:41, 25 March 2009 (UTC)
  • I use it often; I don't have "mark [edits] minor by default" set in prefs.
  • Without intending to be facetious, newbies don't know to do a whole bunch of wiki-things, because they're new & haven't learnt yet.
  • I see the bold m. :)
  • My only real point is that I use it often and find it useful. Useful to aid other editors who might have an article, on which I'm making a series of edits of varying degree, watchlisted; and, vice versa. –Whitehorse1 02:14, 25 March 2009 (UTC)
When I see an edit by an editor I know marked as minor (which is most editors I would trust to make good edits in the first place), I assume it's minor and don't bother with it. bd2412 T 03:29, 25 March 2009 (UTC)
If anything I'd prefer the feature expanded so it could be safe to hide minor edits. Specifically:
  • Allow the original editor to change the minor status of an edit. A number of feasible clarification criteria are possible here.
  • Allow the automated reverts and undos to make the revert and the original edits minor.
  • Allow anyone (or more likely logged in users) to remove the minor status of any edit (or just IP edits).
Mark Hurd (talk) 04:21, 25 March 2009 (UTC)

But that would be a complete bureaucratic nightmare, not to mention a big waste of time. I can just imagine the edit wars over the status of an edit! In any case, it only makes sense if everyone is on board which, obviously, will not happen. And that's my argument for removing the feature in the first place: if only a small minority of editors use it then it has no purpose. In my mind, the minor edit checkbox is just a distraction in what's already a fairly non-user-friendly interface. Pascal.Tesson (talk) 19:17, 25 March 2009 (UTC)

The feature can be trivially removed from use by removing the minoredit permission from the 'user' usergroup; it simply won't be possible for anyone to mark edits as minor. There is a minor technical issue in that bots will need the ability to make minor edits in order for their edits to user talk page to not trigger the new messages banner, but that's easily remedied by granting them the permission explicitly. I'm inclined to agree that the feature is largely useless and should probably be removed. Happy‑melon 20:29, 25 March 2009 (UTC)

If you go to "Minor edit", you can press on hypertext which says "What's this?" which should explain to any one what a "minor edit" is. Personally, I think the feature is quite useful myself. If one looks at the history of an article, it enables which of the edits are mere minor corrections, such as proof-reading corrections (for example, correcting a word that was formerly spelt wrongly), and which of them represent substantial changes to content. I expect that people are more likely to compare versions of past articles in cases where edits have not been marked as minor. ACEOREVIVED (talk) 19:57, 28 March 2009 (UTC)

I too find it incredibly useful when searching for content edits in page histories, as well as looking over my watchlist. I mark all my minor edits as minor to likewise help others. Why remove a feature that is both useful and does no harm? OrangeDog (talk • edits) 19:31, 1 April 2009 (UTC)

April 1st guidelines for 2009

This issue comes up anually and I would like to make it this year. This could have been posted on Talk:Main Page, WT:FAC, and WT:DYK, so this is a central discussion. I would like to propose the following:

  • The main page FA must meet the FA criteria, same for the FP
  • The DYK must follow the criteria it follows all year, same for on this day and in the news.
  • All articles are to remain in tact

The following thing will be permitted that would normally be struck down as per WP:POINT or WP:DE:

  • Humorous project pages may be created
  • Humorous RFAs, XFDs, PERMs, RFPPs, and VP proposals

Like the idea?--Ipatrol (talk) 22:56, 25 March 2009 (UTC)

Agree, there should be some April 1 spirit on the Main page. There is a discussion going on for a while already, check Wikipedia talk:April Fool's Main Page.--Tone 23:07, 25 March 2009 (UTC)
Yep, DYK made a decision long ago to still follow the regular DYK criteria. The only difference is that the April Fool's DYK hooks are allowed (and expected) to be misleading, which is discouraged in regular DYK hooks. rʨanaɢ talk/contribs 23:10, 25 March 2009 (UTC)
Isn't this... just what we do anyway? It seems a bit odd to go to the effort of producing guidelines to tell us to keep doing what we'd do regardless. Shimgray | talk | 23:23, 25 March 2009 (UTC)
Yarly. WT:AFMP has this covered already, including criteria for inclusion. Besides, they have developed better criteria than yours for eg DYK, and I don't see how creating frivolous project pages is a good thing. Modest Genius talk 01:10, 26 March 2009 (UTC)
There is another exception: We normal use a 5-day period to evaluate the DYK articles. For April Fool's Day, we have always accepted nominations that were created or expanded 5x at any time during the prior year. We have dozens of DYK articles that were created in good faith in the past year using this assumption. DYK are expected to be misleading/misdirected. Featured Picture and Featured Article criteria say that it has to be featured through the normal process. Royalbroil 02:00, 26 March 2009 (UTC)

Agreed, lets keep April 1st special .... as usual. Breaking the rules is something that requires that extra effort on April 1st. Luckily we have responsible and fun loving editors. Not sure we need extra guidelines, but dusting them may advertise the event.Victuallers (talk) 17:26, 26 March 2009 (UTC)

This proposal has rather a lot of the "All festive frivolity must be strictly within authorised merriment guidelines!" over-regulation. Previous April Fools' pranks that went too far have been dealt with appropriately as they crop up - there is no need to proactively anticipate problems and come up with guidelines. ~ mazca t|c 21:29, 27 March 2009 (UTC)

I think April Fools shenanigans are OK as long as it's kept to Wikipedia and User namespaces and it doesn't cause undo insanity. Also, in keeping with our tradition for the last few years, the FA was chosen and written up in such a way that everything in it is true, but hopefully people will write it off as an obvious hoax. Raul654 (talk) 21:35, 27 March 2009 (UTC)

  • If people are ever going to take us seriously then this is just an excuse not to, all my friends laugh at me because I frequently edit here, they see it as a joke, something to vandalise, and yet the edits here are just as disruptive and untruthful as anything they could do. An encyclopedia should be factual, and no matter how true the stories are, they deliberatly mislead, if a newspaper did that they'd get sued! Highfields (talk, contribs, review) 18:21, 1 April 2009 (UTC)

You don't mind if WP:BAD is un-historicaled for April Fool's Day, do you?

....hmmm... 192.12.88.7 (talk) 05:33, 1 April 2009 (UTC)

I see a certain editor or two failed to notice this in the Village Pump. 192.12.88.7 (talk) 15:04, 1 April 2009 (UTC)

Download size options on featured pictures seem to be either small (the size it appears on the page) or whoppingly large (17MB on today's FP). It would be useful if one could choose from a range of download sizes after right-clicking. ciao Rotational (talk) 07:15, 1 April 2009 (UTC)

  • I agree that it would be handy if Wikipedia offered this on the image page, but regarding right-clicking, this is a browser function and Wikipedia could not control the options you get when you right-click. Just being pedantic, but wasn't sure if you were aware of that. Diliff | (Talk) (Contribs) 07:22, 1 April 2009 (UTC)
  • Thing is there are no standardly generated sizes, the smaller versions for thumbnails on pages are dynamically generated by the Mediawiki software when the pages are rendered. The only one that is vaguely consistent is the large thumbnail used on image pages. That's not to say that its not possible to have a page with for example 1024, 1600 and 1900 wide versions of the picture of the day for people to easily drag onto their desktop, just that no one has done it. Mfield (Oi!) 07:26, 1 April 2009 (UTC)
  • You could add [[File:Example.png|2000px]] to a random page, preview and download the resulting picture but that's rather awkward. MER-C 08:45, 1 April 2009 (UTC)
  • Something like the options given on the Hubble site http://hubblesite.org/newscenter/archive/releases/2009/13/image/a/ Very user-friendly Rotational (talk) 09:58, 1 April 2009 (UTC)

New Footnote Tags

I propose that superscripted footnote-tags be created for each of the following six scientific classifications, all of them found in Wikipedia: in vitro, in vivo, in situ, ex vivo, in utero, and even in silico.

Need: to uniformly and concisely impart to the reader the specific nature of the experiment being referenced by footnote. Implementing this change would also effect a needed review of references.

Problem to solve: A footnoted statement of fact in an article may imply, for example, an in vivo context, yet the study referenced may actually be strictly an in vitro one. This proposed change would prevent that confusion by means of an identifier in the superscripted footnote itself. Eye.earth (talk) 13:53, 26 March 2009 (UTC)

If the article text and the information in the related footnote are not consistent, then the article text should be changed so the text and the information in the related footnote are consistent. Then there won't be any confusion at all. -- John Broughton (♫♫) 01:15, 29 March 2009 (UTC)

In theory. But consider a current problem, from the "Mode of Action" paragraph in the AZT article. At this writing a sentence is in dispute:

"However, AZT has a 100-fold greater affinity for the HIV reverse transcriptase than for the human DNA polymerase alpha, accounting for its selective antiviral activity."

That sentence currently has two supporting footnotes. Both refer to in vitro experiments only. However, only one experiment has in vitro in its title. To ensure that no one assumed an in vivo affinity I changed the sentence to:

"However, in vitro AZT has . . . "

That single 2-word phrase has led to an edit war. With standardized footnote-tags, this kind of dispute could be avoided, as casual readers would immediately see that both footnotes refer to in vitro experiments and could then draw their own conclusions. Basically this suggestion is an attempt to make inferences drawn from references editor-proof.

If there's an edit war over having this in the text, surely there'd be an edit war over using <ref name="foo" type="invitro"> for the reference tags? If it's just a matter of people not wanting to clutter the text, then there's no reason we can't note in the footnote that it's in vitro (or whatever) - "In vitro results; [citation]" - in much the same way as we add other explanatory notes to footnotes when something isn't clear. Shimgray | talk | 21:15, 2 April 2009 (UTC)

I think it would be much harder to edit-war over what is essentially a binary distinction: an experiment is likely to be either one classification or another. Experiments that encompassed multiple environments could be labeled with a hybrid tag. There would continue to be arguments over whether results could be assumed for another classification, but probably not over the experiment itself. (Odd thought: would future experimenters, if finding such tags inherently useful, incorporate them into the footnotes of their own references when their experiments are published?) Experiments that couldn't be classified with any of the tags would be conspicuous by the lack of a tag, and that might cause arguments in favor of creating tags for such situations. But that would be good, as it might bring to the fore aspects that if hidden could lead to wrong conclusions on the part of a casual reader. I agree that clutter shouldn't be a factor. What is informative in an efficient way can't be clutter. But clutter could result if the tags became too general. They should be specifically meaningful at a glance.

Just a bit of context: User:Eye.earth is seeking support for his or her attempts to insert information into Zidovudine implying that anti-HIV drugs for some reason do not work in vivo, a central belief of AIDS denialists that is not supported by reliable sources. How the above proposal would provide such support is unclear. In any case, the distinctions made by Eye are also unclear. For example, why in utero in addition to in vivo? Keepcalmandcarryon (talk) 23:20, 3 April 2009 (UTC)

Why in utero in addition to in vivo? Most studies would probably need only one as appropriate. But citing both classifications could be plausible for experiments of multiple parts with conclusions drawn separately therefrom, especially if those conclusions are referenced in text.

Readers interested in the dispute in question can see my Request for Comments at: http://wiki.riteme.site/wiki/Wikipedia:Requests_for_comment/Maths,_science,_and_technology listed under Talk: Zidovudine. Eye.earth (talk) 02:48, 4 April 2009 (UTC)

Admin bit to set or clear article display in categories

I would like to suggest adding an extra bit to categories that admins can set to switch on or off the appearance of individual articles (rather than subcats). The category tree tends to get very messy as people often aren't sure which categories or subcats to put their articles in. If we had a bit that admins could set however, it should help the various wikiprojects to set which cats do or don't display articles, and by doing so bring a little more order into what is often a pretty chaotic part of the project. Gatoclass (talk) 05:55, 2 April 2009 (UTC)

I'm a little confused - is this set the category to not display articles for you-the-viewing-admin, so there's less clutter when you're working with them, or not display articles for anyone? The problem with this latter one would be that people probably won't notice they're miscategorised...
(In practice, this sounds relatively workable - something like the "don't display thumbnails" magicword - but I'm not sure of the practical benefits) Shimgray | talk | 21:00, 2 April 2009 (UTC)

Two letters code for musical instruments abbreviations

I have been discussing lately with some friends in a private form the need to indicate (and standardize) common abbreviations of popular musical instrument's names and we came at THIS research starting point. I am not a daily contributor of the wikipedia but I would appreciate your opinions on this matter. The idea is to add the gathered information to the basic info of each musical instrument. Do you find it appropriate?--Florenus (talk) 20:01, 2 April 2009 (UTC)

Is there a more specific discussion place inside the English wiki (for music matters I mean) for me to post and share opinions on this proposal? --Florenus (talk) 20:04, 2 April 2009 (UTC)

I applaud your work in this area, however Wikipedia is not a publisher of original thought: that is, we do not publish our own work, only the thoughts and opinions of other reliable sources. So while you have a good idea here to create a standard convention for instrument abreviations, it should come to wikipedia from an outside organisation such as the ISO, rather than the other way around.
You may find the people at WT:MUSIC or WT:MUSINST interested in the idea, however. My immediate reaction is to say that, while a very good idea, 676 unique codes is very unlikely to be enough to describe all the world's instruments; you probably need three letters if not four. Happy‑melon 20:19, 2 April 2009 (UTC)
As I am trying to explain this is not my own work. I report here a part of the discussion with User_talk:RHaworth: For us common abbreviations of musical instruments are part of the Wikipedia content. Language is not a personal opinion.--Florenus (talk) 19:29, 2 April 2009 (UTC)
Who are "us"? But the operative word is "common". Give me an example of a two-letter abbreviation which is in common use. — RHaworth (Talk | contribs) 19:34, 2 April 2009 (UTC)
The practice is quite typical in artists curriculums or concert programs. Just one: http://www.massimilianomotterle.com/repertoire.htm See "Chamber Music", (in Italian "cameristico", http://www.massimilianomotterle.com/repertorio1.htm): "L. Van Beethoven: Quintetto per pf., cl., fag., ob., cr. in Mi bemolle Maggiore op. 16". But I can show you many. The abbreviations are common in this kind of language. It is right that the wikipedia shows the meaning of the word "op." : http://wiki.riteme.site/wiki/Abbreviation#Plural_forms so, as a reader, I would find logical also to find the meaning of the abbreviations pf., cl., ob., cr., etc..--Florenus (talk) 07:48, 3 April 2009 (UTC)

--Florenus (talk) 07:57, 3 April 2009 (UTC)

If there is some reliable source showing standard use of a particular two-letter abbreviation for an instrument, that should be mentioned in the article on that instrument, and on the disambig page for the two-letter combo. As far as defining these in individual entries, that belongs in Wiktionary. bd2412 T 18:13, 3 April 2009 (UTC)

Closure of English Wikipedia

Please post your thoughts here. Thanks, Majorly talk 14:09, 1 April 2009 (UTC) Are you serious, or this a belated April Fool's Day joke? I say belated, because I note that the time of this edit was 14: 09, which according to an old tradition, is too late to play April Fool's Day jokes. April Fool's Day only lasts until noon; otherwise, you will risk being greeted with these words:

April Fool's Day passed and gone

You're the fool, for carrying on.

By the way, if this was a serious proposal, and the English Wikipedia were to be closed, bear in mind that it would only get recycled on a website such as Includipedia or AntiWikipedia or at least somewhere on the web. ACEOREVIVED (talk) 19:32, 2 April 2009 (UTC) Well, I suggest that as from today, any one concerned about this should look at the tag which now heads the page! ACEOREVIVED (talk) 18:46, 5 April 2009 (UTC)

Reviewer usergroup

As we're progressing towards an implementation of flagged protection and patrolled revisions, it becomes necessary to decide the requirements for the reviewer usergroup, in particular for autopromotion, please discuss at Wikipedia:Reviewers. Cenarium (talk) 14:55, 4 April 2009 (UTC)

A tag for signalling a weak citation

In the Monomyth article, its 5th citation link says only "Northup, p. 8", and in Comparative mythology the 8th citation is identical. So I researched online and didn't come up with anything, it seems original research being claimed as fact.

To quote from the Monomyth entry: Although well-known in popular culture, the monomyth has fallen out of favor in academia, which currently leans away from comparative mythology (comparativism) and toward particularism.

To quote from the Comparative mythology entry: However, modern-day scholars lean more toward particularism, feeling suspicious of broad statements about myths.

I'd like to highlight the linked citation as weak or too insufficient. "Northup, p. 8" doesn't really help to verify and further research the source. boozerker 18:59, 6 April 2009 (UTC)

What research did you do? Have you checked the given reference, "Northup, Lesley. "Myth-Placed Priorities: Religion and the Study of Myth". Religious Studies Review 32.1(2006): 5-10"? Algebraist 19:18, 6 April 2009 (UTC)
Ah, further down. But shouldn't the source be listed in the numbered citation? Also, we can still use a tag for really bad citations. boozerker 19:23, 6 April 2009 (UTC)
It's one of the standard ways of presenting references (see WP:Citing sources#Shortened footnotes). Not sure abount the mix of styles in a single article, though. Algebraist 19:28, 6 April 2009 (UTC)
You probably want one of these templates:
--—— Gadget850 (Ed) talk - 19:32, 6 April 2009 (UTC)
Thank you. If encountering a bad cite, should I put the tag next to the cite # in the article paragraph, or down at the bottom of page in the reference list? boozerker 20:58, 6 April 2009 (UTC)
Inline after the <ref>...</ref> in the body. --—— Gadget850 (Ed) talk - 21:01, 6 April 2009 (UTC)

AES

A proposal has been made at MediaWiki_talk:Revertpage#AES, however, additional discussion is needed. -- IRP ☎ 22:14, 6 April 2009 (UTC)

at time zone to time stamp at bottom of articles "This page was last modified on [dd month year, at xx:xx]"

time stamp at bottom of article fails to provide time zone (current: "This page was last modified on 2 April 2009, at 08:02."). thus, a printed version read by non-wikipedian (and probably many wikipedia users) are clueless that times on wikipedia are in "UTC" (i think it is UTC; somewhere that information is buried within wikipedia; sometimes i stumble upon a usage, but i always have trouble finding it when i want it and i'm sure i'm not the only one).

of course ideally, all time entries (history, discussion, etc.) would indicate which time zone is used.--71.183.238.134 (talk) 08:33, 2 April 2009 (UTC)

This can't be done easily. MediaWiki:Lastmodifiedat could be edited to indicate UTC, but then it would be wrong for anyone who's said their time preferences to anything other than UTC. This might be one to bug the devs with. Algebraist 11:53, 2 April 2009 (UTC)
If someone changes their Date/Time preference, the time at the bottom reflects that. -- lucasbfr talk 15:04, 7 April 2009 (UTC)

Wikipedia and the Internet

I'm not a fan of exceptions, and I love rules. But far too many people on Wikipedia make it their mission to try to remove as many "deficient" articles rather than spend their time creating new ones. Far too many people feel some sort of thrill from having someone's hard work be deleted by slapping them with some rule or criteria. We have too many wiki-cops and too little wiki-artists.

We can say youtube is a site to post videos and Google is a search site. And we can say Wiki is an encyclopedia. But we all know these three are the big e-triumvirate that have grown far past what they were meant to be, to the point that google and wiki have become verbs (even youtube now, "go home and youtube it".

And as much as we have rules for notability, such as having more sources other than let's say Youtube itself. Wiki has to realize that Youtube is a category in itself. Having 17,000,000 views mean at least let's say 50,000 people a year at LEAST (or if you want to be conservative 5,000) will see some reference to Happyslip somewhere online/or hear about it(such as I did), and want to find out more about it. Knowing that even 1,000 people want a reference to it, should be enough. Youtube works more through word of mouth anyway, which is hard to document, who hasn't seen "Charlie Bit me"? I've been in drugstores and heard people talk about it, I've seen mothers put their finger in their children's and say, "ouch Tommy, Tommy bit me!". The beauty about Wiki is that it's not a cut and dry encyclopedia. It also documents e-life, e-phenomenons, and is basically an encyclopedia for us, the surfers. It's an edgier encyclopedia, and while we want to hone our accuracy and dependability, let's not forget that.

We also need to relax and realize that things can be notable now, or have BEEN notable. So for example, when a guy is lost at sea, and the media is buzzing about it. It's everywhere on the news for weeks, and someone adds it here. Three weeks later because the media died down about it does not make it less notable. What happens 5 years from now if the guy is found, and someone wants to see a reference to what they are talking about?

I realize this is not myspace, a forum, or a blog, but I believe there can be a peaceful coexistence between the serious academic and purely entertaining notability. When an article such as the "numa numa" guy faces problems it scares me! As long as an article is unbiased, neat, organized, and facts properly sourced, why work so hard towards deleting it?

I wonder if we could have some sort of view counter on pages, it would certainly help to see just how many people are accessing a page. (I'm hoping at least that would help show how notable something is)

This is just a friendly reminder for us to all take a big breath and care a little less about what grade an article would get. While an A article is beautiful, so is knowing you wrote down a little piece of history.

I sorely apologize if this sounds a bit like ranting. It's not, it's an honest effort to get people to stop a moment and readdress what we want to be, and how to get there. Wiki has matured into something more than just an encyclopedia, and that's a good thing. Pointing to a "WP:whatever" should not be the end of any discussion nor should it be unmalleable. I apologize in advance for my English and I appreciate any feedback. 75.69.233.90 (talk) 22:49, 3 April 2009 (UTC)

It is possible to see how often a page has been viewed, by going to the history tab then clicking 'Page view statistics', although it is a bit hidden away. However, it can be difficult to use the number of page views to judge a subject's notability. For example, this page shows the most viewed articles in August 2008. In position 6 is Wiki, which I'm sure you'll agree is not the sixth most notable subject in existence. Looking through the list, there are plenty of pages there because their subjects are well known, or in the news at the time. It's necessary to use other methods of determining a subject's notability, apart from its number of views. Tra (Talk) 09:08, 4 April 2009 (UTC)
Wikipedia's size also means its effect on the real world is increased. Creating articles about barely notable or non notable people is a recipe for disaster with regard to false statements and libel. Mr.Z-man 18:11, 4 April 2009 (UTC)

I hope you are correct about Wikipedia being big on the Web (I look at it often, but hardly every look at You Tube myself). What you seem to be concerned about here is that Wikipedia has a number of users who identify themselves as "deletionists" and also that to judge a topic as "notable" is not an all-or-none matter. I agree with you that Wikipedia has now grown beyond something similar to a standard printed encyclopaedia - although we are not Wikinews, the coverage of up-to-date media topics does help it to bridge the gap between newspapers and encyclopaedias. To console you about deletionists, can I point out that there are Websites out there such as Includipedia or Antiwikipedia which seem to exist to recycle deleted Wikipedia articles. However, I am inclined to agree that one must use other methods to determine an article's notability than the number of times it has been viewed - a subject in the news might have had many hits, whereas some obscure topic which is known to be important to experts in the field might have few hits, but still be judged important by experts. Also, I already think Wikipedia has balanced the "seriously academic" and the "purely entertaining" well, as it is well-known that there are many articles on popular media culture in Wikipedia.

These are my own personal reactions to the above comment, and do not necessarily represent the views of the Wikipedia community as a whole. ACEOREVIVED (talk) 18:59, 5 April 2009 (UTC)

Three weeks later because the media died down about it does not make it less notable. What happens 5 years from now if the guy is found? Our approach to notability is that if a subject is notable now, it automatically stays notable in the future. Or, if you will, we don't delete articles because very few people are interested in a topic, or very few people are reading that particular article; we look at sources to determine whether the subject of the article ever was notable. So, in your hypothetical case, in five years the article will still be in Wikipedia.
Looking at the various links in Wikipedia:Article Rescue Squadron should make it clear that the issue of excessive deletions have been discussed before. Do keep in mind that much, quite possibly the vast majority of articles that are deleted are pure drek (and are deleted via CSD); only a small fraction of articles are deleted via discussion (AfD). -- John Broughton (♫♫) 01:39, 6 April 2009 (UTC)
  • Articles created by true 'wikiartists' as you call them, 75.69.233.90, are unlikely to be affected because those are rarely deficient in anything. The easiest way to solve this, is simply not to rush article creation. I've already had at least one great example in my own creation log. When I first wanted to create Louis Barnett (chocolatier), only a handful of references were available. By being patient and waiting for a couple of months I ensured that the resulting article I wrote was of sufficient quality. - Mgm|(talk) 08:26, 6 April 2009 (UTC)
  • Some experience patrolling new pages would likely change your point of view. You say "as long as an article is unbiased, neat, organized, and facts properly sourced, why work so hard towards deleting it?". We don't work so hard towards deleting those, we work so hard towards deleting all the other ones, those that do not, will not be unbiased, neat, organized and properly sourced often precisely because the notability of the subject is nil. Obscure bios or pages on high school bands or unknown rappers created out of vanity, hoaxes, nonsense, essays and original research on a variety of subjects, fancruft, POV forks, advertisement ... a ton of articles are created every day that do not and cannot meet the standards set by the community. The AfD process which I believe you are thinking of, is just the tree before the forest, most articles that are deleted do not reach AfD, they are quietly swept away by new page patrollers and admins, "speedy deleted" or more slowly (WP:PROD). Few reach AfD not because "wiki-cops" are nasty people hell bent on disposing of someone's work while nobody's looking, but because they are so below the standards set by the community that it would waste everyone's time and require more "wiki-cops" and "wiki-lawyers" if they did. Now some deletions are contentious, *some*, that's why the AfD process exists, that's were the community deals with borderline cases or at least disputed ones. We *need* standards, or Wikipedia wouldn't be anything like an encyclopedia, and we *need* what you call "wiki-cops" otherwise standards are of no use. There are standards you might not agree with, for instance you might think short lived internet buzz establishes notability, many however do feel that it's a playground for original research and unverifiable assertions. If it takes an AfD nomination to find out if a given article meets standards, then so be it, it's not a punishment, it's not a bad grade, it's just a useful process. Equendil Talk 12:42, 7 April 2009 (UTC)

changing text of edit summary field

Recently on wikien-l Erik Moeller mentioned that on de.wp they have changed the text of their edit summary field to read "Summary and Sources" instead of "edit summary." Apparently lots more new editors started including URLs etc. What do people think of trying this out on en:, as well? Could be an easy way to up sourcing. -- phoebe / (talk to me) 21:37, 4 April 2009 (UTC)

Wouldn't this make people put their sources in the edit summary box instead of putting them in the article? It would be a bit confusing to tell editors that their sources should go in the edit summary box, when they really need to show up at the bottom of the article. Tra (Talk) 21:54, 4 April 2009 (UTC)
yes, it could lead to that, but I think the point is that it's easier for an experienced editor to pull a source from the edit summary and add it in the right place than it is to find a new source from scratch. Also, it reminds new editors that they have to have sources. Footnote syntax and refsections are confusing enough that people often skip it altogether. There might be better phrasing than "summary and sources" possible. -- phoebe / (talk to me) 22:13, 4 April 2009 (UTC)
It would be a lot of work to have to keep going after each edit that puts the source in the edit summary box. I think it would only be worth it if it caused a substantial increase in sourcing. It might be useful to look at the German Wikipedia and take a random sample of edits before and after the change. You could then classify them into vandalism, edits not requiring sources, edits which need a source but don't have one, edits with the source placed on the article and edits with the source placed in the edit summary. The number of edits of each type could then be compared between before and after the change. Tra (Talk) 09:30, 5 April 2009 (UTC)
  • Tend to Oppose because Edit Summaries already have to bear a huge burden in a relatively cramped space, chiefly both what you did and why. Besides your motive, "why" also often includes external reasons that justify your edit (such as policy or a source). At the moment, most edit summaries don't meet (at least formally speaking) both the what and the why, often with unfortunate results, such as abbreviations that are incomprehensible to most ordinary editors, or necessarily-terse reasons that look peremptory, arrogant, hostile or just plain rude. There's also overcompression that hides (often unintentionally) something with which not all other editors might agree, such as "RVV" or "cleanup", tell-tale terms that many of us have learned to view with skepticism when posted by an unfamiliar editor. ¶ However, I'm not opposed to the idea of encouraging editors to give some indication of the source or policy (even though I'm a rank libertine and anarchist who thinks the Manual of Style should be far more permissive and about 5-10% its present monstrous size), so long as sources are also properly posted in the footnotes. Would greatly expanding the size of an edit-summary box, or adding a second one for sources help? —— Shakescene (talk) 07:03, 6 April 2009 (UTC)
  • Strongest possible oppose - makes things very confusing, will obviously reduce in-article citations (which are extremely useful), and generally makes it harder to check if things are original-research or not, for example. Also makes us vulnerable to spam/attack page URLs, as summaries can presumably not be edited by admins. ╟─TreasuryTag►contribs─╢ 07:19, 6 April 2009 (UTC)
  • Oppose, unnecessary. –xeno (talk) 19:02, 6 April 2009 (UTC)
  • Oppose, providing sources is not what the edit summary is for. Equendil Talk 12:50, 7 April 2009 (UTC)
  • I oppose this proposal on the grounds that it effectively asks people to put their sources in the edit summary box, which is not where the sources should be—that description would be misleading. Moving sources from the edit summaries to the article could constitute a significant amount of unnecessary work. If we had an "auto-append ref with contents of box X to addition" feature, however, that'd be a different issue {{Nihiltres|talk|log}} 15:15, 7 April 2009 (UTC)
  • Support something needs to be done to stop unverified claims going into articles. People saying it's not what the box is for well the keyword is OR. Pragmatically, there is evidence from the german Wikipedia that sourcing is on the increase. As an aside, I'm sure someone could develop some sort of script or bot to apply the sources from the summary retrospectively. --DFS454 (talk) 16:01, 7 April 2009 (UTC)

Watchlist tweak.

Often when browsing my watchlist, I find something completely unrelated to my interests. It would be nice to be able to remove articles directly from Special:Watchlist, either through an (diff; hist; unwatch) link or through a checkbox. Headbomb {ταλκκοντριβς – WP Physics} 08:11, 6 April 2009 (UTC)

There are several scripts for this at WP:JS. Algebraist 09:05, 6 April 2009 (UTC)
WP:POPUPS works well for this. –xeno (talk) 19:02, 6 April 2009 (UTC)
See user:js/watchlist for an easy solution: just install on your monobook.js page as instructed. Gwinva (talk) 09:42, 7 April 2009 (UTC)

Redirect Category:uncategorised to Category:uncategorised pages

The former is a historical category with no pages. I propose a redirect to the proper page. --DFS454 (talk) 18:59, 6 April 2009 (UTC)

WP:CfD is the place for this I think. OrangeDog (talk • edits) 23:19, 7 April 2009 (UTC)

Extending Wikipedia: Biographies_of_Living_Persons

Can I please suggest that WP: Biographies_of_Living_Persons policy be extended to include the recently deparated, as well as those still living? Recently, I found out (incidentally, from Wikipedia) that the Japanese theologian Kosuke Koyama had died on March 25, 2009, and put up the "recent death" tag on his page. As this is now more than a week ago, this tag was removed as from today (April 4, 2009). However, looking at the talk page, I see that this page still has the bit about biographies of living people having policies that need to be adhered to, and I did not remove this for this reason. I have wondered whether we should not merely have a policy to protect privacy of living individuals, but also those who, for example, have died in the past five years.After all, there are privacy laws which do exist, I believe,for 40 years (correct me if I am wrong). If a person has died and is therefore technically not a case for Wikipedia: Biographies_of_Living_Persons, that person could still have (and in many cases, would have) relatives who are still living, so we must be extremely cautious about avoiding contentious statements that could be offensive to relatives of a recently deceased individual. I shall be interested to see whether Wikipedia is going to extend this policy.ACEOREVIVED (talk) 21:29, 4 April 2009 (UTC)

  • Disagree - BLP is a very restricted policy for a very specific purpose: that eventualism is not workable for BLPs for very specific reasons. The case of the relatives must also be specific to material about them; because they may not like an article is not the species of harm caused by a bad BLP, not even close. BLP carries enough practical risk of NPOV violations; its scope must be kept very restricted indeed for this reason - David Gerard (talk) 21:43, 4 April 2009 (UTC)
  • Disagree. While courtesy suggests we wait a decent interval before adding anything that might offend the survivors, we should not enshrine courtesy a requirement in BLP the policy. I agree with David Gerard that the scope of BLP should be strictly limited to living people.   Will Beback  talk  21:54, 4 April 2009 (UTC)
  • The policy did formerly extend to "recently deceased" people, but that seems to no longer be true. In any case, Wikipedia:Biographies_of_Living_Persons#Dealing_with_articles_about_the_deceased appears to cover that aspect well enough. — Gavia immer (talk) 04:11, 5 April 2009 (UTC)
  • Support The key point is proper referencing and solid editorial control. Just because a person died and can't sue us, doesn't mean it's a good idea to have unreferenced contentious/controversial material in their article. By not including dead people in an overall People policy, editors tend to ignore the fact that all material should be cited and that contentious material is no different. - Mgm|(talk) 12:52, 9 April 2009 (UTC)

Hide footnotes for printing

Hi,

I would really appreciate if you could include a function so that you can hide the footnotes in the printable version. It would save me la lot printing paper, and it could be an optional setting, sothat the ones who want the footnotes can keep them. Furthermore you could also include an option to hide the Reference out of the printable version.

Sincerely yours, pascal —Preceding unsigned comment added by 87.66.148.198 (talk • contribs) 


ol.references, .references-small *.printonly {display: none;}
  • Follow the instructions at the top of monobook.css to bypass your cache

--—— Gadget850 (Ed) talk - 17:03, 7 April 2009 (UTC)

Excellent suggestion pascal. Gadget850, It might be really helpful to include a button that does the same, for printing. Lots of news sites and web pages have the option to get a clean print. If the option must be hunted for, people aren't likely to know it's there.
Here's the first example using a New York Times article on Wikipedia.
[10]
The print button there is highly visible and gives us this next page.
[11]
Any thoughts? boozerker 18:32, 7 April 2009 (UTC)
Not only do we have a link in the sidebar to the printable version, any decent browser will default to the printable version if you try to print anyway. Footnotes are an integral part of the article, so I don't think they should be left out of the printable version by default. Algebraist 19:02, 7 April 2009 (UTC)
Print styles are automatically applied unless your browser does not support CSS; for those, we have the "printable version" link on the left sidebar. See Help:Printable for more info (I have been rewriting this help page). We don't print elements such as section edit links, navboxes, article message boxes and more. Printing references should be a matter of personal choice; I don't think this should be non-printable by default. --—— Gadget850 (Ed) talk - 19:09, 7 April 2009 (UTC)

Let me try this again. The previous rule will neither display nor print the references. To display but not print, use this rule: 

@media print {
    ol.references, a.references-small {display: none;}
}

--Gadget850 (talk) 19:48, 8 April 2009 (UTC)

Repurpose of Template:Picture of the day

I recently came across this template, as it was tagged on a file in the Special:UncategorizedFiles. While it being picture of the day is worthwhile and all, I don't think this template should be transcluded on the front of images. Like featured article and good article milestones that are accomplished on Wikipedia, I think this template would be best repurposed to the talk page of the image, instead of the actual image itself. Doing this would stop the false leads into finding uncategorized files (since most featured images are on the commons, a lot of uncategorized images tend to be wikipedia file pages with nothing but the potd template on it). — Moe ε 22:27, 8 April 2009 (UTC)

Nobody reads image talk pages. Anyway, anything with a POTD tag on it should also have a {{FeaturedPicture}} or a {{FormerFeaturedPicture}} on it, which would resolve the problem of being uncategorized. MER-C 08:28, 9 April 2009 (UTC)

RFC: Notability of free open source software

Wikipedia is currently missing a standard of notability for free open source software. I wrote a proposal at Wikipedia:Notability/RFC:Notability of free open source software and would welcome your comments. Thank you, Dandv (talk) 04:45, 10 April 2009 (UTC).

Referencing stats

Not really a proposal, other than we should have better stats regarding quality control. Anyways, at User_talk:Peregrine_Fisher#Referencing_stats one of the nice bot operators has come up with some stats about referencing efforts. Check it out. - Peregrine Fisher (talk) (contribs) 04:54, 10 April 2009 (UTC)

'Confirmed' usergroup

We had some discussions on the ability to grant or remove 'autoconfirmed' status, for example here, but it wasn't conclusive. So I propose to create a usergroup confirmed, with an autopromotion identical to the autoconfirmed requirements. I think it's feasible since the 'editor' usergroup in the extension FlaggedRevs has an autopromotion. So it could be granted and removed by administrators, and would be automatically granted by the software when the user meets the 'autoconfirmed' requirements. Cenarium (talk) 17:56, 25 March 2009 (UTC)

Currently the autopromotion system used by FlaggedRevs is different from the one used in the core software. There's a somewhat hacky way to do it with the current core version (create a "non-autoconfirmed" group and require that users not be in it to be autopromoted). Mr.Z-man 18:10, 25 March 2009 (UTC)
So we'd need an extension, such as FlaggedRevs, to make it non-hacky ? Cenarium (talk)
Or the FlaggedRevs autopromotion system would have to be moved to core. Mr.Z-man 18:17, 25 March 2009 (UTC)
Thanks, if there's consensus for this, we'll open a bug then. Cenarium (talk) 18:33, 25 March 2009 (UTC)
We may have other groups with autopromotion in the future, so it would be worth to have an autopromotion system available in the core I think. Cenarium (talk) 10:32, 26 March 2009 (UTC)
This new user group is supposed to have 'autoreview' right? Ruslik (talk) 20:05, 25 March 2009 (UTC)
In the flaggedrevs proposal yes, like autoconfirmed, but this can be done independently. Cenarium (talk) 10:32, 26 March 2009 (UTC)
It can be instead of autocomnfirmed. Ruslik (talk) 11:01, 26 March 2009 (UTC)
Autoconfirmed would be deprecated. It would probably require much rewrite. Cenarium (talk) 12:28, 26 March 2009 (UTC)

The usergroup 'uploaders' could also be deprecated as superseded by 'confirmed'. Possible uses could be:

  • granting: when needed, a new user known to be trustworthy (for example, from other projects, or a wmf account), a bot account (for a trial, etc), restoring the confirmed status when previously removed
  • removing: vandalism, in particular on semi-protected pages, when the vandalism is insufficient for a block (confirmed users are able to perform actions like move, edit semi-protected, and are cleared from certain abuse filters, so the potential damage would be much weaker if the permission is removed) Cenarium (talk) 13:12, 27 March 2009 (UTC)


Poll on (auto)confirmed usergroup

This is a poll/discussion to see if there is support to deprecate the 'autoconfirmed' implicit usergroup and replace it with a usergroup 'confirmed' that is granted automatically to users passing the 'autoconfirmed' requirements and can also be granted and removed by admins. So said otherwise, do you support or oppose a modification of the 'autoconfirmed' permission so that it can also be granted and removed by admins ? Cenarium (talk) 18:14, 27 March 2009 (UTC)

  • Oppose - it makes life very complicated, and would require complex structures and policies to be built up (when is it appropriate to add/remove confirmed status? for how long?), and adds little helpful utility. However, I support a system where Abusefilter-editors can re-add the autoconfirmed status of users who have been "wrongly" demoted, if there is not already such a mechanism (not quite clear from the proposal). ╟─TreasuryTag►contribs─╢ 18:22, 27 March 2009 (UTC)
    This feature does exist. Happy‑melon 18:34, 27 March 2009 (UTC)
    It shouldn't require complex policies, it didn't require complex policies for removing rollback, or adding it, and it's much easier here. We have a problem when an autoconfirmed user vandalizes and remains unblocked, or is blocked temporarily, because the vandalism activity is not sufficient. Autoconfirmed users are immune to many vandalism-related tools, for example some abuse filters, because it is assumed that an autoconfirmed user has been around enough so that they aren't a vandal - or they would have been blocked. A criteria for removing autoconfirmed should be simple: vandalism. Being able to grant autoconfirmed rights prematurely would be helpful for bots, and good-faith new users needing the rights. Cenarium (talk) 20:53, 28 March 2009 (UTC)
  • Support in principle, but a change to this effect should be enacted by making 'autoconfirmed' an explicit group in MediaWiki. Essentially the same effect, but with less fuss. I have complete faith in our ability to cope with the not very complicated at all structures that would be needed. Happy‑melon 18:34, 27 March 2009 (UTC)
  • Oppose the proposal as stated. Just make "Autoconfirmed" removable, and don't automatically readd it if it's been removed. Nothing else is needed. — Gavia immer (talk) 18:45, 27 March 2009 (UTC)
    Ironically, this is essentially what I'm suggesting in my post, with completely the opposite caption :D Happy‑melon 18:54, 27 March 2009 (UTC)
Yes it is. It's purely a matter of semantics - but I preferred to confound the polling thing a bit. — Gavia immer (talk) 19:22, 27 March 2009 (UTC)
We couldn't grant it prematurely then, for bots, etc. According to this, the group is not automatically restored by autopromotion when it has been removed, the status log is checked for removals. Cenarium (talk) 19:32, 27 March 2009 (UTC)
  • Support the idea of allowing the right to be added or removed. I think that autoconfirmed/confirmed (I don't mind about the name) should be really easy to obtain. Any account that's x days old with y edits gets it automatically, anyone who requests the right should get it immediately (unless their account has been blatantly vandalising). Also, I think this right should be given out to anyone who might need it. What I mean is anyone who posts a question about how to move pages, upload files or edit semiprotected pages should receive the right immediately. I'm not entirely sure about when the right should be removed manually. There probably are some good situations for this, but I would imagine it would be a fairly rare occurrence. Tra (Talk) 19:29, 27 March 2009 (UTC)
  • Oppose, agree with TreasuryTag (talk · contribs), above. Cirt (talk) 18:40, 28 March 2009 (UTC)
  • Oppose Too complicated. Would be better to simply make the user group removable. ♪Tempo di Valse ♪ 20:58, 28 March 2009 (UTC)
    So you mean it should be removable, but not grantable prematurely ? Cenarium (talk) 21:06, 28 March 2009 (UTC)

:::Yes, that's what I meant. I agree with Gavia immer (talk · contribs). ♪Tempo di Valse ♪ 21:10, 28 March 2009 (UTC)

Ehh... then again, it would probably be best just to leave things as they are. Too complicated otherwise, really. ♪Tempo di Valse ♪ 21:12, 28 March 2009 (UTC)
  • It can already be re-added if a filter wrongly removes it, but for particularly cumbersome vandals, it would be nice if the ability to remove the group was granted to admins as well. - Mgm|(talk) 10:04, 29 March 2009 (UTC)

I have modified the structure of the poll to make it clearer, move your comment if you wish. Cenarium (talk) 21:18, 28 March 2009 (UTC)

  1. Oppose - I don't think this one actually helps. The aim of (auto)confirm is to ensure some actions can't be done except by users with a modicum of experience or involvement (ie repeat editors). A problem user will just do their 10 edits, then ask for autoconfirm, then vandalize anyway, wasting other users' time. Meanwhile bona fide users will add considerable admin workload that isn't needed, and a user who abuses autoconfirm access is probably a candidate for a block or ban anyway. Open to differing views or reasons why this is poor logic, but for now, no good rationale seems to exist for change. FT2 (Talk | email) 14:43, 3 April 2009 (UTC)
    Users will still be autopromoted after 10 edits and 4 days. I gave examples of users vandalizing who would not have been indef-blocakable at the time below. Cenarium (talk) 20:00, 3 April 2009 (UTC)
In addition to be granted automatically to users after 10 edits and 4 days, do you support to make the usergroup (auto)confirmed :

Removable and grantable prematurely

  1. Thought it over, and decided that it seems to be a good idea. I misunderstood the proposal at first, and thought that the autoconfirmed group would no longer be given out automatically. ♪Tempo di Valse ♪ 21:26, 28 March 2009 (UTC)
  2. Certainly - I cam across this due to some minor vandal who IMO does not warrant blocking but needs watching. putting him back into the new users pack would accomplish that. OTOH valid sockpuppets or established users on other wikis could be promoted to be useful right away. Agathoclea (talk) 09:59, 29 March 2009 (UTC)
  3. Pretty much what Agothoclea said.--Aervanath (talk) 07:34, 1 April 2009 (UTC)
  4. Fine. flSiet (aklt) 09:54, 1 April 2009 (UTC)
  5. Support, New users sometimes point out mistakes in semi-protected articles on the article's talkpage. It would be useful to let them correct the mistakes they point out. Tim Vickers (talk) 23:05, 1 April 2009 (UTC)
  6. Support. There will be some occasions to use it in a positive sense; and there will certainly be occasions to use it to remove autoconfirmed, especially for SPAs with the minimum number. A good first step before seeing if we need to raise the autoconfirmed numbers.DGG (talk) 04:03, 3 April 2009 (UTC)
  7. Support. Per Agathoclea, some people who are disruptive (but perhaps not blockable) should not be able to edit semi-protected articles and if they manage to pass thethreshold should not ruin it for everyone else and cause a page to have to be fully protected. They would also appear on the newbies contribs list. On the other side, some well-established people with valid reasons may create a new account or a legal sock for testing purposes. In this case I think premature auto-confirm is merited and the bit should be in the hands of admins. Valley2city‽ 20:17, 5 April 2009 (UTC)
  8. Support. Per Agathoclea. -- Alexf(talk) 17:14, 7 April 2009 (UTC)
  9. Support with obvious comment As with all admin tools, abuse of such priveleges should be dealt with in the same way as other admin abuse. An obvious statement but one that needs making anyway. Seddσn talk 19:11, 7 April 2009 (UTC)
  10. Support I support as someone may wish to retire one username and form an entirely new one (tho retain their public identity). If they are trusted then it would make sense to be able to remove the normal limits on a new user account. At the same time I also feel that this can be useful on a case-by-case basis. Basket of Puppies 19:37, 7 April 2009 (UTC)
  11. Good proposal Alex Bakharev (talk) 03:02, 8 April 2009 (UTC)
  12. support Reasoning above is good. I can't see much reason for allowing premature granting but I can imagine some circumstances that would probably be ok (i.e. you know someone is a productive user from another wikimedia project). The minor nature of this usergroup means that we really won't need any policy for it for now except more or less common sense. JoshuaZ (talk) 05:28, 8 April 2009 (UTC)
  13. Support This feature would be a net positive for the project, as it will produce more help than harm. hmwithτ 16:49, 8 April 2009 (UTC)

Removable (and not grantable prematurely)

  1. This is definitely where I fall; I can find no valid reason to autoconfirm a user before 10 edits, but I love the other part as an early-step anti-vandal tool--CastAStone//₵₳$↑₳₴₮ʘ№€ 18:24, 7 April 2009 (UTC)
    What if a trusted user comes from a very trusted position in other projects & we're sure they'll be trustworthy here? hmwithτ 16:51, 8 April 2009 (UTC)
    LOL at saying "trust" three times. It wasn't intentional. hmwithτ 16:52, 8 April 2009 (UTC)
    Then they can make ten AfD contributions. Or mod their user page ten times. Or spend 5 minutes looking at and reverting recent changes. Ten edits can be done in 5 minutes easily if you try, and these people will aldeady know how to do it.--CastAStone//₵₳$↑₳₴₮ʘ№€ 16:21, 10 April 2009 (UTC)
    We could use this for new bots in trial period, for example. Cenarium (talk) 17:37, 8 April 2009 (UTC)

Grantable prematurely (and not removable)

None (no change)

  1. The criteria are really too trivial to warrant special treatment. I know there may be arguments in favor of granting instant "autoconfirmed" status to new accounts which are known to be returning "trusted" users, but would saving four days really be worth blowing their cover? I know I'd rather just wait. Also I cannot envision any circumstance where it would it be better to "remove autoconfirmed" status than to simply block the account. Could someone please provide an example of when they would do this? I will say if the numbers were higher, maybe in the order of 40 days and a few hundred edits, granting exceptions both ways would be worth considering, but right now it would be too useless to bother with. — CharlotteWebb 11:50, 29 March 2009 (UTC)
    Since the autoconfirmed status allows to bypass many protections against vandalism, not only semi-protection, but some abuse filters and other anti-vandalism tools (and they would also have some additional permissions in the flagged protection implementation), having an autoconfirmed user vandalizing around is very unfortunate and they're not always blocked, for examples, see the history of vandalized semi-protected articles, such as Obama: 1, 2, 3, 4. Those have vandalized but have not been blocked indef, or not immediately, and two of them have been able to cause vandalism when their block expired. Cenarium (talk) 14:39, 29 March 2009 (UTC)
  2. Auto-confirming lets users move a page and a page to their watchlist. Watchlist doesn't matter, and moving a page can be undone easily. That's why we also have blocking and move protection. Nothing more is needed. Jd027 (talk) 23:25, 2 April 2009 (UTC)
    Any user can watchlist a page. Autoconfirmed allows to edit semi-protected pages, and bypass certain anti-vandalism tools among others. It's simply proposed to allow to grant the autoconfirmed permission before the 10 edits/4 days, and make it removable. Cenarium (talk) 20:00, 3 April 2009 (UTC)
  3. I don't think this is such a good idea to make the autoconfirmed group more than it is now (I see some discussion on removing the right for SPAs). It shouldn't be more than "the account is old enough to edit this page". The user rights are complicated enough. -- lucasbfr talk 14:58, 7 April 2009 (UTC)
  4. I don't see a pressing need. This seems to be another solution in search of a problem. - Rjd0060 (talk) 16:05, 7 April 2009 (UTC)
    Which problem ? Cenarium (talk) 14:58, 8 April 2009 (UTC)
  5. I can possibly see a few use cases for granting it early, but I don't really see any use for removing it. Pretty much any case where it should be removed, it would probably make just as much sense to block the user. Mr.Z-man 16:27, 7 April 2009 (UTC)
    I gave examples above of users that would have not been indef-blockable. Some have been temp-blocked and vandalized just after that. Cenarium (talk) 14:57, 8 April 2009 (UTC)
    Apa aff os and labz were clearly vandalism only accounts and should have been blocked indefinitely, and one of them was. The other 2 I probably would have blocked indef as well. Mr.Z-man 20:52, 8 April 2009 (UTC)
  6. I agree with Mr.Z-man, usually those who would be candidates for having their autoconfirmed status revoked are usually vandalism only accounts and are quickly blocked. -Senseless!... says you, says me 02:21, 8 April 2009 (UTC)
    Precisely, it's not always the case (examples above, more can be found). Cenarium (talk) 15:01, 8 April 2009 (UTC)
    I disagree, either the user should be blocked (indef or not), or just warned (and then no action ought to be taken). Having this extra option is just one more headache to me. Granting it early could be a plus (but having the user wait for 4 days before operating on semiprotected pages is not that big a burden, seriously :)). -- lucasbfr talk 16:05, 8 April 2009 (UTC)
    The problem is, after a temp block, the user can resume vandalizing, and bypass anti-vandalism protections like semi-protection, abuse filters, and other anti-vandalism tools ignoring autoconfirmed users, this happened for those users: 1 and 2. [12] is also used for vandalism detection, we could modify it so that it lists unconfirmed users (or make recentchanges filterable by confirmed users)(and thus granting a bot in trial period the confirmed group would also have the desirable effect to remove it from there). Cenarium (talk) 17:58, 8 April 2009 (UTC)
    The problem is some admins being too soft on blatant vandalism. Mr.Z-man 20:52, 8 April 2009 (UTC)

Wikidoc.org

The gentleman Michael Gibson who operates wikidoc[13] is interested in combining wikidoc with wikipedia. I think that this would be a wonderful idea. They are under the same license as wikipedia but have tighter security with respect to vandalism. They are also written more for a medical audience. Not sure if it would be best to attach it as a sister project or combine much of the information into wikipedia ( as that is were much of the information comes from in the first place ). Anyone have any thoughts?--Doc James (talk · contribs · email) 15:58, 7 April 2009 (UTC)

This is an issue you'd have to take to the Foundation, the users can't decide on their own. But I'm fairly sure you'll just get a "no"... ╟─TreasuryTag►contribs─╢ 16:07, 7 April 2009 (UTC)
Not sure what kind of format the content would take. I'm fairly certain the Foundation would not host WikiDoc without some form of payment, given the extra traffic it would need to host. As far as combining content, what would the mechanism be for moving content back and forth? This sounds like a GFDL headache.
All this apart from the fact that WikiDoc was launched with much fanfare, largely built on Wikipedia's current medical content but without any consultation. JFW | T@lk 09:59, 8 April 2009 (UTC)
Maybe I was just out of luck, but for the 5 articles I checked, none came with sufficient sources. Merging the wikis together would only give us a whole bunch of extra unreferenced material. Not to mention we already cover much of the topics they have. - Mgm|(talk) 12:47, 9 April 2009 (UTC)
The one article I looked at, Local anesthetic, (yes, I know, inadequate sample) started out life as a Wikipedia article of around 8,000 characters, in October 2007, and (on WikiDoc) had reached 12,000 characters (after 15 edits) as of December 2008 (its last edit). Meanwhile, the Wikipedia article, after about 70 edits, had also reached about 12,000 characters in length. So it would be an interesting challenge to try to figure out what new material in WikiDoc was worth bringing across. In any case, it makes absolutely no sense (to me) to have WikiDoc as a separate Wiki. -- John Broughton (♫♫) 23:17, 9 April 2009 (UTC)
Well, it's up to the foundation, but I don't think it's a good idea either. WikiDoc is under GFDL, so all changes they have that we don't, we can incorporate into Wikipedia anyway. SoWhy 23:27, 9 April 2009 (UTC)

I see this as mainly as a way to increase the number of editors of medicine article. It does sound like a nightmare to combine the two and would be easier to have it as a sister project. This would make the transfer of info back and forth easier. One could write for a medical audience. It would be like have we have simple English as a language. We could have medical English as a language aswell? Just ideas.--Doc James (talk · contribs · email) 06:14, 10 April 2009 (UTC)

It's not at all clear that having that wiki be on a Wikimedia Foundation server would make transfer of information back and forth any easier. We already have a system where (using interwiki links) we can link to another wiki that isn't in a WMF domain. And we can obviously cut-and-paste from WikiDoc, something that probably wouldn't be a good idea if WikiDoc really was aimed at a medical audience.
I suppose it would be easier, if WikiDoc was a WMF wiki, to ask editors of WikiDoc to do (more) editing at Wikipedia, but since WikiDoc seems be be based around visible "ownership" of articles ("editor-in-chief") whereas that is against the rules at Wikipedia, I suspect that very few editors would be willing to switch. And WikiDoc doesn't allow anonymous (IP editing), something that is a core Foundation principle.
Obviously editors at WikiDoc are aware of Wikipedia, plus they have MediaWiki editing skills, so if they want to edit here, why wouldn't they already be doing so? In short, the best way to add editors to Wikipedia - if that is the goal - is probably to shut down WikiDoc. -- John Broughton (♫♫) 14:54, 10 April 2009 (UTC)
Wikidoc does not allow anons to edit which I think is great. Some of use get tired of all the vandalism and wish to know more about the editors which I think attacks people to wikidoc. I do realize that this is a long shot and just put the idea out there.--Doc James (talk · contribs · email) 20:39, 10 April 2009 (UTC)

Suggestion for WP software. If the "Edit summary" is left blank...

If the "Edit summary" is left blank then it would be nice if the software would pop-up an intermediate page that gives a little warning and says "You forgot to fill out your edit summary, please fill-out the edit summary to continue." in bold & red letters directly next to the field.

Various online forms do this sort of thing as a reminder. Like when you come across a form that asks you to fill-out your name, address, phone number, email etc. If you forgot a field it will notify you... I must admit sometimes I am flying through something and I click before I realised that I've revised without adding to the edit summary. Because of this I wish the Wikipedia software could pop-up up a warning that the edit summary wasn't filled out. To my mind, I think a LOT of vandalism on WP might also get circumvented this way because if someone has a track record of claiming they are doing something legit (according to the edit summary they posted, but in actuality they aren't) then they will have eventually left a long trail showing they intended to vandalise while making their false edit summary statements claiming they were doing good. Others who are making legit contributions will get a mere small nudge to share what they are changing and will be able to move along thereafter. Would this process add too much load to the WP servers? CaribDigita (talk) 04:37, 9 April 2009 (UTC)

There is. Special:Preferences → Editing → "Prompt me when entering a blank edit summary". EVula // talk // ☯ // 04:52, 9 April 2009 (UTC)
Actually, this is an interesting idea: how about requiring edit summaries as a way to prevent IP vandalism? Calliopejen1 (talk) 12:22, 9 April 2009 (UTC)
It's been suggested! ╟─TreasuryTag►contribs─╢ 12:26, 9 April 2009 (UTC)
  • Then they'd just include a seemingly innocent summary making the vandalism harder to spot.- Mgm|(talk) 12:43, 9 April 2009 (UTC)
  • Ditto. I'd much rather have vandals do their things from an IP and no edit summary, the more they stand out the better. Besides, I find it infuriating when some piece of software tries to force me into doing something. Especially with popups. Ain't how tools are supposed to behave. Equendil Talk 23:32, 9 April 2009 (UTC)
  • Oh no you have me all wrong. It would **not** be a "pop-up", as in a Javascript pop-up window. I hate those too. It would look like the same thing as when you only--- input your username (but not password) on say the Yahoo login or Gmail mail login. If you don't fill in *both* the username and passwords on those sites they return you to the same page again with the red text reminder asking you to input something in both username and password fields.... In the meantime, great suggestion EVula. I'm going to turn mine on right now. :-) CaribDigita (talk) 01:26, 10 April 2009 (UTC)
  • I would prefer mandatory filling of the edit summary for logged-in users in the article namespace. It would be very helpful for page watchers, and also it could prevent having too many edits by the user in a short span of time. Jay (talk) 02:49, 10 April 2009 (UTC)
    • We could start by having the preference "Prompt me when entering a blank edit summary" set to "yes" (that is, checked) for all new user accounts. Then editors could turn it off if they wanted to. Plus the edit summary would not be mandatory, since clicking the "Save page" button a second time will save an edit even though the edit summary is (still) blank. -- John Broughton (♫♫) 15:02, 10 April 2009 (UTC)

Making the "remember this is only a preview" message look like an editnotice

See proposal: essentially with a bit of CSS we can turn the preview bar into a proper editnotice like all the others we have. Comments appreciated over there. Happy‑melon 19:57, 10 April 2009 (UTC)

Adding a note on sourcing in copyrightwarning or edittools

I have often noticed IPs or new users who didn't know how to cite, and messed up with references tags or just didn't format. So we could add a note on sourcing and link to Wikipedia:Citing sources in MediaWiki:Copyrightwarning or MediaWiki:Edittools. Of course, it would also help to improve sourcing. For example:

And/or adding a more detailed note on this below Please note:, although it would be less visible. Cenarium (talk) 19:28, 10 April 2009 (UTC)

Or something like:

Content that violates any copyright will be deleted. You irrevocably agree to release your contributions under the GFDL*.
Encyclopedic content must be verifiable, references are required for most claims, please cite your sources.

Please discuss at MediaWiki_talk:Copyrightwarning#.22must_cite_sources.22. Cenarium (talk) 20:39, 11 April 2009 (UTC)

Poll: autoformatting and date linking

This is to let people know that there is only a day or so left on a poll. The poll is an attempt to end years of argument about autoformatting which has also led to a dispute about date linking. Your votes are welcome at: Wikipedia:Date formatting and linking poll. Regards Lightmouse (talk) 09:05, 11 April 2009 (UTC)

Wikipedia:Advertising discussions

Please see Wikipedia:Advertising discussions, a proposal I've made to formalise guidelines on where and how the largest discussions should be advertised around Wikipedia to ensure sufficient input to major discussions. Improvements to the page and input on the talk page would be appreciated. Carcharoth (talk) 10:33, 11 April 2009 (UTC)

Poll on reviewer autopromotion for flagged protection and patrolled revisions

There is currently a poll on the autopromotion of reviewers at Wikipedia talk:Reviewers#Poll on autopromotion, for the trial implementation of flagged protection and patrolled revisions. For information, see general documentation and overview. All users are invited to comment, and to participate in the elaboration of a reviewing guideline as well. Cenarium (talk) 13:43, 12 April 2009 (UTC)

Disputed maps templates

Despite the importance of the maps, we have very little editorial tools (or control process) over the maps. We have no templates, inline for map citations, or for map pages, to indicate that a map may be inaccurrate or unreferenced. We only have the {{POV-map}} template for indicating on a map page that it may not be neutral, but we have no inline version for caption. I propose creating the five missing templates, see also threads at Wikipedia talk:Dispute templates#Disputed map, Template_talk:Unreferenced#What_about_maps.3F and Template talk:POV-map#Inline version. --Piotr Konieczny aka Prokonsul Piotrus| talk 17:20, 12 April 2009 (UTC)

I support this proposal. Incorrect maps can distort an article greatly.HP1740-B (talk) 08:23, 13 April 2009 (UTC)

Subpage feature

We are planning to enable the MediaWiki subpage feature on the namespaces Help, Help talk and Category talk. If anyone has any comments to that, see discussion at Wikipedia:Village pump (technical)#Subpage feature. Technical comments are especially welcome, we want to know if anyone knows anything that might break when we turn that on.

--David Göthberg (talk) 12:12, 13 April 2009 (UTC)

Automatic detection of citation format

I have proposed that Citation bot amends pages using a mixture of 'Cite xxx' and 'Citation' templates so that only one family of templates is used. I would welcome comments on this suggestion here. Thanks, Martin (Smith609 – Talk) 20:01, 13 April 2009 (UTC)

Quality related proposal - use of a "drafts" namespace.

I was considering the issue of BLPs, and not convinced that any of the current proposals (CSD#10, or otherwise) would make sufficient difference. A possible suggestion:

From <date> onwards, all new articles should be of some basic standard, to be added to the wiki. At a minimum:
  1. Any claims or statements likely to be controversial must be reliably sourced
  2. Any BLPs have sourcing for their major statements, and a reasonable balance of weight for any criticisms or potentially negative content.
  3. Any article that relates to a person, group, organisation, web content, or news event should have some reason visible why it is likely to be encyclopedic.

New articles that do not visibly meet these criteria may be moved by any user to a "Drafts:" namespace as follows:

  • The author is notified as follows: "Thank you for contributing to Wikipedia. Your article [NAME] needs a little more work done on it, before it can be added to Wikipedia. The [move log] will explain what issues were found. Otherwise the draft will be removed in 5 days, but you may always ask for a copy of the text by email, for the purposes of improvement and re-posting."
  • The article in the Drafts: namespace has a header added - "This draft article is awaiting improvement by its author or any other user, to rectify issues noted in the [log]. Once these are fixed it may be moved back into the main encyclopedia. If they are not fixed within 5 days the draft will be automatically deleted."
  • The Drafts: namespace is forcibly NOINDEXed.
  • No redirect is created for moves to Draft: . Instead a note is added to the "page not found" notice saying to check if a missing page was moved to that namespace


Advantages compared to current processes:

  1. Dodgy or questionable articles (especially BLPs) can be removed from mainspace and indexing, immediately, until the basics are fixed, and "benefit of doubt" is no longer a problem.
  2. Articles can be retained for improvement but their new location isn't spidered, so they aren't doing harm while the author is consulted or others work on it.
  3. It's more user-friendly to move something to drafts, than to delete it, and informs a well-meaning author what's needed to make it okay. This encourages good faith authors to do more, and to a better standard.
  4. All articles added to the wiki henceforth, will be of a basic minimum standard, or else they can be instantly deleted, or Draft-ified.
  5. The process is open and flexible, and hence well suited to be extended or updated based upon experience.
  6. This has all the advantages of PROD and none of the disadvantages. So PROD can probably be deprecated.

Initial thoughts?

FT2 (Talk | email) 15:12, 3 April 2009 (UTC)

  • Oppose - this is broadly similar to Citizendium or Veripedia or whatever I'm thinking of :p and impairs the concept of a wiki. As long as there are new-pages-patrollers, people should be able to create new articles of any standard that meet the very basic guidelines, and have them improved by the community in general. ╟─TreasuryTag►contribs─╢ 15:17, 3 April 2009 (UTC)
How exactly does it prevent any of that? It simply says that if certain common basic issues are noted in the article, it's moved to a separate namespace where it can't do harm, and the author (and others) advised of its defects. Anyone can work on it, anyone can create new articles... these things are unchanged. I think you may have misunderstood the idea. FT2 (Talk | email) 15:20, 3 April 2009 (UTC)
Well, I certainly read everything you wrote ;-) The thing is, if you're going to take the "it won't make any real difference" tack, then why introduce such a complex change? And if it is going to make a big difference, than that's my point.
I don't understand what practical, tangible benefits the introduction of a new namespace, and the template-messaging of newbies saying "We've stuffed draft: in front of your article title until you complete the following tasks..." (yes, exaggurated, I know), will bring to Wikipedia. ╟─TreasuryTag►contribs─╢ 15:27, 3 April 2009 (UTC)
You are essentially talking about a way of using flagged revisions. In one common configuration, the actively edited but not yet delivered to the public version is even placed behind a tab called "Draft". Dragons flight (talk) 15:29, 3 April 2009 (UTC)
Flagged revisions is quite different. This would be for new articles only, and not require any new "permissions" or "classes"; its aim is to ensure that at the first addition of a new article to the wiki, at least certain basics are taken care of, or else the author is asked to fix them first. As such there is no "class" or users who can and can't do this - the pages are in a namespace anyone can access, and anyone can re-mainspace them. In effect a genuinely defective 1st draft of a new article is put somewhere safe until the author fixes up the basics and moves it back to mainspace. Flagged revisions is considerably different. FT2 (Talk | email) 15:33, 3 April 2009 (UTC)
I believe that this effect can actually be achieved with FlaggedRevisions, or certainly something very similar to it. Happy‑melon 16:13, 3 April 2009 (UTC)
Whether it can or can't, Flagged Revisions is not trying to achieve this goal. The aim here is two things -- new articles going forward should at least have reasonable sourcing (especially BLPs) and reasonable notability, and, if they don't, then the dichotomy of CSD/PROD/leave is not necessarily a good one. It may be better to return them to the author (out of mainspace and not indexed) with a request to improve, rather than a simple "delete/don't delete" (CSD) or "leave to be mainspace and indexed while waiting for evidence of appropriateness" (PROD). I've suggested a "draft" namespace but it could as easily be userified. The advantage is that userspace might be indexed, draft space wouldn't be. FT2 (Talk | email) 19:15, 3 April 2009 (UTC)
  • Oppose It's against our editing policy. Our articles are perpetual drafts. Either it's to be deleted and we have processes for that, either it's to be fixed, and moving to a less visible place will make the fixing less likely. Cenarium (talk) 19:46, 3 April 2009 (UTC)
  • Disclosure: FT2 asked me to take a look at this, so here I am. In my view, the opposers are opposing on "anyone can edit" grounds, essentially. They have a point. This proposal does not exactly fit our current culture. But they miss the larger point which is that our current culture ... is broken. It needs fixing. We have quality problems. In some areas it's a so what... that we have the details wrong about an early 19th century landscape composer isn't going to be the end of the world. But in other areas (BLPs for example) it matters a great deal. Disclaimers or not, we do want high quality. This proposal may not work. But it is worthy of further investigation and elaboration. Dismissing it out of hand is wrong. Support further elaboration. ++Lar: t/c 20:21, 4 April 2009 (UTC)
    If we put a page in a corner where nobody will find it, then its quality is not going to improve. Our articles are steadily improved because of their visibility - and incidentally, because anyone can edit - but forking like this will not result in improvements. Drafts will be forgotten and inappropriate content will stay. The vast majority of our articles, even our best ones, were started as stubs or in bad shape. We need increased coordination for BLPs, and progress in this sense has really started only recently. Cenarium (talk) 22:06, 4 April 2009 (UTC)
Unfortunately, there are some articles where sufficient bad shape in key areas is a big enough problem that "eventually" isn't good enough. Hence CSD and PROD. "Yes there happens to be a contentious claim that's unsourced and could do harm if inaccurate but someone'll eventually fix it so never mind" just doesn't work, for a top 5 reference site. This proposal would require articles to be held in abeyance and their authors (or other editors, or patrollers) notified that contentious claims needs to be sourced and cited, before it's fit to be added to mainspace. This isn't contentious - sufficiently inadequate articles are historically often deleted (A7) rather than just passed back for improvement. Drafts (under this proposal) will be automatically deleted in 5 days, as PRODs are, the difference is that a wider range of problem articles will be able to be intercepted and improved, ie, a quality improvement of new articles added to the wiki. We need those adding articles to have it explained at the point of posting, that basic sourcing of anything contentious is part of initial stub writing, not just an afterthought. FT2 (Talk | email) 10:20, 5 April 2009 (UTC)
Of course, some BLPs need swift action. But why should we apply such a process in other cases and not let our current editing process apply ? You say that this would be used for new articles and that it would deprecate prods, but prods are not used for new articles only. (Moreover, moving a page that has existed for a long time to the draft page would surely be controversial, and I imagine move wars over this.) Anonymous and new users could not use this process because it requires moving a page, so I would oppose for that only. I would much prefer and support a template that can be put on a blp when it is suspected that it violates the BLP policy, and would put the page in a tracking category, and optionally noindex (removals can be monitored with the abuse filter). Cenarium (talk) 14:56, 8 April 2009 (UTC)
  • Oppose #1 is basically a pseudo-CSD for enforcing WP:V, #2 is a pseudo-CSD nuclear option for enforcing WP:BLP, and #3 is a vaguely-defined version of WP:CSD#A7. This sounds like a bad way to chase off new editors, and a poor excuse for not having consensus for a CSD to enforce WP:V: instead of outright deletion, it shoves the pages off to some obscure corner with no reference to it, where it will be deleted in 5 days. It also seems wide open to abuse where one side decides that it will never accept any source as "reliable" or any wording of criticism as "balanced". I also find the claim that this is somehow the only way to deal with unsourced statements in BLPs to be inaccurate; what ever happened to removing the statements in question instead of nuking the entire article? All in all, it strikes me that Wikipedia is neither Veropedia nor Citizendium, and I'm not convinced that needs "fixing".
    IMO, the only good idea here is the NOINDEXing of pages pseudo-prodded in this way; but why not just NOINDEX any BLP that is prodded/AfDed for this reason instead? Also, as you allude, the idea (and others like it) is currently having much more in-depth discussion at WT:CSD. How about joining that discussion instead of forum shopping it here? I don't see a single comment with your signature on that page. Anomie⚔ 16:10, 5 April 2009 (UTC)
Veropedia locked stable versions of articles down and Citizendium had articles written by proven experts. I don't see how eithe project relates to requiring basic article writing criteria to be met. Veropedia only comes in on 'finished' articles and we still don't put a limit on who can write the article as long as they register as a user. - Mgm|(talk) 08:35, 6 April 2009 (UTC)
Both seem to be based on an idea of "only people who 'know enough' and want to jump through our hoops can edit", as opposed to Wikipedia's "anyone can edit". Forcing every new contributor to have knowledge of the intricacies of WP:V and WP:CITE or their contribution gets summarily deleted strikes me as a pretty big hoop, and far beyond the current threshold of "your contribution has to have some basic indication as to why it's worth inclusion in an encyclopedia" given in CSD A7 and A9. Anomie⚔ 12:26, 6 April 2009 (UTC)
The problem is that CSD is (as its name suggests) for speedy actions only - that means those where there is pretty much overwhelming cause. We need to tilt a balance slightly more towards quality, say 3/10 rather than 1/10, and asking that basics like letting authors of new articles know "please cite contentious claims in new articles before mainspacing them" is not something that CSD is designed for, so it's not helpful to suggest it on that page. FT2 (Talk | email) 17:22, 7 April 2009 (UTC)
  • I don't oppose the idea of a draft namespace on its own (having a draft space might actually make people stop and think before creating deficient articles in mainspace), but if anything that's no goof after 5 days is deleted, people will simply use userspace as is common practice now. Noindexing already takes care of the outside visibility, so there's no reason to speed up deletion. - Mgm|(talk) 08:31, 6 April 2009 (UTC)
That makes sense. If it would help get things moving, then thats reasonable, or at least a longer period. FT2 (Talk | email) 17:22, 7 April 2009 (UTC)
  • Oppose We already have an option for deleted articles to be moved into user space. I don't think editors other than the creators would trawl through the draft namespace looking for drafts to improve. Those that know the main WP policies and the techniques form implenting them will probably just create decent versions themselves (10 mins max for initial text and a couple of refs). So I think this is a solution in search of a problem. In addition BLPs need much stricter streatment as a "bad" BLP can expose WP to lawsuits and other hazards such as being blocked in some less-develpoed countries. The draft name space would have some trail of links that readers can follow, otherwise it might as well not exist. In that case WP would be exposed to the hazards I've mentioned, even if such articles are not indexed by the search engines. So, much as I dislike speedy deletion in principle, speedy deletion without saving a copy anywhere seems the only solution for "bad" BLPs. --Philcha (talk) 11:00, 14 April 2009 (UTC)

Category:Pages with incorrect ref formatting

I propose some automated (bot) cutting-down of this category. All the 6,119 page included have some <ref> issues that result in the loss of information. However, within that there are many distinct causes which a bot (or someone with a lot of spare time on AWB) could sort, leaving the important ones more accessible. The point is that many of these pages - and I wouldn't propose editing anything in article space, don't worry - are now archives, and no-one really cares very much.

Automated fixes
Page scope Solution Controversial rating
AfC declined archives (example) If they have an existing == References == or == Sources == section, auto-add a {{Reflist}} after that. Else, dump a new section in at the bottom. Uncontroversial
Handpicked list of general Wikipedia: ARCHIVES (example) Add a new {{Reflist}} catch-all section at the bottom, with a useful note showing it was added later. Substantial - may goes against 'do not edit the content of this page'
AfC archives (example) Ditto above Ditto above
AfD nominations (example) Add in a new section, with note, at the bottom, outside of the archive box. Knock on clears logs pages as well. Moderate.
FACs (example) Ditto above, knock-on archive listing Highly - goes against 'no futher edits...'
Templates with built in refs (example) Create and transclude a doc page warning about the need to place before a {{Reflist}} in articles, as well as a 'preview' of what that ref will look like. Not overly - added value due to documentation.

That's just a start, but we'll see exactly the community is happy with (editing archives?) before proceeding. - Jarry1250 (t, c) 10:40, 13 April 2009 (UTC)

See Help talk:Cite errors#RE: Category:Pages with incorrect ref formatting. We have been discussing namespace detection for this set of errors. I don't think there should be any issues with removing it from any talk page, but we need to discuss other spaces.
As to templates with refs; see Help talk:Cite errors#Broken refs in templates/infoboxes/etc..
--Gadget850 (talk) 11:18, 13 April 2009 (UTC)
Well, having read a few of the various discussions, I think I'm with debresser - I'd rather fix these than ignore them. As for templates - and I'm sure your experience in previous discussion would be most useful in advising here - that documenting with a {{Reflist}} would have an added benefit of alerting people to the fact that the template may cause errors if incorrectly placed in an article. - Jarry1250 (t, c) 11:26, 13 April 2009 (UTC)
You want to fix the errors on talk pages? That is going to be a never-ending task. AS to templates, I had a template at {{template reflist}} but deleted it after discussion. It can easily be restored if needed. --Gadget850 (talk) 11:45, 13 April 2009 (UTC)
Fair enough about talk pages, but we have thousands of never-ending tasks on Wikipedia, and a full backlog-clear would be of no harm, surely? - Jarry1250 (t, c) 16:15, 13 April 2009 (UTC)

What do you mean? That is an argument to do what? Debresser (talk) 02:02, 14 April 2009 (UTC)

BTW, fixed the first 5 templates from this category. Their only problem is a missing references section. See my talk page for how to fix this. Debresser (talk) 03:15, 14 April 2009 (UTC)

Hmm, I think I've got our wires crossed. That's very much what I'd be for, just (if we we're letting a bot do all the hard work) with the additions of creating and transcluding a doc page if one did not exist, and warning on that that incorrect usage of the template in article space can cause ref errors. In other words, not something we're directly talking about here, but a related tangent. But yes, that's exactly the sort of fix for templates I would like to see mass carried out (I'll do it with AWB if it comes down to it). - Jarry1250 (t, c) 07:24, 14 April 2009 (UTC)
I think I understand you now. You are thinking of what will happen when somebody uses such a template in a article without a references section, right? Well, that happens, although usually either the article already has a references section, or the user will notice the problem and fix it. But yes, on my talk page I mentioned that I fixed a few instances where this was cause for a references error. Frankly, I wouldn't worry about it, Even if it happens, it'll get fixed soon enough, especially now with the Category:Wikipedia pages with broken references cleared from its backlog. Debresser (talk) 08:53, 14 April 2009 (UTC)

See my talk page that I fixed all images, all subcategory pages, and all stray templates. Left: templates at letters "I" (from Infobox) and "T" (from Template). Debresser (talk) 14:31, 14 April 2009 (UTC)

In short: I think we need "Article", "Template" and "Category" namespace, preferably also "Help" and even "Image" namespace, "but not "Talk", "Wikipedia" and "User" namespace. Other namespaces I dont care either way. Debresser (talk) 15:01, 14 April 2009 (UTC)

That sounds doable— I will look at it later today; gott make a deadline in real life. --Gadget850 (talk) 15:06, 14 April 2009 (UTC)
I'm happy you say so. I've come to know you as a person who adds deeds to words, and quickly. I from my side am willing to put in a fair amount of work, as you may have noticed.
I think it is not only doable, but more or less logical also. Debresser (talk) 15:10, 14 April 2009 (UTC)
And very easy to do now that I found {{namespace detect showall}}. --Gadget850 (talk) 15:54, 14 April 2009 (UTC)
Namespace detection for MediaWiki:Cite error group refs without references and MediaWiki:Cite error group refs without references have been updated so that the messages show only in main (article), template, category, help and file (image) namespaces. I will wait a day or so for additional comments before updating the other messages in a like manner. --Gadget850 (talk) 18:27, 14 April 2009 (UTC)

bugzilla:11477

That bug was opened almost two years ago and nothing has been done. The proposal has been made again during a discussion at Wikipedia:Abuse filter/Requested#LEPS. -- IRP ☎ 20:21, 14 April 2009 (UTC)

Also made the request here. -- IRP ☎ 23:34, 14 April 2009 (UTC)

Image → File

After the rename of the "image" namespace to the "file" namespace, I propose that we rename links to "images" to be links to "files", if the article is already being edited for some other reason. For example, this can easily be done using AWB while also making other edits, but edits should not be made solely for the change as it is a waste of server energy.

The reason for this proposal is that seeing both "Image" and "File" could be confusing to newer users who aren't aware that there was a change. File is also the more correct term to use after the rename, and being two letters shorter could have some impact on page loading for users with slower connections if there are a lot of files on the page.

Thoughts? –Drilnoth (T • C) 22:45, 6 April 2009 (UTC)

I know you said "if the article is being edited for some other reason" but I still don't see the need for a planned process to change these over. I figure if you notice while editing an article, change it if you want, but it won't make any difference. - Rjd0060 (talk) 02:58, 7 April 2009 (UTC)
I don't think that there needs to be a specifically planned process to accomplish my proposal, just an acceptance of the change when someone uses AWB or the like and makes it. –Drilnoth (T • C) 12:18, 7 April 2009 (UTC)
You've already started planning the process, by creating this thread. :-) I don't see a need for this organized effort, honestly. - Rjd0060 (talk) 16:08, 7 April 2009 (UTC)
Using image vs. file will have no noticeable effect on loading time. What matters for most page loads is the rendered text, and "Image:" is always converted to "File:" for the rendered text except in the rare case of unpiped image links like Image:Example.jpg, even then, the target of the link is still converted and a couple bytes isn't going to make a difference, even on a dialup modem. There might an extra microsecond to look up the namespace alias on the server, but the performance impact is basically nil. Mr.Z-man 16:45, 7 April 2009 (UTC)
Yep, all excellent reasons why we shouldn't go through and changes these en-masse, but I'm sure the it could be added to AWB's general fixes (if it hasn't already). Drilnoth has a point about consistency and not confusing new editors. It'll be a slow process, no doubt. –xeno (talk) 16:51, 7 April 2009 (UTC)
Okay; I just wanted to make sure that I could add the change to my customization of AWB and that there wasn't any real opposition to it (I can't tell if Rjd0060 is opposed or just neutral on this matter). The primary concern was to reduce confusion for newer editors; I didn't know whether the loading time thing was accurate or not. And I just prefer file over image. :) –Drilnoth (T • C) 17:04, 7 April 2009 (UTC)

The change from Image: to File: has not been published very widely, so there are probably quite a few long-term editors who are not aware of it (I wasn't). And then just changing this will actually confuse them even more than new editors, who will simply start using File: to start with. Since there is not any positive effect to be achieved by changing Image: to File, I would still recommend to NOT do combine changes in other edit work. AWB work is often already obscure; please don't make it more obscure. IF the change is necessary/required/decided, then a simply bot can do all the changes throughout WP. Wim van Dorst (talk) 19:30, 9 April 2009 (UTC).

We already had problems with editors thinking that changing Image to File was a good idea. I noticed 1 or 2 editors doing only this. If we add it to AWB we will cause more confusion. I think we are ok the way we are. Changing Image to File is like changing redirects with the original title. No gain, more confusion, more editors are making only non-constructive edits. -- Magioladitis (talk) 23:42, 15 April 2009 (UTC)

New search engine option, so everyone is happy. The tags can be blocked from reviews.

  • PROBLEM Many deletionists are constantly trying to delete articles they don't like, much to the irritation or people who like them and want them to remain. There are constant debates for deleting, merging, and editing articles.
  • SOLUTION A simple solution would be to tag things, and then have the search feature filter things accordingly.

With the Google search engine, you can search for a specific term, found only in the tags, and only show those with tags you like, and not those with tags you don't like. Click here to see a search that reveals all those articles tagged as fancruft. You can have Google filter out all searches that have that also, if you don't want to see any fancruft at all.

If you want only want to find article approved as being of a certain quality level, then you can search for those who have an appropriate rating on the Assessment scale and/or the Importance of topic scale. Additional tags can be made. Just determine what some people want(such as articles for every episode, character, and list of weapons in a series), and others do not, and tag them accordingly, so people never see something they don't want to, while others can still have their fun.

Remember, 99% of wikipedia articles are just entertainment. Even some education ones, listing all species of extinct insects, ancient battles from two thousand years ago, etc, are entertainment only for those who like that sort of thing, there absolutely no practical application for that knowledge. And that's just fine with me.

And for all those people who are complain constantly that fancruft and whatnot give wikipedia a bad reputation, to whatever snotty elitists they believe are out there judging us and care about, you can have the default set to filter fancruft and whatnot out, people only finding it if they click the option under the search button, saying they want to see it. That way, everyone is happy, no legitimate complaints left to argue back and forth on. Dream Focus 21:33, 13 April 2009 (UTC)

Comment If you want your proposal to go over well, you might want to assume good faith when proposing it. As a "snobby elitist" deletionist, I take offense at your characterisations in this post. Furthermore, Wikipedia is not, and never was intended to be, "just entertainment". Wikipedia is a serious encyclopedia and what happens on here has serious consequences in the real world. ThemFromSpace 21:44, 13 April 2009 (UTC)
Comment Leaving aside Dream Focus' character assassination of many editors who actively work to improve article content, I can't quite see what value there is in this proposal. Surely the best way to ensure that users find content in an encyclopaedia that is, er, encyclopaedic is to work on the actual articles in order improve the chances of finding factual articles that link to other, non Wikipedia, sources.
Practically this proposal looks like it would make using Wikipedia more difficult to use.
I don't think that whether anybody "likes" or "doesn't like" an article is relevant, nor should it be. pablohablo. 23:03, 13 April 2009 (UTC)
"actively work to improve article content"? Does that mean erasing 99% of the article because you consider it cruft? Usually when someone speaks of improvements, they end up deleting much of the article, or all of it. Dream Focus 00:32, 14 April 2009 (UTC)
What it means is "actively work to improve article content". pablohablo. 00:39, 14 April 2009 (UTC)
I see no value to this proposal - DISCLAIMER: I am an evil evil deletionist (just in case dreamfocus is keeping a list). --Cameron Scott (talk) 23:06, 13 April 2009 (UTC)
Careful, that's my registered trademark ;) Cheers, Jack Merridew 07:11, 14 April 2009 (UTC) for the Evil Deletionist® Cabal
Its simple. Instead of deleting all the articles you don't like, we simply make it so only people who like that sort of thing can find it. And it wouldn't be confusing. See the search button over to the left? Have a few things under it you can click on, to select them. That'll add things you can search. Dream Focus 00:32, 14 April 2009 (UTC)
Got that bit. So it makes the search more unwieldy (not a benefit) to filter articles on the basis of whether the searcher "likes" them. (not a consideration). Or am I missing something? pablohablo. 00:37, 14 April 2009 (UTC)
Simple? This sounds much more complicated than the current system. At the minimum it requires rewriting major parts of the search engine to replace deletion. I agree with Themfromspace, Wikipedia is in the real world. Even if we filter it out of our own search results, it'll still be in Google results and all the other external search engines and we still have to make sure the articles are quality work. Though if you don't understand the difference between an article on a historic war and one about a video game character, I doubt you're going to be convinced by any of the arguments that people present here. Mr.Z-man 02:11, 14 April 2009 (UTC)
Odd that Optical character recognition is taggeddiff as {{fancruft}} — I didn't realize that there are OCR-fans out there; this proposal is, of course, silly. A far better wiki-world would be one where all the fancruft was on the appropriate wiki. Cheers, Jack Merridew 07:11, 14 April 2009 (UTC)
  • Oppose. 1) That's a solution to a false problem. "Deletionists" are not constantly trying to delete articles they do not like, they are people concerned that many articles created on Wikipedia are inherently not encyclopedic (dictionary definitions for instance), in violation of copyrights, unverifiable, hoaxes, inherently non neutral, adverts etc. The vast majority of deletions are not in dispute. 2) That's akin to a fork of the project. I can't imagine any good coming from that. By the way Deletionpedia keeps pages deleted on Wikipedia. Equendil Talk 16:19, 14 April 2009 (UTC)
  • Oppose some tortured effort to split wikipedia in two to solve some sort of straw man problem that i don't understand. People can already exclude things ("-") when searching on google and the like. There are strong reasons that some material isn't suitable for inclusion in an encyclopedia that have nothing to do with technology, but rather how we chose to organize and display information to maintain credibility, usefullness, etc....Bali ultimate (talk) 20:48, 14 April 2009 (UTC)
  • I'm an inclusionist, but I'm crossing the aisle to join my deletionist friends and oppose this. Wikipedia is optimized not for experienced editors but for readers, in particular for casual readers who come straight off a simple google search, don't know what Wikipedia tags are and would never use such tags to filter their searches. If this proposal is a replacement for the deletion of certain articles, the effect will be as if those articles had been straight-out kept. If current policy is too deletionist, the solution is to gain consensus to change policy directly, rather than trying to work around deletionism. Baileypalblue (talk) 17:49, 15 April 2009 (UTC)
  • I don't see the problem. You would only get search results for "fancruft" if you searched for them. I don't know what kind of search engine would give you Wikipedia articles about Bulbasaur if you were searching for E. E. Cummings. OrangeDog (talk • edits) 23:58, 15 April 2009 (UTC)

Spell checker

To Wiki programmers: could someone add a spell-checker to the edit buttons above? I don't think it'd be a big task, and wiki editors would be forever grateful--would save so much time and hassle. After installation, other wikis could also copy/translate the proceedure, a gain for every Wiki on the planet (I happen to work for hu.wiki). The substitute solutions offered by en.Wiki for having and operating a spell-checker while creating articles are clumsy and troublesome. A spell-check button above would be so much simpler. Please help us out. Thank you,--97.112.153.113 (talk) 00:06, 14 April 2009 (UTC)

Actually, I think such a thing already exists, in a way. If you use Mozilla Firefox, then a spell-checker automatically appears in the edit box window, underlining words that haven't been spelled correctly. tempodivalse [☎] 00:11, 14 April 2009 (UTC)

Thanks, but I know about Firefox. I don't have it, and don't want to have it. Why wouldn't the above suggestion work? Should I transfer my request to Bogzilla? --168.103.249.30 (talk) 00:15, 14 April 2009 (UTC)

I'm not sure, but I think that WikiEd, which is a javascript function available to registered users, features some sort of a spell checker. tempodivalse [☎] 00:18, 14 April 2009 (UTC)
WikiEd doesn't work in Internet Explorer so you would need to install FireFox to use it. Tra (Talk) 00:21, 14 April 2009 (UTC)
Google IE Spell - nifty free spell checker add on for IE. -- AnmaFinotera (talk · contribs) 00:23, 14 April 2009 (UTC)

Oh please, gentlemen...I read about it all. Can't you just answer my question: why couldn't Wiki install a spell checker into its edit box? Can it or can't it. I can't believe it can't. --97.121.172.3 (talk) 00:47, 14 April 2009 (UTC)

PS. In addition, what I need is a Hungarian spell checker. ieSpell doesn't have that. (FoxFire does, but as I said above, I don't want FoxFire.) But if enWiki would put the spell checker into its own edit box, all wiki sites could instantly install their own. Why is that so difficult? Please don't ignore the proposal, and the innumerable wiki volunteers, all wishing for an easy access to a checker in the editing box. If you can't help, nobody can.--97.121.172.3 (talk) 01:04, 14 April 2009 (UTC)

As with most computer related questions, the answer is yes, it is possible. But is it practical to replace an HTML textarea element with a java application or some other complicated structure, when spell checkers are already readily available to the end user? Probably not. Is it likely? Probably not. If you prefer to use a browser with no built-in spell checking capabilities, that is your choice. IE usually picks up features popular in other browsers, so maybe a future version will give you the functionality you desire. -- Tcncv (talk) 02:27, 14 April 2009 (UTC)
The spell checker is not likely to happen any time soon, given the availability of Firefox and other similar solutions. Per the FAQ on the technical Pump page:

"No, we will not add a spell-checker, or spell-checking bot. Spell checking has been disabled on the Wikipedia search engine for performance reasons, and also because it is impossible to prevent it 'fixing' legitimate errors (see Teh). You can use search engines like Google to search Wikipedia and correct mistakes in searches: include "site:wiki.riteme.site" with your searches. And for spell-checking what is in the edit box, you can use a web browser like Firefox, which includes such spell checking."

--Ckatzchatspy 02:32, 14 April 2009 (UTC)

You quote: "Spell checking has ben disabled...for performance reasons...etc." May I ask you this: what about us, i.e. our time? I don't have to elaborate on this, you all know what I'm talking about. All we want is to have a spell checker, that's just a click away, right under our noses; to correct no more than typing errors, as fast as possible. Gentlemen, I want you to know that I wrote to the founder of Wiki, telling him about this problem--for him small, for us fairly big. I hope he will listen and do something about it. Thank you for trying to help. My best regards to you all. --97.121.172.3 (talk) 03:17, 14 April 2009 (UTC)

It will probably come with new interface we're getting next year. See Wikipedia:Wikipedia Signpost/2009-01-03/News and notes, section "MediaWiki interface to get a facelift". I doubt it will happen before then. - Peregrine Fisher (talk) (contribs) 03:51, 14 April 2009 (UTC)

Well, thank you, Peregrine Fisher--at last there's one person who understood my plight. I looked up the link you directed me to. Yes, there are many "non-tech" editors (including myself), otherwise able to do lots of valuable things. It's a pity that the "facelift" is so far away. Greetings,--168.103.248.249 (talk) 15:57, 14 April 2009 (UTC)

I suppose you could just get Firefox in the mean time... :-p Sillyfolkboy (talk) 16:42, 14 April 2009 (UTC)
Yeah, spell checkers are nice, I use one myself right now. But:
So, anonymous user with many IPs, what about our time? That is, all us users with slow connections and/or slow computers? The code for javascript spell checking would be huge, thus slowing down page load and page rendering a lot for users like me. And it would also make the editing in the edit box very slow.
And what about the time of the MediaWiki developers? It would be a lot of work to implement such a thing. There are many other things that need fixing here at Wikipedia that thus would have to wait or never be done.
Oh, and a spell checker would not work especially well for users like you who don't log in. Since one of the things that makes a spell checker usable is that you can add words to it, so over time it doesn't mark all the correct but unusual words you use. But a javascript based spell checker could not remember words you add, since Wikipedia can not know you are the same user that comes visiting again. Unless of course we add cookies so we can track IP users like you... But many users have their browsers set to remove all cookies when the browser is closed, so even cookies wouldn't help.
And since the spell checker could not know the preferences of not logged in users like you, what kind of English should it use? British, US, Aussie, South African or some other variant of English spelling?
So instead I suggest you install a spell checker plug-in in your Internet Explorer (apparently such things do exist), or if that doesn't work then there are better browsers. But if you are too lazy, or prefer a bad browser, then there's really no way to solve your problem.
(Well, there is a way to make a spell checker that doesn't need javascript, that is entirely server based. But it would work badly for users like you who doesn't log in. And it would be fairly clumsy even for logged in users. And it would cost a lot of server resources and a lot of developer time. Resources that we don't have.)
--David Göthberg (talk) 13:03, 15 April 2009 (UTC)
I would also point out that the development of an English spell checker would not necessarily mean that spell checkers for every other language like Hungarian would be instantly available. At the very least, word lists for each language would have to be found or compiled, and the algorithms used to make suggestions (what good is a spell checker that only says that you're wrong and not how to fix it?) may need to be changed to reflect the different languages. Mr.Z-man 16:44, 15 April 2009 (UTC)

Renaming Articles for Deletion to Articles for Discussion

There is an ongoing proposal to rename Articles for Deletion to Articles for Discussion. Interested editors are asked to comment and make their thoughts known. --NickPenguin(contribs) 04:30, 16 April 2009 (UTC)

Favourites Section

I'm proposing to include a favourites section in the members 'taskbar' so members can quickly access aticles they like, and also to take their favourites around with them. It could also help students with their studies as they could quickly find the articles they need. It's just an idea and feel free to shoot it down. JRGregory (talk) 23:41, 14 April 2009 (UTC)

How is this not redundant with the bookmarks feature every browser has built in? You can easily separate out Wikipedia bookmarks from your others by making a folder for it in your bookmarks bar. A list of pages you want to separate out for quick navigation can also easily be kept on one's user page, or in any offline document. A user's watchlist also functions as a monitor of changes to pages you have taken enough interest in to watch.--Fuhghettaboutit (talk) 01:59, 15 April 2009 (UTC)
I'll hazard a guess the OP wants portability from such a feature—faves, perhaps taggable, accessible at home, work, school, and the privacy aspect of only the logged in author able to see the list. –Whitehorse1 02:08, 15 April 2009 (UTC)
Watchlist can do all except being taggable. No one can see your watchlist, its accessible soon as you log in, and easy to add/remove entries. -- AnmaFinotera (talk · contribs) 02:11, 15 April 2009 (UTC)
I know. *g* There was an edit conflict, and I typed my comment before the previous commenter added the last sentence. –Whitehorse1 02:15, 15 April 2009 (UTC)

A watchlist is mainly for watching articles that you have edited, or in the process of editing. I'm talking about being able to use your favourites everywhere, with IE or Firefox you have to reinsert your favourties everytime you get a new computer. A favourites section which is intentionally used for favourites, not edited articles. JRGregory (talk) 10:55, 15 April 2009 (UTC)

A watchlist is for whatever you want it for. You don't have to ever edit a thing to use it. Browser bookmarks can easily be transfered between computers, it's not an issue, though there's a point to being able to access it everywhere. Why not make a user subpage with Wikilinks to your favorite articles (or even on your main user page?) ♫ Melodia Chaconne ♫ (talk) 11:27, 15 April 2009 (UTC)

What i'm really trying to explain is practicality. People who will use wikipedia for research will not want to go through the lengthy process of saving bookmarks offline or saving them to a subpage. Most people including myself want to be able to quickly get on a website and get started immediately after registering. People will be put off the fact that they will have to redesign their page using code, just to get a favourites page. JRGregory (talk) 14:09, 15 April 2009 (UTC)

See WP:VPT#Notes page?. –xeno (talk) 14:13, 15 April 2009 (UTC)

My solution would be to just edit your user page with the desired links to save the developers from unnecessary work. If that's a problem, you can always create a user subpage specifically designated for these links. I've done this many times in the past.-- penubag  (talk) 07:46, 17 April 2009 (UTC)

Usage statistics as encyclopedically relevant

This is the slightly revised text of a message that I was directed to post in this forum.

Following my perusal of the discussion regarding whether the British singer Susan Boyle meets notability and BLP criteria, and regardless of either the particular case of that article, or the more general and difficult question of whether brief but massive media attention is always notable, I have come to wonder whether the usage statistics of Wikipedia itself may not be more productively used.

While reported usage statistics from other web services or search engines, (e.g. Google searches, YouTube views), suit me just fine personally to establish how notable a thing is, though certainly not how credible, it may not presently be possible to surmount the problem that most web services, as privately owned or administered, are flatly not credible as the only sources of their unreviewable claims unless their service (and thus methodology), were really, truly completely transparent, which Google is certainly not.

However, what i'd like to emphasize here is that the usage statistics of the Wikipedia itself are *relevant to what people want to find in an encyclopedia* unless one were to propose a rather dubious argument that millions of queries for a phrase or a name, or millions of views of an article, reflect a poor popular understanding of what an encyclopedia is supposed to be.

Although I do not see any obvious solution to the notorious problem that editing seniority has displaced peer review in the Wikipedia project, I think that the Wikipedia does have its merits, and that one of them is an unique opportunity for a definitive encyclopedography, such that is not possible or not worth the effort in a paper encyclopedia.

For the present, I would like to see only a few small changes (that may well be impossible to implement retroactively, but that could still be started later rather than never). I want more usage statistics incorporated into the main article layout; this information is actually valuable to me. I would also like administrators to formulate specific guidelines on the relevance of this type of information for content management. It is as important as a consensus by the editors, or more so, because it is found rather than deliberated.

I'm not in the least suggesting an (accessible) list of current watchers, which, in addition to being unavoidably inefficient, would also in my opinion reflect an inappropriate philosophy for the project. rather, in addition to accessible counts of authors, revisions, and a simple total of views, i would like various subsidary counters describing the actual use of links to an article, links from an article, instances of query entry of the article title, and redirects of alternate titles (so we learn which title is actually more in use!)

I wouldn't necessarily care whether these counters are placed in situ or in an appendix, or tab, or box or whatnot. (links to an article, and the counters for their use, would have to be tabulated in an appendix; links from could have a counter in situ). ideally we can even derive some sort of percentage relevance from these counts. (Isn't that exciting?)

More ambitiously, I would like to know what information is proximal in actual usage, rather than nominally by deliberately creating cross-references. I would like the Wikipedia to sample at random what wikis a given user is looking at before and after the current wiki to whatever distance would probably be relevant. This data could be collected for a good sampling of users without much overhead. The results will have high redundancy with cross referencing, but what we'd get out of this automated process are some new cross references that would not necessarily have occurred to us.

L —Preceding unsigned comment added by 24.83.173.203 (talk • contribs) 09:52, 15 April 2009

Yes, it is interesting to see how many visits a page gets, and we actually have a tool that shows that. Here is page view statistics for this talk page last month. At the bottom of that page you can fill in the name of any other Wikipedia page to get the visitor statistics for that page. And you can check earlier months too etc. That tool is linked at the top of the revision history for all pages. So the easiest way to reach it is usually to click the [history] tab of a page, and then click the [Page view statistics] link there.
Note that there sometimes are some days or weeks missing from the statistics. That is because the statistics collection some times crashes, or are turned off for other reasons.
Sometimes when I wonder if a page is worth the effort to take care of I check the page view statistics for the page, and the result is often that I think "Wow, that many visitors? We better take good care of that page." :))
I understand that you want much more statistics than what that tool provides, but it is a good start.
--David Göthberg (talk) 17:33, 15 April 2009 (UTC)
Because usage statistics can be played like a game, it is inappropriate to use the raw numbers to guide content, particularly page views on WP. As long as there are mob-mentality groups that can inflate these to game the system, we can't use this. --MASEM (t) 17:39, 15 April 2009 (UTC)
The inclusion of content may as well be subject to 'mob rule', although I think the exclusion of content must not be. On the premise that the popularity of a document directly attests to its social relevance if nothing more specific than that, something to which a large number of people object is just as relevant as something of which a large number of people approve.
In any case, the *nature* of content should obviously not be determined ad populum --I'm not suggesting that, and I don't think anyone in their right mind would.
Moreover, the underlying assumptions of the argument that 'popularity criteria = mob rule' may be well motivated as the statement suggests a low specificity exclusion of possible vested interests, but I'm pretty sure there's a baby in the bathwater; Wikimedia is in a unique position to make empirical findings about how social espitemology works.
(It's also possible that i'm being accused of advocating mob rule because I picked a bio of a reality show contestant as my only example of a deletion flag that I thought shouldn't have occurred to anyone. Much as I dislike reality shows, my pretentious postmodern conscience doesn't allow me to dismiss what people watch. Incidentally, it seems that during the first three days of existence the article was viewed 35000 times. Of course this will dwindle even if Mrs. Boyle remains successful, but even so I don't think we can just delete stuff like that. Nor do I think that this example reflects the self-interested gaming of some part of the user base.)
L

Not long before Easter 2009, there was a request from a Wikipedian, who was concerned about articles getting deleted, to have some type of "page view" counter. The answer was - one is already there, if one presses "History" at the top of any article. However, it was pointed out that we should use measures other than how many times a page has been viewed as a measure of notability, and I am inclined to agree. After all, if we were to use these page view statistics as our prime measure of an article's notability, Wikipedia would end up being sadly lampooned as an encyclopeadia of popular media culture. Which of these articles do you think had the most views in early 2009 - Paul Tillich, James Joyce, Ludwig Wittgenstein or Amy Winehouse? Yes, I am afraid it is the answer one might fear. More disturbingly still, did you know that the articles on John Lennon and on Star Wars got more views in March 2009 than the article on the Bible? Well, I think this is evidence that what ever use we attach to page view statistics, they should not be used as either the only or the prime index of an article's notability. ACEOREVIVED (talk) 20:23, 16 April 2009 (UTC)

I agree that giving exclusive or primary importance to a viewing statistic would be an extraordinarily bad idea. I do think there is a place for these numbers in an AfD discussion despite 'page views' being listed as a fallacy in AfD discussions. Of course, one cannot say whether something is notable by referring to page views alone; it is a discrepancy between perceived notability and page views which should prove to be useful when in doubt of notability. There would be nothing wrong with supporting a notability judgement with statistical analysis that predicts how articles in certain categories would be expected to perform, (assuming that existing articles largely pertain to notable instances of that category --if we may thus provisionally reduce the information), compared to the actual performance of the article. (I don't claim to have made such analyses and would hate to try, just to be clear.)

(... also, shame about Wittgenstein; surely the man was unhappy enough to have been just as interesting as Winehouse.)

Irrespectively of relevance to inclusion/deletion debates, applications of query information and views would serve to keep prevalence-sensitive information up to date without any need for sources pertaining to prevalence (esp. of nomenclature; synonyms, metonyms, aliases) --which, *actually*, are quite likely to be inferior to the quantitative data drawn directly from the user base, anyway. (If a poll on the scale in the Wikipedia operates contradicted earlier surveys of prevalence, I would say the earlier surveys were wrong!) E.g., with an extremely simple script & the appropriate database, the most prevalent way of referring to a given subject could always automatically become the title to which all other queries redirect.

The short and skinny of the bigger proposal is that an empirically based, automatically generated proximity map of each wiki in relation to other wikis would be a useful and attainable complement to existing hyperlinks and classificatory elements. The user would be able to look at all 'nearby' wikis whether or not the nearby wikis are 'hard-linked'. It does occur to me that, where the hard links differ from the generated links, the pop culture bias would probably be higher in the latter, but since this scheme would not be intended to replace other ways of framing relationships between wikis, biases, whatever their nature, would actually be desirable. So, how is this different from just using a good search engine cleverly enough? Only in that the contents of the Wikipedia are already selected specifically for expository value.

L

Oh, and one other thought that makes me extremely pleased; if we could classify articles in such a way that their performance (in views/time) may be predicted, we would not merely have an indications that an underperforming article may not have been as notable as we thought, or that a disputed article performs well enough to satisfy skeptics, but also than an *overperforming* article might have been 'gamed'! yay, stats!

Move tab

Is there any particular reason, technical or otherwise why the move tab has no other tabs at the top, ever other tab does, doesn't make sense for this one not to. I'm guessing this is a bugzilla thing but thought I'd bring it up here first--Jac16888Talk 02:52, 17 April 2009 (UTC)

Not sure what you mean. When I click on the "move" tab, the page that comes up has a "special page" tab, as has the "Move succeeded" page. Are you missing (some of) these tabs? Mark Hurd (talk) 04:32, 17 April 2009 (UTC)
No they're still there, I'm talking about Page, Talk, Edit, History, Delete and Protect, why are they not there?--Jac16888Talk 04:40, 17 April 2009 (UTC)
AFAIK no "special page" has any other tabs. Mark Hurd (talk) 05:07, 17 April 2009 (UTC)
The special pages all ought to be in the toolbox. It's inconsistent to have one of them as a tab. —Remember the dot (talk) 06:22, 17 April 2009 (UTC)
What's inconsistent is to have most of the common page actions as &action= parameters in the URL, and yet have one action as a special page. I believe, however, that the general feeling amongst the devs is to move towards the special-page system. We could always add the tabs using JavaScript... Happy‑melon 09:41, 17 April 2009 (UTC)

Talk page banner

Because my computer isn't working online right now, I'm using my alternate account (meant for use on public computers) instead of my actual one, Nyttend. Each time that I use this account, I have to go to my main account's talk page to see if there are new messages, which I'd like to avoid if possible. Would it be possible somehow to create a system whereby those of us with legitimate multiple accounts could somehow get them "tied" together, so that a message left on one talk page would generate the orange "You have new messages" banner on the other account? Nyttend backup (talk) 12:44, 17 April 2009 (UTC)

that would be cool. –xeno (talk) 12:50, 17 April 2009 (UTC)
Add your main to your watchlist? ♫ Melodia Chaconne ♫ (talk) 13:09, 17 April 2009 (UTC)
[normal computer working now :-)] I could do that, to be sure, but I don't see how that would be any easier than going to the talk page. Nyttend (talk) 15:21, 17 April 2009 (UTC)
Well, you wouldn't go there in vain when there's nothing new, because you'd be alerted when there's something new there. -GTBacchus(talk) 16:44, 17 April 2009 (UTC)

I propose a "why don't you run a wiki" section

I've realized after installing a wiki for my personal websites - that only I can edit - that some of the 'fun' of wikipedia is to edit stuff even if nobody else contributes. So if some people are so determined to edit and nothing can stop it even everyone else tells them to stop, "why don't you run a wiki" tell them:p --AaThinker (talk) 18:06, 17 April 2009 (UTC)

Are you saying that we should tell vandals to vandalise their own personal wikis. I don't see them listening. Zain Ebrahim (talk) 18:11, 17 April 2009 (UTC)
People who want to add in information that others consider fancruft, or not notable, should be directed to www.wikia.com, it existing for that purpose. Many wikis already exist, loaded with vast amounts of information fans find interesting, and enjoy editing. Star Wars Wookieepedia, Marvel comic books, Gantz, Forgotten Realms novels, and The Simpsons, are good examples of different types of wikis you find over there. Dream Focus 20:44, 17 April 2009 (UTC)
Wikipedia:Alternative outlets to your right. --Gadget850 (talk) 21:22, 17 April 2009 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_45&oldid=1171579425"