Jump to content

Wikipedia:Village pump (proposals)/Archive 47

Add links
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

Should talk pages of redirects be replaced with a redirect to the new talk page?

As another editor has expressed concern over ListasBot 3's approved functions (in short, whether or not talk pages of redirects should be replaced with a redirect to the new talk page), I've set up a discussion on how to proceed with this bot. Input would be appreciated. The discussion is at User:Mikaey/Request for Input/ListasBot 3.

Thanks, Matt (talk) 02:49, 12 May 2009 (UTC)

Funny, I just experienced an example of where that bot wouldn't be helpful: I wanted to place a redirect template ( {{R to scientific name}} ) on "Dandelion" (which redirects to the more scientific name "Taraxacum") but it was a fullyprotected page.. so normally I'd go to the redirect's talkpage to post the {{editprotected}} request but I just got redirected again to the new talk page (Talk:Taraxacum). So I had to go back to Talk:Dandelion and overwrite the redirect code in order to place the {{editprotected}} request. Kinda annoying. -- OlEnglish (Talk) 08:48, 12 May 2009 (UTC)
The first (unnamed) parameter caters for that scenario. On Talk:Taraxacum you could have put {{editprotected|Dandelion}}. Mark Hurd (talk) 18:16, 12 May 2009 (UTC)
Perhaps this should be copied over to User:Mikaey/Request for Input/ListasBot 3   M  21:52, 12 May 2009 (UTC)
Doh! Just read that in the docs. :) -- OlEnglish (Talk) 10:08, 13 May 2009 (UTC)

Create an article

In response to the early results of the usability study, I propose adding a link to the Navigation sidebar. This link would be called "Create an article" and it would link to Wikipedia:Your_first_article (or perhaps an even more simplified version of that page). In the case of anon users, ideally, this page should only explain to them why they cannot create a new article and not present any of the other information (Unfortunately, this is likely only possible with FlaggedRevs).

I realize that this link would be pointless to many of our resident users, but I think it is important for our new users. So important, that I think we should get over our own objections to such a thing. :D Atm. we are trying to avoid "n00b" articles through obscurity, but we are also pushing away many editors that have difficulty understanding 1 of the 3 basic things new users are looking for (read, edit, create) on our website. I think it is worth considering this once more. —TheDJ (talk • contribs) 20:30, 9 May 2009 (UTC)

Do you have evidence that the usual way to create an article fails in some way? Where should this link be placed? (Under upload file, I think.) –MT 21:53, 9 May 2009 (UTC)
I suggest you read the early draft of the usability study. "Create an article" section... —TheDJ (talk • contribs) 00:21, 10 May 2009 (UTC)
Sure, but it might help if you copied a couple of the most relevant sentences here for people to see. –MT 00:31, 10 May 2009 (UTC)
We delete more than a thousand articles every single day. This proposal would clearly increase that number. -- John Broughton (♫♫) 22:06, 9 May 2009 (UTC)
It's not clear and it's not intuitive. And the fact that many proto-articles (rightly or wrongly) have a very short half-life certainly does not imply the opposite: that there are not also and at the same time huge swaths of Wikipedia that are sparse, barren or spottily-populated, and where we've long desperately needed material. Sometimes these are just stubs that have never been expanded, but often even the stub hasn't been created. (And some outsider or newbie with incomplete information might start a necessary stub where none exists now to be filled-in and improved over time by more-experienced or knowledgeable editors.) Even stubs that get quickly deleted can sometimes serve a purpose by pointing out under-covered areas. And this doesn't just apply to stubs: it's quite possible that some outsider with particular knowledge of (say) some little-known corner of Baroque music, bacteriology, sports, computer science or ecclesiastical history might be able to create a perfectly-adequate article from scratch. That outsider might, however, not have the patience to puzzle out how to start. —— Shakescene (talk) 23:13, 9 May 2009 (UTC)
Exactly Shakescene. I'm not doubting that we would have more articles that need to be deleted every day, i'm just saying that we are confusing users and potentially putting off people that would want to contribute and in the long run would be valuable contributors, had their first experience not been so confusing. This is one of three most critical activities that users are expecting to find easily on the website, and we are making it so difficult that they get totally lost within the website. The point is that having this would be a "net positive" for the project, regardless of the fact that it would lead to more CSD activity. —TheDJ (talk • contribs) 00:21, 10 May 2009 (UTC)
You could argue that though we'll see more useless articles, we'll also see not only more useful articles too, but also more people who join in on the project and go on to help delete useless articles. Do you have any statistics as to what the deletions are for? This might help you make this argument. –MT 00:34, 10 May 2009 (UTC)

See also a previous proposal made here which gained some support, now auto-archived, but moved to Wikipedia:WikiProject Policy and Guidelines/Suggestion Box#Search Results - Article Creation Wizard. Basically make an Article Creation Wizard and link it from locations like MediaWiki:Noexactmatch. (Draft: User:Rd232/Noexactmatch/Proposal). Rd232 talk 14:04, 10 May 2009 (UTC)

Ah, I like it, and linking to such a creation wizard instead of Your first article, might be even better. We should work with Trevor I think. He has put up some early design idea for reworking the Search results page itself [1]. —TheDJ (talk • contribs) 14:50, 10 May 2009 (UTC)
The problem is that people don't know that to create an article, you need to type its name into the search box. Tra (Talk) 17:12, 10 May 2009 (UTC)
Yes, this is exactly why I propose to add a link to the sidebar. It still won't be easy to create an article, but at least, people will be put onto the right path. If this links to a form of "Your first article", or to an "Article creation wizard", is not entirely the point of this proposal. It is the idea that from a usability perspective, we should give people an "entry point" to reach their goal. Where that entry point leads to and how we best guide users beyond this first link can probably best be discussed separately. —TheDJ (talk • contribs) 18:14, 10 May 2009 (UTC)

¶ Perhaps, since most new readers/editors are understandably nervous, confused, hesitant and even intimidated about the whole process (I've started very few articles from scratch myself in the year I've been here, and the first one was filling in a stub, New York City mayoral election, 1917), there might be another option, "Propose an article", where hesitant newcomers (not inclined by nature to BE BOLD) could solicit guidance without the fear of (1) putting an unsatisfactory article out in public, (2) starting a lot of work that's speedily deleted or edited beyond recognition, or (3) being on the receiving end of a ton(ne) of hostile brickbats. From the other end, it would allow other editors to point out in advance where a proposed article is already covered elsewhere, or needs to be reconceived to meet some Wikipedia criterion. —— Shakescene (talk) 19:45, 10 May 2009 (UTC)

Don't we already have that in the form of Wikipedia:Requested articles ? —TheDJ (talk • contribs) 21:15, 10 May 2009 (UTC)
As I understand it, "Requested articles" is for articles you want other people to write; I'm suggesting a way for people to propose articles they want to start. —— Shakescene (talk) 22:31, 10 May 2009 (UTC)
I'm not sure if we could find the amount of editors that would be needed to "man" such a desk, but it is beside this discussion as far as I'm concerned. Like I said above, I don't really care where the link leads to, I just think that from a usability perspective, their should be an "entry point" in the webpage that would direct people to A place where they are educated about article creation. —TheDJ (talk • contribs) 22:51, 10 May 2009 (UTC)
I'm with you in not caring so much as where a link would lead as in the existence of an obvious path for someone who wants to start one. I wondered whether my idea was relevant but decided that it might be another way to engage puzzled new would-be authors. I don't know that a dedicated staff would be necessary (perhaps it would) but most such incoming traffic (Recent changes, etc.) is covered by ordinary random editors. —— Shakescene (talk) 23:16, 10 May 2009 (UTC)

This has long been a concern of mine. Originally, new articles were intentionally made difficult to create so that all articles would come from red links, and so not be orphaned - this is wiki philosophy but I think it's unrealistic, especially when starting articles in a sparsely-populated area.

I understand that a straightforward, quick way to create a page is unlikely to gain acceptance because of concern about poor articles being created. Because of this I propose a two-step solution:

  1. There is a link in the toolbar reading "Create an article". It links to a page briefly describing what sort of articles are acceptable at Wikipedia and what sort of information should be placed in a new article. If the user is not logged in, there is a message at the top of the page telling them that they must create an account to create a new article.
  2. At the bottom of that page is an edit box where they enter an article title and a button that says "Create".

This would make it straightforward to create new articles, and ensure that they had a chance to read the relevant guidelines. I believe the influx of new useful articles would more than justify the increased work of deleting articles, for the same reason that we let all users edit articles. Dcoetzee 07:32, 14 May 2009 (UTC)

Maybe we could use something similar to the AFC wizard. I see there's also Wikipedia:Article wizard, which could be restructured in that way. We could sync it with the AFC wizard: the "create an article" link would link to the first page, and users could choose between the wizard for registered users and the AFC wizard for anonymous users. Cenarium (talk) 16:22, 14 May 2009 (UTC)

IRC client in a wiki page.

Would it be feasible to let users connect to IRC through Wikipedia itself, instead of being forced to either install a chat client, or try using Mibbit, which has the distinct possibility of being blocked from Freenode? UntilItSleeps PublicPC 19:38, 12 May 2009 (UTC)

Is there something wrong with the java IRC clients out there? –xeno talk 19:48, 12 May 2009 (UTC)
They are external, slow-loading, not-integrated, most people don't understand them, irc has a reputation for being 'hard to use', and so on). Imagine how much more effective the various help services could be if we had a Special:Chat that logged the person into, say, #wp-helpdesk as "<xeno-wp543> hi" (or as "<bot> <xeno> hi"). To prevent people from being overwhelmed, the chat client could by default hide all messages except "<m> xeno: hey" (which would display as "<m> hey"). Normal irc users would see the whole chat, and that setting could be disabled. After special:chat is closed, a bot can paste the log into the editor's talk page for reference.   M  21:49, 12 May 2009 (UTC)
Would an official server be able to host such a chat bot, or would some other server have to be used? Is such a bot/interface feasible?   M  22:48, 13 May 2009 (UTC)
We are actually here to produce an encyclopedia, I don't think that the developers' time, or the Wikimedia Foundation's charity money, would be validly spent in producing an instant-messaging function for the MediaWiki interface. If people don't understand IRC (and it's quite simple, you log in, you type a message, you press enter, you wait) then they can probably cope with waiting a couple of hours for a reply at the help desk. ╟─TreasuryTag►contribs─╢ 15:58, 14 May 2009 (UTC)
I don't think that "well, then they'll just have to figure it out, or figure out the current tools" is an appropriate response to usability problems. Developers have already spent the time - it's the talk page, which is the single most important and useful editor tool on Wikipedia. However, it's a) difficult to use, and b) has a very slow turnaround, both of which discourage new editors. For certain types of communication - "I don't get this reference thing", "what kind of writing style should I use"[2] - an accessible and real-time method of communication is clearly more appropriate. This is also a feature that might not even require the time of the MediaWiki devs.   M  17:54, 14 May 2009 (UTC)
Inventing a new special page, with the mechanisms that you described [Special:Chat that logged the person into, say, #wp-helpdesk as "<xeno-wp543> hi" (or as "<bot> <xeno> hi"). To prevent people from being overwhelmed, the chat client could by default hide all messages except "<m> xeno: hey" (which would display as "<m> hey"). Normal irc users would see the whole chat, and that setting could be disabled. After special:chat is closed, a bot can paste the log into the editor's talk page for reference] would almost certainly require funding, dev-time, and all sorts of new structures and functions (user-rights, ops, Oversight, deletion, accountability, how it affects user-contributions and so on. I'm not sure that the added amenity (a slightly faster response to help-desk enquiries by those users intelligent enough to navigate such a system, but not savvy enough to click here) would make this worthwhile. ╟─TreasuryTag►contribs─╢ 18:26, 14 May 2009 (UTC)
We really don't have to do it all at once, and maybe we can start with figuring out a script-like way to help out UntilItSleeps_PublicPC. Javascript that, say, pings a chatbot for new messages every second is trivial. A 'helpdesk' chatbot of this sort may already exist, and there are many irc bot frameworks already available. The biggest problem is finding a host...   M  20:37, 14 May 2009 (UTC)
I believe a bot that pings the #wikipedia-en-help channel whenever a new help desk section is created already exists. But that's a lot different than embedding a custom-made IRC client into a wiki page. Embedding a plain Java IRC client into a wiki page like PJIRC would be fairly trivial (at least 2 extensions to do this already exist) and embedding an AJAX client like [3] probably wouldn't be too hard (among other benefits, Java applets have the benefit of running almost entirely client-side, so performance impact on the servers isn't much of an issue). Making a custom client to automatically handle logging in and filtering messages would be a lot more work. Depending on how versatile they are, it would would require anything between heavy customization of an existing program to starting from scratch. In any case, finding a host for a bot is the least of the issues; there's plenty of Wikipedians with toolserver and/or ClueNet accounts as well as some that have their own servers. Mr.Z-man 21:39, 14 May 2009 (UTC)
I think that the filtering is pretty trivial (starts with 'z-man:' or 'z-man,'), and that authentication might be done using the following steps: the gadget 'connects' to the bot, sends it a random string, then creates a new section in the user's talk using that string in the edit summary. It then sends the revid to the bot, the bot verifies, and chat begins as usual. After completion, the gadget (or bot?) inserts the log into that section in the user page. There might be a better way too, but I think this might take care of a few of the problems.   M  22:09, 14 May 2009 (UTC)
I think you missed my point, my point is that embedding a Java client that autojoins the help channel would be trivial, but once you start getting into customizing the source code of the client itself, the difficulty level increases exponentially. Mr.Z-man 23:08, 14 May 2009 (UTC)

Make new contributions or changes in articles appear in a different font colour

Recently an Irish student posted on Wikipedia a fake quotation from the recently dead composer Maurice Jarre. He said he was doing a sociology experiment. Apparently it succeeded, as several media outlets cited the quotation in their obituaries.

In order to prevent Wikipedia becoming an easy target for such fraud, I suggest that all new contributions in Wikipedia articles appear for a time (say for 5-10 days) in a different-coloured font such as in red. This way when journalists and other serious researchers consult the site, they can distinguish between recently added content which would naturally be less trustworthy and long-established content which would be far more trustworthy.

Luderart (talk) 22:00, 12 May 2009 (UTC)

I don't think that journalists need red text to remind them to do their research correctly. This would also make some articles unreadable, since our diff algorithm sucks. Would we mention deleted content, or is this not relevant? Here are the first 3 articles from recent changes compared to what they were 10 days ago, with the sort of coloring you'd see on the right (new sections would also be red): [4] [5] [6]. What do you think?   M  22:30, 12 May 2009 (UTC)
I agree, it's not our responsibility to force journalistic integrity and ethics upon the world. --Golbez (talk) 22:51, 12 May 2009 (UTC)
Length of time in the article is a rather crude way of estimating content quality. It would only be somewhat useful on the few articles that get edited almost every day. On all the other articles, it would be mostly useless. Mr.Z-man 23:00, 12 May 2009 (UTC)
Though I think that the 'recentness' idea (which is intended to help journalists) is broken, maybe there are ways to help regular editors become familiar with the diff/history, so they can check for this sort of vandalism themselves. How about a "check this article for vandalism" link, which goes to a version of the history page that has a help section ( "this shows older revision, you can track changes by blah blah; here's how you revert, add [citation needed] if you think something is dubious" ) at the top?   M  23:13, 12 May 2009 (UTC)
You might want to look at Wikipedia:Flagged revisions and the surrounding discussion. This is used on the German language Wikipedia. --Stephan Schulz (talk) 10:31, 13 May 2009 (UTC)
Maybe we should highlight new text in red, and have it rateable by anyone other than its author—if it's positively rated, its background nears white, if it's negatively rated it turns more red. Dendodge T\C 20:43, 13 May 2009 (UTC)
Actually, if this can be made less intrusive, it might be a way to attract editors. Cleanup templates are frequently used - maybe we could have a skinny autogenerated one, for use on certain pages (ones with fewer than 50 edits? fewer than 10 in the past month?) that says "This page has recent edits that you, the reader, might want to check out." Clicking takes them to the diff, or the red-text version. We might even be able to give this a trial run on a few pages using just regular templates, and see if the numbers of helpful anon edits increases.   M  21:00, 13 May 2009 (UTC)

This proposal is not all that different to what one can find if one clicks on "History" at the top of each page. At least on this PC, one normally finds that revised editions on "History" are in a different colour. ACEOREVIVED (talk) 20:27, 14 May 2009 (UTC)

I think it's often easy to overlook how difficult familiar tasks are to new and non-technically-minded users. If you asked some of the people in that recent usability study to 'make the new text look red', they would have absolutely no idea what you were talking about. Though it's true that we have most of that functionality implemented, if that's what you mean.   M  22:13, 14 May 2009 (UTC)

Photo dump

As some of you know, RemoveImageBot has been reported of deleting pictures that have been removed from pages. I'm thinking that they could be put into to a "Photo Dump", so they could be easily put in use again. It would prevent things like this from happening again, and would be convenient. Only established users and Admins can use this, and no bots. Please consider. Thanks, Old Al (talk) 02:11, 14 May 2009 (UTC)

Only orphaned fair use images are deleted. They must be deleted to avoid violating the law. They can be restored by an admin at a later time if necessary. Dcoetzee 07:35, 14 May 2009 (UTC)

Moving articles

It strikes me as strange that the ability to move articles is solely an auto-confirmed right, and can't be given by admins on request. I understand that this policy exists to prevent new editors from violating Wikipedia:Move, but I feel that admins ought to be able to give this right to editors who demonstrate knowledge of the appropriate policy, even if 4 days have not elapsed. If there is prior discussion about this policy, could someone please direct me to it? Nanowolf (talk) 07:00, 14 May 2009 (UTC)

I'd imagine that there are very few editors who could demonstrate that sort of knowledge of policy in under four days. Because getting the autoconfirmed flag is so easy, and because moving articles is not an everyday task (well, unless you're a pagemove vandal, I suppose), I don't really see any need to come up with a separate flag just for moving things. I'd imagine that by the time an editor comes across an article that needs moving, they'll probably have naturally gained the ability to do it, and for the handful of exceptions, there is always Wikipedia:Requested moves. Lankiveil (speak to me) 08:47, 14 May 2009 (UTC).
If someone knows the policies well enough, they could just go on to the talk page and propose the move...or wait the four days. ♫ Melodia Chaconne ♫ (talk) 11:26, 14 May 2009 (UTC)
Thanks for the comments. Reasonable points. Does anyone know if there's been a discussion of this policy in the past? Nanowolf (talk) 22:31, 14 May 2009 (UTC)

Source verification process

Currently, more than likely, the internet is used as a source for a piece of information. While this is all well and good, the internet (in my opinion) is very unstable. Not in its design but in the websites, in that a website could be up one day, and down another. We already are beginning to see this in Featured articles, where a source may go down, but with FA status, its creators (I as one) believe that maintenance can become a little lazy. When FAR may come around, these sources are found. But Wikipedia seems not to have acceptance to the fact these sources were not accurate. That new ones must be found and archive websites don’t have every single website.

On WP:Notablity, it says notability is not temporary. If an article is notable enough now, then it is notable enough in 1000 years. But in 1000 years, will the sources on those articles be available to access on the Internet. (Presuming the internet and Wikipedia survives) In my opinion, most likely not. So every internet source will inevitably have to be replaced. But with the new source, this process will go around in circles. And a source describing a minor issue on a biography, may not be repeated in a new accessible source. So is a source temporary? Why do sources have to be replaced? That’s because in line with Wikipedia policy, we need reliable sources and a dead link is certainly not reliable, and we can’t assume the person who placed the source there was correct. I don’t believe sources are temporary, if a reliable source is trusted now, it should be in 1000 years. But how do we stop this.

My proposition is a source verification process/system. Where templates like {{cite news}} and {{cite web}} have parameters including a verification and verificationdate. The verification will be done by an independent user, and the date when the user provided the verification. The user, will check the source, read what contents it provides against the information on the article and it is verifiable and then sign in the template that the information is verifiable. Then the information should be good enough to survive through the ages. Perhaps two verifiers?

The problem is, this is a huge process, and to have every internet source on Wikipedia verified, would be massive. A huge logistical effort. Also, independent means someone who has not used the article or source before, otherwise, someone could claim incorrect facts, and no-one should verify a verification. There are many flaws already in this proposition, but I believe it’s a necessary step to make. Especially at a minimum, for our featured articles, because I would hate to see, the featured articles lose their FA status due to the gradual decline in source availability. As a writer of a FA, I would hate to see the article lose its FA status after I have left Wikipedia. Look at Karmichael Hunt, it is practically reliant on online sources, in a thousand years, if even one of those sources is still available, I’ll turn in my grave. But in 1000 years, if this went under FAR, it would fail because it had no sources.  The Windler talk  10:42, 6 May 2009 (UTC)

I am also unsure if this is the correct place to write this, but please direct me if incorrect.  The Windler talk  10:42, 6 May 2009 (UTC)
You're confusing the issue of whether a source really supports the text with the issue of preserving a copy of the source document. If we solve the second, the first is irrelevant, since anyone can check the source document at any time. And given the huge amount of unsourced text in Wikipedia articles, I really doubt that there is any significant interest here in spending valuable time looking closely at citations that we already have. Particularly since the overwhelming percentage of them do really support the related article text.
With regard to the second - and much more important - issue, you should look at Wikipedia:Citing sources#Dead links, which discusses preventing dead links as well as repairing them.
As for a thousand years from now, I really doubt your or anyone else's ability to predict what the future will look like 100 years from now, let alone 1000, and I think there are a lot more important matters to worry about than whether Karmichael Hunt will still be an FA then. Let's concentrate on what will improve Wikipedia in the next two or three years, yes? -- John Broughton (♫♫) 18:45, 6 May 2009 (UTC)
Hmm, I knew not of the on-demand archive service, thank you for your reply, just food for thought,  The Windler talk  21:47, 6 May 2009 (UTC)
Also, a fair number of the citations on Wikipedia, though maybe not a majority, are either cited to paper or cited to internet sources with paper equivalents or near-equivalents. (Examples: Newspaper and magazine articles, academic journals, court cases.) --Philosopher Let us reason together. 01:24, 8 May 2009 (UTC)
It seems that the responses have solved the issue - is that correct? –MT 00:14, 10 May 2009 (UTC)
Well, I have found WebCite (a on-demand archive site, so it solves the problem, I wanted, so yes.  The Windler talk  03:49, 16 May 2009 (UTC)

Image upload proposal

I have created a proposal at Wikipedia talk:Upload#Free images and Commons regarding a possible change to the upload system; all comments are welcome. –Drilnoth (T • C • L) 17:25, 15 May 2009 (UTC)

split "discussion" across "questions" and "edit"

Closing this discussion while a precise proposal is in the works on my talk page, please join in. rrzzrr (talk) 18:16, 18 May 2009 (UTC)

Whether you're reading or writing on Wikipedia is a fluent situation. They are, however, different modes of use. When you want to retrieve information (consume), you want clear data, attractive presentation and minimal distraction. When you contribute information (produce), you don't mind verbosity, great complexity or ambiguity in the search for clarity. A reader is best served with accurate simplicity, a (collaborative) writer is best served with scribbles, notes and feedback. The best versions for reading and writing are therefor incompatible, resulting in a compromise. This understandable compromise is most obvious in the frugal features for collaboration and overlap between user (user/user, user/producer) and producer (producer/producer) interaction in "discussion."

I'd like to request separating the two. Rebrand "discussion" as "questions" and focus it on users, to ask questions about the subject. Expand "edit this page" to include an annotatable version of the article, allowing producers to discuss, comment and collaborate on the article.

It's a rough proposal, to be sure. But I'm also sure separating the modes of use will allow Wikipedia to tailor two environments to enhance both experiences even further.

rrzzrr (talk) 20:17, 11 May 2009 (UTC)

This idea certainly has merit, and I would like to see it in practice, but I'm not sure how easy it would be to make. Dendodge T\C 21:33, 11 May 2009 (UTC)
The Wikipedia:Reference desk is available for readers to ask questions about content. This centralised approach avoids problems such as knowing which precise article's page to ask your question on, and gives a much wider audience of users able (and willing) to answer a question than those who are watching a talk page. OrangeDog (talk • edits) 00:01, 12 May 2009 (UTC)
Re: Wikipedia:Reference desk, how about if the proposed "questions" tab linked directly to the appropriate desk? User queries would then have a clear, simple pipeline. rrzzrr (talk) 12:58, 12 May 2009 (UTC)
Or perhaps some sort of {moreinfo|What's a thisthing?} template, if we could teach casual readers to use it, which I don't think we can. Adding Have a question? to the 'interaction' toolbox might overload helpdesk, though it might break the ice to (some form of) editing for a few people.   M  22:55, 13 May 2009 (UTC)

The ratio of readers to editors is roughly 1000 to 1. Anything that encourages readers to think that only "other people" edit Wikipedia is only going to make this ratio even worse. And if the volume of questions from readers increases, assuming that the questions do get answered, that's only going to drag "producers" away from other things. -- John Broughton (♫♫) 01:31, 14 May 2009 (UTC)

However "bad" the ratio of editors to users is, the english version counts 6,906,395 articles. The editors seem to be holding their own.
As to a flood of questions from readers, though initially a "questions" function will likely cause a spike, many questions on a given subject will overlap and FAQs will emerge rapidly. Moreover, if we accept that the purpose of Wikipedia is to enlighten, then whenever an article fails to do so, feedback is a great thing. These FAQs then constitute a great boon, as they confront editors with the reader's experience, identifying the weaknesses of articles.
As for editors, apart from the benefit mentioned above, a "dirty" (annotable) page will provide a natural, intuitive environment for collaboration; issues can be seen at a glance and discussed; observations and new information (sources) can be shared, etc, etc.
In short: deviding the reader and editor experience more clearly, doesn't alienate them from eachother, rather, both experiences are enhanced, while contact becomes easier and more fruitful. rrzzrr (talk) 20:59, 14 May 2009 (UTC)
Very interesting idea, rrzzrr, but I think it'd be a nightmare to implement (annotable versions of articles, in a wiki interface, with user rights, and reverting, and signatures, and history, and ongoing discussions). Scarcely a good investment in our time, to fix something that's not really broken. ╟─TreasuryTag►contribs─╢ 16:07, 14 May 2009 (UTC)
No pain, no gain. Whether it can be done should always follow talking about whether it should be. :) I know it would require some serious sandboxing, but that's what they're for, right? rrzzrr (talk) 20:59, 14 May 2009 (UTC)
I think the 'feedback' point is a great one, and I think this sort of thing belongs on talk pages and wikiproject pages, not at refdesk. I don't think we want to encourage ref-desk type questions, but perhaps modifying some of the standard talk templates to say "if the content of this article is unclear [etc.], please click here to leave a brief descriptive message for other editors". Would this be a good way to go?   M  21:33, 14 May 2009 (UTC)

Just out of interest do you know about reference desk? David D. (Talk) 21:43, 14 May 2009 (UTC)

Sorry, just noticed this has already been pointed out by OrangeDog. Note this does not have the same function as the help desk. It would be appropriate to link to ref desk if there was a question tab. It would not be appropriate to direct a reader to ask a question on the talk page, IMO. The talk pages would become a ghastly mix of questions and article improvement content, not to mention the odd flame war here and there. David D. (Talk) 21:50, 14 May 2009 (UTC)

I this is an interesting suggestion and there may be a form in which it could exist which does not bring any of the problems cited but does bring the rather compelling benefit cited: that feedback may well highlight article weakness if a question has had to be asked, and locating that feedback with the article could dramatically improve the chances of a corresponding improvement being made to the article compared with, say, a helpdesk query of some kind. Even without annotable versions of articles, an interface identical to the present talk page interface would support this amply, IMO. No doubt someone here can gauge the technical feasibility of adding a second "talk" page for this purpose, but even without such, perhaps the mix of questions and article improvement content on the one talk page would not be so ghastly, remembering that each talk page section is usually considered in isolation from others. I am quite taken with this idea. PL290 (talk) 12:39, 15 May 2009 (UTC)

Closing this discussion while a precise proposal is in the works on my talk page, please join in. rrzzrr (talk) 18:16, 18 May 2009 (UTC)

Easy references

One of the problems raised by the Wikipedia usability study was the difficulty of adding references - this intimidated users who felt obligated to add them but couldn't figure out how. In lieu of a proper technical solution, I suggest we provide an alternative "easy references" syntax for use by newbies. It's very simple: they just enter the reference in parentheses after the statement it's sourcing. Most people know what to include in a reference from English classes, so that wouldn't be a big issue. These can be trivially reformatted by other users by throwing in ref tags and a References section. Dcoetzee 07:40, 14 May 2009 (UTC)

We could always enable the refTools gadget by default on new user accounts; this makes adding references easy and I've been using it successfully for a long time now. Lankiveil (speak to me) 08:50, 14 May 2009 (UTC).
"Most people know what to include in a reference from English classes, so that wouldn't be a big issue." You're assuming (1) that they actually had an English class that taught them proper sourcing, (2) that they actually remember in enough detail what they learned about sourcing in that class, and (3) that they will realize they need to use that knowledge here. I'm not particularly confident that any of those assumptions will be true often enough; I know #2 isn't true for me. Anomie⚔ 11:33, 14 May 2009 (UTC)
I agree with Lankivell. Can someone please make the ref tool be in the edit toolbar by default? It's moronic to not automatically enable the ref tool when it's extremely helpful by automatically formatting references, and it's still optional to use. Reywas92Talk 23:20, 14 May 2009 (UTC)
The downside is that additional 'features' are often confusing. Maybe we should just have the Cite your sources:<ref></ref> spit out <ref>insert source here</ref>.   M  22:32, 15 May 2009 (UTC)
I suggest you try it. It's not confusing. Click the button, choose source type, copy and paste the link, author, publisher, etc. into the designated fields, and then click Add Citation; it automatically adds the completed template. Trying to use one of the templates by itself it much more confusing, having to find the template, which has too many unused fields, filling it out, and copying that into the article. And users can still just insert the link if they can't understand. There's nothing wrong with an available link to the feature. Reywas92Talk 23:00, 15 May 2009 (UTC)
I can cope; the problem is new users. See the link to the usability study above.   M  03:57, 16 May 2009 (UTC)
(e/c)We have that, its the button on the toolbar, which gives <ref>Insert footnote text here</ref>. I support making my script a sitewide script as well, though mainly for the reason that I'm too lazy to give it all the improvements it needs, and if its a sitewide script, other people might be more willing to work on it :P Though there currently isn't a way to enable gadgets by default, except including them in Common.js (though this is being worked on, I think). Mr.Z-man 23:04, 15 May 2009 (UTC)
(I always assumed that they were just redundant. Could this just be changed then in js?) I'm not a fan of template citations in the middle of articles, they make source extremely hard to read/edit. These should be in references (reftools would be great for this) with <ref>Jones pp.43</ref> inline, as ugly as it is. [cite:Jones pp.45] (unused, intended to mimic [http:... text], rather clear and standard) would be much nicer. Most people who are capable of citing a source know that sources go towards the end, and having a bunch of these templates at the end, in one place, lets people learn by example. Then, the references section would throw it all together, and put the [cite:..] things as a sublist under the actual citation.   M  03:57, 16 May 2009 (UTC)
There's 2 (significant) issues with putting all the references at the end. 1) It makes editing references during section editing even more difficult. While this is somewhat of an issue now with named refs, it would be more of an issue if we required all the references to be separate from the content. 2) All the editors used to the current system and anyone who learns by example would all of a sudden be doing it wrong. Mr.Z-man 04:28, 16 May 2009 (UTC)
Agree with first point, though in some cases the inability to find text that you want to edit is way worse. For the second, the old system could still be used, but discouraged. Maybe a script could be written that removes all refs into an a div below the edit textarea, replacing them with numbers[439]. If you mess with the number, the ref-down-there turns red. Click the button to inject another ref below using reftools, and a number inline. Parsing/replacing the refs wouldn't be very difficult, and then add a timer that makes sure the numbers are all still there in the text. Offer little 'add this ref' for any new numbers (so right now I'd see '439: [click to add ref]' somewhere below).   M  05:16, 16 May 2009 (UTC)
People should not feel obligated to add references in "proper format"; please distinguish between improving content and copyediting. Also, there is no excuse for people not to add references in some form because we still support all manner of in-line linking, including adding bare urls. The notion that people are put off by the ref-syntax is a red herring; the reality is people just don't want to add supporting citations in any form ... and it is any form that is supported, not one form. --User:Ceyockey (talk to me) 18:38, 16 May 2009 (UTC)
You are incorrect:
  • "Another major concern that participants expressed was the need to cite and validate their information. More often than not, our subjects did not know when they were expected to add a reference, felt an impulse to add a reference anyway, and faltered on the right way to do that, which included determining where in the article (or which section) was appropriate, the correct formatting, and the appropriate syntax when the references were autogenerated."
  • "Without any prompting, the majority (one less than the entirety) of our participants expressed the desire or obligation to cite their sources, provide references, or validate the information they were adding or editing on Wikipedia. That desire, however, rarely resulted in a successful citation. Subjects struggled to differentiate between a reference, an internal link, and an external link. In fact, only one subject used the "shortcut" for an internal link in lieu of using the full html address for the forwarded article.
    Whether in the course of attempting to create a reference or while accomplishing another editing task, many users hovered over each of the toolbar icons in search of a solution. If/when users found the "reference" button (at the far right!), most could not digest the syntax that was placed at their cursor and questioned where the super script, footnote number, and text belonged and would end up. In the few cases in which the subject was adding a reference to an article where these references were auto generated, the users were completely dumbfounded."
Check out the usability study linked above.   M  19:05, 16 May 2009 (UTC)
  • Based on the passages you have provided above, indeed I am incorrect about the desire to add citations. However, I do need to look into the nature of the participants, because if there was such an overwhelming desire to support additions with reliable sources, I cannot imagine why there are so many articles without a single hint of a citation whatsoever. However, I will suspend my disbelief on the point of editors' desire to add citations; if true, it is very good news indeed.
  • I contend that the underlying driver of dissatisfaction in the first quote you have drawn above is indicated by the passage "and faltered on the right way to do that, which included determining where in the article"; this is a response to anxiety of "doing it wrong". Many if not most heavily active editors delete passages and ask questions later, interpreting improper format or position as indicative of a worthless addition. The propensity for content to be thrown away despite value is something well known by the public about Wikipedia. I stand behind the notion that editors who have not overcome the baseline usability hump would benefit from being educated that there is no wrong way to add a citation.
  • The second passage again conflates the notion of "citation" and "properly formated citation". There has been a great deal of work done by people who have developed the citation tools in use now. However, there has also been the emergence of a sentiment that people who are not using the proper format are not, in fact, providing support for their additions. In point of fact, the strong focus indicated by the passage on the "reference button" is counter to the spirit of the Wiki, that additions need not be constrained by available tools, but facilitated by them. Again, I stand behind the notion that the single most valuable educational activity - at minimum in the form of prominently placed statements supporting the notion - would be to relieve editors' anxiety that their attempts to cite are "unsuccessful" because they have not using the ref-tag based syntax; "success" in adding a citation should not be measured against conformity to a copyediting standard, but rather addition of a traceable reference (in any form) in the same article that a fact/statement has been added which provides reliable support for that fact/statement. Period. It is the purview of copyeditors to cleanup the non-conforming citations. Education of the editor in proper syntax is another matter altogether.
--User:Ceyockey (talk to me) 01:14, 17 May 2009 (UTC)
As admittedly something not central to this discussion, but relevant to the thought, especially if interface updates are being considered: as a relatively new (but now regular) editor I have never yet noticed or used the edit toolbar. I have entered everything manually. I am grateful to you for having drawn my attention to it with this discussion and will try it out! But I could otherwise easily have never noticed it, and presumably, how much more true this would be for a more occasional editor. So the point I want to make is that the assistance with entering references, be it launched from a toolbar or elsewhere, could perhaps have more attention drawn to it, and this enhancement could form part of any update decided to the interface. (Playing devil's advocate, it should be said that I am a computer/html geek so entering code and suchlike comes naturally to me and I would otherwise have taken more notice of the toolbar.) I leave the thought for consideration. PL290 (talk) 19:35, 16 May 2009 (UTC)
Since the obsession for references has taken hold, editing (and reading) Wikipedia has become much less enjoyable. The extra work of finding and entering the references is one of the negative aspects, but at least that work is unavoidable and it has positive value. But there are other negative aspects of references that have no such excuse:
  1. Even the simplest reference markup (<ref>...</ref>) is too cumbersome. Please provide a cleaner markup for references, such as [<..>]. (Where would wikipedia be if all wikilinks had to be entered with <wlk>...</wlk>?)
  2. The references often have to be inserted in the middle of paragraphs, thus making the source text very difficult to read. I presume that colorizing the source in the edit window is out of the question. But perhaps the wiki parser should be convinced to ignore line breaks before a <ref> or after a </ref> ? Then editors could use indentation to visually separate the article text from the reference text, without messing up the rendered page.
  3. The visual appearance of the reference on the formatted page is too obstrusive. Why should the reference anchor show its number? That made sense in printed media, but on a clickable computer screen a single small mark for all reference anchors (e.g. a superscript "♦" or "†") should be enough.
  4. Even better, use a single anchor for any number of consecutive refrerences, so that instead of "[12][17][21]" it shows just "♦". Clicking on that mark should scroll to the reflist and highlight all those references simultanously.
  5. The standard WP format for references is "Author (year), Title. Journal, volume etc." But many external sources use different formats, like "Journal, Author: Title, year, volume etc." and many other permutations. So even when one finds a reference that can be copy-pasted, putting it in standard format requires quite a bit of editing. Now, some of that editing is easy and almost automatic: deleting extraneous text, adding some markup, fixing spacing and line breaks. But rearranging the fields, for some reason, seems to require many more brain cycles and concentration, and hence is more tiring. So, could the WP standard-makers please relax a bit, and proclaim that any reference format is OK, with the fields in any order, as long as it is clean, correct, and readable?
  6. Often the same reference is relevant to dozens of articles. To reuse a reference, the editor must (1) open a new window/tab and fetch an article that has that reference, (2) start editing the second article, (3) find the refrence text among the source text, (4) copy it into the first article, and (5) cancel the edit of the second. So, could WP provide tools for (a) searching the *references* used in WP articles, and (2) pasting into the edit window the source text of a reference from another article, without editing the latter -- that is, skipping steps (1,2,3,5) above?
  7. (Moved to section #References as separate mini-articles --Jorge Stolfi (talk) 18:01, 17 May 2009 (UTC))
  8. Converting a plain <ref>...</ref> to a {{Cite...}} template is a lot of boring and pointless work. A plan reference that fits in one line easily becomes 10 or more lines when converted. If the reference has 8 authors, one needs to split that into 16 fields and insert 16 keywords. Moreover, to get wikilinks for the authors, one must add another 8 keywords, and enter each author's name again, *twice*. So, "A. U. Thor" becomes ... | first7 = A. U. | last7 = Thor | authorlink7 = [[Augustus Usquebaugh Thor|A. U. Thor]]. The template cannot accomodate references with exceptional format, and silently drops any field which has an inappropriate or mistyped keyword. And all that work for what? The template-provided markup is often incorrect, and the information that gets displayed is exactly the same that would have been shown by a plain <ref>...</ref>. So, please drop the {{Cite...}} templates and let plain, free-form <ref>...</ref> be the standard.
All the best, --Jorge Stolfi (talk) 05:47, 17 May 2009 (UTC)
I don't think you're thinking this through properly. Your suggestions are almost all impossible, or counterproductive.
1. Angle brackets are used to delimit XHTML tags. Tags are used to enclose and give semantic meaning to content. Tags are not themselves content, but they give structure to the content around them. As such, changing the reference text from being content with semantic meaning, to being non content that's supposed to be a structural element, is wrong. What makes you think having slightly shorter delimiters is going to magically improve readability?
2. And what happens when a reference appears at the end of a paragraph? Suddenly, well, it doesn't appear at the end of the paragraph any more, because the two blocks of text have suddenly been concatenated.
3. And what happens when you print the page out? Now you've got two hundred diamonds floating on your text, and a block of references at the bottom, with no way to unify them. Silly.
4. You use Firefox, don't you? Lovely browser, I use it too. That blue highlighting doesn't work on IE, which is what the majority of our readers use. And it won't work for users using screenreaders. Or on mobile devices. And again, it's definitely not going to work when printed...
5. I disagree with the suggestion that having multiple varying reference formats, especially within a single article, is at all professional. However, I'd like to echo the comment I saw above somewhere: "any reference is better than no reference". If someone wants to add a reference upside down, back to front and written in Serbian, I'd much rather that than no reference at all. Equally, the person who then comes along and formats the reference appropriately deserves their own praise. There's no reason why the two need be separate people, of course, but equally no reason to praise the latter and lambast the former. Add references whichever way you want, humans or bots can come round formatting them at a later date.
6. This is a nice idea, and could probably be done with JavaScript. It would be confusing an unintuitive, however, to force it on all users.
7. (Item 7 of my post is now section #References as separate mini-articles --Jorge Stolfi (talk) 18:07, 17 May 2009 (UTC))
You have examples of references that are used in hundreds of separate articles? I would very much like to hear of them. Otherwise, I think this is a gross exaggeration.
8. Per my point 5, there's a world of difference between adding a reference and formatting a reference, and there's no need to necessarily do both at the same time (although it helps, of course). The cite templates ensure a consistent and professional appearance, allow easy extraction of the reference into a machine-readable form, and provides a useful semantic separation. If you find them hard to use, then leave them for others to use.
Happy‑melon 10:22, 17 May 2009 (UTC)
  • 1)Any notation ( <<...>>, ((...)), etc.) will do, as long as it is as easy to read and type as the [[...]] of wikilinks. Besides being hard to type, the <ref>...</ref> delimiters are hard to match visually. As for the distinction between "tags" and "structural elements", most users are not aware of it, and need not be. There is no reason why WP's markup language should follow W3C's (or anyone else's) markup philosophy, Besides, external links [... ] already contain both strcuture (the URL) and content (Title/description).--Jorge Stolfi (talk) 16:12, 17 May 2009 (UTC)
  • 2)Leave a blank line between the ref and the next paragraph. Or any of many other possible solutions. The important thing is to make it possible for editors to enter the ref text so that it is clearly separated from article text in the edit window. In particular, if a reference fits in one line, it should be possible to enter the whole of it, including its delimiting tags, as a single indented source line.
  • 3)That is the point. The current reference format was designed and optimized by publishers of static printed media, with the primary goal of saving expensive paper, and secondarily of helping the reader find the reference entry in a static printed list. That is why anchors show the reference numbers, and why the full refrence list is printed at the end of the article even though most readers will never look at it. That is also why reference lists are sorted by author or year (rather than title, topic, or randomly).
    WP articles should be optimized for viewing on a computer; for printed copies, there should be a "print" button that formats the article appropriately for that medium (with options to include/exclude refs, external links, see-alsos, side-float images, navboxes, etc.). --Jorge Stolfi (talk) 16:12, 17 May 2009 (UTC)
  • 5)Any printed encyclopaedia or dictionary. Technical reference books (Merck index, Abramovitz & Stegun tables). Undergraduate and graduate textbooks. Shakespeare's plays. etc. --Jorge Stolfi (talk) 16:12, 17 May 2009 (UTC)
  • 7)I couldn't say it better. But note that (1) Wikipedia is not written by professional editors, so it doesn't have to look professional -- just pleasant to read and browse; and (2) the author-first convention too dveloped to get around the limitations of paper media. --Jorge Stolfi (talk) 16:12, 17 May 2009 (UTC)
  • 8)The point is that it takes more work to convert a free-form ref to a Cite template than it would take to format the free-form ref by hand with plain wiki markup. It is wrong to waste so much volunteer work in a task that brings little (or negative) benefit --- no matter whose work it is. Besides, the Cite templates are well below current standards such as Bibtex+TeX — in input syntax, smartness/flexibility, and output quality — and it is unlikely that they will get much better, given the inadequte programming tools available to template writers. --Jorge Stolfi (talk) 16:12, 17 May 2009 (UTC)
I present a fatal accessibility issue and you say "exactly"?? Wikipedia is not optimised for any particular medium, we aim to generate content that can be freely and widely distributed in diverse media, ranging from web access, mobiles/PDAs, offline DVDs, printed media, even aural speech. Wikipedia strives to match or even exceed the quality of a professional encyclopedia, we are not trying to make something "easy to read and browse". I'm honestly not sure what you're saying in your comment 5: are you suggesting that all these publications routinely incorporate multiple reference formats within individual sections? And your point 8 is self-contradictory: you say that reference display is currently sub-optimal, yet then say we should make it harder for ourselves to improve it? Which would you rather do: make a change to one page that improves a reference on that page, or make a change to one page that improves the references on half a million pages? That's the power of citation templates. Volunteers work on whatever they want to do, what is "wrong" is to suggest that they should be forced to work in a particular way. If an editor wants to spend his time formatting references, or writing and running a bot to do the same, who are you to stop him? Happy‑melon 18:23, 17 May 2009 (UTC)
Accessibility: The information is all there and it is just a "small matter of programming" to cast it into whatever format is best for the user and medium. WP already allows users to choose the page skin, date format, whether the TOC shows or not, etc.. None of my proposals prevents delivering articles in the current style to users who like it.
Quality: WP will never (well, not on my lifetime) reach the level of *presentation* quality of a classical encyclopedia. To do so one would have to prevent editors from adding new contents, and convince them to spend another 5-6 years just copy-editing whay is there today. Then it may look professional, but its contents will uneven, incomplete, and full of subtle errors — as one cn expect, given that 95% or more of its articles were clearly written by amateurs in the respective topics. Not that this is bad, quite the oposite: WP is a completely new thing, and it calls for a completely new definition of "quality".
Point 5: Those are examples of books that are likely to be cited by hundreds of articles.
Display is sub-optimal: the Cite-templates often generate confusing or improper markup, whereas with a plain <ref> the editor may choose the markup that is best for the readers, case by case. For example, the italic/roman convention for book/article titles, and the cryptic notation "3(12):1-22" (paper legacy!) for journal articles are quaint even for scholars that are used to them; for most readers and editors, they look more like bugs than features. See also, for example, the long discussions on the Cite talk-pages about whether "|pages=256" should be formatted as "256 pages" or "page 256", or how one should enter and render multiple (re)publication years. These are examples of non-problems that became problems when Cite-templates were proclaimed to be the "official" way to include refs.
leverage: I am afraid that we are at a point where any change to a Cite template is more likely to break a million articles than to improve them.
Which would I rather do: I would allow each editor to enter the references in any sensible format, without making them feel guilty about "leaving a mess behind" for other editors to "clean up".
I have no doubts that the present reference policies and tools, including the straitjacket of the Cite-templates, are turning away many potential contributors. All the best, --Jorge Stolfi (talk) 21:02, 17 May 2009 (UTC)
I'm pretty sure that the script below addresses most of these problems by turning references into little [43] numbers.   M  21:59, 17 May 2009 (UTC)

There is already a gadget for this. Go to "my preferences" then click on the Gadgets tab, and check RefTools. Documentation for it can be found here. It's really easy to use, and will work with most of the {{cite web}} type templates.--Unionhawk Talk E-mail 20:47, 17 May 2009 (UTC)

Dereference script

User:M/monobook.js now contains a script that rips out refs, replacing [2]<ref name=abc/><ref>cba</ref> with [2][1][3]. Puts refs back when the buttons are clicked. I described this above, where I made the word 'script' bold. Right now it just 'hides' the refs, which is working great for heavily-cited articles. The ref data is all there, though, and the other features described are pretty easy to implement - when that's done, editors would not need to deal with ref syntax. They'd be able to insert[354] random numbers to add refs, and modify any such ref using a form. To try out the hiding part, copy jquery from google (or me, but it's minified/obfuscated) and the dereference section in my User:M/monobook.js into your monobook.js.   M  08:33, 17 May 2009 (UTC)

For the sake of discussion, I propose that this be turned on by default, or added as a gadget.   M  21:59, 17 May 2009 (UTC)

Alternative proposal

See User:Magnus Manske/less edit clutter.js – this is an interface change, via javascript, that puts references (and magic words and templates) in separate edit boxes, so that (basically) only text is in the main edit box. (screenshot, mailing list discusion) -- John Broughton (♫♫) 22:06, 18 May 2009 (UTC)

Clamouring for attention

I came late to the "History tab at the top" party so fear new comments may not be noticed by those who've spent time there and moved on to other things. Those who opposed may well be interested in a point I've raised there. I apologise if starting this new section merely to draw attention back there is felt to constitute an ill-mannered or otherwise misguided action by this comparative newbie. PL290 (talk) 11:03, 17 May 2009 (UTC)

Watchlist header

I would like for every registered user to be able to create a .js subpage that is transcluded as a header for their watchlist. Not actual JS, mind you, just not editable by everyone. I think most people visit their watchlists more than any other page. Wouldn't it be a great place for your to-do list? Or links to other projects that you cannot add to your EN watchlist? The above conversation about watchlists in other projects is a good example. A list of your different watchlists for ease of access, or a checklist of completed tasks, or whatever. Does anyone else think this would be useful for users (if not themselves)? ▫ JohnnyMrNinja 17:39, 17 May 2009 (UTC)

Better just to add a "to do" link to the standard six on the upper right, or a "notes" tab to the standard four tabs at the top of the page, to open a subpage.
There are a lot of editors who don't view their watchlist reports frequently, and in any case wouldn't want a large amount of text to be transcluded at the top of their watchlist report, but would like easy access to a standard subpage.
Of course, you can just put link(s) to subpage(s) at the top of your user page; then such pages are always just two clicks away. -- John Broughton (♫♫) 13:38, 18 May 2009 (UTC)

References as separate mini-articles

(Moved from item #Easy references above. --Jorge Stolfi (talk) 18:03, 17 May 2009 (UTC))
The same reference text is often duplicated in dozens or hundreds of articles. Any copy-editing that has to be done in that text must be repeated that many times. So, what about entering the text of each reference only once, as a separate mini-article ? That could be either a special category of WP articles, like the disamb pages, or perhaps entries in a separate repository ("wikirefs"?). Then the main articles would just wikilink to those mini-articles, instead of copying them. (I suppose one could use templates for that. But the average WP editor does not know how to write templates, and they were not designed for this kind of use, right?) --Jorge Stolfi (talk) 05:47, 17 May 2009 (UTC)

Elaborating further:

  1. Location and naming: Each reference is entered as a separate Wikipedia article (a ref-page), in the main namespace.
  2. The ref-page is named "Reference @{677735}" where 677735 is a Wikipedia-assigned number.
  3. Format: Ref-pages will have a few specific style conventions, but otherwise they are ordinary articles, with same markup language, editing tools, etc.
  4. The lead section of a ref-page is the full text of the reference, as it would appear in a printed journal which did not mind printing costs, e.g.
    Alexander Undecimus Thor and N. O'Body (pseudonym of Carl O'Awther), DNA comparison of leprechauns and rhinogradentia. Journal of Missing References, vol.2 no 12, December 1996, pages 22-230.
  5. The ref-page may optionally include somewhere an invisible template {{Short-ref|A.U.Thor +|DNA comp. leprechauns...|J.Miss.Ref.|1996}},that specifies the text to be used when displaying the ref in cramped contexts (see below).
  6. Ref-pages can be redirects to other ref-pages, so duplicate entries can be easily merged and eliminated.
  7. Ref-pages can have categories, what-links-here, history, talk pages, see-alsos, links to other-language versions, etc. etc.
  8. In particular, ref-pages can cite other ref-pages, list external URLs, include abstracts, reviews, book covers and sample illustrations, etc..
  9. All pertinent WP policies and protocols apply to ref-pages too.
  10. Markup for citing a reference: To cite a reference that already has a ref-page, authors just have to insert @{677735} (a ref-link) in the article's source. See tools below.
  11. The citation may include arbitrary modifiers, e.g. @{677735|p.235}, @{677735|Ch.I–III}, etc.
  12. Or, the editor may use a normal wiklink to the ref-page, e.g. "An [[Reference @{677735}|authoritative source]] claims that leprechauns are related to..."
  13. Rendering of ref-links Any number of consecutive ref-links is displayed as a single ref-button, say "♦".
  14. Hovering the cursor over the ref-button brings up a pop-up with the (abbreviated) lead parags of the corresponding ref-pages, one per line, with the respective modifiers.
  15. If there is only one reference, clicking on the ref-button behaves just like clicking on a wikilink. Otherwise the same popup above opens, with each line behaving like a wikilink.
  16. There is also a single button somewhere that will produce a "self-contained" view of the current article, formatted according to the current convention --- with numbered ref-buttons "[21]" and the (full) lead parags of all cited ref-pages listed at the end of the article, in an automatically provided "References" section.
  17. Obtaining the id-number of a ref-page: Several tools may be provided to help the editor:
  18. The editor uses the WP search facility with an option to list only ref-pages. She then copy-paste pastes the @{677735} part of the ref-page's title into the edit buffer.
  19. Or, the editor opens another article that she knows that uses the reference. She clicks on the ref-button "♦" to jump to its ref-page. She then copy-pastes the @{677735} from the title, as above.
  20. Or, the editor right-clicks on the ref-button "♦" to bring up the popup with all its ref-page headlines. Then she right-clicks on the correct one to copy its ref-link into the clipboard. Then she pastes the clipboard it into the edit buffer.
  21. Creating a new ref-page. Above the edit buffer there could be a button labelled "New Ref". Clicking on it opens another article-edit window (or a second edit buffer below the current one) where the editor can enter the refrence as the new article's lead paragraph. When the ref-page is saved, its title is automatically set to "Reference @{677735}" where 677735 is a new WP-assigned id number. The editor then copy-pastes the ref-link @{677735} into the referencing article.
  22. The first time a new ref-page is saved, WP will use some heuristics to find similar-looking entries. If one or more possible duplicates are found, the editor is notified and asked to either confirm the creation, or cancel and use one of the pre-existing ref-page.
  23. Robots and edit tools can be provided to upload single refs or whole bibliographies, converting from external formats (Bibtex, Google scholar, etc.) to WP ref-page format.
  24. A robot or robot-assisted editor will eventually go through all current articles and rip out all the <ref>...</ref>, {{Cite ... }}, "==References==", "==Publications==", etc., replacing them by ref-links to ref-pages.

Does this make sense? All the best, --Jorge Stolfi (talk) 19:32, 17 May 2009 (UTC)

And this is intended to simplify reference creation? Happy‑melon 19:42, 17 May 2009 (UTC)
I believe so. The description looks complicated but that is mostly in the implementation. What the users --- and especially editors --- will see will be simpler, IMHO, than what they see now. Much more so for editors that maintain dozens of articles on relaetd topics.
Just try writing a similarly detailed description for the current model. All the best, --Jorge Stolfi (talk) 20:04, 17 May 2009 (UTC)
In fairness this only appears overwhelming because Jorge Stolfi has provided an extremely detailed and enthusiastic specification, including all kinds of interesting ideas about how it could be implemented and benefits that might accrue. Point 21 appears to stand on its own as an illustration that using such an approach, reference creation could be quite a simple action. I think the suggestion has merit in centralising references in what would perhaps effectively be a repository where they could be kept in good shape in a uniform way and not duplicated around the place as is presently necessary. PL290 (talk) 20:10, 17 May 2009 (UTC)
Isn't this what ref names are for? They do the same thing, but are far simpler. Dendodge T\C 20:17, 17 May 2009 (UTC)
I assumed ref names would only work within one article though. Am I mistaken? If so I must start using that technique. But the repository effect still seems to have benefits in any case. PL290 (talk) 20:25, 17 May 2009 (UTC)
Oh, I didn't know the OP was intending to use this across multiple articles. Anyway, I don't like the idea—the current system works just fine. If it ain't broke, don't fix it. Dendodge T\C 20:32, 17 May 2009 (UTC)
Hear, hear. Oppose proposal. ╟─TreasuryTag►contribs─╢ 20:33, 17 May 2009 (UTC)
Named refs only work within an article. Having used Bibtex (a 25-year-old piece of software, still the best thing aroud), I see the WP system of copying each reference whole into each article seems rather, well, prehistoric. (1) If a book is cited by 10 articles, making it into a ref-page will multiply by 10 any edits made to it. (2) turning a reference entry into a ref-page allows entering abstracts, reviews, and ref-to-ref links, *once*, no matter how many articles cite it. (3) each ref-page is fetched only if the reader wants to see it, which is almost never the case. This means signficant savings in server bandwidth, download time, browser cpu time and memory, and screen estate. (4) When a user opens an article for editing, he sees only the article text and the ref-links. The source is much easier to read and edit. (5) Conversely, users who look up a reference and feel like editing it will see only the source of the ref-page, not a ref entry embedded in a much larger article source. And so on. --Jorge Stolfi (talk) 21:58, 17 May 2009 (UTC)
(edit conflict) I think I have to agree with Happy-melon. (1) This whole "mini-articles in mainspace" idea is asinine; what about the template namespace, or a new namespace just for references? People have even made and used such templates before, that's nothing new. (2) Using opaque ID numbers instead of names is actively user-hostile. (3) A new syntax for transcluding references is superfluous, what's wrong with the existing transclusion syntax? (4) Adding all sorts of fancy javascript (which won't work for everyone), random buttons, and right-clicks in order to see anything besides a completely uninformative "♦" is foolish and inaccessible. (5) Better ideas about using symbols and combining adjacent references are in T18294. Anomie⚔ 20:36, 17 May 2009 (UTC)
The presentation details are secondary and surely there are better ideas. Accesibility is better served by letting users choose how they want the ref-links to be displayed, than by forcing everybody to use a lowest common denominator.
Putting ref-pages in the main namespace is better because (1) users will not need to learn a different set of conventions, styles, syntax, etc. (2) It discourages potentially disruptive programming hacks that are possible with templates, (3) it allows ref-pages to use all the tools and conventions of ordinary articles, (4) logically they are much more like ordinary articles ("data") than templates ("editing tools"), (5) they won't get downloaded and expanded when the article is fetched, as templates are.
As for using reference numbers, anyone who has collected a database of more than a few hundred articles knows that there is no "natural" way to refer to an entry. Nevertheless, that does not mean that in-article references are better than a large unified bibref database; quite the opposite, the latter gets more convenient as it gets bigger, since it is more likely that the reference one needs is there already. Mnemonic hints may help a bit (such as using authorInitials-year-firstWordOfTitle-serialNumber instead of just a serial number), but eventually the hassle of generating those tags (such as dealing wil variant name spellings) more than offsets their little benefits. If you look at scholarly databases used by millions of people -- the CAS registry, Genbank, Citeseer, IMDB, and even the venerable Roget's Thesaurus, you will see that opaque numerical IDs are actually more convenient to use than any mnemonic names or tags. The same problem would arise if all refs were turned into templates, and the same solution --- opaque, WP-chosen IDS --- would have to be used to refer to them.
All the best, --Jorge Stolfi (talk) 21:58, 17 May 2009 (UTC)
And on the downside of your "mini articles", they'll come up in Special:Random and they'll be included in our "count of articles" unless weirdness is done like MediaWiki:Disambiguationspage. Also, all of your points are incorrect: 1 is simply absolutely wrong as there will most certainly be special styles and syntax required (unless your proposal has drifted far from where it began), 2 is wrong because the only thing "special" about template space is that it's the default for {{}} transclusion syntax, 3 is wrong because there is nothing special about the main namespace that makes any "tools" or "conventions" not applicable to other namespaces, 4 simply makes no sense, and I fail to see how point 5 would work without them being "expanded" in some manner or other (again, unless your proposal has drifted far from where it began). This seems like stuff that anyone that has made many edits to Wikipedia should be familiar with. Anomie⚔ 01:36, 18 May 2009 (UTC)
Surely the random-page and article count are minor issues compared to the work involved in maintaining other WP bell and whistles.
For point 1, I don't see what "special syntax" a ref-page would need, besides the optional {{Short-ref}} template. By the way, for most books one could let the ref-page be just a redirect to a normal WP article on the book, e.g. the ref-page [[Reference @{67753}]] be a redirect to the book article Un Coup de Dés Jamais N'Abolira Le Hasard (Mallarmé). The redirect would be used for inline citations @{67753} while wikilinks to the book could use its full title, as now. So actual (non-redirect) ref-pages would be mostly for journal/newspaper/magazine articles, specific TV/radio shows, and for otherwise non-notable books and reports that do not deserve a named article (e.g. the 1967 Sears Catalog, or the 1996 Report to Stockholders of the Pastafazulla Company). But being in the same namespace would make promotion between the two categories easy, in case anyone cares.
For point 2, indeed I have mostly a fuzzy outsiders's view of what template-space and article-space means (Can you move a page from template-space to article-space, or vice-versa?). But that is not the point. It seems that I failed to get through an important feature/motivation of the proposal: the bibliography entries need not be and should not be pasted, included, or transcluded into the articles that cite them. They should be downloaded only if and when the reader clicks on the corresponding ref-button (whether it is displayed as ♦ or [23]); or if and when he asks to see all references of the article; or if he has opted to always get articles in the traditional format by default (with "References" section at bottom).
The assumption that the bibliography listing should be appended to the article is just another legacy of the printed paper era. Wikipedia has already broken many such legacies, such as the linear ordering of material, the concept of "definitive publication", "authorship", "edition", etc. We should question the concept of the "References" section as well. All the best, --Jorge Stolfi (talk) 04:12, 18 May 2009 (UTC)
I don't know about normalizing refs, this sounds unnecessary. I do think, though, that certain facts should be kept apart from presentation. Looking at a random page, Golden_ale_(UK), and assuming that the entire lead is somewhat controversial, we would have the following in talk, each followed by citations and links to previous talk-page discussions:
Golden ale
is a style of beer
was developed in the late 20th century by breweries
to compete with the large light lager market.
typically appears similar to a Pilsener.
Malt character is subdued [...]
This isn't the same idea as above, and it's partially implemented by faqs on some pages. The purpose is to have a solid reference for facts that might get blurred by frequent 'style' edits.   M  21:00, 17 May 2009 (UTC)
I don't see the point to this. I agree with most of what Anomie said. This seems at least as complicated as the current system with the extra drawbacks of: 1) its not at all backward compatible with the current system, 2) Any user who is familiar with the current system will be entirely back to square one. I think if we're going to refurbish the reference system, there are far better ways to do it. Mr.Z-man 23:33, 17 May 2009 (UTC)
"far better ways to do it" - such as? Rd232 talk 17:24, 18 May 2009 (UTC)

You may want to review {{Source_list}} and its subpages. Ruslik (talk) 09:45, 18 May 2009 (UTC)

That looks very useful to me, but is there a way to define a source in isolation from page numbers, or use parameters for the page numbers? Otherwise it would seem multiple sources, differing only by page numbers, must be defined for the same published work. PL290 (talk) 10:17, 18 May 2009 (UTC)
For a book used multiple times in a Wikipedia article, where information comes from different pages, you can still use a single footnote if you add the {{rp}} template wherever that source is cited in the article. [Page numbers aren't normally needed for newspaper, magazine, and journal articles.] -- John Broughton (♫♫) 20:52, 18 May 2009 (UTC)

Proposed new global policy: m:Biographies of living people

There is a proposal for a new global policy regarding biographies of living people. Comments, suggestions, and other input are welcome at m:Talk:Biographies of living people. Cheers. --MZMcBride (talk) 02:55, 19 May 2009 (UTC)

search for meta-stuff

I would like to see an easy way to search for things concerning the working of Wikipedia. For example, a lot of editors throw around abbreviations (e.g., CPOV) with-out explaining them. While it would be ideal if they were explained or linked, that simply is not going to be the case on a regular basis.So, why can't there be an EASY TO FIND way of looking up stuff about using Wikipedia, such as a search window. I find myself too often going back to places like my own talk page where some-one once answered my desparate question, and I search there to find the link given. This is a ridiculously slow way to do things -- and it only works with subjects I've already had problems with. Kdammers (talk) 11:35, 17 May 2009 (UTC)

For acronyms there's WP:Alphabet soup and WP:Glossary, which includes other jargon, or you can just type them into the address bar; if you use the main search box you can tick off article space and tick Wikipedia space, which should find most stuff. That's not necessarily a criticism of the proposal, just a reminder of what does exist already. - Jarry1250 (t, c) 14:39, 17 May 2009 (UTC)
There also is the Editor's index to Wikipedia; finding the relevant topic can answer a lot of questions (though the two links above are definitely better for abbreviations/acronyms than the index, which isn't designed for that purpose). (See WP:EIW#Terms, in this case.) -- John Broughton (♫♫) 00:39, 18 May 2009 (UTC)
WW: Alphabet soup is hidden - i.e., if you don't know about it or know about it but can't remember the strange name, it is hard to find. I have no idea what an address bar is. The only place I, or a normal user or editor, can see to type in as the search box, which in my experience does nto bring up meta stuff. While people at a certain level of awareness might know of WP:EIW, I've never seen it despite searching for some-thing like this. If people don't see it, it doesn't do much good.Kdammers (talk) 11:46, 19 May 2009 (UTC)

Audiopedia

Create a software that would generate a understandable audio version of the articles. Additionally, those spoken articles could be organized in automatic playlists, the possibility of learning for adults would be frankly incalculable. Peaople don't have time to read. There is also the help it would provide to visually handicapped people.

It would be similar to attending a university while working or driving, and instead of listening to music or a novel in cd format, we could listen a topic and learn.

This is my dream. Hope someone from Wikipedia takes this suggestion and think about it. Millions would benefit. ~darynthe (email redacted)

TTS (Text to Speech) engines already excist, and i know WikiProject Spoken Wikipedia actively records spoken versions of Wikipedia pages (User spoken though). That being said text to speech engines often sound quite... unnatural when they synthesize speech. Often some words will be barely understandable at all and the pitch and tone have been said to be an irritation for some users as they are flat without emotion.
Another issue would be more technical. Pre-generated spoken versions for all 2.8 million articles would not only take quite some space (that issue can be overcome) but would at the same time be old versions of the wikipedia pages since pages are constantly edited. Generating these recordings on a "on demand" basis would take a lot of CPU and time, which could cause annoyance with users.
Don't get me wrong, its a very good idea, but if we are to implement that, some serious thought would have to be put into it. :) Excirial (Contact me,Contribs) 14:47, 19 May 2009 (UTC)

Contest proposal

A proposal has been posted for a contest between all 200 country WikiProjects. We need to know how this contest should be run, and what problems to look out for.

The Transhumanist 17:21, 20 May 2009 (UTC)

Over at Template talk:WikiProjectBannerShell there's a proposal to make a mass-conversion from {{WikiProjectBanners}} (which is collapsed by default to {{WikiProjectBannerShell}}, which is uncollapsed by default, for WPB templates that only have a small number of banners inside. Please come and discuss!!. Happy‑melon 18:19, 22 May 2009 (UTC)

Autoprotected user space pages

During the process of rewriting the way editnotices work, it was suggested that user editnotices should only be editable by the user himself (and admins), similar to what already happens with .js and .css pages. With the AbuseFilter, this could now be done quite easily.
However, seeing that the autoprotected .js and .css pages are already often abused to store other content (huggle.css, a subsituted signature, ...), and that those pages display wikicode differently than normal pages, it might make sense to allow additional user subpages that can only be edited by the user himself (and admins).
I have two questions:

  1. Do we want anything of the kind in the first place? Should any pages in addition to .js and .css be protected in such a way?
  2. If so, what would be a good way to distinguish such pages? E.g., any user space subpage of User:Example/protected/, or any user space subpage starting with ".", or any user space subpage ending with " (protected)" or ".protected". User talk subpages would never be protected that way.
    Or should it stick to editnotices?

Personally, I would support such autoprotected pages. There is a use for them already with huggle.css and the like, and while I don't see huge amounts of editnotice vandalism, vandalism to editnotices can be far more disruptive since

  • they are unwatched, possibly not even by the creator if the vandal creates it
  • it is only noticeable when editing, and the talk page owner might not edit his own talk page if he prefers to reply on his correspondents talk page, so subtle vandalism can go undetected for a while
  • due to MediaWiki oddities I'm not going to explain here (WP:BEANS) vandalism on editnotices can disrupt the MediaWiki interface (there's a reason that they were originally only allowed in MediaWiki namespace)

Opinions? Amalthea 13:40, 20 May 2009 (UTC)

String support for this proposal. I think that the user and user talk editnotice pages (in their present locations!) should have this protection, as should pages like "User:Example/protected/*". The "." notation would make sense to Unix people, but not to people who are familiar with Windows. עוד מישהו Od Mishehu 07:08, 21 May 2009 (UTC)
What kind of string?? :D Happy‑melon 15:23, 21 May 2009 (UTC)
Strong support: irrespective of editnotices (which I confess I'm not yet familiar with), if the editnotice rewrite can bring about the ability for users to maintain any vandal-proof content in User:Example/protected/ or suchlike, then that is a very useful achievement. PL290 (talk) 08:16, 21 May 2009 (UTC)
Support, preferably the User:Foo/protected/* notation. Happy‑melon 15:23, 21 May 2009 (UTC)
Strong support (with string cheese) Following the work that lead to this, it seems sensible. WE need to get a lock on this before the system proliferates. ---— Gadget850 (Ed) talk 22:48, 21 May 2009 (UTC)
Oppose. This is a wiki. Contrary to popular belief, pages in ones userspace do not belong to the user. This is a community and such pages should only be protected as needed (such as after several periods of vandalism), and most of them don't need it. - Rjd0060 (talk) 01:02, 22 May 2009 (UTC)
Very bad idea. There's a reason this feature hasn't been integrated into the software. We're a wiki. Misusing the Abuse Filter like this isn't appropriate. --MZMcBride (talk) 01:06, 22 May 2009 (UTC)
Just out of curiosity, what is that reason? Anomie⚔ 14:39, 22 May 2009 (UTC)
A wiki allows anyone to edit (nearly) anything, including userspace, and we are a wiki.   M  15:21, 22 May 2009 (UTC)
But we don't allow anyone to edit anything in the MediaWiki namespace, or any page in userspace ending with ".js" or ".css", or the Main page, or "high-risk" templates, and so on. What all those have in common is that screwing with them will cause major issues; this proposal is intended to do the same for user things that are not js or css. Which, IMO, means you have missed the point. Anomie⚔ 20:01, 22 May 2009 (UTC)
CSS/JS pages are protected due to security reasons. What is the use case for normal pages to be automatically protected? Mr.Z-man 02:21, 22 May 2009 (UTC)
Change policy: There doesn't appear to be any good reason why specific pages in user space shouldn't be protected for a user. The guideline mentions, almost incidentally, that "pages in user space still do belong to the community", giving examples of bot access, GFDL etc., but it states that "by convention your user page will usually not be edited by others". This is indeed a wiki, but user pages are already treated as a special case: the talk page has a different relationship, and you do have more latitude in user space than elsewhere. Change guideline/policy to allow some protected pages in user space. PL290 (talk) 05:53, 22 May 2009 (UTC)
  • Changes to policy generally need some sort of reason. What's the use for this? Mr.Z-man 06:27, 22 May 2009 (UTC)
    • The possibility of vandalism is the flipside/downside of freedom of edit by all. In the case of (some) user space, there is no point in allowing freedom of edit by all. By some, perhaps, yes (such as admins), but not by all. So the use for this change is to remove the possibility of vandalism where freedom of edit by all is irrelevant. PL290 (talk) 08:16, 22 May 2009 (UTC)
    • Config files for software, Twinkle, Huggle, etc. Editnotice loaders where vandalism is less noticeable and potentially more damaging. Pages like this. There are a wide variety of reasons why having a secure directory would be a big improvement. You're right, MZ, that this will never be implemented in core software, but that doesn't translate to it automatically being a bad idea, or that using other means to make it happen is "misuse". Happy‑melon 09:15, 22 May 2009 (UTC)
    • Yes, what Happy Melon said. Such configuration files should be on wiki, and they should be protected from editing by others. For example, Huggle's configuration file contains edit summaries which will be automatically applied, and which are hard to take back if used in a vandalized state. And I believe I've described above why I think user editnotices should be protected as well. Amalthea 09:55, 22 May 2009 (UTC)
      • Why should they be on wiki? As far as I know, the only reason huggle's config is on wiki is so that admins can disable it in the case of misuse. Twinkle's config should be in a normal JS page, because it is JS. Just because you say they will be great for X, Y, and Z, doesn't mean other users aren't going to use them for A, B, C, D, and E. Now you've got pages people can use for spam and vandalism that can't be tagged for deletion by normal users, userspace POV forks that only the user can edit, and a new way to make violating WP:NOT#WEBHOST even easier. Mr.Z-man 15:27, 22 May 2009 (UTC)
        • Depending on the application: For Huggle to allow disabling it here, for the off-site statistic tool Melon mentioned to allow an easy opt-in signal. Twinkle's config can remain in .js, yes, but another tool I'm currently working on has a lot more meta content (edit summaries and user notifications) that would benefit from wiki formatting and will be placed outside .js space.
          As mentioned below and above, talk pages would still remain unprotected, so they can still be used for any tagging. And if it is a concern that those pages will be abused for content creation, or used for anything except meta content, it would be easy to remind editors with an editnotice showing on all those pages. Amalthea 17:00, 22 May 2009 (UTC)
          • Yes, I'm sure vandals and spammers will be deterred by an editnotice telling them to stop. This would also allow users to "hijack" existing pages by moving them into a protected subpage of their userspace where only an admin could move it back. I'm sure with some more time, I could come up with some really WP:BEANSy ways to abuse this. Mr.Z-man 19:16, 22 May 2009 (UTC)
            • Vandals and spammers abusing them can be dealt with as they are dealt with now, with the only difference that the talk page needs to be tagged instead of the subject page. Editnotices would help with more subtle, good-faithed abuse of such pages. And vandals can already hijack pages by moving them into the .js/.css area of their user space. No change there either. Amalthea 19:37, 22 May 2009 (UTC)
    • Another example: User:Erwin/AfDNote, and other templates placed by bots without human intervention. Those snippets should be on-wiki so that they are changeable without needing to bug the bot owner, they often need to be protected, and the bot owner should usually still be able to change them himself. Amalthea 11:08, 23 May 2009 (UTC)
  • Note that a change in policy would be insufficient for the purposes discussed above, as those purposes require the corresponding user subpages be preemptively protected rather than just be protected on request. Anomie⚔ 14:42, 22 May 2009 (UTC)
  • Comment. I do not think there is any need to create protected page in the user namespace. (css/js pages are a special case.) On the other hand, semi-protection may be desirable in some cases such as edit-notices. Ruslik (talk) 13:47, 22 May 2009 (UTC)
    • Semi-protection would be useless for the purposes discussed above, including the edit notices. It's trivial for a vandal to create an account, make a few innocuous edits, and wait a few days to get autoconfirmed if they already know enough to vandalize these user edit notice pages. Anomie⚔ 14:35, 22 May 2009 (UTC)
  • Oppose, there's no argument that I can see for this to be made a general feature. Support protecting the editnotice. Should userspace (as defined by the user) be protected? No, because this prevents editors from putting deletion notices on attack pages and other junk. If you want a protected page, create a .txt file. Unless better reasons can be provided...   M  15:21, 22 May 2009 (UTC)
    The proposal is to protect a particular branch of userspace - I support a particular subdirectory - in the User: namespace only. notices such as CSD templates can be put on the talk page, as is already done for normally-protected pages. I don't think (certainly hope you're not) you're serious about the "create a .txt file", as this is obviously not a solution to the usecases posed. Huggle config is not a cascading style sheet. Why are we required to hack the interface to such an extent in order to give it the required level of protection? Happy‑melon 15:30, 22 May 2009 (UTC)
    Or if tagging the talk page isn't good enough, there's also WP:ANI, WP:AIV, and so on. It's not like tagging the page is anywhere near the only way to do anything. Anomie⚔ 20:01, 22 May 2009 (UTC)
  • I'd be more comfortable having a list of protected pages (e.g. an editnotice page, a Huggle page, a Twinkle page, whatever) rather than creating a generic protected directory. I'm not sure how many cases people have in mind, but it doesn't seem like it ought to be a long list. This way there would also be a clear understanding that using those protected pages for other purposes (like content) is not okay. Also, I would support using Robots.txt to noindex all such pages. Dragons flight (talk) 16:19, 22 May 2009 (UTC)
    • To get robots.txt to noindex them would I believe require that they all share one prefix, which means they couldn't technically live in user space anymore, but would have to go to e.g. WP:Protected user content/Amalthea/Huggle. Not particularly pretty, and I don't think there's much harm in indexing them anyway? Spam there would get deleted just as quickly or slowly as it will at any other user page.
      I don't know how long an exhaustive list of such pages would be. Certainly manageable, but open ended. If it is done that way I'd suggest to place them in a clearly marked subpage tree anyway, e.g. at /protected/Huggle.
      I do think however that, with a proper guideline, editors can be convinced to only use these pages for meta content. To make sure, an editnotice as a reminder could easily be created to show on those pages. Amalthea 16:44, 22 May 2009 (UTC)
      • You're right about Robots.txt (I sometimes forget how limiting its syntax is.) Dragons flight (talk) 17:18, 22 May 2009 (UTC)
        • Incidentally, Google and Yahoo both support an expanded Robots.txt syntax that allows expressions like "/wiki/User:*/Huggle" to be blocked where the "*" is any string of characters. So one could block the big boys if one really wanted to, but it is probably not a big enough concern to get hung up on. The main point here is that I feel it is better to have pre-discussed list of things deserving pre-emptive protection rather than an open directory where anything goes. Dragons flight (talk) 17:26, 22 May 2009 (UTC)
    • I agree with Dragons flights. A protected directory is a bad idea. The limited uses of this make it possible to utilize the Title blacklist (yes, another hack) for things like Editnotices if you really want them semi-protected. The issue is that if a protected directory is created, it will be used for things beside configuration pages. Which is unacceptable. --MZMcBride (talk) 16:47, 22 May 2009 (UTC)
      • The titleblacklist will only work with semi-protection, as you say, which is not enough for script configuration pages, and I believe is also not enough for edit notices. Personally, I'd prefer disabling editnotices loaded from user space to leaving them unprotected. Amalthea 17:16, 22 May 2009 (UTC)
        • Uh, I never understand why there is so much paranoia surrounding editnotices. They can get vandalized. Who cares? So can nearly any article, user page, user talk page, policy page, etc. If you had a {{notice}} at the top of your user talk page, it could get vandalized too. People seem to have this crazy idea that because it goes above the edit form it's somehow sacrosanct. I don't get it. --MZMcBride (talk) 17:20, 22 May 2009 (UTC)
          • I've said so above: vandalism through them can be sneakier and less noticeable, and they can wreak havok with the interface to a point where a page cannot be edited anymore until the change is reverted. Since the devs show no inclination to fix this, it needs to be prevented here. Amalthea 17:24, 22 May 2009 (UTC)
            • Vandalism that disrupts normally editing can just as easily be done to articles using CSS hackery. The unclosed tags thing, well, meh. There seems to be all this talk of possible misuse, but I don't see any actual evidence. Is there a editnotice-vandalizing brigade? --MZMcBride (talk) 17:28, 22 May 2009 (UTC)
              • Except that you can add "action=edit" to the URL manually to get a clean edit form. Can't really do that when it's an editnotice causing the problem. Anomie⚔ 20:01, 22 May 2009 (UTC)
    • I think Dragons Flight has the right idea. I also would love to see Robots.txt used, I have seen far too much use of userspace to host fringe/deleted/promotional articles and it is never easy to get them deleted. I've seen such articles show up on the front page of Google searches. I wouldn't expect the casual reader to realise that they weren't ordinary Wikipedia articles. Dougweller (talk) 17:07, 22 May 2009 (UTC)
      • If you want to prevent that then you will need to get the whole user space noindexed again. The pages this proposal is about has little to no impact on that – you say it yourself, you find them at google already. Amalthea 17:16, 22 May 2009 (UTC)
  • Comment A number of people above have raised the concern that users could use this for article forks, attack pages, and so on. If that's really that much of a concern, just make it a part of the policy that things in there may be deleted by any admin without warning if it wouldn't pass WP:RFPP, and in the "ou can't edit this" message shown to non-admins who are trying to edit it point them to some appropriate place (e.g. WP:ANI).
    Someone also complained about the possibility of a vandal moving an article into their protected space, forgetting that AbuseFilter can easily deny any move into or out of the protected space if necessary. Anomie⚔ 20:01, 22 May 2009 (UTC)
  • Oppose Opens more cans then it closes. Makes user pages a bit too owny imo. Q T C 22:06, 23 May 2009 (UTC)
  • Support if this is only to protect editnotices. A /protected/ or *protected idea would lead to abuse of protection. MC10 | Sign here! 02:31, 24 May 2009 (UTC)

Unwatch from watchlist

Background: whenever a watched page that hasn't been edited recently pops up in my watchlist, that may well be my signal to remove it from the list. For example, I have the "Add pages I edit to my watchlist" preference enabled because when I edit an article I come across, though that article is not one I currently intend to spend further time on, I'm always interested in any initial reaction to my edits. When the article pops up at a later time, it would be an improvement if I could remove it then and there with one click, rather than having to view the article and click "unwatch" there.

Propose: Add a further link to watchlist entries, so that after the article name, the existing links (diff; hist) become (unwatch; diff; hist) PL290 (talk) 08:36, 21 May 2009 (UTC)

Oppose > it's already too cluttered in there. However, if you turn on popups (like me!) there's an unwatch-link that appears when you hover your mouse over any link to any page, from any page, and loads of other useful stuff besides. ╟─TreasuryTag►contribs─╢ 08:39, 21 May 2009 (UTC)
I have use a script (not mine) that adds a link at the beginning; see my monobook.js for that (it's the free code section near the bottom; I customised the original version, which I'm sure you can find somewhere, by reducing it from "unwatch" to "-". - Jarry1250 (t, c) 08:53, 21 May 2009 (UTC)
Comment: If you go to the top of your watchlist, you'll see "View and edit watchlist" and "Edit raw watchlist", which may not be so quick as a single click, but can be done without having to open the article (template, talk page, etc.) itself in order to click the "Unwatch" tab. I hang onto the discontinued Netscape Navigator 9 browser (available from http://www.oldversion.com) specifically for Wikipedia editing, since I can put my Watchlist in the "mini-browser" sidebar and use it to open each watched page (or diff) in whatever order seems best. —— Shakescene (talk) 09:10, 21 May 2009 (UTC)
Firefox 3 editors can bookmark their watchlist, then right click the bookmark and check "Load this bookmark in the sidebar", which I think creates a similar effect. - Jarry1250 (t, c) 09:14, 21 May 2009 (UTC)
No no no no NO -- It's already too easy to hit the rollback, but at least others can take care of fixing it if you miss it. Adding unwatch in there...no. If you only need to unwatch a specific article, just click it, is it so hard? If you need to unwatch a bunch, you can use either of the two edit functions on top. ♫ Melodia Chaconne ♫ (talk) 11:20, 21 May 2009 (UTC)
Incidentally, after a couple of accidental rollbacks using my dodgy laptop touchpad I hid the rollback button on my watchlist. I think it's worth it. - Jarry1250 (t, c) 12:07, 21 May 2009 (UTC)
Sugestion: Have you tried using User:Js/watchlist.js in your monobook.js? It adds a link on the watchlist to toggle unwatch links (as an "x"). Ost (talk)
You can also get there via Popups. OrangeDog (talk • edits) 21:34, 21 May 2009 (UTC)
To get this to work, do I have do anything other than add importScript('User:Js/watchlist.js'); to my monobook.js? Tried it with both that line and a full copy-paste of the code, but neither altered my watchlist (yes, I bypassed the cache). Steve T • C 07:57, 22 May 2009 (UTC)

Thanks for the tips; I can see I'm going to have fun now I know about monobook.js.

Steve, watchlist.js works fine for me whether I use copy/paste or importScript. It's not obvious it's there though, till you click the single 'x' that appears first of all (see bold text in my "screenshot" below). Once you click the 'x', more 'x's appear, one by each watchlist entry. Slight pity you have to click the first 'x' every time the page is loaded; maybe I'll look into tweaking the .js to do it on load etc. now I know about monobook.js. I like the watchlist.js way better than the Popups way which takes you to another page instead of remaining on the watchlist. But I can see there's plenty of other good stuff in Popups (et al) which I'll now start to play with.

Watchlist options
You have 78 pages on your watchlist (excluding talk pages).
Below are the last 28 changes, as of 17:08, 23 May 2009.
Show last 1 | 2 | 6 | 12 hours 1 | 3 | 7 days all | Only new | x | <- click this 'x' to make the others appear

As a parting thought, there's always plenty more to learn about WP... so with new editors in mind, perhaps my original proposal still applies. One thing that's becoming clear to me from discussions here is that advanced editors can tweak the hell out of the UI, and I confess I'm not terribly convinced yet by the reasons for opposing. Too cluttered? one 'x' character (which could even be optional). Accidentally clicking? Why single out unwatch as so terrible a new risk? It doesn't damage anyone's edits, and with the watchlist.js approach, the line even remains right there, struck out, so you can just watch it again straight away. All the same, those new editors I'm now arguing for can always do it the slow way, so I can't pretend it actually matters very much; in fact, no, leave it as it is: it was a useful trigger to get me to start looking at monobook.js, so it could have the same effect on others. PL290 (talk) 17:52, 23 May 2009 (UTC)

Great minds think alike. I came here to ask the same thing. I stumbled across popup ages ago, it's amazing, but the whole point of the request is for a single click unwatch - it's a simple task so it's a pain to go through a page load or multiple clicks. However, watchlist.js does the trick! This has also inspired me to find the list of scripts at WP:JS. Watch out wikipedia, this digger's automated! Bigger digger (talk) 13:05, 24 May 2009 (UTC)

For anyone that doesn't like User:Js/watchlist.js, I recommend User:Alex Smotrov/wlunwatch.js as an alternative. It doesn't require clicking that first 'x', so it's a bit more convenient. — Gavia immer (talk) 15:11, 24 May 2009 (UTC)

I liked Js', but the lazier the better for me!, thanks Gavia! Bigger digger (talk) 15:36, 24 May 2009 (UTC)

OoK's expediency

Entities must not be multiplied beyond necessity.

Honestly, I turned suspicious of the Outline of knowledge existence within Wiki. The main problem is maintenance of associated tons of articles, the majority of which essentially duplicate the main ones and will flood Wikipedia soon. The namespace will be inflated to additional thousands articles, some of them, like hot issues, will natuarlly require extra attention (vandal patrol, bots etc.). Another issue is that outlines may oversimplify some articles akin to what was predicted in Fahrenheit 451.

Since OoK's transclusion to some non-WP venue may be problematic, I offer warranting the outlines just for long, difficult articles (such as existing Outline of medicine). brandспойт 12:17, 21 May 2009 (UTC)

Outlines articles are lists; it's rather unclear to me how a list can "oversimplify some articles" (by which I assume you mean "oversimplify some topics). And even if a list doesn't link to all the articles it could, it can still be a good starting place, since there are plenty of wikilinks within Wikipedia articles that will take readers to related articles. Plus the best solution would be to improve the outline/list, not delete it.
It would be helpful, for further discussion here, if you would point out two or three examples of problem outline articles. Could you do that?
Also, I'm having real problems trying to figure out what you mean by "associated articles" that duplicate "main ones"; could you provide an example of an "associated article" and the "main one" that it duplicates? And please don't use "the namespace" when you mean "article space" or "mainspace"; and please don't use "Wiki" when you mean "Wikipedia"; a wiki is not the same thing as Wikipedia. -- John Broughton (♫♫) 15:10, 21 May 2009 (UTC)
I don't propose deletion, but (not emphatically of course) facilitation somehow since I'm afraid it is rather impossible to manage all outlines amid pending issues. To point problem spots: many topics are too limited (either in terms of our knowledge or per se) to create outlines, such as the Outline of Adamstown, Pitcairn Island or Political scandals of São Tomé and Príncipe. And in particular nearly all existing articles on countries use the same request pattern, so we have even Fjords of Rwanda and other phantom or funny links.
John, I am perfectly aware of the words I'm using like nampespace not merely of articles, but also talks etc, and Wiki, written with capital letter as Wikipedia's lovely diminutive :) brandспойт 19:30, 21 May 2009 (UTC)
Okay, I'm starting to understand. Regarding duplication, List of São Tomé and Príncipe-related topics and Outline of São Tomé and Príncipe are two list-style articles with large amounts of overlap. And the second article has a lot of redlinks for things like Political scandals of São Tomé and Príncipe (your example) and Glaciers of São Tomé and Príncipe; the first probably could be easily sourced but the second is far more doubtful.
Still, I'm inclined to doubt that Wikipedia is going to be "flooded" anytime soon with thousands or tens of thousands of articles, requiring huge amounts of work, because these outline articles exist: If that is going to happen, why hasn't it already? These outlines have been around for quite a while; doesn't Ockham's razor say that the most likely future is similar to the past? (And in the past, these outlines have not caused problems, correct?)
In short, you seem to be proposing a controversial solution (deleting a lot of outline articles) to solve problems that you can't actually show now exist. Nor is there any reason to believe that the problems that you're worried about will ever appear. And if they do, we can deal with them then. -- John Broughton (♫♫) 15:01, 22 May 2009 (UTC)
We (WP:WPOOK) recently noticed that there are outlines that aren't called "Outline of". So we've started gathering them to Category:Outlines where they can be more easily spotted and dealt with. They will probably eventually be converted to a standard outline format or merged with an "Outline of" article. To be determined on a case-by-case basis, by usual wiki-procedures, of course. The Transhumanist 03:43, 25 May 2009 (UTC)
There's a guideline draft being written for outlines. It explains a lot of this stuff. See Wikipedia:WikiProject Outline of knowledge/Outline of knowledge. The Transhumanist 04:06, 25 May 2009 (UTC)

By the way, if you're opposed to the contest being proposed at Wikipedia talk:WikiProject Countries#Country outline contest proposal, you really should post your objections on that page, not here. -- John Broughton (♫♫) 15:15, 22 May 2009 (UTC)

Policies and guidelines shouldn't be treated like articles

It seems to me that policies and guidelines are treated too much like regular articles in that, first, anyone (or if the page is semi-protected, any established user) can edit them, and even more problematically, changes are decided by talk page consensus. Why should it be assumed that editors who happen to be involved on a particular project talk page at a given time are representative of the community consensus? This is especially troubling in light of such pages existing to describe rather than dictate accepted practice. Then there is the recurring question of whether No consensus regarding the status quo is grounds for a removal or whether decided consensus is needed for any change to such a page.

One solution would be to fully protect all guidelines and policies so that only admins can edit them. I anticipate the counterargument—that such matters are decided by the community and not merely the admins. However, admins are supposed to be those who have the trust of the community at large, and should be trusted to make such pages representative of community consensus. Moreover, they would figure to be the ones most aware of what is widely accepted or rejected in practice, therefore are most apt to make sure that is accurately described. PSWG1920 (talk) 16:25, 23 May 2009 (UTC)

I'd definitely like to see some movement towards greater stability in the various guidelines and policies. Full protection is definitely worth exploring, given that these are the rules that govern our conduct. However, we'd have to ensure that the intent of this is crystal-clear, being to ensure stability, and that the "admin-only" lock is in regards to posting changes, not making them. --Ckatzchatspy 16:39, 23 May 2009 (UTC)
On the principle of WP:NOTLAW, a change is never actually made (unless it comes from the top, i.e. Jimbo Wales), but rather evolves. Policies and guidelines exist to describe what has already evolved. That is my concern with talk pages deciding what the policies and guidelines should say. PSWG1920 (talk) 16:52, 23 May 2009 (UTC)
Nope. The issue has little to do with open editing. I've been around for quite a while now and I discover new policy pages all the time. (Wikipedians love instruction creep.) The rules are descriptive, not prescriptive. They describe best practices. Any user should be able to use common sense and not ever have to read a policy page. If they're updated or changed, that's fine. But the spirit is what is important, not the specific wording being used. And, of course, any major changes to major policies are usually well-advertised. --MZMcBride (talk) 16:49, 23 May 2009 (UTC)
It's in the nature of WP that policy pages are descriptive. For them to be prescriptive would require a change to policy pages to be systematically enforced; this doesn't (and perhaps can't) happen unless the community (a) knows about it and (b) agrees with it. Only in the case of certain admin actions is there much chance of policy change preceding practice (because there are many fewer admins than editors, especially in relation to specific admin tasks). Anyway full protection is unnecessary, because editors on talk pages generally know that proposals for major changes need to be advertised way beyond the talk page. Failure to respect that generally gets reverted. Rd232 talk 19:10, 23 May 2009 (UTC)
However I think general semi-protection of at least well-established policy/guideline pages is worth exploring; IPs in my experience contribute little to the main policy pages, as do new accounts - but they do produce vandalism which (a) makes it harder to read the history to see how policy pages have evolved and (b) discourages people from paying attention to policy pages, because changes are too often junk or reversion of junk. Since changes should be discussed on talk anyway and they can still propose changes on talk, the cost of excluding IPs and new accounts from such pages is very low. Rd232 talk 19:10, 23 May 2009 (UTC)

See also WP:EP#Editing policies and guidelines. Rd232 talk 18:15, 24 May 2009 (UTC)

History tab at the top

It would be less jargon if the history tab at the top say "authors" or "edited by". History is abstract jargon. An "authors" tab would give subtle credit to the thousands of people who have built this encyclopedia. It's a nice thing to do! User F203 (talk) 19:35, 1 May 2009 (UTC) (note, after reading the instructions, this is the proper place for discussion as developers read here according to the instructions.)

"History" is exactly what it is. It's the history of every revision that has been made to the page, and that is not jargon. While I wouldn't argue against a special page to list authors—indeed, I would welcome such a development—I think that it would be misleading to give the history tab such a title, as "authors" or "edited by" is exclusive of a significant part of the purpose of the page. {{Nihiltres|talk|log}} 01:07, 2 May 2009 (UTC)
You raise a point that I never thought of! Why not have a separate tab for a list of authors? Having a list of authors is a good idea and makes Wikipedia honest (by giving credit to people). Not recognizing authors or hiding it somewhat is intellectually dishonest. User F203 (talk) 17:32, 2 May 2009 (UTC)
History is far, far more accurate a term; just because someone has edited a page does not mean that they are an actual author of the page (such as with vandals), whereas the page does show the history of the article. EVula // talk // ☯ // 17:34, 2 May 2009 (UTC)

(ec)::An easier way for the developers is to rename the tab "history/authors". Currently, the history tab is the shortest one so lengthening it is ok. Project page, discussion, and edit this page are all far longer in length.

As far as vandals, they are blocked so fixation with vandals while forgetting to encourage good authors is short sighted.

How about renaming it "authors/history"? Or have a separate tab for authors? User F203 (talk) 17:37, 2 May 2009 (UTC)

I don't see what the benefit of an "authors" page would be, though. Each edit is different; I shouldn't get the same credit for an article just because I italicized a movie title as the editor that wrote 90% of the article. I also don't see what's so arcane about the term "history" that it would need to be changed in the first place. EVula // talk // ☯ // 17:52, 2 May 2009 (UTC)

Note that no developer action would be needed to change the name of the tab. Any admin would just have to edit MediaWiki:History short if you ever got consensus for renaming it. Anomie⚔ 18:09, 2 May 2009 (UTC)

History is correct. What is an 'author'? Someone who changes 'was' to 'were'? Someone who adds OR or uncited material? Someone who adds stuff we find to be copyvio? I'm happy to be an editor. Dougweller (talk) 18:52, 2 May 2009 (UTC)
I agree with EVula/Dougweller. A vandal wouldn't be an author, nor would the person or bot who reverted the vandalism. What about people whose edits were so long ago that what they wrote has been rewritten so many times that it no longer exists in any form in the current version of the article? Mr.Z-man 19:06, 2 May 2009 (UTC)

If not an author, how about an editor? Some textbooks have editors. Or how about "Recent editors"? Rather than just say "No", how about some ideas! User F203 (talk) 19:42, 2 May 2009 (UTC)

If there's a consensus that it's inaccurate (there doesn't seem to be), I wouldn't be adverse to "Article history". "History" is ambiguous, and adding the qualifier (something like "Page history" might work also) would seem the best route. --Izno (talk) 22:05, 2 May 2009 (UTC)

Would strongly support changing it to "page history", that should help usability quite a bit. (Edit: I see this has been done before but was reverted as it was "redundant"; which I do not agree with at all) GDonato (talk) 23:37, 2 May 2009 (UTC)
I think "revision history" would be good too as that's what it says on the actual history page. I'd prefer it to "page history" or the current "history". Cool3 (talk) 00:02, 3 May 2009 (UTC)
Though I don't see the necessity of the change, I'm willing to admit that it's due to my familiarity with the term; "page history" is more descriptive, and is still an accurate name for the tab. I'd be fine with the change. EVula // talk // ☯ // 10:21, 3 May 2009 (UTC)
Or simply Revisions? --ClickRick (talk) 11:59, 3 May 2009 (UTC)

I agree with several of the editors here. Many ideas are better than "history". History of what? Wikipedia? Roman Empire?

Better terms than history include Page history, Previous versions, Old versions/editor list, etc. One advantage to some use of the word "editors" or "authors" is if someone writes "The Pope is dead", that vandals may be quickly reverted but someone may see it. That someone thinks that a hypothetical "Wikpedia Corporation" wrote it. If we have a tab with some reference to authors or editors or article credit or versions/editor list or something else, we protect the integrity and reputation of Wikipedia in spite of any dumb things an individual editor does.

Note that the common casual reader does not know all the jargon like admin, IAR, history, ban/block, etc. This is supposed to be an encyclopedia not a geek site. User F203 (talk) 16:18, 3 May 2009 (UTC)

I don't think lumping "history" along with "IAR" as 'jargon' is an appropriate assessment. While it is ambiguous, it is not obscure or requiring insider knowledge. We cannot protect against personal stupidity: if someone is sufficiently unfamiliar with the way Wikipedia operates that they do not understand the absence of "Wikipedia Inc." despite the "history" tab appearing next to a bolded "edit this page" link, then there is precious little we can do to change that. Certainly renaming one tab is not going to miraculously enlighten them; I don't really see how you think it will. "page history" would be an appropriate clarification. Anything that tries to paint the history page as a list of contributors is, IMO, fundamentally incorrect. Happy‑melon 17:42, 3 May 2009 (UTC)
Oh come on, your "history of what" examples are ludicrous. It's in the same cluster of tabs as "edit this page" and "move". It's pretty obvious that the tab isn't there for any content-related matters. EVula // talk // ☯ // 18:26, 3 May 2009 (UTC)

By the by, German Wikipedia has "Versions/Authors", which I don't much like. "Page history" would be OK with me, but I'm not sure how much more helpful it would be. (Not sure how we could find that out, either.) Rd232 talk 18:29, 3 May 2009 (UTC)

You might be looking for http://wikidashboard.parc.com/ 199.125.109.77 (talk) 00:19, 4 May 2009 (UTC)

  • Been bold with MediaWiki:History short since my tabs still don't go off the screen at 800x600 and I'd expect most people are higher resolution than that anyway. GDonato (talk) 13:06, 4 May 2009 (UTC)
    • Then let me be the first to raise objection. I think adding "page" is redundant (What else should it be the history of? And why not also change "edit" to "edit page", and move to "move page"?), my main objection as an editor is that it's taking far too much room. And yes, I think that the tabs should be mostly optimized for editors, not for readers, since they don't care. I could of course change it back via javascript, but would prefer just reverting the message back to how it was.
      Amalthea 13:19, 4 May 2009 (UTC)
    • I've reverted the change... This thread cannot reasonable be taken as "consensus" as most people probably ignored it being pretty much a dead proposal (no offense to proposer). Please make a new proposal that clearly delineates what will be done. –xeno talk 13:21, 4 May 2009 (UTC)

Just dropping by to also object; the tooltip explanation (and the many help pages, etc.) are sufficient. Shorter is better. Sorry. JesseW, the juggling janitor 18:04, 4 May 2009 (UTC)

There is a request to "make a new proposal that clearly delineates what will be done". I think this could be rather heavy handed. Rather than say "change to ---", I thought the current situation was not ideal and there could be improvements.

Discussion is useful. Some points brought up, I didn't know before. User F203 (talk) 19:09, 4 May 2009 (UTC)

The History tab is part of the GFDL license, and a different title would be non-compliant. Please read Wikipedia:Text_of_the_GNU_Free_Documentation_License. Even if we are dual-licensed, we need it to stay compliant. Sorry. ▫ JohnnyMrNinja 00:02, 5 May 2009 (UTC)
This is interesting, but misguided. I don't think any articles on wikipedia have a history section. The content of an article is the stuff under the title. Interpreting legal documents takes a level of expertise that cannot be verified on a wp talk page. –MT 05:15, 5 May 2009 (UTC)
WM seems to believe that linking to a history section is compliant. We do not contain a full list of authors in the text of the article, it is in the history section of the article, which is accessed by the tab. If this does not qualify as a "section", then WM is in violation of the GFDL, so it doesn't matter what it is called. If WM is not in violation of the GFDL, then we shouldn't deliberately violate it. ▫ JohnnyMrNinja 05:35, 5 May 2009 (UTC)
So then every non-English Wikimedia project is in violation of the GFDL because they don't have the history tab as "history" in English? Mr.Z-man 15:34, 5 May 2009 (UTC)
lulz. For the English-language Wikipedia (that's where we are now, right?), any time a document (article) is modified the date and the author must be added to the "History" section. Please read the (English) GFDL and tell me if this is not correct. It is very specific about the title of every section so that they can be easily identified on any GFDL document. ▫ JohnnyMrNinja 18:04, 5 May 2009 (UTC)
Wikipedia does not have front and back covers, and this is explicitly stated. It's usually best not to raise complaints based on your own legal interpretations here at all, though if you can find a reliable source that makes exactly the point you're making, this should be acceptable. –MT 23:40, 9 May 2009 (UTC)
Support revisions. If you're an editor, add a javascript. The default interface is for anonymous users. Shorter is not better. A number of people mistake 'history' to be yet another section of the article - a section on its history. The word 'history' should be avoided; and 'revisions' or 'old versions' is the way to go. –MT 05:15, 5 May 2009 (UTC)
"A number of people"? How many? Seriously, I can't imagine that this is that perplexing of an issue. EVula // talk // ☯ // 05:45, 5 May 2009 (UTC)
I agree with M. Would it be possible to have it show up as "revisions" when one is not logged in, and then as "history" for logged in editors? -GTBacchus(talk) 05:49, 5 May 2009 (UTC)
You need to pretend that you're dealing with impatient and dumb 7 year olds - not because most users are stupid, but because they don't have time to put up with poor interfaces. You're trying to find out about some country. You see discussion (which isn't even about the country, it's just a bunch of tedious arguments) and history at the top. Great, they must have split it up. But no, you're in some weird list now. From a few months ago: User:AxelBoldt/Wikipedia_usability_problems#History_tab. –MT 08:39, 5 May 2009 (UTC)
How about "Update log"? --Philcha (talk) 17:14, 5 May 2009 (UTC)
That implies a register of changes, where each change was to bring it more up-to-date; many changes are, of course, to add information, or present existing information more clearly, irrespective of freshness. I might support a change to "Log", although I'm not convinced "History" works ineffectively. –Whitehorse1 18:10, 5 May 2009 (UTC)
Revisions has about 5 supports, 3 on this page and 2 in the linked. I think that unless a point against it comes up ("not the right word", etc.) it should be our candidate for replacing 'history'. I support replacing history, and I support replacing it with revisions. –MT 02:31, 7 May 2009 (UTC)
Log is inappropriate; it has a similar, but distinct meaning in MediaWiki. On the other hand, the page history contains entries that are not, strictly-speaking, revisions (records of page moves, protections, etc). I don't think "revisions" is any more correct than "history"; probably less so. Happy‑melon 10:42, 7 May 2009 (UTC)
I would oppose the change on the basis that I oppose changing a very visible part of the interface based on the opinions of only 5 people. Mr.Z-man 13:50, 9 May 2009 (UTC)
This seems to be a meta-opposition :) I'm sure that a proposal like this wouldn't get passed in any case until many people (including you) have voted. Under what conditions would you approve? Do you reject any changes to the interface at all? Is this change baseless? –MT 23:40, 9 May 2009 (UTC)
I wonder what opponents think of the variant of using three words (already done by "edit this page") added yesterday in a potentially confusing sequence of mis-edits by me. My point is that "history" is not the "wrong" word but context is the problem because there are multiple, simultaneous contexts here (a website... an encyclopedia...). So the sense in which "history" is being used is not clear unless you already know. I've suggested "page edit history" or "page revision history", not unthinkably verbose given the existing "edit this page". I've added a new section for this in the straw poll; perhaps this is of interest to those who have so far opposed. PL290 (talk) 06:51, 17 May 2009 (UTC)

History tab straw poll

"The wording of the history tab should be changed to authors"
"The wording of the history tab should be changed to revisions"
No change
noun/verb tabs are already in the ratio 3:2, so let's not argue no change on that basis. PL290 (talk) 21:31, 16 May 2009 (UTC)
Although I now see that you refer only to the noun/verb issues concerning the word "edit" within your own phrase "edit history". PL290 (talk) 21:40, 16 May 2009 (UTC)
  • If it needs clarification, expand it to "page history". I haven't even see evidence that this is necessary. Happy‑melon 19:22, 10 May 2009 (UTC)
  • Support - Unnecessary. Garion96 (talk) 19:28, 10 May 2009 (UTC)
  • History is fine, better than proposed alternatives. 'Authors' is unrepresentative and 'revisions' is too technical for the general public and a bit boring. I find history more attractive. Cenarium (talk) 19:43, 10 May 2009 (UTC)
  • Support - "History" is clear enough in the context of the interface - it's right next to "edit this page". However I could see the advantage of a short explanatory message/link at the top of the History page so that any confusion is immediately clarified for people expecting something else. (In fact, I'm a bit surprised we don't seem to have this already.) Rd232 talk 19:51, 10 May 2009 (UTC)
  • Comment: when voting no-change, please keep in mind that this isn't for registered editors, but for those who are brand new and have never clicked 'history'. It may be appropriate to say "support, but I'd change my mind if it can be shown that 'history' is actually confusing for newcomers" or "support, they'll just have to get used to it", rather than just "support". –MT 20:27, 10 May 2009 (UTC)
    Or you could simply assume that people commenting have read the discussion above and don't agree that a change is necessary. Garion96 (talk) 20:38, 10 May 2009 (UTC)
    I don't mean to imply they haven't. I'm just trying to encourage more feedback, rather than just support/oppose. –MT 20:45, 10 May 2009 (UTC)
    This is why we are conducting a straw poll, not a vote. If convincing evidence suddenly comes to light that some of the reasons for the 'no change' !votes are simply invalid, then they can be discounted; it is the quality of argument that matters. No one has simply posted "support", they have presented arguments that you need to successfully dispel if you want consensus to swing towards this proposal. Happy‑melon 20:48, 10 May 2009 (UTC)
  • No change is necessary. Even the few hypothetical readers who click "history" at the top of Canada and think they are getting a history of Canada will quickly be educated when they get to the next page that clearly demarcates "Revision history of..." and also has a link to Help:Page history. –xeno talk 18:34, 11 May 2009 (UTC)
  • Oppose - Cenarium sums up my thoughts well. Mr.Z-man 02:41, 13 May 2009 (UTC)
  • No change. Seriously, this is still here? There's nothing broken, so please don't fix it. — Gavia immer (talk) 03:02, 13 May 2009 (UTC)
  • No change. Arguments for other labels tend to reach for reasons to change that are very minor, see Xeno above. Sswonk (talk) 04:05, 13 May 2009 (UTC)
  • Mark Hurd mentions "edit history" but is worried about n/v ambiguity. Never-the-less, I support "edit history" unless enough people agree with PL290 that "page revision history" is not to long. "Editing history" comes close but doesn't improve on "edit history." Kdammers (talk) 11:25, 17 May 2009 (UTC)
Kdammers, I'm sure you'll have considered this aspect, but the "edit history" noun/verb issue is compounded by the fact that the tab is one of a group containing "edit this page" whose "edit" really is a verb. So it's not only n/v ambiguity, but also n/v clash between two tabs in close proximity that would start with the word "edit". Hence my now-soapboxed "page edit history", sharing two words with "edit this page" and thereby emphasizing its relationship with the latter . PL290 (talk) 16:41, 17 May 2009 (UTC)
  • No change — I take it as part of the Wikipedia vernacular that "history" is short for "page history" or "revision history"; the short "history" has its meaning clarified by context. --User:Ceyockey (talk to me) 00:58, 21 May 2009 (UTC)
  • No Change. As others have said "history" is exactly what it is, in the sense of the past of the article. It also follows current use in software, as in e.g.: Photoshop. Hairhorn (talk) 23:51, 24 May 2009 (UTC)
  • Don't change anything > per Hairhorn, and just convention. It's clear what it means, and it's not broken. ╟─TreasuryTag►hemicycle─╢ 10:01, 25 May 2009 (UTC)
Yes, it's crystal clear what it means—to all of us, now we know—but per M, keep in mind that the efforts being made here are on behalf of newcomers. I suggest it's not at all clear to a newcomer what the isolated word "history" means, on a web page of an encyclopedia containing articles about world history. PL290 (talk) 12:50, 25 May 2009 (UTC)
"The wording of the history tab should be changed to 'page edit history' or 'page revision history'"
  • Support - "History" is not the "wrong" word but context is the problem because there are multiple, simultaneous contexts here (a website, an encyclopedia...) so the sense in which "History" is being used is not clear till you know. Spell it out: "page edit history" or "page revision history" are not unthinkably verbose given "edit this page". PL290 (talk) 21:08, 16 May 2009 (UTC)
How about "editing history": would that be clear, intuitive, grammatical and accurate? —— Shakescene (talk) 23:41, 16 May 2009 (UTC)
Definitely better than "history", but still easily misinterpreted simply because of the wide range of grammatical styles in general use on websites for such things. For example, the Microsoft home page (right now, at least) has a left navigation bar item called "Using your computer", and "editing history" could easily be misconstrued as being a source of information about how to edit the history (whatever "history" might be)—or even the means to commence that activity. Whereas, "page revision history" disambiguates, both grammatically and contextually. If desperate to save another 4 characters, "page edit history" would be an alternative, and perhaps I like it even more since it contains both the word "edit" and the word "page", giving a stronger relationship with "edit this page". PL290 (talk) 06:51, 17 May 2009 (UTC)
Sorry for the lack of response, but I don't think anyone is taking this poll or discussion seriously at this point. This proposal will likely never go through for the reason that while the number of support v. oppose may be equal (which I highly doubt is the case), the people who are inclined to support will not all like the same word(s). But in all honesty, history is the best name, any confused people will figure it out, this isn't Simple English WP, let's drop this now? ▫ JohnnyMrNinja 17:46, 17 May 2009 (UTC)
"The name of the history tab should be changed to 'previous changes', 'previous revisions' or 'previous edits'" [new choice, May 20]

Propose: If a new user sees "edit this page", then the purpose and nature of an adjacent tab reading "previous edits", "previous revisions" or "previous changes" should be intuitively clear and unambiguous. —— Shakescene (talk) 03:36, 21 May 2009 (UTC)

Support: any of "previous changes", "previous revisions" and "previous edits" would be an improvement, but most especially "previous edits" which, by containing "edit", establishes the tab's relationship to the "edit this page" tab, which, IMO, is the whole point. PL290 (talk) 08:05, 21 May 2009 (UTC)

"Change both 'edit this page' and 'history', to 'edit article' and 'article history' respectively" [new choice, May 25]

Propose: Citing an earlier point, "history" on its own is not the wrong word, but context is the problem: there are multiple, simultaneous contexts here (a website, an encyclopedia containing articles about world history... an editable article), so the sense in which "history" is being used isn't clear. PL290 (talk) 09:45, 25 May 2009 (UTC)

End of the line

Comment: this straw poll has a confusing structure that doesn't allow simple tabulation. I am seeing something near 13 poll voters asking for no change and ~5 poll voters asking for something else. Since the poll has been conducted for over two weeks, I think it is safe to conclude that those numbers clearly point to a consensus against any change. The tooltip of the tab link and content of the history page make it very clear to even a first time viewer what the page is about, and unless there is substantial argument against I think reasonable editors will all agree that no change is mandated by votes or consensus at this time. Comments can certainly be added to the thread, but in my view this part, the "History tab straw poll", has reached the end of the line. Sswonk (talk) 14:29, 25 May 2009 (UTC)

This straw poll is as good as dead. It was initially intended to be a way to decide on a good alternative to propose, not as a vote on the issue. Most of the people voting have no evidence that this does or does not affect new users. We should have voted on whether or not the preferences of established users should be considered (they should not), gone from there to figuring out if crappy terminology on our part makes editing difficult (it does - see the usability study), and finally implemented whatever solution was best. Instead we're asking users who would be entirely unaffected if we called the tab "kl;rc", and might even prefer that, since it's shorter.   M  18:05, 25 May 2009 (UTC)

New pages, created by novices, should include noindex by default

Proposal summary

Pages created by users who are not autoconfirmed should, by default, include a noindex template. The template should only be removable by an autoconfirmed user

What problem is being addressed?

Brand new users, many unfamiliar with the guidelines of Wikipedia, create pages that violate many rules. Many of these pages are indexed by search engines such as Google. Links to Wikipedia pages often score very high in the Google page rank system, thus these pages are very often one of the first presented to a person using a search engine. In the case of some rule violations (poor grammar) it is only mildly troubling that such a page would appear in a search engine. However, other violations, such as copyright violations, and libelous statements against living persons, are far more serious. While established editors can and do run afoul of the rules, pages created by the newest Wikipedians are more likely to be troublesome.

I did a very unscientific review of a few recently created pages. Results here:User:Sphilbrick/Sandbox for support of proposal The sample size is too small to draw broad conclusions, but does illustrate some of the issues. In short, I reviewed a number of new pages created by users with fewer than ten edits, and found eight with concerns. Six of the eight are already found in Google, and can still be found, even though, in some cases, the underlying page has been deleted.

What are the benefits?

Under my proposal, none of the eight pages identified would be found using a search engine (outside of Wikipedia). One of these pages is flagged for a copyvio, and all but one of the others reflects poorly on Wikipedia.

While this benefits is admittedly modest, I estimate that dozens of pages with problems are created each day by nonautoconfirmed users, and these pages are finding their way into search engines. If a better estimate of the potential count is needed, I can do a more rigorous analysis, but I'll note that my review covered fewer pages than are generated in a single day, so it is highly unlikely the number is less than thousands in a year. (However, I don't know how long it takes for a deleted page to drop out of Google, so I don't have an estimate of the number of problems pages in existence at any time.)

What are the costs?

I see four types of costs:

  1. Implementation time
  2. Education time
  3. Template removal time
  4. False positive cost

My list is somewhat long, but each is minor. IANAP so I don't know precisely what is necessary to implement this, but I assume that when a user creates a new page, it fires off an algorithm that would need modification. The algorithm needs to determine whether the user is autoconfirmed, but my understanding is that this happens every time a user does an action, so is no cost. The algorithm would have to create the new page in a slightly different way for the two types of users, but I think adding a template should not be a major cost. (Does the system already add a non-patrolled template, or is that handled a different way?)

If the proposal is implemented, user manuals would need a rewrite. Not zero, and I may be under-estimating the places affected, but not major.

If the proposal is implemented, someone will have to remove the template at some time. However, most of these pages will have templates relating to other issues, so removing this template when the other problem messages are removed should be a minor addition of time.

Finally, there is a possibility that a new user will create an excellent article relating to a breaking news item, and users of search engines will run across the article later than they would under the present approach. While it needs to be mentioned, I find it difficult to believe it could be a meaningful problem. New pages relating to breaking news are highly likely to be patrolled, and it seems very unlikely that such a page would escape review by an autoconfirmed user with the ability to remove the template for more than literally minutes.

Background

This proposal was inspired by a discussion in Technical here. This proposal stands on its own, but interested readers might want to read the link to see, for example, why removal based upon a time limit was criticized, or why a proposal that it would take an administrator to change the status was a problem.

Alternative

I feel that the noindex template rule should be stronger than simply users who are not yet autoconfirmed. I would prefer something like a few hundred edits and a few months. However, creation of a new class of users is likely to be a big deal, so I chose to make the distinction using autoconfirmed. I do note that Tor users have rules applied at a different point - 90 days and 100 edits. If that status is easily available, I would find it a better choice.Sphilbrick (talk) 23:31, 22 May 2009 (UTC)

Are new pages created by random users not already detected in some way? Have there been actual cases where this has posed a problem - complaints, that sort of thing? One main objection probably is that adding noindex would deprive us of an important tool for finding these types of pages (that is, Google and other engines).   M 
Responding to your main objection - one of the aspects of the proposal is that any confirmed editor can remove the noindex tag, so in the case of acceptable articles, the delay would be minutes or perhaps a couple hours. Unless you meant that you wanted to find these offending articles using a search engine outside WP - but I'm failing to understand why.Sphilbrick (talk) 12:59, 23 May 2009 (UTC)
  • Looking at your sample articles, I think you may be making too big a deal out of this. No-indexing of pages (which currently can't be done with articles at all), should only be done when there are the potential for serious problems. Some of the articles you picked out are just bad writing. Ijare may not be particularly helpful, but its not harmful. David Collier (producer) may be terribly written and an unsourced BLP, but the article itself is entirely positive. I don't really see anything wrong with Women's Action Alliance, for an article by a new user, its not that bad. Arthur Do is written like a CV, but other than that, not bad. Liam Bunston was a crappy autobio, but not something particularly terrible. No-indexing exists to hide potentially problematic content within our inner-workings from Google, not to hide our minor messes. Mr.Z-man 06:19, 23 May 2009 (UTC)
For those new to the discussion, the reference to "sample articles" is the list in my first pass review. I've supplemented my review with a more comprehensive review - my third pass covers all articles created in the first eight hours todaylatest.Sphilbrick (talk) 18:27, 23 May 2009 (UTC)
I agree that the harm is, at most, modest in the selected articles. The Women's Action Alliance is a good example of how the proposal works well - yes, it would be caught in the net, but I anticipate that within hours (maybe even minutes), some editor would decide it is good enough and remove the tag. I do suggest, however, that badly written articles do contribute to harm, by adding to a perception that one can find a lot of crap in WP. That said, my main goal is to filter out a fair number of the more egregious problems, such as Fstg, with the possible copyright violation. Ironically, while it is tough to search for pure copyright violations, the filter I propose would also fiter out some abysmal writing, while not filtering out decent contributions for more than a very limited amount of time.Sphilbrick (talk) 12:59, 23 May 2009 (UTC)
No, the harm for most of those articles, using the definition generally applied when discussing Wikipedia articles, is 0 (some of the articles are so overly positive, the harm is probably negative). When most people speak of "harm" coming from an article, its harm to a 3rd party, generally the article's subject. Harm to Wikipedia's reputation from poor writing is not considered. We should not try to hide the fact that we have poorly written articles. If anything, we should highlight them so they get improved faster. Mr.Z-man 15:53, 23 May 2009 (UTC)
  • I think it's a good idea. The examples may not be very striking but the potential for more serious effects is clear from the proposer's narrative. If it's really "highly unlikely the number is less than thousands in a year", a number increased by an unknown factor by Google's old-page cache, then I'd have thought it's worth doing something about along the lines suggested. The only reason not to do so appears to be if implementation cost is prohibitive (which I don't think opponents are so far saying). PL290 (talk) 10:08, 23 May 2009 (UTC)
  • I would be fine with the software automatically noindexing all new pages for a fixed period - say 3-5 days. This gives time to actually get the article started, and to speedy delete it if it is speedy deletable. It does little damage for the world to wait a few days to read about it. Time-sensitive topics like current events may be an exception. Dcoetzee 13:35, 23 May 2009 (UTC)
    Well, the software wouldn't know what was time-sensitive and what wasn't... --Izno (talk) 16:48, 23 May 2009 (UTC)
Actually, why not set up a 7-day noindex "honeymoon" for all new articles? Autoconfirmed threshold of 10 edits is ridiculously low; has anyone ever reached a thorough understanding of basic policies on their eleventh edit? NVO (talk) 17:57, 23 May 2009 (UTC)
From your edit summary I think you intend only all new articles by novices here, not all new articles? This sounds promising, as the proposal is specifically addressing issues caused by novices (para. 1). PL290 (talk) 18:14, 23 May 2009 (UTC)
I agree that the ten edit threshold is ridiculously low. As noted in the Alternative section, I'd prefer something like 100 edits and 90 days. However, the benefits of this proposal are modest, I want to ensure that the costs are modest, so i deliberately chose a threshold which wouldn't require new programming. If the programmers tell me that a higher threshold is as easy, I'd prefer a higher threshold. Sphilbrick (talk) 18:31, 23 May 2009 (UTC)
All new articles; at least, all unpatrolled. Perhaps, if some sort of reviewing is ever introduced, all articles until they are properly reviewed. NVO (talk) 19:43, 23 May 2009 (UTC)

I'd support something in this direction, on the basis that (a) new articles are generally some form of draft; waiting long enough for improvements or deletion should not be a problem for a website seeking to be an encyclopedia; (b) the idea that current events articles should be excluded from this noindexing squarely forgets WP:NOTNEWS. (In fact, so many current events articles should be on Wikinews anyway - and with new licence changes, we'll be able to transwiki content from Wikinews to Wikipedia as appropriate, once the significance of the current event is clearer and something resembling a encyclopedia article rather than a news report is more likely to result. Only real problem with this is that - in my experience - Wikinews procedures are impenetrable, versus the child's play of creating a new WP article.) Rd232 talk 19:18, 23 May 2009 (UTC)

While I maintain significant doubts about the desirability of noindexing pages, were a consensus to agree with the basic idea of this proposal, I'd suggest that new pages which have not been patrolled (that is, via a modification of the existing new page patrol system) be the ones to be noindexed. Obviously acceptable articles would be quickly patrolled, while backlog would not cause unacceptable pages to become indexed without review. The large backlog already present might be a problem, but it's an approach worth considering should people find noindexing of articles otherwise acceptable. {{Nihiltres|talk|edits}} 21:06, 23 May 2009 (UTC) (iPod edit)

I'm still not sure what this proposal would solve. Has there been any problem with a search engine indexing new articles?   M  19:58, 24 May 2009 (UTC)

The problem it will solve is not advertising our first drafts, spam, tests, and miscellaneous unreviewed junk to the world, via said search engines. Rd232 talk 20:08, 24 May 2009 (UTC)
I understand this much, but what policy or principle or consensus does such advertisement violate? We have drafts, and vandalism, and all sorts of junk, and I don't mind 'admitting' it to the search engines.   M  20:14, 24 May 2009 (UTC)
The issue is that new articles are more likely to be junk than old; or at any rate older articles have been around long enough to have a chance to get reviewed. Generally, people don't publish first drafts; Wikipedia does. Why advertise them as well? Noindexing may even discourage (however slightly) vandalism, spam, and general junk creation; and if not, the junk will have less effect on the world, being much less visible. Rd232 talk 20:30, 24 May 2009 (UTC)
"Why advertise them as well?" should be "Why not censor them?", and there has been no need demonstrated. Further, no evidence that new pages really are bad has been provided. (I just checked 10 new pages, and they were all remarkably good.)   M  20:55, 24 May 2009 (UTC)
Allowing Google to index them is not advertising them. "Adverting" implies we're going out of our way to promote them. The default is to allow indexing; we just let Google do its job. The main argument in favor of this seems to be "poorly written articles make us look bad" - and they should. We shouldn't try to hide our flaws to give people a false impression of our quality. Personally, I support putting articles in need of cleanup on the main page as a way to get more people involved in editing. Mr.Z-man 05:26, 25 May 2009 (UTC)
I'd understand your argument if we were talking about, say, no-indexing articles tagged and categorised as "bad" in various ways: hiding flaws. This is not that: it's the equivalent of saying "no, you can't see my first draft!". And frankly saying that google-indexing isn't advertising is splitting hairs - it is the major way such new articles are found. Finally, this isn't just about looking bad, it's about being bad: by (in an important sense) publishing first drafts via google, we're not allowing ourselves enough time to review and remove junk which should not be published. Looking at it purely as a "looking bad" issue implies an expectation that new articles should be perfect, and that the failure of such articles to be perfect shouldn't be hidden from the world. Put another way, the whole point of Wikipedia is to write a collaborative encyclopedia; why not give ourselves some time for collaboration to take place on new articles, before announcing the result to the world, via google? Rd232 talk 11:53, 25 May 2009 (UTC)
Because we want to collaborate with the world. Every reader is a potential editor. This proposal is to hide content from the general public that does no real harm. I cannot support that. And again, "announcing" and "advertising" are action verbs, both suggest that we're taking some action, when we're not. This is not "splitting hairs", its an important distinction to make. You seem to be twisting things around to make it sound like we're taking some action to force Google to index them when we're simply not stopping them from doing so. No-indexing them would be taking an action; it would be changing the default. Mr.Z-man 15:19, 25 May 2009 (UTC)
(a) I'm not twisting anything: choosing not to act, once you know there is a potential action (here, noindexing) is still a choice. (b) again, we're not talking about hiding all bad content (however defined) or for an unlimited period - only new "first drafts", temporarily. Seeing as there is no deadline, and WP:NOTNEWS, there is no reason to allow publication (if you prefer) before content has had a chance to be reviewed. Again, WP is a collaborative effort; why should things be published before any collaboration has had time to develop? This change fits all kinds of aspects of WP:NOT, and allows the WP community time to exclude WP:NOT violations. Why is this controversial? Are there other issues people are thinking of but haven't mentioned? PS Of course we still need new editors, but by definition this change is about weeding out topics not meriting inclusion, which by definition we don't want to attract people to and don't want to waste time on. Articles a week or two old will still be published to search engines, and still need improvement, and still attract editors hoping to help. Reminder: WP is an encyclopedia not a news source: why is it a problem for new draft entries to be reviewed internally before they're made more widely available externally? What's the deadline here? Rd232 talk 12:58, 26 May 2009 (UTC)

Central bibliography

Let's consider this in isolation from any implementation details. The vision of Wikipedia is to provide free access to the sum of all human knowledge. Human knowledge includes knowledge of published works. Wikipedia contains, embedded within article text, a large number of definitions of published works. The question then seems to be: once published work knowledge has been accumulated in this way,

  • does Wikipedia provide sufficient user access to the sum of that knowledge, and
  • does Wikipedia provide sufficient internal access to that knowledge, by allowing reference to it from inline citations in multiple articles?

From a current discussion on a certain proposed implementation, it appears the answer is no.

I propose that a mechanism be set up to allow access to the sum of all knowledge of published works, as a central bibliography, to both

  • users, who can then view and search the central bibliography, and
  • editors, who can then reference entries in the central bibliography from inline citations, specifying variable information such as page numbers as they do so.

PL290 (talk) 16:01, 18 May 2009 (UTC)

I really don't see how one can propose a new system without giving a thought to implementation. From my experience, in the vast majority of cases, it results in a bunch of people supporting and getting excited for something that never materializes. I've given some thought to an overhaul of the ref system myself, I have some notes at mw:User:Mr.Z-man/cite. Note that the a system to search references is one of the more difficult aspects of the implementation. Mr.Z-man 18:31, 18 May 2009 (UTC)
The goal of Wikimedia as a whole (and what Jimbo was talking about in that quote) is indeed to create "a world in which every single human being can freely share in the sum of all knowledge". Wikipedia is one component of that, we are an encyclopedia. Encyclopedias are not indiscriminate lists of things, such as books. When we're finished, we will have encyclopedic articles covering every notable work ever published. That's legitimate encyclopedic content. I don't think a List of all books ever published is legitimate content. That's what a library is for. Happy‑melon 18:34, 18 May 2009 (UTC)
Quoting Jimmy Wales is not the same as quoting Wikipedia policy. We follow policy, not what Jimmy said in some interview. And WP:NOT is quite clear: we're not a directory, and we're not an indiscriminate collection of information. Or, to put it at its most basic, we're an encyclopedia. Yes, we could, if we changed policy, spend huge amounts of time trying to build a central bibliography (do you have any idea how many tens of thousands of journal articles and books and newspaper and magazine articles are published every month?), at the cost of neglecting our core mission of improving articles. No, we shouldn't bother. -- John Broughton (♫♫) 20:43, 18 May 2009 (UTC)
Fair comments. I stand enlightened. I'll focus my thoughts then on only the "reference-sharing-across-articles" aspect, which was the trigger for this proposal in the first place. There seem to be further points still being made about this in the other discussion, so I'll see what transpires there. PL290 (talk) 18:52, 19 May 2009 (UTC)
I am working on a crude prototype of this thing. Check the draft article User:Jorge Stolfi/Oxocarbon test, Template:@@ and the subpages of the latter. Things to note in the draft artcile:
  • The "♦" buttons link to the entry in the repository, instead of the entry in the reflist.
  • The [E] buttons at the end of each entry in the reflist, to edit the entry in the repository.
  • The way references are entered in the drft article's source.
There are many things missing still, e.g. a button to omit/show the Reflist section, hovering popups, etc.. Please be patient, I am still learning how to write templates... All the best, --Jorge Stolfi (talk) 06:14, 21 May 2009 (UTC)
I haven't had a chance to study it in great detail yet, but it looks extremely promising as far as I can see. (As an aside, does an "out-of-body reference" result in an "out-of-body experience"?!) On a more serious note, do you envisage that it will support multiple references in an article to the same work, e.g., by passing a page-range argument to the template? (For an example of why this is needed, see The Beatles, section Notes and section References. PL290 (talk) 07:50, 21 May 2009 (UTC)
Perhaps in conjunction with {{rp}}, mentioned above by John Broughton? PL290 (talk) 07:55, 21 May 2009 (UTC)
A combined solution using {{rp}} and {{@@}} sounds quite interesting. I'm going to let this sit in the back of my head for a while before saying more. Kudos to the editors who have contributed to both. --User:Ceyockey (talk to me) 01:20, 22 May 2009 (UTC)
My prototype User:Jorge Stolfi/Oxocarbon test is broken at the moment because I can't figure out how to expand the {{{1}}} in <span title="{{{1}}}">...</span>. The #tag function works for ":ref" but not for ":span".) Hints would be appreciated... --Jorge Stolfi (talk) 06:20, 22 May 2009 (UTC)
I think, I fixed your problem. Ruslik (talk) 17:37, 23 May 2009 (UTC)
DBpedia, or related projects, would be more likely candidates for this idea. Wikipedia would then access their data.
Side-note: This thread reminded me of http://ottobib.com/ which might be of interest to anyone that hasn't seen it yet. -- Quiddity (talk) 02:27, 26 May 2009 (UTC)
Frankly, I think you are right, Quiddity. The centralization of bibliography does fit in quite well with conversion of Wikipedia to a more computable format. I find the solution that Jorge has put forth to be innovative and useful, but I do think it quite unlikely that any but the most experienced editors might adopt it in practice. --User:Ceyockey (talk to me) 01:21, 28 May 2009 (UTC)

Many thanks to Ruslik for helping me fix the prototype. Please check User:Jorge Stolfi/Oxocarbon test again.
Note that any logged-in user can choose between the "old" and "new" reference display styles by changing the "Date and Time" option in his/her user profile. (Is there a prize for ugly template hacks? 8-) Logged-out users should see the page displayed in the "new" style.
The "old" style is like the current one, except that each entry in the references list has buttons [E][e] to edit the entry ad its half-line version.
The "new" style supresses the "References" section and instead displays a "♦"-link to each ref-page, with the half-line versions displayed in the hover pop-up.
This is about as far as I can get with my current knowledge of wikihacking. Hope it helps. All the best, --Jorge Stolfi (talk) 07:45, 27 May 2009 (UTC)

It would save time and annoyance if external links that have "died" could be shown in red, similar to non-existent subject pages. This seems to be a natural task for a bot. It would scan all external links periodically. Since access time is slow for many links, and links are often down temporarily e.g. for maintenance, it might be best to retry a dead link after, say, 12 hours before marking it red. Then keep trying it and return to blue immediately it responds. Cuddlyable3 (talk) 07:17, 27 May 2009 (UTC)

I don't know if there is a bot doing this, but we do mark them with {{dead link}}. The Checklinks tool will scan an article, help to find alternative links and mark dead links. ---— Gadget850 (Ed) talk 09:43, 27 May 2009 (UTC)
Remember, (new) dead links on Wikipedia are soon to become a thing of the past. - Jarry1250 (t, c) 10:48, 27 May 2009 (UTC)
As for the millions of existing links, many of which are bad, I looked at the relevant section of the Editor's index (WP:EIW#LinkRot), and found mentions of three bots to find bad links: User:EchoBot, User:Stwalkerbot, and Wikipedia:Bots/Requests for approval/ShakingBot. The first two bots, both of which have been inactive for quite a while, posted messages on article talk pages when a dead external link was found; the third bot, which never was approved (inactive request), would have flagged bad external bots in the article itself. And then there was a bot to actually fix bad external links - User:RefBot; the Editor's index says that this is "not operational due to restrictions on owner – ArbComm cases". -- John Broughton (♫♫) 13:24, 27 May 2009 (UTC)

Old chestnuts

I think there should be a guideline for these proposals and their responses. It seems silly to have to keep filling up these threads over and over again with the same distracting explanations about whether or why you should or shouldn't say the users are just stupid and can put up with it or I've got used to it so why can't they. I think it would be better if you could just cite the guideline and carry on. Laughing Jean Genome (talk) 11:14, 27 May 2009 (UTC)

If you don't like em, don't read em. There's always the possibility that someone will bring something new to the table. Trying to regulate discussion in such a way is kinda the antithesis of what WP is all about, even if it's not related to the articles themselves. ♫ Melodia Chaconne ♫ (talk) 11:38, 27 May 2009 (UTC)
I like 'em, I wanna read 'em, once! Once, and clearly, not again and again while people are trying to discuss something else. You say someone may bring something new to the table: that's my point too. I want to see it when they do. The other distracting discussions belong at another table. I want to see it when people bring something new to either table but not both at the same time! Laughing Jean Genome (talk) 12:27, 27 May 2009 (UTC)
Have you seen WP:PEREN? That seems to be exactly what you're looking for. — Gavia immer (talk) 16:55, 27 May 2009 (UTC)
No I hadn't seen that, but it's not what I'm looking for thank you! What I meant is when the proposal is a new idea, not one of those perennial ones. Someone then chimes in saying they had to get used to the system like it is, so why shouldn't the newcomers have to get used to it too. That kind of thing. Then, others have to explain again why that's not a valid objection, and how we should focus on whether the proposal will help the newcomers. So threads are getting clogged up with this kinda stuff when it could be said once, in a guideline. That's what I meant about bringing suggestions to two tables. The proposal is one table and the guideline is the other. Why have the guideline discussion turn proposal discussions into spaghetti threads! Laughing Jean Genome (talk) 17:51, 27 May 2009 (UTC)

Tabs at top of page

This has no doubt been brought up before, but instead of having:

  • page - discussion - - edit - history - move - watch
  • page - discussion - - edit - history - move - watch

wouldn't it be more logical and helpful to have something like:

  • page - edit - history - move - - discussion - edit - history - - watch
  • page - edit - history - - discussion - edit - history - move - - watch

so that (a) you get immediate access to the history/edit pages of both main page and discussion page, regardless of which one you're on; (b) it doesn't look like the discussion is just one of the options under the main page, equal with edit and so on?--Kotniski (talk) 11:53, 27 May 2009 (UTC)

I think the point here is that your changes would be an improvement to simplicity of use, but they are also confusing to someone wishing to edit the article or see the article's history and is confronted with the buttons. The large number of buttons is also (more) distracting. It's just a case of whether the improvements outweigh the downsides, and I don't think they do. - Jarry1250 (t, c) 11:59, 27 May 2009 (UTC)
Perhaps the less immediately relevant ones could be displayed differently, for example using a less prominent typeface, or by doing something like:
  • page - e - h - - discussion - edit - history - move - - watch

?--Kotniski (talk) 12:04, 27 May 2009 (UTC)

I have ten tabs at the top of my pages already; oversighters would have even more. This change would be of little benefit to new or inexperienced users (would be confusing as Jarry says, "e h" is jargon that newbies can't be expected to intuitively understand) and for more experienced users, the downsides of taking up valuable tab real-estate probably outweigh the advantages of easy access. If you want to add tabs to your own skin, you can easily do so in your JS files. Happy‑melon 12:14, 27 May 2009 (UTC)
Well actually, it was more new users that I had in mind. My experience as a new user was that I was always getting confused, thinking I was going to the page history when I was going to the discussion history etc. - it still happens from time to time; and I still get annoyed that I can't go straight to the page history from the discussion page. And obviously we should be prioritizing ordinary users - how many buttons admins or oversighters have is surely irrelevant. --Kotniski (talk) 13:08, 27 May 2009 (UTC)
This is what gadgets are for, I think: once an editor gets comfortable at Wikipedia and starts thinking about making editing easier, then he/she can look at gadgets (again). So while I oppose this suggestion (adding two more tabs just makes the world even more complicated for a new editor), I would support adding a gadget that would add two more tabs - something like Wikipedia talk:WikiProject User scripts/Scripts/Six tabs. -- John Broughton (♫♫) 13:32, 27 May 2009 (UTC)
FWIW, here's the "Usability Wiki". I see hiding everything except "Article" and "Edit", with a hover over "Edit" (or "Tools" or "Info" or other possibilities for the tab title) revealing the other sections with better details, like this:
I know, hover does not work in this case – this is just a very rough sketch of what might work to help explain the meanings of the tab titles, while removing visual clutter. The power user would want to avoid all of the descriptions; I think the appearance of the menu would be entirely configurable in user preferences, i.e. "classic" (as it is now), "custom", etc. What about anon, IP users? Well, they can register and/or use an actual account to adjust the appearance of the menu, or it can change by default based on user group. I think a lot of experienced users have ideas along these lines, and think there should be a formal collaborative effort to get such changes in place, I just am not sure where that debate is or who they think should participate. Certainly our opinions should matter even if the changes are to benefit new users. Sswonk (talk) 13:42, 27 May 2009 (UTC)
Yes, it's always hard to get a useful discussion about what works for new users. But surely the newer the user, the less we should be hiding from them - they don't know what to look for, after all. I agree that all this should be personalizable with gadgets, etc., but that's quite irrelevant to ordinary inexperienced users, who ought to be given the most clear, intuitive interface. For me the current tab setup never made sense - you see two groups of two/three tabs, then when you click the second tab the meanings of the 3rd/4th/5th all change, although you don't see any change... Then there's not even any indication that there are other tabs "under" the 1st/2nd one... Maybe it's just the way my mind work-ed/s, but to me the extra confusion from two more tabs is far outweighed by the added clarity (and functionality, of course).--Kotniski (talk) 13:58, 27 May 2009 (UTC)
No, I don't want to hide anything either, but to your points about "clear, intuitive interface" and "extra confusion", wouldn't only two tabs be better, with the second tab immediately revealing detailed descriptions of all the possible other tabs for new users only? Again, like you maybe it's the way my mind works. You are right about the way the tabs currently change meaning, it's bad. Sswonk (talk) 14:36, 27 May 2009 (UTC)
Not sure I've properly understood you, since you say you don't want to hide anything, yet your proposals seem to be about making things invisible until you click/hover over other things, which is what I understand by hiding. This sort of thing is fine in its place (I like the way it works in popups, for example), but I don't see any need for it in a situation where space is not restricted - and at the top of the page there seems to be plenty of room, at least for the tabs a normal user (non-admin) would see under my proposal.--Kotniski (talk) 15:28, 27 May 2009 (UTC)
Absolutely. But there is not plenty of room for clear formal descriptive sentences about each tab. If something at the very top says "Edit", or "Contribute HERE!" (not seriously, but it can be more precise than "Edit"), and displays full details when hovering or clicked, that is going to be easier to understand and decipher than the multiple, somewhat ambiguous offerings now. I still would like to know if there is a single, authoritative UX forum/RFC if anyone can point it out. Sswonk (talk) 17:09, 27 May 2009 (UTC)

PDF of usability design. For those who had not found it yet. —TheDJ (talk • contribs) 14:15, 27 May 2009 (UTC)

I actually suggest a set of tabbed pages is not the best metaphor in the first place. Tabs soggest switching between concurrent activities, whereas here we are selecting—indeed invoking—one activity at a time. For example, clicking "article" is not a valid way to look at the current version while editing, as this will lose the editing done so far. So I would prefer to see something which is, in fact, just like the contents of that "edit" navbox provided above by Sswonk, i.e. a vertical list of completely comprehensible choices, and—lest anyone immediately counter that the long list will take up too much vertical space, which actually perhaps would not be very much—note that further, I suggest the choices visible at any time should only ever be those pertaining to the current action, so for example there would not be an "article" choice visible during editing. PL290 (talk) 14:46, 27 May 2009 (UTC)

AFAICT your point, though valid, really relates only to the edit window. I don't know what the best solution would be - again, not hide the tabs, I think, because you very often do want to quickly access one of the other tabs while editing (e.g. using the browser's "Open in new window" option). But perhaps new users could see a warning message when accessing another tab from the edit window, saying that they will have to use the "Back" button in their browser to get back to editing - and that message could be dismissable once you've learnt. --Kotniski (talk) 15:28, 27 May 2009 (UTC)
That's true up to a point about it mainly being the edit window as far as my example goes; however, consider: once you click "discussion", the "discussion" tab is seen to become the active tab, and three other tabs ("edit this page", "history" and "move") are seen to have remained unchanged as inactive tabs. However, far from having remained unchanged, those three have taken on new meanings and will invoke new actions. This further demonstrates that the tab metaphor is not helping, and that the list of available choices ought to change according to the current action. As to the need to access the article while editing, yes, but that could perhaps be better accomplished by starting the edit itself in the new tab/window. No warning would then be needed. PL290 (talk) 18:32, 27 May 2009 (UTC)

Suggestions for the Go/Search box

The as-you-type feedback in the Go/Search box may be the greatest improvement to the WP interface in years. Here are some suggestions to make it more useful to WP editors:

  1. Make the displayed list a bit longer, say 20 entries instead of 10.
  2. On my Firefox browser, the feedback pop-up only shows 7 of the 10 lines; I must scroll to see the other 3. I couldn't figure out how to change its size. So, if that is under WP control, please make the feedback popup window taller. If space is the issue, consider moving the Go/Search box further up.
  3. To help editors, please distinguish real articles from redirects in the feedback list (e.g. by italic, bold, color, or a '#' suffix.) Better yet, show the target of redirects, e.g.
    natrium
      → sodium
    This feature could be a user profile option, and/or enabled only while editing an article.
  4. Provide somehow a way to pick one of the feedback lines and paste it into the edit window, with [[..]] markup, instead of jumping to that page.

All the best, --Jorge Stolfi (talk) 07:47, 17 May 2009 (UTC)

I will agree that the current MWsuggest feature is rather primitive. As for your points:
  1. This would increase server load. But, of course, there's WP:DWAP.
  2. The search portlet panel is not going to be moved, I believe, judging by earlier discussions. The rationale behind the choice of its height is mysterious.
  3. Redirects should be italicised, like at Special:AllPages. Showing of the target would be cool, but what about things like Thick-film dialectric electroluminescent technology → Thick-film dielectric electroluminescent technology?
  4. Why?
— This, that, and the other [talk] 07:57, 23 May 2009 (UTC)
If you want to edit the search box, make more results, ect, why not just make a userscript? If you want to publcize it, you can put it in Wikipedia's user script gallery. ⊕Assasin Joe talk 22:42, 26 May 2009 (UTC)
4. Why? Because usually when I find an entry there I would like to open it in a new tab. I have my browser (Firefox 3.0.10 on Windows/XP) set up to open links in a new tab when I right-click, but that doesn't work with this drop-down list. Copying the link to the clipboard would be a second-best choice to enable me to do this. Phil Bridger (talk) 20:12, 28 May 2009 (UTC)

As defined by wiki markup at least, the Lead is not a "section", but some text that appears at the top of the article. This excludes the Lead from having an edit link auto-generated. It would though be beneficial to at least have the option to edit the Lead section in isolation, just like any other section. Benefits include fewer edit conflicts, particularly for large, frequently edited articles or during periods of heavy editing by collaborating editors. PL290 (talk) 10:51, 28 May 2009 (UTC)

Special:Preferences → Gadgets → MediaWiki:Gadget-edittop. Amalthea 10:56, 28 May 2009 (UTC)
If you go to Special:Preferences, and look at the "Gadgets" tab, you'll see an option under "User interface gadgets" that provides just such a link. It is (currently) the third line down, "Add an [edit] link for the lead section of a page". Hope this helps. --Ckatzchatspy 10:59, 28 May 2009 (UTC)

Marvellous—thank you both—then I guess the proposal changes to "make that the default preference setting". PL290 (talk) 11:02, 28 May 2009 (UTC)

I enabled that after two weeks of editing, and I still click on it when I mean to edit the whole page and not just the lead. - Jarry1250 (t, c) 11:11, 28 May 2009 (UTC)
Yes, I do see that's a potential issue; one, in my opinion, compounded by "edit this page" being far away, and appearing to be a tab, per the #Tabs at top of page discussion. Compounded also by what might be termed the Lead's "sectional ambiguity": hierarchically, the Lead is the start of the article and does include all the other sections, yet it's convenient to think of it as a section for some purposes. I'd have thought the gadget, being specific to the Lead, could be tweaked quite easily to add both links in close proximity (edit Lead and edit page) so you see them both at the same time and are more likely to click the right one.PL290 (talk) 11:48, 28 May 2009 (UTC)
  • FWIW, this is the reason it's not default - it's still not working very efficiently, and gets snarled up in the page rendering sometimes. It's on the development to-do list, though. Shimgray | talk | 00:26, 29 May 2009 (UTC)

Watchlist improvements

Hello,

Was directed here a few days ago to suggest my improvement.

Currently i have about 200 to 300 pages on my watchlist and each day i can be seeing about 50-100 changes. My suggestion is to make grouping so says for this wikipedia pages you get a collapse menu that shows all wikipedia related items, then you have project pages etc etc, and maybe customised caterogies as well.

This would mean oyu could say have 20 caterogies and then you can see how many changes are in each and you can look through smaller samutn without missing stuff.

A better example is i was offlien for 3 days and it took me 6 hours to work out what had changed and what i had to restore back etc.

Anyway if oyu need mroe information i will let you know.--Andrewcrawford (talk) 19:54, 28 May 2009 (UTC)

To summarise the numerous debates we've had on this topic: it's technically unfeasible for now. The watchlist code is still far too hackish, and yet to be improved to a standard whence it can be improved upon. Sorry. - Jarry1250 (t, c) 20:02, 28 May 2009 (UTC)
Fair enough, thanks for the reply i hope in the future something like the feature i have said can be implamented as it make editors life much easier esicpally if oyu watch a lot of pages. Thanks again :)--Andrewcrawford (talk) 20:09, 28 May 2009 (UTC)
Its not really "hackish", just inflexible. It works great for what it does now, but almost every feature request for watchlists would require either additions to or a total redesign of the database table for watchlists. Mr.Z-man 20:21, 28 May 2009 (UTC)
Andrew, you might want to test out the script "WikiWatch", which organizes watchlist entries into categories. The project page says it is not under active development at present, but it may be worth a test. --Ckatzchatspy 20:31, 28 May 2009 (UTC)
Thanks ckatz that seems to be what i am looking for, unfortnally i will need to muck about to find out hwo to use it since the pages does not say--Andy t c 20:51, 28 May 2009 (UTC)
No problem... I was going to offer to install it for you, but then saw that you've already done so. (FYI, the "Lightmouse" script for date delinking is the subject of an injunction against its use at the present time.) Best of luck, and feel free to ask if you have more questions. --Ckatzchatspy 20:56, 28 May 2009 (UTC)
To be honest teh date delinking script does not work for me at all, but thanks for the heads up--Andy Chat c 20:59, 28 May 2009 (UTC)

undent. If anyone like me finds the Cacycle/wikiWatch script runs too long, an alternative is to create a set of bookmarks (or wikilinks on your user page) to specific namespace watchlists like these:

My watchlist has 1,322 pages and I found I was missing many changes buried among all the article changes. 84user (talk) 02:07, 29 May 2009 (UTC)

Disabling "create a book"

Per the early results of the usability study (ctrl-f "Creating a New Article") and the reported "mess" [7] [8] at CSD that is the result of this usability issue, I propose we disable this additional section, until a more usable alternative is created/proposed. —TheDJ (talk • contribs) 20:41, 6 May 2009 (UTC)

Have a look at User:Zetawoof/BadBooks also. I've been going through these for a while. It's full of crap. Good stuff too, yes, but mostly crap. DS (talk) 20:43, 6 May 2009 (UTC)
I fully agree with you. Our "books" section has nothing to do with building an encyclopedia and everything to do with financial gain. The section is totally divorced from the mission of building a better encyclopedia and only commited to selling the better encyclopedia; selling free content. This was ill thought-out and poorly implemented from the top-down with little to no opinion from the community whether we wanted this feature and whether we support the Wikimedia-PediaPress financial partnership. Wikipedia isn't a vehicle for advertising, neither from its users or its parent corporation. The resulting mess of this uncoordinated and poorly thought out plan to make a quick buck is a total shame to the mission of building a neutral, verifiable encyclopedia. As a user-built encyclopedia we have the final say in this matter and I think there's sufficient evidence to show that the "create a book" feature, the "books" namespace, and the thinly disguised marketing propaganda that goes with it have no place here. ThemFromSpace 22:31, 6 May 2009 (UTC)
This is not about the books functionality, it is about the placement of some of the Books tools. —TheDJ (talk • contribs) 23:51, 6 May 2009 (UTC)
I might support temporarily disabling the feature for usability reasons, but strongly disagree with the anti-corporatism of Themfromspace - the feature provides downloadable PDFs for free, and printing articles is critical for getting them into the hands of people without Internet access. But let's not polarize this discussion and stick to the issues. Dcoetzee 23:08, 6 May 2009 (UTC)
Mmm. I've nothing against the PDF-creation thing per se, but the implementation we have of it just now does seem to be actively counterproductive in a way we didn't anticipate. Shimgray | talk | 23:13, 6 May 2009 (UTC)
I love the PDF generation myself. That link (which is in the toolbox and not in the "create a book" section. can stay as far as I am concerned. —TheDJ (talk • contribs) 23:51, 6 May 2009 (UTC)
If you're taking about the "Add wiki page" link, it's already been changed to "Add page to book" in SVN. --brion (talk) 23:52, 6 May 2009 (UTC)
As far as I am concerned, we are talking about the entire "p-coll-create_a_book". It's a lot of extra material with little gain to a small set of users, and confusing to a large group of users to boot. Like has been suggested before, It's better as a Gadget or something. I don't believe the group of users that is affected by this problem is gonna be helped with "Add page to book", I have doubt in their ability to differentiate between Wikipedia and "a book", they might think wikipedia IS a type of book. —TheDJ (talk • contribs) 00:02, 7 May 2009 (UTC)
I honestly have no clue what the hell the "create a book" stuff did. It got rolled out while I was on a wikibreak, near as I can tell. EVula // talk // ☯ // 03:22, 7 May 2009 (UTC)
Support. Let's not pollute the sidebar beyond the mess that it already is. This needs to be thrown into special pages. –MT 03:33, 7 May 2009 (UTC)
Pretty much the first thing I did after seeing this development was to hide it in my CSS. I love the functionality to generate PDFs of articles. I support having the functionality available, and I'm neutral about WMF and other companies profiting from it. I see absolutely no reason why it needs to be flashed in the sidebar for every logged-in user. If people want to access Special:Book, let them either know where to look for it, or to find it through an appropriate introductory page (Wikipedia:Books or Help:Books) that explains what the hell this confusing feature is and how to use it properly. Happy‑melon 10:49, 7 May 2009 (UTC)
Yes, please. The list I created, which currently contains only books which contain less than two articles, or which contain only project-space pages, currently encompasses over a thousand books. This amounts for well over 50% of all created books — it's clear that a lot of users are misunderstanding what the Books feature is for. One or more of the following things needs to happen:
  • The Book sidebar needs to be either deemphasized heavily, or hidden until users start the process of creating a book by explicitly visiting Special:Book. As the usability study noted, the current verbiage suggests that this is the correct process to create a new page with. Either it needs to be made even clearer how pages are created, or this feature needs to be toned down a lot.
  • The "Books" feature should be renamed back to its internal name of "Collections". A lot of users are ending up under the impression that the Books feature is used to write books, and appear to become confused when adding chapters doesn't give them any way to edit those chapters (because, of course, that isn't how the books feature works). A link to Wikibooks ("If you're trying to write a new book, go here instead") wouldn't be out of place either.
  • Logged-out users should not be prompted to create an account to save books. The PediaPress integration can still function correctly without saving a book, so there's no need to invite a user to save a book which (in all likelihood) won't be useful to us.
  • As I've mentioned elsewhere, it's much harder (in terms of process) for us to delete a "junk" book in userspace than it is for a user to drop by and create one. This should probably be rectified.
Zetawoof(ζ) 11:03, 7 May 2009 (UTC)
I think part of the reason for the bad usability is that we've always made it relatively difficult to create new articles. This is purported to serve a purpose, like avoiding orphaned pages, but I think it's counterproductive. Why not just have a "Create a new article" link in the sidebar? For the books feature, I'd suggest a wording like "Combine articles into a book." Dcoetzee 11:41, 7 May 2009 (UTC)
Did you see the part above where I said it's already been changed? Thanks. --brion (talk) 16:33, 7 May 2009 (UTC)

I like the idea of renaming it "Collections". Seems much more accurate and helpful. Rd232 talk 03:49, 8 May 2009 (UTC)

  • We have *waisted* thousands of hours of volunteer's time for the maintenance of this system, for very little benefit to Wikipedia. I think we definitely need some additional restrictive measures, for example:
  • Users who are not autoconfirmed are not allowed to store books in project space through Special:Book, I think we should also apply this for userspace. There's no benefit in allowing inexperienced users to create books in userspace, the vast majority of books created by them are tests or inappropriate (including a vast amount of blpvios and copyvios).
  • Do not allow to create a book with only one page. Cenarium (talk) 13:44, 9 May 2009 (UTC)

So it is a problem

OK, I see that a significant amount of people share the same feeling here. Now to do something constructive. The question becomes what... If we disable this element in CSS, than basically the whole books functionality ceases to function. That is a rather drastic and dramatic move that I would rather try to avoid. I propose therefore we request the following changes to the devs:

  1. The books/collections sidebar becomes disabled by default
  2. A link is added to the toolbox (alla Cite this page) to Special:Books
  3. When you visit Special:Books, you can ENABLE the sidebar for books (would be ideal trough a persistent preference option, but otherwise can be done with JS and a cookie).

This would make this entire functionality much more lean and mean in my opinion. I will post a request in bugzilla for these changes to be implemented. If this takes to long, then we can request the extension be disabled, or we ourselves change the CSS to hide the books sidebar, until this functionality is implemented. I think this would significantly avoid many of the problems we discussed above. A good idea? —TheDJ (talk • contribs) 20:05, 9 May 2009 (UTC)

  • Support turning off the sidebar. Already in special pages, is poorly understood, and causes too much needless work. Also support turning it back on again, but this is much less important –MT 01:11, 10 May 2009 (UTC)
  • Support This way it won't utterly confuse readers and inexperienced users. Anonymous and logged-in users can choose to enable it for the session. For logged-in users, we could also have an option in preferences (or even accessible from Special:Book) to enable it indefinitely. Cenarium (talk) 19:17, 10 May 2009 (UTC)
  • Support... all we really need is for an extra class to be added to the books sidebar when the user actually has books in their collection. That way, we can trivially hide the toolbar until a user activates the system through Special:Book directly. The preference option should also be added - should be easier with the new preferences - documented at Special:Book as you say. We can add the toolbox link ourselves. I also think we should hide the toolbox for the time being; that would put huge pressure on Pediapress to implement the requested features with urgency. Happy‑melon 19:36, 10 May 2009 (UTC)
I've been hiding the books sidebar for a while using javascript User:M/monobook.js - might save you some time. –MT 23:29, 10 May 2009 (UTC)
  • Oppose - instead I propose to collect and discuss ideas how the usability could be increased and implement them. Regarding above issues:
    • The confusion found during the usability study was fixed by Brion who altered the label (see above)
    • Stored books can only be created by autoconfirmed users for some time now (as a result of the CSD discussions linked at the top of this thread).
I don't see the requirement for any expeditious actions. We don't shutdown Wikipedia because it currently misses add/delete-page buttons (which seems to be the problem in the first place with above issues), do we? --He!ko (talk) 13:04, 11 May 2009 (UTC)
Please note that He!ko is managing director of Pediapress (ref) and has made no or few edits outside this topic. Cenarium (talk) 15:08, 11 May 2009 (UTC)
Please note that our concerns are not limited to the "label" of the one option, as stated above. The usability study, simply confirmed ONE of the concerns that several editors have had since the extension was enabled. I have felt a growing annoyance of this extra sidebar among the editors. We see a problem, and we want to fix it. I appreciate the work that you and your company have done for this extension Heiko, but for the English Wikipedia, it is "Yet Another (non-critical) Function", and to boot one that rather suddenly appeared in our sidebox. Our standards as editors are high, and increasingly more so. If people don't want to wait a month for this to be fixed, but rather act now, then we can surely consider this. (Note that we are also discussing a new link for users to create articles, as well as pondering about ideas to work on the Search results page from our side. All points that have come out of the usability study. —TheDJ (talk • contribs) 18:47, 11 May 2009 (UTC)
Disabling the little toolbox if you find it annoying is already trivial, and creating a gadget to do so would make it even easier. As per the below, I'm in favor of exploring an alternative UI, but you're arguing for disabling the feature entirely until certain conditions are met, which, given the actual scope of the problems, seems like a strong overreaction -- especially considering how many useful books have already been created using this feature.
What I'm suggesting is that we try to develop a consensus on the UI and book creation workflow before there's a roll-out to logged out users; I assume there wouldn't be any problem rolling out the "PDF version" link to all users at this time.--Eloquence* 01:43, 12 May 2009 (UTC)
  • Oppose. To recap:
  1. The label "Add wiki page" has already been renamed in SVN to "Add page to book" as a result of the user testing.
  2. Books-created in user space are automatically tagged with noindex to exclude them from search engines
  3. Books can only be created in Wikipedia: space by autoconfirmed users.
  4. The discussion regarding CSD does not indicate that everyone actually feels that test books in user space are a problem: some people do, some people don't.
  5. Hundreds of useful books have been created using this feature: clearly it is something that users want to be able to experiment with.
It doesn't therefore seem reasonable to me to want to disable the feature right now, based on a small discussion with a handful of people. That being said, I'm in favor of having a constructive conversation about the usability and workflow of the book feature. I propose targeting the following functional changes:
  1. Have an explicitly toggled "Create a book" mode which, once activated, can be as prominent in the UI as it needs to be, and which is activated with a single link in the sidebar. (This is similar to the suggestion above, except that it wouldn't require an additional page visit.) That would save the space in the navigation bar currently occupied by the book-box, which may not be of interest to many users. (It's currently only shown to logged in users anyway.)
  2. Add an "internal save" function which doesn't create pages. Deprecate the current user-space book feature.
  3. Continue to allow sharing in the Wikipedia: namespace for autoconfirmed users.
The disadvantage of this approach is that it would deprive us of useful books created by new users. In the longer term, we could have a "Submit for review" feature, or some other form of semi-public sharing which doesn't create pages, to allow new/anonymous users to submit their book suggestions.
These are changes we can target over the coming weeks, but I don't see any emergency that would require the feature to be immediately disabled.--Eloquence* 18:24, 11 May 2009 (UTC)
Zetawoof mentions that this feature has caused over 1000 junk books to be created, well over 50% of books. How is cleanup being handled? What process was used to establish a need to add that sidebar to the Wikipedia interface?   M  01:21, 13 May 2009 (UTC)
I've suggested a path going forward above. As regards what has happened so far, I simply disagree that what you're describing is a problem. We're talking about pages in userspace that are already automatically tagged with no-index. They're not in the normal path of a reader's Wikipedia experience. If you feel compelled to clean them up, you're free to do so, but nobody forces you to do it, and it doesn't present a significant advantage to Wikipedia's utility to do it. I acknowledge the argument that a different type of save operation that doesn't create perceived clutter is desirable: hence my suggestion for an internal save feature. But let's not overstate something that's a minor nuisance at worst, while completely omitting the actual utility and value of the functionality we're talking about.--Eloquence* 01:45, 13 May 2009 (UTC)
The fact that only pediapress and the foundation are defending this sidebar so far, does say something however. I have not yet removed the sidebar, partly, because doing so would cause our 30 day cache for CSS to hamper our ability to instantly reinstate it. If we don't have to wait months for this to be fixed, then we can probably live with it for a while longer. —TheDJ (talk • contribs) 02:14, 13 May 2009 (UTC)
It's probably well over 50%, actually. The 1000/50% figure is just counting books which can be automatically identified as lacking content - there are probably a lot more test books that manage to squeak above the barrier (by, for instance, including two random articles) but which still don't have any useful content. Zetawoof(ζ) 21:45, 13 May 2009 (UTC)
The only reason those pages are noindexed is because I added the noindex template to {{saved book}}, due to the relatively high number of spam, blpvios and copyvios this system generates, but users generally remove content while editing the "book", and can very well remove the template {{saved book}} or the category, thus the page is no longer noindexed or traceable. The only way to reliably track those pages would be to parse the database for user pages containing the string /books/... So again, more work for us (we ought not to let that kind of pages hang around). Test pages in userspace are generally allowed, so test books are not the major problem, it's when they are edited to become something else. Aside from inappropriate pages, maybe even worse happens: we loose potential articles here (I also modified {{saved book}} to try to direct new users to the introduction to editing, but quite inefficient, as some users do it several times).
Changing 'add wiki page" to "add page to book" will not solve the usability problem. Most users will still believe that's just a funny way to say create a new article, or just don't get what is meant. The term book in this sense is very unnatural. Of course, some 'useful' books have been created, when you have a new tool, you want to experiment it. But we've got more problems than positive results so far; this effect to confuse users is dramatic, it can only diminish the chances for them to edit articles or successfully create ones. Not at a single point in the process, it is explained how it works, just a link to the help page is given, and as usual, only a few will click it.
To be more successful, you need to give a good explanation of the feature to users before letting them play with it. So you'd need to link to Special:Book, in a toggle named to something like "make a collection of articles"; as "create a book" would only confuse users. But simply activating the interface on one click would still cause the same problems, you need to explain the feature beforehand at Special:Book, than let it be activated. An internal save may be better in some regards, but we have to consider the server resources it will take, and what other components will suffer from it. We already regularly have watchlist or log lags, most serious recent example here, I'd prefer not to put a new strain on the servers for that. In the mean time, the right course of action seems to deactivate this non-critical feature, until the usability problems are solved. I don't see why we should give high priority to a feature that would be used by probably less than 1 out of 10.000 users, which introduces right now usability problems affecting many more; while we have in parallel software requests on which the community finally agreed upon, aimed to address critical issues for which the WMF said to be firmly engaged, that are visibly given lower priority. Cenarium (talk) 23:28, 13 May 2009 (UTC)
  • Support turning off the sidebar. Hopefully later we can have a centralized discussion on the books feature as a whole, but anything done to keep this as separate from the rest of Wikipedia as possible is a plus. As of now, since what is written in the books may not correspond to our policies and guidelines its presense in the toolbar is deceptive. ThemFromSpace 02:27, 13 May 2009 (UTC)
  • I have a little experience here, I was aware of this project, and I think it a good one. Yet the implementation confused me. I have relieved to find that others feel similarly. "Create a book" does not by itself have a very obvious meaning--this needs to be done properly. It should be immediately disabled until it can be implemented in a tested manner. DGG (talk) 06:07, 13 May 2009 (UTC)
  • So currently the proposal (to hide the "create a book" sidebar box with CSS for the time being, until the feature can be reimplemented in a more user-friendly and less disruptive manner) has the support of six editors and opposition from the managing director of PediaPress and the Foundation's Deputy Director (both in their capacity as editors, AFAIK). I'm going to spam this discussion elsewhere for more input. Happy‑melon 17:21, 13 May 2009 (UTC)
  • Support. Really, really bad idea, and if for some reason the opposition picks up strength, I'll go into detail. - Dank (push to talk) 17:31, 13 May 2009 (UTC)
  • Support turning off the side bar. Frankly, I don't see the point of the function at all, but at the very least it shouldn't be in a side bar. The WP definition of book is not the same as the normal definition so having a "create a book" link is bound to lead to massively confusion (and has.) --ThaddeusB (talk) 17:38, 13 May 2009 (UTC)
  • Support removing the sidebar. There needs to be more discussion on books, including specific style, guidelines, policies, etc. I don't think most users even know what they are. hmwithτ 18:00, 13 May 2009 (UTC)
  • Oppose per arguments above. Griffinofwales (talk) 18:13, 13 May 2009 (UTC)
  • I'm still interested in knowing more about how this feature was implemented, and how we managed to miss that this would be a problem for users and editors. (Incidentally, I turned this back on in my .js, and the first thing I did was accidentally 'add a page to book'. I expected some sort of complicated submission/confirmation page, like much of the rest of the wikipedia interface.)   M  18:16, 13 May 2009 (UTC)
  • Support - Unlike the simple PDF download link, the "Book" feature seems rather poorly executed and is of only marginal utility on Wikipedia. I'm not convinced that it warrants a spot in the sidebar. There needs to be a lot more documentation on how the system works. Looking at a random sample of 15 books in userspace, all but 3 seemed to be either test pages or spam. Hundreds of books have been created, how useful any of them are is questionable. Changing the label is not going to magically fix all the confusion. Just because they won't show up on external search results is no reason to allow userspace to be an unmonitored dumping ground for spam and other garbage - WP:NOT#WEBHOST still applies. Mr.Z-man 18:27, 13 May 2009 (UTC)
    "Hundreds of books"? Thousands, actually. There are around 2200 pages transcluding {{saved book}} right now, plus a bunch more which have already been deleted. Zetawoof(ζ) 21:45, 13 May 2009 (UTC)
  • Support per above. --Kbdank71 19:06, 13 May 2009 (UTC)
  • Support, per my comments above and elsewhere. There might be a good idea in the Books system, but the current implementation is incredibly confusing and practically invites misuse. Zetawoof(ζ) 21:45, 13 May 2009 (UTC)
  • Support We need to better think how to use this tool to help build an encyclopedia and not just throw it out there without any guidance. Chillum 01:39, 14 May 2009 (UTC)
  • Support, I'm sure that there's a use for this tool, but as alluded to above, it hasn't actually been discovered yet. Lets have a think about how the Books tool can be used, and if a good reason is brought up, then we can add it back in at a later date. Lankiveil (speak to me) 08:40, 14 May 2009 (UTC).

This consensus seems indisputable to me. I have therefore hidden the sidebar box. Now we can start to think about what actually needs to be done before we're willing to reenable the feature. I think it's fair to say that the PediaPress tech team will give whatever we request their full attention :D </evil laugh> Happy‑melon 09:08, 14 May 2009 (UTC)

I have added caution banners to related pages. —TheDJ (talk • contribs) 12:46, 14 May 2009 (UTC)
I'm coming in rather late to this but I'd like to add my request. For our private wiki, we'd really like the PDF functionality, don't want the book functionality. I saw several people above expressing similar sentiments. Can we not have a PDF only version for Wikipedia? --Robinson weijman (talk) 19:56, 14 May 2009 (UTC)
  • I'm coming in late, too, but I support the hiding of this tool in the sidebar. It was sprung on us without any real discussion (so fast that the Userpage was deleted as a G11 when it was first created) and the function is poorly understood. Protonk (talk) 21:16, 14 May 2009 (UTC)

Moving forward

Ok, so we have hidden the sidebar, and now have some breathing-space. How do we proceed? What needs to change? How does the feature need to be improved? End straw poll, start new discussion.

I for one think that TheDJ is on the right track with saying the feature should have to be 'activated' through Special:Book before appearing in the sidebar. I also second Robinson weijman's request above to separate the per-page PDF renderer from the book interface proper. Thoughts? Happy‑melon 21:23, 14 May 2009 (UTC)

Agree with the PDF point. We could use a brief explanation in this section about how the books feature currently works. (Incidentally, does it track by the revision? Because I don't want to see vandalism in a 700 page tome, nor do I want to 'pre-review' it, since this is presumably what I was doing right before I clicked 'add'.) I think that the only time you need to add a page to a book is after you're aware of what a book is, so it should be initially disabled, and possible to enable in prefs (like every other feature) or via a link from its wp page. I think that this was the main concern, and that most people agree on this. A separate issue is how prominent the feature itself should be in the interface. Should we have a link to WP:BOOKS (err-that's not it, what's its wp page?) on every Wikipedia page? I think that the toolbox could use a link to prefs/gadgets, though overall I think the sidebar needs to be substantially reduced. The idea here is that if we moved a few of the gadgets to more prominent locations, we'd see more misuse, since only the more experienced editors tend to find their way into prefs. How much experience is needed to use this feature?   M  22:42, 14 May 2009 (UTC)
I believe in the "release early, release often" principle. So release the PDF version now (since there is little problem with this) and then we can consider what to do with the books. That way, if we do include books, the quality of those books will be better because we'll be doing bug fixing up until that point. And if we don't include books, it'd be a shame to have wasted time discussion the pros and cons of books when people could have used the PDF functionality in the meantime. Let's release PDF now. --Robinson weijman (talk) 14:16, 15 May 2009 (UTC)
Have people lost interest in this? It's been days since anyone has commented here. Release the PDF only version now! --Robinson weijman (talk) 05:48, 19 May 2009 (UTC)
C'mon people - let's make a decision, please. Any objections to PDF only? --Robinson weijman (talk) 05:36, 20 May 2009 (UTC)
It seems reasonable to allow people to make and download PDFs. Leaving cruft in the project namespace or userspace, especially when it's mostly test pages, seems bad. Stifle (talk) 11:58, 20 May 2009 (UTC)

Oh, it seems I've been misunderstanding. I thought what was suggested was to implement the "PDF version" link separately to the whole Collections functionality, so the per-page renderer could be enabled while Special:Book was disabled in software. But actually you want to be able to create collections on Special:Book, and render/download them, but not be able to save them on-wiki? I can see the merit of this approach: ultimately, do we care how many books PediaPress print? No, the only issues are accessibility/usability, and repercussions on-wiki with the buildup of random crappy books. So step 1: ask that the extension be altered to allow saving of books be restricted to arbitrary groups, and request that no such groups be assigned for enwiki. Sensible? Happy‑melon 13:19, 20 May 2009 (UTC)

I would prefer if any registered user were able to save a book (collection) temporary on a pseudo-page (in special: namespase). This page could then expire after some time. This would solve the problem of "crappy" books, while allowing users to have saved versions of their collections, so that they could modify them later (before expiration). Ruslik (talk) 13:37, 20 May 2009 (UTC)
I didn't even know you could save wiki books (whatever that is) on Wikipedia. I just want to be able to download a PDF of a page, a selection of pages or a whole category, as was possible in the book software. And I'd like this as an extension I can download for my own wiki (or included in core MediaWiki code). --Robinson weijman (talk) 19:13, 20 May 2009 (UTC)
I think that is a tad beyond the scope of this discussion. If you want stuff for you own wiki, you are welcome to ask their developers this, or do it yourself of course, but it should not be part of this discussion. —TheDJ (talk • contribs) 20:44, 20 May 2009 (UTC)
Fair point - that's what I meant with "And..." So, I would like PDF downloads for Wikipedia and then I would use it for my own wiki. --Robinson weijman (talk) 20:51, 20 May 2009 (UTC)

Ruslik's got a point. Having books saved as normal page text is the fundamental problem. Let's be honest, does anyone actually think that we're ever going to say "look, readers, at this collection of books we've created for your delectation"?? That sounds like Wikibooks to me. The Collection extension is for personal use, IMO, it's for users to create books that are useful to them. Or is that just my opinion? Thoughts? Happy‑melon 09:24, 22 May 2009 (UTC)

Probably, but on the other hand, it shouldn't be IMPOSSIBLE to share a 'book' either I guess. —TheDJ (talk • contribs) 10:32, 22 May 2009 (UTC)
Can someone please explain why we are talking about books now? Can we not first agree to get PDF functionality running, try that for three months, and then if all goes well restart the book discussion? Why is there a need to release these together? --Robinson weijman (talk) 19:07, 22 May 2009 (UTC)
Now I'm really confused. What do you mean when you say "PDF function"? Do you mean "click a link to view a PDF version of a single page"? If so, this is already available (and active) on enwiki, appearing in the toolbox underneath "permanent link". We've agreed that the software should be modified so that this feature can be made available separately to Special:Book. Or do you mean "construct a list of pages and be able to view a PDF version of the whole ensemble"?? That is a book; the question we're discussing is whether you should be able to 'save' that ensemble and come back to it later, or if it should be discarded when you navigate away from Special:Book. Happy‑melon 15:38, 23 May 2009 (UTC)
I mean the current book PDF functionality: that I can make a PDF from one or more pages, or from a whole category (or any combination). Thanks for the info on single PDF pages - I did not know that. --Robinson weijman (talk) 05:53, 24 May 2009 (UTC)
Then why the heck is the entire Book feature turned off instead of only the Save function? I just want to create a book and save it to my local drive. If the issue is wiki drive space and abandoned books, etc. this should not have stopped my ability to actually make a book for myself to save as a PDF on my own hard drive. Turn off the Save feature, turn the Book feature back on and then continue the discussion... Davealexander (talk) 16:00, 24 May 2009 (UTC)
Because that is not possible with the software as it is currently written. When we have a consensus on what needs to be done, we will get the developers to implement it. The extension is supported by PediaPress, who have quite a strong incentive to get it back up as quickly as possible, but it's not fair to them to bend over backwards to accomodate us when we haven't even decided what we want done. Happy‑melon 17:26, 24 May 2009 (UTC)
Good point, but I think a consensus is emerging. PDF save to hard drive now (how many times have I said this?!) is something everyone agrees on. So let's release this now. Sigh. Sorry to be a pain but I really am quite tired of this endless conversation. --Robinson weijman (talk) 17:42, 24 May 2009 (UTC)
I think you're right, on this aspect at least. T20902 Happy‑melon 17:58, 24 May 2009 (UTC)
So, how can we address the title of "Moving forward"? That is - what next? --Robinson weijman (talk) 14:56, 25 May 2009 (UTC)
Well, we wait until that bug is resolved. If PediaPress want any clickthroughs from us, they'll do it PDQ. Now, when they've made the change I requested, we will be able to assign the right to 'save books to the wiki' to an arbitrary usergroup, if any. We should have a consensus by that point about who, if anyone, should have this permission. Personally, I don't think it's at all useful (books look like this when saved on-wiki), and should be left totally disabled. But that's just MHO; what do others think? Happy‑melon 15:16, 25 May 2009 (UTC)
I don't see too much harm. These seem like... mini-categories or portals? I do think that they might help for organizing certain topics. It would be nice to see some progress here. At the very least they could release a gadget that people could enable to turn things back on using js.   M  17:50, 25 May 2009 (UTC)

We can disable saving in the user namespace altogether, and allow it in the project: namespace for autoconfirmed users. That should limit shared books to stuff created by bona fide community members.--Eloquence* 19:41, 27 May 2009 (UTC)

A bit off-topic, but relevant to the PediaPress issue is that Render PDF and Preview/Order a Book produce two VERY different items. The PDF rendering is extremely inferior to the PediaPress rendering. The PDF rendering does not give true paragraph break lines; the paragraphs sort of run together and look like a solid page of words. The PediaPress Book setting gives you a full and complete Table of Contents AND an auto-generated Index while PDF does not. Why the difference? Just because I want to print it on my desktop printer instead of pay PediaPress I get an inferior file? I think the rendering of a PDF should be the same for both methods.Davealexander (talk) 19:36, 25 May 2009 (UTC)

That's something you'll need to add to the bugzilla. Stifle (talk) 14:53, 28 May 2009 (UTC)
I'm not convinced that this is the case: the results from clicking the "PDF version" for a random article, verses creating a book with that article and then rendering it, seem identical to me. Can you show some specific examples? Happy‑melon 15:36, 28 May 2009 (UTC)
You can see the differences at a web page I made -- http://www.transactual.com/bookvspdf.html I think the real issue I am trying to raise is this: Am I correct in assuming (and I am assuming here) that PediaPress created both the PDF rendering and Book rendering modules and disabled some of the features for the standard PDF rendering so that if you want an index or table of contents (or prettier fonts or nicer spacing or footnotes at the bottom of each page instead of crammed at the end -- and there are a lot more examples of how these two documents differ) you have to buy their physical book? That's how it appears to me. You cannot save their book rendering to your local drive. All you can do is preview it -- and then purchase it.Davealexander (talk) 02:57, 29 May 2009 (UTC)
I have to say I'm not seeing them. The collection renderer doesn't generate a book ToC or index when the book has only one page either. I think it's the same engine, it would be silly for them to have written two separate renderers for the same task. And you can download and save the collection render in exacly the same way as the per-page view: it's even served from the same directory system. The real test is to compare a per-page view with a collection render for a collection that only contains that same one page; when I did that, I couldn't distinguish between the two PDFs. Happy‑melon 10:15, 29 May 2009 (UTC)
The pages I showed on the web page were from the collection render and the PDF render, both from a collection with 23 pages. The PDF collection render did not generate an index or TOC while the book render did. I think it's silly, too. But they are doing it.Davealexander (talk) 23:58, 29 May 2009 (UTC)
Look at that web link above again. I added a couple of pages at the end. My point is that it is definitely not the same rendering engine.Davealexander (talk) 00:43, 30 May 2009 (UTC)

Note that you can still render or order printouts of books already created; you just can't create new books at the moment. Stifle (talk) 14:53, 28 May 2009 (UTC)

I can still create, render, save and send books to be printed from my user page. You just can't do it when you're not logged in and it's gone from the left nav boxes.Davealexander (talk) 02:40, 29 May 2009 (UTC)

Suggestion for wikilink syntax: trimming the article name

There are many articles with qualified names, such as "English language" or "pipe (computer science)". To link to those articles within normal text, one must usually type the first part of the name twice, e.g. [[pipe (computer science)|pipe]]. So, why not provide wikilink syntax to display only a prefix of the article's full name, e.g. [[Pipe|| (computer science)]] or [[pipe[ (computer science)]]]. The last form could be extended to allow replacement of middle parts, e.g. [[Pierre [Edouard Leopold|E. L.] Verger]] that links to "Pierre Edouard Leopold Verger" but displays as "Pierre E. L. Verger".
All the best, --Jorge Stolfi (talk) 08:16, 17 May 2009 (UTC)

Did you know that you can just type [[pipe (computer science)|]] and it automatically converts to [[pipe (computer science)|pipe]], without you having to type anything twice? That appears to be what you're looking for. ╟─TreasuryTag►contribs─╢ 08:27, 17 May 2009 (UTC)
Just for future reference, it is called the Pipe trick. Mark Hurd (talk) 05:18, 22 May 2009 (UTC)
You know, I proposed this also when I was a newbie. Maybe it needs to be publicised better. — This, that, and the other [talk] 08:13, 23 May 2009 (UTC)
I second that. I've been editing since '05 and only found out about it a month or so ago due to reading an edit summary. --Cybercobra (talk) 01:17, 30 May 2009 (UTC)

Italicise watchlist redirects

Every so often I go through my watchlist (in the "View and edit watchlist" screen) and pick out the things that I don't need to watch anymore. I would find it useful if redirects would show up there in italics, as they do in categories and allpages. It might, in fact, also be useful for redirects to show up in italics on the regular watchlist. Any thoughts? bd2412 T 11:18, 29 May 2009 (UTC)

Try User:Anomie/linkclassifier.js; highlights redirects (among other things) everywhere. Happy‑melon 16:32, 29 May 2009 (UTC)
I imported the code, but it doesn't seem to do anything for me. Am I missing a step? bd2412 T 05:09, 31 May 2009 (UTC)
The script only adds CSS classes to the links; you need to add the appropriate CSS rules to change the display how you want it. For example, to display redirect links in italics: 
A.redirect { font-style:italic; }
I use User:Anomie/linkclassifier.css to turn them green, among other things. Anomie⚔ 05:21, 31 May 2009 (UTC)
Thanks, got it working, and HOLY CRAP is that awesome. Is it just me, or does it slow load time a wee bit? Even if so, worth it! bd2412 T 09:52, 31 May 2009 (UTC)
It'll slow load time slightly just for loading the extra javascript and css, of course. And then the JS does have to go over all the links in the page to extract the linked titles (taking a little CPU time), make a few API calls (1 per every 50 unique internal links, IIRC), and then go through the links again as each API call returns (taking a little CPU time again, plus a little more as the browser updates the rendering based on the newly-added classes). Anomie⚔ 15:22, 31 May 2009 (UTC)

An idea

How about we have a User of the Month or something, as another way to show appreciation for what a particular user has done for Wikipedia. Like if one managed to turn twenty articles from stub-class to good article (just an example though)? I'm not aware of something like this, and I think it's a very good idea. Please support me on the idea. Ross Rhodes (T C) Sign! 20:20, 30 May 2009 (UTC)

No. Why? Because no. ♫ Melodia Chaconne ♫ (talk) 20:53, 30 May 2009 (UTC)
If your saying no, then why? It's a good way of showing appreciation. Ross Rhodes (T C) Sign! 20:54, 30 May 2009 (UTC)
Please see here for why this is such a bad idea. If you want to show your own appreciation of a user, we have a fine collection of barnstars. – iridescent 21:00, 30 May 2009 (UTC)
I suppose. I just thought it was something diffrent. Ross Rhodes (T C) Sign! 21:04, 30 May 2009 (UTC)

Don't be too discouraged, because if you read an earlier section of this discussion page, you can see an idea (supported by Wikipedia co-founder Jimmy Wales and many others) for a Featured Article of the Year. I'm not keen on the idea myself, and presented #an alternative notion, but don't please feel that you're the only one who might see merit in such an idea, or that the idea reflects some kind of ignorance. —— Shakescene (talk) 11:12, 31 May 2009 (UTC)

DISPLAY all edits

Every article should be displayed in its original form, then any changes should be highlighted in color beneath the original article, similar to a blog. If that takes too much bandwidth, or for whatever reason is not possible, changes should be stored, then users should be able to click on a SHOW EDITS link that will then reveal all changes made to an original article, and either the editor and/or their source, and the reason they made the change (such as: "I was an eye witness, thats not the way it happened," or, "I am the subject of this biography, I would know..," or, "Just correcting a typo...") --97.104.242.113 (talk)

Try clicking the "history" tab at the top of the page. For example, this page's history can be foundhere. Dendodge T\C 00:08, 30 May 2009 (UTC)
The 'original' form of a large majority of articles is pretty small compared to their current size. Check out the first edit for Romeo and Juliet for instance. ♫ Melodia Chaconne ♫ (talk) 00:29, 30 May 2009 (UTC)
Short as it is, that is actually the fourth edit to Romeo and Juliet, not the first. Rmhermen (talk) 16:18, 30 May 2009 (UTC)
As pointed out, the page history gives this info. I think the approach suggested is more suited to when the primary intent of the reader is to see that history. Here, the primary intent is to read the "correct" article, with recourse to history and cited sources along the way. Also there would be issues because Wikipedia must remove certain material (material that violates copyright or makes false claims about living persons, to give just two examples) rather than continue to display it in the current version of an article. PL290 (talk) 13:09, 1 June 2009 (UTC)

Calender date on "On this Day" section.

Dear Sir/Ma'am, Do you think it would be possible to add the date from the Islamic Calendar, along with the Jewish one. Islam is the fastest growing religion in the world and I assure you many Muslims log on to your website. Thank you for your cooperation Musa Alami

The "On this Day" section doesn't use the Jewish calendar, it uses the English-speaking standard Gregorian calendar. OrangeDog (talk • edits) 15:23, 31 May 2009 (UTC)
I'm pretty sure he's asking both be added. --Cybercobra (talk) 03:45, 1 June 2009 (UTC)
Hmm, I guess you can read it that way. In that case, where would you draw the line? There's a reason for using an international standard, rather than including any dating scheme you can think of. OrangeDog (talk • edits) 14:36, 1 June 2009 (UTC)
"On this day" is so miscellaneous that it wouldn't really hurt to add even obsolete calendar dates such as Roman (Ab Urba Condita-A.U.C.) and French revolutionary dates. Iranian, Julian and other dates in current use would certainly be reasonable. —— Shakescene (talk) 14:48, 1 June 2009 (UTC)
On a purely practical matter, as the Islamic & Jewish calendars are lunar rather than solar, anniversaries won't fall on the same dates as their Gregorian equivalents (1 June 2009 CE = 7 Jumada al-thani 1430 AH = 9 Sivan 5769 AM, but 1 June 2010 CE = 18 Jumada al-thani 1431 AH = 19 Sivan 5770 AM). – iridescent 15:06, 1 June 2009 (UTC)
So a very rough, purely random and hypothetical parallel in the Christian calendar might be: "Today is the Second Sunday in Lent. On the Second Sunday in Lent of 1737..." when Lent separates the moveable feasts of Ash Wednesday and Easter. (This is not even counting the further complication of Lent starting in different weeks of that particular year in England and Italy.) —— Shakescene (talk) 15:20, 1 June 2009 (UTC)
It just wouldn't work. With On This Day, we're basically saying 'today is X day of Y; on this day in previous years, these things happened...'. You could do it with any ohter calendar, it would just be a completely different list of events. Unless there was a preference or tabbed/chosen way we could implement easily? - Jarry1250 (t, c) 15:26, 1 June 2009 (UTC)

Seeking eyeballs; odd browsers and platforms, especially welcome

This page is loaded from non-wiki text at:

So, I've a change in the works that needs peeking at by a wider audience using all the browsers and platforms.

This url will pull up the /temp page.

The "look" should be identical. The difference involves how the 10 links around the logo work when hovered over. In the currently live page, you have to point at 'English', or another, to click thru to the language specific wiki. In the modified version, the clickable area is a larger rectangle that surrounds the language name, the 'Free Encyclopæa' tagline, and the article count. This is rather friendlier and there are no tooltip on them, too.

The discussion of this is at

Cheers, Jack Merridew 08:49, 31 May 2009 (UTC)

This has gone live so better to compare with:

Cheers, Jack Merridew 06:50, 1 June 2009 (UTC)

An opinion - How can Wikipedia reliability be improved.

Hi all. I've written a blog post about the Wikipedia reliability issue, and what I think can be done to improve it.

My idea has a major technological aspect, but is based on human review, or "Human Computation" if you'd like.

Anyway, the blog post is here: How can Wikipedia improve its content reliability

-- Itai Bar-Haim

The right way to judge the reliability of an article is to read it and look at the sources it uses. Is your idea of creating an arbitrary numerical grading system for every article likely to encourage or discourage editors doing that? Cuddlyable3 (talk) 08:59, 29 May 2009 (UTC)
The numerical grading system is supposed to let readers know how reliable the article is. Currently Wikipedia articles are not reliable enough for use in academic or even elementary school works, simply because teachers cannot trust that information. I suggest a system that will allow users to know just how reliable that article is, by letting people grade its facts. Who the people are? This I will let Wikipedia editors decide. These can be any reader, trusted editors, or both (trusted editors for specific articles, etc.). Currently, even if editors do check reliability of all sources, and make sure that all facts are correct, a user might still read the specific version of the document that is incorrect without knowing that someone just messed it up. I hope this answers your question. --84.228.205.79 (talk) 09:23, 29 May 2009 (UTC)
You never went oy my univeristy or college then, they always say use wikipedia it the most relible thing alive.--Andy Chat c 09:56, 1 June 2009 (UTC)
The problem is that even with a system like what you are suggesting, people will be able to get around it. For example, they might edit an article so as to keep a particular number the same but changing the text surrounding that number (e.g. changing 'The population of Guernsey is 60 000' to 'The population of Jersey is 60 000'). The statement would become false but the software would detect that the number was unchanged and would treat the statement as correct. It would also be possible for malicious people to obtain the necessary rights to become trusted. There is currently no mechanism in Wikipedia to check someone's qualifications so there would still be the opportunity for someone to game the system.
You said 'When ever someone that is not trusted in a certain value or category, changes a fact field, the reliability factor for that fact field decreases.' What that implies to me is that a fact field edited by multiple untrusted editors is more unreliable than a fact field edited by one untrusted editor. Surely you would just need one person to put in a fake number and the fact field would instantly become incorrect. Tra (Talk) 10:19, 29 May 2009 (UTC)
Not to mention, a fact that WAS true can easily change. ♫ Melodia Chaconne ♫ (talk) 11:24, 29 May 2009 (UTC)
This is all true, of course, and I won't argue with that. However, all of those issues are solvable to some extent:
  • Regarding the "changing the text around the numbers", I specifically mentioned there are other types of fact fields, so the entire text surrounding the number can also be marked as fact, and/or make special fields, that include all the relevant terms ("Population", "Guernsey", "60,000" in the above case).
  • Regarding the one untrusted editor that messes up things, versus several untrusted editors that messes up things - it's really all the same and up to the chief editor decision. It can be decided that for a certain value, any change made by an untrusted editor in a fact field would simply mark the entire paragraph/section/article unverified.
  • Regarding a fact that WAS true and was changed - as I wrote in the blog post, the article will be granted lower reliability factor, thus a link to the highest ever reliability factor will appear next to it, and will show you the version of the article with the correct fact. —Preceding unsigned comment added by 84.228.205.79 (talk • contribs)
This sort of system might work better in an environment where the data is stored in a table e.g. a table of populations of countries. That way, it's clear to the user and the software which fact field is which and it would be easier to handle changes to individual numbers. On Wikipedia, even if you end up turning every other word into a fact field, you'll still very often have people rewording entire sentences and paragraphs and messing up the system. Tra (Talk) 13:47, 29 May 2009 (UTC)
I agree, however, to my (very little) experience, most people who make such changes tend to be registered users, that spend quite a lot of time editing values on Wikipedia. After a while, I believe such people can be granted higher reliability, so a lot of work is off-loaded from the chief editor/editors. Again, I don't say this is perfect, but I do think that if done right (and improves with time) this can increase the reliability factor for most articles. I do believe it will bring Wikipedia to a better position than it is today in the area of reliability (currently it basically has nothing...)

Fact fields? What good do they make, say, in Israeli-Arab conflicts? Or a biography? Dates are the same, numbers are the same. NVO (talk) 18:08, 29 May 2009 (UTC)

Biography consists from a set of facts. It can be teared down to many specifics. It has dates, names, numbers, etc. Each such datum can be marked as a fact field. This means that every change in that field would yield a change of fact, which is usually bad, so the reliability factor would decline. And regarding the Israeli-Arab conflicts? Well, nothing gonna help there... (I say that as an Israeli).

OK, let's put it so: increase of reliability is going to require some sort of correction of mistakes in the article text. This proposal does not seem to affect the article text itself in any way, thus it is unlikely to improve reliability of Wikipedia. It is perception of reliability that might change instead. Currently Wikipedia is (hopefully) perceived as "useful, but not reliable". And it does not seem to be obvious that it's actually a bad thing. At least, that way Wikipedia is not very useful for disinformation. Some falsehoods in articles are not that bad as long as no one believes them. But what if Wikipedia was suddenly perceived as reliable..? --Martynas Patasius (talk) 15:41, 30 May 2009 (UTC)

Let me get this straight - you prefer Wikipedia to remain unreliable and be percepted unreliable, instead of making it reliable? The idea I came up with was not a manner of correcting text and rating articles out of the blue as reliable. I keep saying that - trusted editors will still have to verify articles. It's the reader who will at least get to know how verified the article is. Currently he/she just can't tell. -Itai. --84.228.0.40 (talk) 17:51, 30 May 2009 (UTC)
No, not really. I prefer the Wikipedia to continue to be perceived as "useful but unreliable", because, well, it is so. And I still do not see how the current proposal can increase the reliability, thus (as I guess), it will continue to be "useful but unreliable". The only difference is that we would be creating the impression (in some cases completely false) that some statements are "almost reliable". For example, the "fact" that Maurice Gamelin participated in Soviet-Polish war (most likely it is simply the result of confusing him with Weygand) would probably be marked as "almost reliable" by the proposed system (it was added in January of 2006 [9], marked with "citation needed" tag in March of 2008 [10] and removed in May [11])...
And, by the way, the readers can check the facts - they just have to look for relevant sources (in addition, they can find simple vandalism by analysing the article history and talk page). And I doubt that there are any shortcuts to that - as Euclid is said to have told to one king, "There is no royal road to Geometry."... --Martynas Patasius (talk) 19:55, 30 May 2009 (UTC)
The German Wik has a system in which versions of articles are recorded as having been "viewed" by some sort of checkers. Kdammers (talk) 00:31, 31 May 2009 (UTC)
It's called "Flagged Revisions" here and has been under discussion for a long time. See WP:FLAGGED. From a purely technical point of view, it's easy to implement, but only guards against fairly obvious errors. On the other hand, I don't see how we could make Itai's suggestion work at all - both from a technical point of view, but also from an editorial point of view. Wikipedia is mostly flat text with some hyperlinks. There currently is no way of getting such fields into the data base, and I think even writing a good parser for this will be hard. Assume, e.g. a controlled field is copied from the main body into the lede. What happens to its annotation? Which of the two instances gets it? Or do both? What if one of them is subsequently edited? How much to we want to burden editors with extra syntax? --Stephan Schulz (talk) 07:45, 31 May 2009 (UTC)
I share the reservations others have expressed about this proposal, and would add the opinion that a "content reliability factor" is unhelpful applied to the article as a whole. At present Wikipedia makes it abundantly clear that readers, whether or not they actually notice this and take responsibility for it, would need to refer to cited sources to verify facts presented before taking action based on what they read. In my opinion, the proposal would encourage those readers who neglect this to make further superficial judgement by considering only the entire article's "content reliability factor" instead of verifying one particular fact of significance to them. So rather than allowing better decisions it will encourage worse ones. Sorry, but I think the issue is inescapably the flipside of having an "encyclopedia that anyone can edit" and mitigation can only come in the form of generating greater awareness of that. Put a banner at the top of the screen if you want: "Anyone can edit this: check the cited sources before taking any significant action based on what you read here!" PL290 (talk) 12:05, 1 June 2009 (UTC)
Now why would I want to use an encyclopedia that tells me to check its content? I want to use an encyclopedia because I want to know things. If I knew I would also have to re-check those things, I wouldn't use this encyclopedia in the first place. Who guarantees you that whatever written in Britanica or any other printed encyclopedia is 100% correct? The people who wrote it and sell it do their best effort, but that is all you get. It is, of course much better than what Wikipedia offers, because in Wikipedia, ANYONE can edit the content. However, there are people who take Wikipedia seriously. Those people try to make sure whatever written is correct, and fix whatever needs fixing (a best effort, of course). So, if those people are trusted, they can at least mark a version of an article as a "Revised" or "Reviewed" version, which will be the version visible to all new-comers, just like Kdammers said about the German Wik. However, I still stand behind my suggestion that an article reliability factor can be calculated from the reliability factors of all fact fields in it. Then the most reliable version of an article can be presented by default, allowing to see most recent edits, even if the reliability has declined.
And yes, verifying facts is still a job for human beings. These human beings will be trusted authors. When a trusted author will mark a fact (or the entire article, for that matter) as "Reviewed", than this version is considered to be correct, thus any change made to it by an untrusted editor would yield a decline in that fact reliability factor, thus decrease the entire article reliability factor. This would trigger a "Review Request" for trusted authors (or at least get added to a list so any trusted author can see and check/fix), and also (since the article reliability factor was decreased) the new version of the article wouldn't appear by default.
And yes, not every fact written in an article can be verified, but for that discussion was invented, and trusted authors need to agree on such "facts", than "lock" a preferred version using a fact field. This will make sure no one will change it again, and no "ping-pong" will occur.
I also understand that it is quite a burden implementing such a feature. Still I believe it worth it, since it will help the common reader to make better decisions. The common reader really shouldn't care about checking the article correctness by cross-checking references. I really do believe knowing someone else - some trusted - had reviewed it would help a lot.
Itai.
You want a reliability gauge? Write a bot to check periods at the end of sentences against the existence of footnotes at the end of sentences. The more sentences in the article that have a corresponding footnote, the more reliable the score the bot would assign the article. I believe this would be ten times more accurate than your proposal, based on the way fine articles are created and maintained. Fine Wikipedia articles aren't written collaboratively in the sense of numerous people dropping by and making changes until the article becomes good. I have never seen that happen. Not once (I don't think it is possible). No, fine, reliable articles are written by a core group, sometimes just one person, sometimes a few, who organize, focus, do research and cite facts, while writing the main content. When people are interested in a subject, write well, and focus on our core referencing requirements, they tend to get things right because that's what the requirements promote. It's one thing to dash off a line of text from what you think is the case. It's quite another to actually have to find a source to support a particular fact. It also is self-weeding in a sense. Those who are able to source are more likely to be concerned with getting things right. Reliability comes from the reliable sourcing process, and all articles to be considered fine articles must be sourced pretty much in their entirety. Secondarily, when people check those sources, and some indeed do, and it is found they're bullshit, everything gets checked. Once an article is sourced it's watched so crap changes get reverted. And the sourcing also secondarily promotes other polices like neutral point of view. Those articles get more hits and someone comes along and says this is skewed for X reason; then a discussion occurs; there's a fight over which sources to use and third parties intervene and a hopefully balanced compromise is reached, and on and on. So most of the time, an article sourced to its teeth tends to be fairly reliable for many reasons.

Oh, of course there would be articles on each end of a bell curve which this would miss. The rare articles that is extremely reliable but unsourced, and the rare articles that is seemingly impressively sourced, but written by a ponce. But statistically, this would provide a reliability gauge on crude and simple basis that would work far better than having fact fields and trusted reviewing editors and the like, if that was even scalable. I have written numerous articles that no one can fact check except another expert in the same field. You could have ten trusted editors check but they wouldn't know how to evaluate the facts to see if they were reliable. But I don't think we need any such reliability gauge, yours or mine. What we need is to teach people to look for sourcing. Yes, verifiability is inextricably intertwined with the concept of being able to check a source, but the underlying requirement of sourcing itself, most of the time, leads to reliability even if no one actually checks the sources.

Wikipedia articles are not unreliable as compared with other encyclopedias if they are approached with just a touch of common sense and awareness of what sourcing looks like, and what it means. We have almost 3,000,000 articles. Of course tons of them are crap. But tons of them are unsourced. Tons of others are barely sourced. Then there's moderately sourced, and that scale stretches all the way to good articles and at the acme, Featured articles, many of which are as good, and some much better, than any corresponding article in any encyclopedia on the planet. I submit, that we don't need any reliability gauge. We need more well-sourced articles (of course), and we need only to teach people how to recognize sourcing, and that it is fundamental to reliability. We should have a banner framed above every article which says THE BETTER THE SOURCING THE MORE RELIABLE THIS ARTICLE IS LIKELY TO BE. NO SOURCES = PROBABLY, MOSTLY, A CROCK OF SHIT; PLEASE FEEL FREE TO READ BUT PLEASE DON'T TRUST. I'm only half kidding.--Fuhghettaboutit (talk) 20:38, 2 June 2009 (UTC)

Message box categories

I'd like to create categories for organizing message box templates, for example: Category:Article message boxes.

The natural way to do this is to add conditionals like 

<includeonly>{{#ifeq:{{NAMESPACE}}|Template|[[Category:Article message boxes]]}}</includeonly>

to the end of {{ambox}} and its friends.

One category would be created for each message box type.

I don't think this should be controversial, but since it does mean editing a number of high profile protected templates, I thought I'd mention my idea first. If anyone's curious, my immediate motivation for this was the discovery that embeddedin mw:API queries die a violent death when searching for template space uses of {{tmbox}}, presumably because it's scanning a million talk page uses of {{tmbox}} on route to picking out the few template uses. The kind of organization scheme mentioned above would work around my API problem and also provide a resource that might be useful to humans searching for particular message boxes. Dragons flight (talk) 06:57, 3 June 2009 (UTC)

Sounds fine to me. — Martin (MSGJ · talk) 07:32, 3 June 2009 (UTC)
You're gonna pick up every template that transcludes {{high-risk}}, etc, though, into the ombox cat. I agree that it's better than nothing, but it's not going to be completely effective. Happy‑melon 08:47, 3 June 2009 (UTC)
I'm thinking about skipping ombox / mbox actually, between {{high risk}}, {{intricate}}, and a few others, there are a lot of places those are used as messages in template space, and I think the mistagging rate may go over 50%. Dragons flight (talk) 22:30, 3 June 2009 (UTC)

Stupid question, these categories are going to be hidden, correct? --Kbdank71 14:16, 3 June 2009 (UTC)

I don't think that they should, since only the templates themselves will be in the category, not articles, and it could be a convenient navigation system for template coders. –Drilnoth (T • C • L) 14:37, 3 June 2009 (UTC)
Gotcha. See, stupid question.  :) --Kbdank71 14:50, 3 June 2009 (UTC)

Pronunciation/audio pronunciation for main/key entries

Hello All,

The subject line pretty much says it. Many times I've had to search elsewhere for the pronunciation of the medical/technical terms that I mostly look up, and it seems that some requirement for a pronunciation guide for at least (or maybe at most) the main/key entries in an article makes sense. I would very much like the option for an audio pronunciation also but since I don't know at all what that involves software/code -wise, I'll leave the feasibility of that to the experts.

Thanks, Hal

That already exists on some pages. No idea how the audio is created though. --Cybercobra (talk) 21:48, 3 June 2009 (UTC)
See Wikipedia:WikiProject Spoken Wikipedia/Pronunciation task force. ---— Gadget850 (Ed) talk 00:49, 4 June 2009 (UTC)

Proposed enhancements to table sorting (rowspan/colspan support)

Should we implement proposed enhancements to table sorting that support tables containing rowspans and column spans?

Hello all. I've been working quite a bit with tables and noticed that one of the long-standing issues that has been on the table sorting todo list is "don't break on colspans/rowspans (bug 8028)". A recent scan of the article mainspace yields about 1000 articles having tables with broken sorts. (See Broken table sort articles.) I suspect that there are many other articles with tables that would benefit from sort capabilities, but where sorting has not been enabled due to rowspan and colspan issues.

Well. I've taken on the task and have put together an enhanced version of the wikibits sorting algorithm that implements rowspan and colspan support. To summarize, the enhancements do the following.

  1. Before sorting, rowspans will be exploded, so that each row is self contained and can be moved without corrupting the table structure.
  2. During sorting, colspans are recognized and counted when retrieving column values, so that the proper sort value is retrieved from each row. Each column in a colspan range is treated as having the same value. Colspans are preserved – they are not exploded.
  3. After sorting, some cell ranges may be recombined under certain restrictive conditions. In particular, cells that were previously exploded may be recombined. Also, class="autorowspan" may optionally be applied to column headers or the entire table to enable more aggressive rowspan combines, such as combining cells in the newly sorted column that were not originally combined.
  4. Multirow headers containing rowspans and colspans are also supported. Each cell will get its own sort icon. Sort icons may be inhibited from being added to selected header cells by adding class="unsortable" to that cell.
  5. Sort icons in headers that span multiple columns will perform a multi-column sort.

To see a demo of the enhancements, you will need to add the statement importScript('User:Tcncv/sorttables.js'); to your User:Xxx/monobook.js file (or whatever skin you use). Several sample tables are located in User:Tcncv/Table Sort Demo. You can also test your own tables (or those identified in the list referenced above) by copying them to a test page and changing the table class from "wikitable sortable" to "wikitable tsx_sortable" or "wikitable tsx_sortable autorowspan".

I will eventually submit this for formal review by the code gurus in Bugzilla, but I would like to first submit it here for review and comment. In particular, if you see any unexpected behaviors or bugs, or have suggestions for different behavior, please let me know. Also, If you like what you see, please say so, since such interest may influence whether or not these enhancements are accepted and implemented.

Thank you. -- Tcncv (talk) 02:48, 27 May 2009 (UTC)

I loved this when I first saw it and I don't love it less now. Haven't found any bugs yet (but I haven't looked at many tables other than the ones on the test page). —JAO • T • C 12:54, 27 May 2009 (UTC)
I've just looked at some of the samples, and this looks great! I've been wanting something like this for a long time. –Drilnoth (T • C • L) 17:35, 27 May 2009 (UTC)

I'll Take the above responses as two votes of support. -- Tcncv (talk) 00:22, 28 May 2009 (UTC)

Sounds good—I'm installing it now. Dendodge T\C 00:24, 28 May 2009 (UTC)
One minor issue I see is that the first column in the Olympics medal table shows a downward arrow, rather than the correct symbol, when sorted in reverse alphabetical order. Despite that, I love this script, and hope it can be implemented sitewide soon. Dendodge T\C 00:36, 28 May 2009 (UTC)
That was actually a bug in my browser, which I've just realised occurs with all sortable tables. I can find no issues with the script. Full support Dendodge T\C 21:42, 28 May 2009 (UTC)
If you let us know the browser type and version, perhaps we can isolate the problem and possibly include a workaround in a future version of the wikibits script. -- Tcncv (talk) 22:11, 28 May 2009 (UTC)
By "bug", I mean my browser was playing up (FF3, it plays up often), so displayed the alt text of images rather than the images themselves. Sorry for the trouble I caused. Dendodge T\C 22:20, 28 May 2009 (UTC)
OK. It looks like the current implementation will set alt-text to up arrow (↑) and down arrow(↓) but does not have a separate alt-text character for unsorted. I don't see why not. Perhaps the an up/down arrow(↕ or ⇅) would be appropriate. I've tentatively added the second arrow. -- Tcncv (talk) 02:58, 29 May 2009 (UTC)
Should we request that MediaWiki:common.js be altered to include your new code, or do we need more input first? I want this to be implemented as soon as possible, and I see no reasons anybody would oppose this. Dendodge T\C 16:46, 30 May 2009 (UTC)

We may need more input, but we could also make the change and see if there are any complaints (it seems that there's a lot of other things going on on this page, so you'd probably need a thirty-day RFC if we don't just do it now). If the consensus is to implement it now, I could make The Edit if Tcncv can just get it prepared (e.g., so that it uses wikitables rather than the custom classes, etc.) –Drilnoth (T • C • L) 16:53, 30 May 2009 (UTC)

I say we try it out, and set up a "bugs" page somewhere, linked from WP:CENT, where people can report issues they find. I don't see why anyone would oppose this, and see no reason to not give it a go. Dendodge T\C 20:20, 30 May 2009 (UTC)
The sorting code is part of wikibits.js, which I believe is part of the core MediaWiki installation. I believe the procedure for implementing this change is to submit it to Bugzilla as a patch which needs to be reviewed and approved by the development group before being applied. It would them be included in the next MediaWiki update. If we do not want to wait that long, I might be able to adapt it for temporary inclusion in common.js. I would have to have to add code to undo the hooks wikibits adds to the tables before adding hooks for the new functionality. This would be removed once wikibits is updated. This seems kind of klugy, though, and might be better not to rush this through.
An RFC sounds like a goods idea, as it might attract more attention. I might not wait the full 30 days before submitting this to Bugzilla, but I would certainly be interested in any comments and suggestions. In particular, I have a need to have people try this out in different environments, particularly with different browsers such as Opera and Safari. Should I host the RFC here, or move it to another page such as Help talk:Table? -- Tcncv (talk) 00:54, 31 May 2009 (UTC)
Ah; I see. Now why can't admins edit that? :) Anyway, here or Help talk:Table would both seem to work. –Drilnoth (T • C • L) 01:02, 31 May 2009 (UTC)
Okay. I've recast this as an RFC (submitted under the Wikipedia style, referencing, and layout category, since no other category seemed a better fit). -- Tcncv (talk) 04:13, 31 May 2009 (UTC)
For what it's worth, I browse almost exclusively in Opera, so there don't seem to be any compatibility issues there. —JAO • T • C 19:08, 31 May 2009 (UTC)
That's good to know. The more cross browser testing the better. -- Tcncv (talk) 05:54, 6 June 2009 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_47&oldid=1145855535"
pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy