Wikipedia:Village pump (proposals)/Archive 47

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

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)

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

• 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

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)

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)

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:

Edit
Edit - edit the content of this article
Discussion - talk about improving the content of this article with other users
History - display an interactive list of all past versions of this article
(and so on for the rest of the available actions - "Actions"! maybe that would be a good title.)

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)

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
   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. --Ckatz^chat_spy 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.
  talk
  | 00:26, 29 May 2009 (UTC)

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. --Ckatz^chat_spy 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. --Ckatz^chat_spy 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:

• 3 days Article
• 3 days Talk
• 3 days User talk
• 3 days Wikipedia
• 3 days Wikipedia talk
• 28 days File
• 28 days Template
• 28 days Help talk
• 28 days Category
• 28 days Category talk
• 99 days Portal talk

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)

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.

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. --

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. –M^T 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. --

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 –M^T 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 filed bugzilla:18756. Tomorrow I will set the CSS to hide the sidebar. —TheDJ (talk • contribs) 23:20, 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. –M^T 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.--

*

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.--

*

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.--

*

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.

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.--

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.

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.

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)

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 "

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)

• <dumbfounded>Oh.</dumbfounded> --Jorge Stolfi (talk) 16:34, 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)

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)

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

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)

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)

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

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)

• http://www.wikipedia.org/

This page is loaded from non-wiki text at:

• m:Www.wikipedia.org template and tweaks are queued-up at
• m:Www.wikipedia.org template/temp

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.

• http://pruebita.org/cgi-bin/livepreview.py?page=Www.wikipedia.org_template/temp

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

• m:Talk:Www.wikipedia.org template (multiple sections; @bottom)

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

This has gone live so better to compare with:

• http://www.wikiquote.org/ and the others

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

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.

(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.

(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.

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

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)

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.

• {{ambox}} -> Category:Article message boxes
• {{tmbox}} -> Category:Talk message boxes
• {{imbox}} -> Category:File message boxes
• {{cmbox}} -> Category:Category message boxes
• {{ombox}} -> Category:Other message boxes
• {{mbox}} -> Category:Multi-namespace message boxes
• {{fmbox}} -> Category:Footer and header message boxes
• {{dmbox}} -> Category:Disambiguation message boxes
• {{asbox}} -> Category:Stub message boxes

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 {{

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. –

T • C • L

) 14:37, 3 June 2009 (UTC)

Gotcha. See, stupid question.  :) --Kbdank71 14:50, 3 June 2009 (UTC)

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)

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. –

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.) –

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

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)