Wikipedia:Village pump (proposals)/Archive 36

There's currently a plan to create categories for death ages where known, such as this one. I don't have a firm opinion on the matter, but I thought it might be a good idea to discuss it before it gets applied to thousands of biographies. Biruitorul ^Talk 00:54, 29 September 2008 (UTC)

• Thousands? hardly viable. The "plan" calls for rigorous verification, it's not a bot task. Plus consider the amount of editors willing to spare their time on this classification (not me). It may have value, but without a broad editor base it's stillborn. NVO (talk) 19:05, 29 September 2008 (UTC)
  • We can always add it to {{Death date and age}}. I've created {{Deaths by age}} in the meantime. Don't worry, it works. the editorofthewiki (talk/contribs/editor review) 23:55, 29 September 2008 (UTC)
    • I'm not sure about it, but if we start inserting Microformats into biographical articles (which I think we are doing right now), we'll only need an external tool to do the search. That way, we won't need large number of categories that need huge maintenance, nor templates which will overcrowd the code. Eklipse (talk) 09:50, 1 October 2008 (UTC)

I just noticed something on the New York Times website. In any article, double-clicking on a word performs a reference search, and automatically provides a definition of the word in a dictionary, thesaurus, and encyclopedia (all apparently powered by Answers.com).

I think this would significantly enhance the scope and impact of Wikipedia.

If this isn't at perennial proposals, it should be. It probably isn't possible and isn't a good idea. First off, Answers.com isn't open source, as far as I know. Second, how would link to something in a different namespace? How would you pipe links? It's a solution looking for a problem. Paragon¹²³²¹ 16:36, 30 September 2008 (UTC)

To clarify, the Answers.com thing was a description of how the New York Times website works. I'm not sure exactly what the OP is proposing, but it appears to be either a way to double-click on words in Wikipedia articles to get their definition (say on Wiktionary), or a way to double-click on words on other sites to get their Wikipedia article. I don't particularly support either of these. Dcoetzee 18:18, 30 September 2008 (UTC)

You know, while I think this may be a perennial proposal, technically, I don't see why every word shouldn't link to wiktionary. The only point of difference is the presumption of the word "link". The way that the wiktionary links could be shown/presented could be the normal black text (rather than the blue links or ? that we normally would assocoate with a "link"). And, by clicking on the black text of a word, one could go immediately to a wiktionary entry. If anything this might help to greatly reduce dictionary entries here, and increase understanding (not to mention that it would likely inspire increased editing to wiktionary, which would also be a plus : ) - jc37 18:27, 30 September 2008 (UTC)

Wikipedia doesn't use Allwiki. {{Nihiltres|talk|log}} 22:25, 30 September 2008 (UTC)

It's not a bad idea to have a way to jump from words in an article to their Wiktionary entries, but it's difficult to do well - much English text contains phrases, expressions, and idioms that have their own Wiktionary pages and which may be difficult to extract from a stream of English text. I think this would be an interesting thing to experiment with using Javascript or browser add-ons though. Dcoetzee 18:17, 1 October 2008 (UTC)

This could probably be implemented as a JavaScript Gadget. --MZMcBride (talk) 06:01, 1 October 2008 (UTC)

I believe there are many Firefox addons that could do it. Eklipse (talk) 09:42, 1 October 2008 (UTC)

I'd disagree with many, but wikilook does an adequate job, albeit with an initially unintuitive (but sensible) UI, the gesture of highlight and hover is not usually done by accident; yet is simple to do deliberately and allows you to loook up multi-word terms easily. (We have a prototype for looking up double-clicked words in wiktionary itself, but double clicking is done too commonly by accident) Conrad.Irwin (on wikt) 23:16, 1 October 2008 (UTC)

Just as a follow-up, there's a proof of concept here: User:MZMcBride/wordclick.js. I wouldn't import it because it's very beta and will screw up text, but it shows how something like this could be implemented. --MZMcBride (talk) 02:23, 2 October 2008 (UTC)

Next episode below. JackPotte (talk) 23:04, 13 November 2009 (UTC)

In June 2008 the Arbitration Committee announced a request that the English Wikipedia consider allowing some non-administrators the ability to view deleted material. The summary of the announcement was

The activation of the passive "can view deleted" right, and a policy allowing its grant for good cause, would allow non-administrator users to gain wider participation in the English Wikipedia community. For details and discussion, see Wikipedia:Arbitration Committee/June 2008 announcements/Activation of view-deleted-pages

Note that this is a request that the idea be considered, nothing stronger. The announcement led to this proposal. As this conversation has gone on for several months, the proposal has shifted around quite a bit. This makes it very unclear where editors are currently giving their support or opposition. For the sake of clarity, I am attempting to pick out the main proposals, and create a straw poll around them. Please share your opinion at Wikipedia:Village pump (proposals)/Persistent proposals/Straw poll for view-deleted. ~ JohnnyMrNinja 09:05, 26 September 2008 (UTC)

The proposal has been marked as "failed to gain consensus", following a statement by the legal counsel for the Wikimedia Foundation. See the straw poll page for details. -- John Broughton (♫♫) 23:51, 3 October 2008 (UTC)

I would like to put a notification about the "view-deleted" straw poll in the watchlist. My reasoning is that this is a big decision that will affect all users, possibly the way that Wikipedia works, but not everyone reads the noticeboards where I posted messages. Also these noticeboards move rather quickly (especially WP:AN), so this will make sure that more people have a chance to see it. This is the line I would like added -

A poll is now open to determine if non-administrators should be able to view deleted pages. All editors are asked to voice their opinions here.

Thoughts? ~ JohnnyMrNinja 16:26, 27 September 2008 (UTC)

The proposal has been marked as "failed to gain consensus", following a statement by the legal counsel for the Wikimedia Foundation. See the straw poll page for details. -- John Broughton (♫♫) 23:51, 3 October 2008 (UTC)

please see Wikipedia_talk:Did_you_know#A_Couple_of_Suggestions... for more info.

Thanks,

BG7even 08:31, 2 October 2008 (UTC)

• Wikipedia:Village_pump_(policy)#Rollback_option

(I meant to post it here, but I didn't check berforehand what WP:VPP redirects to : )

So, see the discussion there. - jc37 02:47, 4 October 2008 (UTC)

Why do we have duplicate pages here? GO-PCHS-NJROTC ^(Messages) 01:51, 4 October 2008 (UTC)

The "tip of the day" is a rotational list of 365 tips, so you may well see the same tip on August 31, 2009. I'm not sure why there is a 2006 page and also a 2007 page - Wikipedia:Tip of the day/August 31, 2006, but not a Wikipedia:Tip of the day/August 31, 2008 page, but it's really irrelevant - Wikipedia is not a paper encyclopedia, and it actually takes more server resources (not to mention human time) to delete a page than to simply let it exist (ignore it). But if you really, really want to know, and the matter isn't explained at the page Wikipedia:Tip of the day, then ask as Wikipedia talk:Tip of the day. -- John Broughton (♫♫) 13:48, 4 October 2008 (UTC)

I've always loved the idea of the random article button, but it never takes me anywhere interesting. So, I thought it would be awesome if readers would be able to get to a random article within a specific category with similar ease and convenience to just clicking the random article link. If that were to be implemented it would definitely be a feature I would use quite a bit. I'm surprised that no one seems to have proposed it before (or have they?). Abyssal (talk) 17:02, 4 October 2008 (UTC)

For sure it is a good idea, I think software features are meant to be requested on bugzilla and there is already a bug filed for this proposal: Bug 15834.--Commander Keane (talk) 09:19, 5 October 2008 (UTC)

As some might now (though I suspect most don't), user talk pages are no longer indexed thanks to bugzilla:13890. This was cited as the conesnous for that change: Wikipedia:Village pump (proposals)/Archive 25#Stopping search engines from indexing the user talk namespace?

I think I speak for a lot of people when I say what the frak?

We've already got the __NOINDEX__ magic words that let us exclude pages if there's an issue. There's no need for this change and there's a lot of reasons to oppose. -- Ned Scott 02:58, 26 September 2008 (UTC)

• Support indexing as the nominator of this proposal. -- Ned Scott 02:58, 26 September 2008 (UTC)
• Oppose indexing per the inappropriate search results linked at Wikipedia talk:NOINDEX of noticeboards#Noindexing user talk space and other thoughts. Users sometimes post under their real names, and their user talk page may have "is biased editor", "is not notable" strewn all over it, which is not a good look and might harm unrelated people who happen to share the same name. About 99% of the content in the user talk namespace is fine; the other 1% should not be indexed by search engines. The Wikipedia search can be restricted to the user talk namespace like this. I concede that noindexing user talk space is less important than noindexing pages like requests for arbitration, which are much more likely to contain defamatory content. Graham87 03:32, 26 September 2008 (UTC)
  • Removing 100% of user talk pages for the sake of 1% is a really bad idea. Our internal search leaves a lot to be desired, and we can opt out of indexing on a per-page basis thanks to __NOINDEX__. -- Ned Scott 04:23, 26 September 2008 (UTC)
• Support indexing until evidence is presented that Googles access to the user talk namespace is systematically causing harm it should not be hidden, if a user does not want his/her talk page index they can use the "magic word" per Ned Scott. - Icewedge (talk) 05:46, 26 September 2008 (UTC)

• Support indexing, per my reasoning above (repeated here for reference): Having a full and complete searchable index of wikipedia should be the norm, and only in a few cases where demonstrated and repeated harm has come to the project or individuals, and we're unable to contain it with normal editing, should we use sweeping technical measures like this rather than the usual revert and ignore. So, in absence of evidence of concrete harm google indexing of these namespaces has caused, I don't see any reason for a blanket prohibition on indexing. [de-indexing is] a poor technical solution to a social problem. I'm not blindly opposed to de-indexing pages - there are some cases where it can be a practical solution, but I don't think we should do it on a whim and in the absence of demonstrated harm. Wikipedia should be open, warts and all. henrik•talk 08:24, 26 September 2008 (UTC)

• Support freedom of choice: The choice of having userpages/talkpages appear in Google should be up to each individual user, not applied unilaterally to everyone. (In case anyone cares; I have NOINDEX tags on my userpage and talkpage). ~ User:Ameliorate! ^{(with the !) (talk)} 08:52, 26 September 2008 (UTC)

• Oppose indexing (Support noindexing) - Honestly, I'm not sure what the concern is. Is this another round of: "But I wanna use my external search engine"? Or is there something more than this? - jc37 09:27, 26 September 2008 (UTC)
• Oppose indexing - user space creates an area that is largely unmonitored for libel and spam. Indexing it is only asking for problems. --B (talk) 12:54, 26 September 2008 (UTC)
  • What problems? There were no problems that couldn't be solved with our existing tools (blanking and NOINDEX magic word) for all of the years the userspace existed up until two weeks ago. Swing by WP:MFD sometime and see if your claim of being largely unmonitored is true. -- Ned Scott 03:50, 28 September 2008 (UTC)
• Oppose indexing - Agree with rationale provided by all the oppose comments above. Cirt (talk) 12:59, 26 September 2008 (UTC)
• Indexing is fine. Use the appropriate magic word if necessary. Stifle (talk) 15:23, 26 September 2008 (UTC)
• Oppose indexing - We shouldn't put the convenience of a relatively small number of users who would need this kind of information in Google results over people's real lives. I really don't buy the "but the internal search isn't good enough" argument for user talk pages. You're either going to be searching for plain text on the page, in which case it should be fine, or you're going to be searching for the username, which if it isn't a real word, Google isn't going to be able to do much better than MediaWiki. Mr.Z-man 16:11, 26 September 2008 (UTC)
  • I'd rather not believe that you are that ignorant about the shortcomings of our internal search. -- Ned Scott 03:50, 28 September 2008 (UTC)
    • I'd rather you give me some examples. What kind of cases do we need to search user talk pages, where the internal search isn't good enough but Google is? I can't even think of a need to search user talk space at all, besides possibly searching my own archives. Of course Google is better, they have 400000 servers to use for nothing but searching; I think we have something like 20 dedicated to searching. But you're talking like it doesn't work at all. From my experience, most of the complaints about the internal search are just people repeating other people's complaints without actually investigating it themselves. Mr.Z-man 17:29, 28 September 2008 (UTC)
• Oppose indexing I want more spaces de-indexed, not this. MBisanz ^talk 16:18, 26 September 2008 (UTC)
• Comment you can, actually, "opt in" to indexing by applying {{Index}} to your talk page. Protonk (talk) 18:16, 26 September 2008 (UTC)
• Oppose indexing - If user talk pages were indexed, those pages would flood Google results. I remember when I searched for my user name before NOINDEX was added, user talk pages filled the results page. With NOINDEX, there are much more relevant results. Besides, if someone was looking for a user on Wikipedia, wouldn't they want a user page as a result, not a talk page? -- Imperator3733 (talk) 18:37, 26 September 2008 (UTC)
  • They were "flooding" Google results before, and it was fine. -- Ned Scott 03:47, 28 September 2008 (UTC)
• Oppose indexing per all the very valid reasons above. It is not that difficult to use Wikipedia's search to search User_talk: and User: this proposal is merely about being able to use an external search engine for that. I understand that it is better but we would flood search results and put lots of content that isn't monitored like rest of WIkipedia out to a wider range of people. Scottydude _review 16:04, 27 September 2008 (UTC)
• Oppose indexing due to users' entitlement to privacy coming above all else. ╟─Treasury§Tag►contribs─╢ 16:17, 27 September 2008 (UTC)
  • What kind of ignorant dipshit posts to a public website and claims they have any entitlement to privacy of those public comments? If you go shouting out in the streets then you don't get to complain if someone notices you. If anyone here needs to post something in private then they can use e-mail or any number of alternative options. -- Ned Scott 03:47, 28 September 2008 (UTC)
    • Probably the kind of ignorant dipshit who posts nonpublic information or blatant libel about someone other than himself. Or the kind of ignorant dipshit who comes to Wikipedia and doesn't realize when first making an account that there are websites set up specifically to out and harass Wikipedians. Mr.Z-man 17:29, 28 September 2008 (UTC)
      • Excluding user talk from being indexed won't make those problems go away, and it's highly doubtful they'll even help the problems significantly. Libel information is found in the main article space, the main user space (drafts), and other talk namespaces all the time. I'm sorry, but we shouldn't be bending over backwards to the morons who post on the internet and are surprised when google finds it. My name was indexed on blog pages long before I ever became active on Wikipedia. Forum posts as well. Are you people new to the internet? You really have to be a fool to think that you have an entitlement to privacy when posting public comments on one of the largest websites on the internet. -- Ned Scott 03:28, 29 September 2008 (UTC)
        • I'm not, but many of our users are. Its getting hard to tell if this proposal is about our convenience in administering the project, or issuing a big "screw you" to new users, based on your recent comments. You might be able to attract more support if you didn't act so emotionally attached, calling users "ignorant dipshits" and "morons." And I'm going to assume that "You really have to be a fool" was just a general statement, and not aimed at myself... Mr.Z-man 04:30, 29 September 2008 (UTC)
          • Actually, most new users I come across know at least that much. Hell, my parents probably know better than to post anything private to the internet without being sure that it wasn't a public place. My point isn't to say "screw you", but rather my point is that the privacy issue only applies to an extreme minority. Rather than saying I'm emotionally attached, it's more of a case that I'm appalled at the lack of common sense here. I'm not saying that everyone who opposes indexing lacks that common sense, just the ones using rationales like "entitlement to privacy". I don't completely disagree with the idea, but I sure as hell know that no one is entitled to privacy on a public website.
          • I'm also appalled that this change was done on a whim and with no community support, and no one seems bothered by that. You might not have a problem with it when it's something you agree with, but there's nothing stopping people from filing bug reports that you disagree with, and not being able to do a damn thing about it. -- Ned Scott 10:02, 1 October 2008 (UTC)
          • Z-man, I don't know why it is that in every debate I'm in with you, you always assume the wrost from me.
            • When you use terms like "ignorant dipshit" and say things that could possibly be construed as calling several users commenting here (including myself) fools, I'm not sure what you want me to think... Mr.Z-man 16:59, 1 October 2008 (UTC)
              • Well.. I.. ok, I see your point.. Getting worked up in all of this does hurt my point, and I've made a lot of rude comments. My apologies, if that means anything. -- Ned Scott 23:45, 6 October 2008 (UTC)
• Oppose indexing What needs to be indexed by external search services is the encyclopedia, not the mechanics of making it. We can develop our own wp-internal indexes for that. Not just a matter of privacy, but of avoiding confusion. DGG (talk) 00:27, 30 September 2008 (UTC)
  • Yeah, good luck with that. -- Ned Scott 10:02, 1 October 2008 (UTC)
• Oppose indexing. Since, as Protonk points out, you can still cause pages to be indexed by use of the appropriate template, the question really becomes what the proper default should be for external search engines in user space. On balance, I do think that it is better to take this personal content, some of which includes working copies of articles that are not yet intended for article space, out of the search results. Xymmax ^{So let it be written} _{So let it be done} 15:07, 30 September 2008 (UTC)
  • User space is still indexed. -- Ned Scott 10:02, 1 October 2008 (UTC)
    • It should also be non-indexed by default. Reyk _YO! 20:41, 1 October 2008 (UTC)
      • I've put {{index}} on my user page pre-emptively, in case your position ever wins out. <brrrrr> scary thought! ^^;; --Kim Bruning (talk) 11:08, 4 October 2008 (UTC)
• Oppose indexing - gang, we have enough reputation problems already, without the nonsense that fills so many talk pages being splattered across the search engine results. --Orange Mike | Talk 19:02, 30 September 2008 (UTC)
• Oppose Indexing- anyone who wants to opt in can do so by using the appropriate template; privacy should be the default. Reyk _YO! 05:53, 1 October 2008 (UTC)

  How does not indexing user talk space help privacy, can you explain? (Aren't those pages still published on the public internet?) Why is privacy actually desirable on wikipedia, according to you? --Kim Bruning (talk) 11:06, 4 October 2008 (UTC) There are several people I know who refuse to answer e-mail, because they prefer to have their discussions on *public* talk pages. Hmmm, If those same people are exceptionally paranoid about it, would they now refuse to post to user talk as well? I wonder about that! :-)

• Oppose as user space is not a forwards facing space but an internal space. Hiding T 13:51, 1 October 2008 (UTC)
• Indexing please - people need to stop seeking solutions to problems that don't exist. –xeno (talk) 14:41, 1 October 2008 (UTC)
• Oppose indexing - When they were indexed these pages often came out highly placed in Google search results. That runs directly counter to the entire 'Wikipedia is not MySpace' philosophy. I even recall a recent article about a reporter who found that there was a, rather 'colorful', Wikipedia user with the same name as them... whose Wikipedia page came out as the top search result on the name. Wikipedia content should be indexed. The rest of it should not. Especially not userspace. --CBD 15:24, 1 October 2008 (UTC)
• Oppose Indexing There is no need for the vast majority of internet users to be able to search anything other than the article, portal and maybe image spaces, and there is really no need for them to see any of the talk spaces. Nobody should be sent to a user talk page by google. The inconvenience to a few thousand editors is not worth cluttering up the search results for millions with irrelevant information. Jim Miller ^{See me | Touch me} 17:36, 1 October 2008 (UTC)
• Oppose Indexing We're here to offer the convenience of an encyclopedia to the public, and that's it. There is no benefit to the public of allowing indexing of talk pages. As has been mentioned ad nauseum on a dozen conversations across a dozen dozen pages, unless BLP and standards involving living people (including editors themselves) are as rigorously enforced on talk pages, talk page archives, or any derivatives, we can't present this in "public" via anyone-can-find-it-search. It's too dangerous, reckless, and irresponsible. If there is still a problem with our internal search engine, for internal user-use, then that discussion or consideration has absolutely nothing to do with this no-indexing. That's a question of why volunteer developers are doing things other than fixing our broken search engine. rootology (C)(T) 13:24, 2 October 2008 (UTC)
• Oppose Indexing Dud idea, if you ask me... Can think of a good reason why I would want to search for my own (or somebody else's) contributions using Google. I can think of even fewer to allow the whole world to search for my contributions to talk pages and user-space articles. These spaces should not be indexed, FULL STOP. It should not even be an opt-in process. The nominator's convincing rationale was "what the frak"... I don't think I need to say any more. Ohconfucius (talk) 13:58, 2 October 2008 (UTC)
• oppose indexing Internal search has gotten better as of late and if there is any user space that has lots of issues it is probably user talk space. If we are going to go down this road in general then this might even make more sense than AN and ANI. JoshuaZ (talk) 21:37, 2 October 2008 (UTC)
• Oppose indexing. While in the end it's up to the user to make sure any privacy-invasive or otherwise dangerous material is not kept on their Talk page, not everyone is patrolling their talk pages every day; the chances of someone posting something on a talk page -- a personal attack, a posting using personally identifiable information, etc. -- is too great. As Ohconfucius says above, there's no use to be had in allowing a talk page to be indexed anyway. Many online forums -- Yahoo Groups comes to mind -- don't allow indexing of their pages; Talk pages, especially user talk pages, are often of the same principle as forum pages, and shouldn't be indexed, either. 23skidoo (talk) 05:55, 3 October 2008 (UTC)
• I'm strongly in support of indexing of user and user talk pages. I've undone the archiving of the discussion because something can only be snowballed if it's (virtually) unanimous, and that's not the case here. Besides, I have very strong reasons for having userspace google-able as well.

Part of the implicit social contract of a collaborative project such as wikipedia is that it contributes to a persons' online reputation. We have precious little to reward (or punish) our users with as it stands.

User: and User talk: are two places where outsiders can find out about a person's value to the project. You can tell I might be someone who relies on my online reputation, because I'm using my real name.

Having your name explicitly linked to your actions, or prone to retribution is also something that keeps an awful lot of people honest. Google acts like a kind of third-party oversight.

Wikipedia is a public location. Everything you do is public, with all the privileges and responsibilities that entails. So it has always been, so it should stay.

Whatever the ultimate decision, however, I'll be adding {{index}} to all my user and user talk pages over time. I think I've built up a few of those over time ^^;;

--Kim Bruning (talk) 10:44, 4 October 2008 (UTC) And... done that <ouw my poor wrists :-(>

Kim, I appreciate the sentiment but is there any real evidence that anyone cares enough that they would not create problems because of this worry? I suspect that most real troublemakers won't ever be involved enough to find out what our policy is in regard to page indexing. JoshuaZ (talk) 23:22, 6 October 2008 (UTC)

Regardless of who supports what, is anyone else bothered by the fact that this change was first made without any real discussion? I know we don't want to give the devs grief over stuff like this, which is most likely a misunderstanding (AGF), but we really need a better way of dealing with these kinds of changes. -- Ned Scott 03:56, 28 September 2008 (UTC)

• I think it is unfair to say there wasn't discussion, because I can remember reading discussion on this point all the time I've been here. However, I agree that perhaps we do need to centralise these discussions better, and that bug reporting and interface tweaks can have ramifications that merit discussion. Hiding T 13:51, 1 October 2008 (UTC)
  • What I meant was that there was only one cited thread, and in that thread there really wasn't any discussion. -- Ned Scott 02:33, 7 October 2008 (UTC)
• Agreed, there was hardly consensus for the change (at the time). –xeno (talk) 14:41, 1 October 2008 (UTC)
• Actually, we HAVE a centralized place for these kinds of discussions... Bugzilla itself. Unfortunately, most people don't keep an eye on that. Might make sense to have a local page listing recent suggestions so people know to go there and comment. Maybe a column in the 'signpost' or part of the existing B.R.I.O.N. column. --CBD 15:24, 1 October 2008 (UTC)
  • Please God do not use Bugzilla as a chat forum. It is most definitely not intended to be used as such. A board like this one is where discussion about changes to the project's configuration should take place, with possible cross-posting to other places. --MZMcBride (talk) 15:46, 1 October 2008 (UTC)
    • We can have all the discussion we like on Wikipedia, but if all the developers see is the request on Bugzilla then that's all they have to go on. Ultimately, somebody has to go there and say, 'please do not do this because it has problems X, Y, and Z'. --CBD 16:42, 1 October 2008 (UTC)
      • Right. The correct procedure is having all the discussion about a new proposal or configuration change here or on a similar noticeboard. And then when ready, someone files a bug with the 'shell' keyword and links to the oldid of the on-wiki discussion. And, within two hours or two years, a sysadmin will resolve the bug. :-) --MZMcBride (talk) 02:25, 2 October 2008 (UTC)

moved from above, since the discussion has reopened

I'm closing this now as it seems to be snowballing. It seems like the widely held consensus is that User talk: pages should remain noindexed as was set by the developers. While there may or may not have been consensus for this at the time, it's clear from this discussion that the majority of interested users are uncomfortable with the indexing of these pages for a wide range of reasons, including but not limited to: confusion between people; confusion between encyclopedic content and userspace content; privacy and "outing" concerns from attack sites; lack of need due to built-in search functions; etc. While it is true the outing concerns do not happen often, they do occur often enough that we regularly see otherwise good editors leave the project due to what essentially boils down to blackmail in the loosest of terms (I do not intend to make any sort of legal accusation/threat/statement with that comment, that is simply my personal observation on previous matters). Removing these pages from Google will not stop that (and I notice nobody said that here), but it will certainly slow it down, as well as address many of the other concerns raised about indexing.

If a user wishes to have their usertalk page indexed by search engines, they are entitled to do so by adding the template {{INDEX}} to their user talk page. This will override $wgNamespaceRobotPolicies and grant access by search bots to your talk page. Some time should be allowed after the addition for the googlebots to get around to finding it again, but ideally the page should be searchable by external engines within a week or so. Naturally, users should not add this template to any page but their own; this is a personal choice, and users have the right to decline search indexing if they wish. Since the great majority of those here are declining it, the default will remain as-is; noindex. Hersfold ^(t/a/c) 21:17, 3 October 2008 (UTC)

Currently, when a new or experienced user hits "edit this page" on a page like Microsoft, this is what they see. It's a mess. It's confusing. And it's horribly incomprehensible for a lot of users.

I'm proposing that we move infoboxes to subpages of their respective templates and incorporate "view - talk - edit" links into the boxes themselves at the bottom. So, for example, Microsoft's infobox would be located at Template:Infobox Company/Microsoft and Template:Infobox Company would be modified to have "view - talk - edit" links at the bottom of it.

Over a year ago, I converted some of the chemical element infoboxes to a subpage-type format and editing of the articles is now much more user-friendly. Compare: previously to now.

Thoughts, suggestions, comments, concerns? --MZMcBride (talk) 04:09, 5 October 2008 (UTC)

Wish I could think up something that clever. o.o Kylu (talk) 04:14, 5 October 2008 (UTC)

Offhand, it makes more sense to me for infobox templates filled-out with article-specific details to be article subpages instead of being template subpages. -- Boracay Bill (talk) 04:17, 5 October 2008 (UTC)

That'd be fine, except there are no subpages in article-space. A page like OS/2 is indexed in special:random (making it an article), whereas User:OS/2 would be one of User:OS's subpages. Kylu (talk) 04:28, 5 October 2008 (UTC)

While I think a complete redesign of how templates like infoboxes work would be ideal, that's a long, long way off. This would be good in the meantime. Mr.Z-man 18:19, 5 October 2008 (UTC)

This would make it more complicated for the people that know what they're doing, and not only in obvious ways. Someone fixing links to disambiguation pages might have to click through to the infobox. Someone updating a headquarters city will need to make two edits, one to the article and another to the infobox template. If the infobox name is based on the article name, it will have to be moved if the article is moved. --NE2 18:34, 5 October 2008 (UTC)

Why don't we just put overly complex infoboxes in subpages (Microsoft/Infobox in this case)? By definition, an infobox about a single company isn't a template anymore; it's encyclopedic content. If someone happens across one with Special:Random, big deal; we can just put a noinclude tag around the explanation that it is used on Microsoft. If someone is confused by that, I'd be surprised if they have the mental capacity for editing anyway. :) EVula // talk // ☯ // 21:10, 6 October 2008 (UTC)

That wouldn't work since article space doesn't have subpages. -- Imperator3733 (talk) 21:52, 6 October 2008 (UTC)

---

I'm proposing that we move infoboxes to subpages -- MZMcBride

it makes more sense to me for infobox templates [...] to be article subpages -- Boracay Bill

Why don't we just put overly complex infoboxes in subpages (Microsoft/Infobox in this case)? -- EVula

Great suggestion! Anything that reduces line noise and preserves the wikitext spirit of being quick and easy to edit gets my vote.

That wouldn't work since article space doesn't have subpages

It does work (see here and here). OK, it's not technically a subpage i.e. there's no backlink to Microsoft, but it's otherwise the same. The only caveat is that the infobox must be transcluded as {{:Microsoft/Infobox}} rather than {{Microsoft/Infobox}}.

chocolateboy (talk) 10:44, 7 October 2008 (UTC)

And it will also show up as an article on places like Special:Random, and will be counted as an article for the article count on the main page. Mr.Z-man 12:48, 7 October 2008 (UTC)

And it's another page for vandals to attack and users to have to watchlist. Der Wohltemperierte Fuchs ^(talk) 12:54, 7 October 2008 (UTC).

Separate pages also make it difficult to maintain named references (very commonly used when details in an infobox are duplicated in the box). I think the better solution is to standardize the way the infoboxes are presented in article bodies, using the "lined up on equals sign" approach so that it's clear its a special function. --MASEM 13:17, 7 October 2008 (UTC)

All good points. Still, I'd suggest keeping it that way for a while. More people are likely to spot the change in the Microsoft article than are monitoring this discussion, and they can weigh in here. It's easy enough to CSD the subpage if that's the consensus.

I think the better solution is to standardize the way the infoboxes are presented in article bodies, using the "lined up on equals sign" approach

Yeah. I've tried to do that (here for instance). It works well for uncluttered templates like that, but the Microsoft infobox is full of references and nested templates, which end up line-wrapping, so the unreadability is hard to avoid.

chocolateboy (talk) 13:31, 7 October 2008 (UTC)

I would like to suggest, a form of invisible universal category that all articles would belong to. It would be called the Index. it would be viewable to all people, just like an index an the back of a paper encyclopedia. It would look like category pages currently do. Until developers can get in on this, bots would attach all articles they find to an "index" category. The index would have an abridged versiom of articles with only at least a certain number of monthly visitations, an an unabridged version with all articles. You may comment, discuss, or vote under the following categories. --Ipatrol (talk) 00:57, 7 October 2008 (UTC)

Special:AllPages--Jac16888 (talk) 01:01, 7 October 2008 (UTC)

It looks like you're describing Special:Allpages. --Carnildo (talk) 20:19, 7 October 2008 (UTC)

There is a problem with material cited with an online reference, when that reference disappears, especially when someone then deletes the content on the basis it can't be verified. There are two situations: a) sometimes it is known, or can be suspected, that a ref will disappear because of the nature of the site (its practice is not to archive its own pages)—there is then the opportunity for pre-emptive action; b) it is unexpected—in this case it may still be available on google, but possibly only for a short time.

Some solutions to this might be:

1. An archive noticeboard, where editors ask for endorsement that the material they have used is accurately based on the ref. This would be viable for simple uses of the ref, such as straightforward factual material.

2. An archive noticeboard where relevant extracts from the ref are posted and endorsed. This would be useful when not a large portion of the ref is being used.

3. A Wiki cache, similar to google, where editors can cache a page directly. This would be particularly useful if it could also cache a google cache.

The best solution is 3, as it does not require any other editor participation or endorsement. 1 and 2 don't need any developer work, and could be instituted immediately. There could be a combination of these.

Ty 09:00, 13 September 2008 (UTC)

I share Ty's concern about cited web pages disappearing. Some topics are mainly covered by web pages, and articles on these topics risk being left unreferenced in a few year's time.

Option 3 looks best, as it's hard to tell in advance how much detial wil be needed, e.g a Ga /. FA reviewer might want to check that an article paraphrases a source correctly and does not select only passages that favour a POV.

A wiki cache could be implemented by a bot. The bot should only cache pages the first time they are referenced, as they may be later taken over by advertisers / domain resellers. The bot should:

• exclude citations that have an ISBN, DOI, PMID or other reference number that identifies an alternative route to the information.
• exclude web pages that have an ISBN, DOI, PMID or other reference number; but insert these reference numbers into citations if they are not already present.

The greatest difficulty for a bot would be multi-page web articles such as those at Findarticles.com - I'm still trying to think of a solution for that. -- Philcha (talk) 09:54, 13 September 2008 (UTC)

I was envisaging a more modest proposal, where the wiki caching would only take place when a user initiated it, as there's no need to wiki-cache refs that are likely to be available indefinitely. In the case of manual caching, multi-page articles could be done one at a time. Ty 11:22, 13 September 2008 (UTC)

How can editors judge which refs "are likely to be available indefinitely"? Some sites go off-line without notice. Many of the online mags drop pages completely after a couple of years; this is most common in "popular culture" subjects, e.g. computer games. A few academic mags move pages to archives, and I've recently had to contact one of these to tell them that the archive entry for the article I wanted linked to the wrong article. -- Philcha (talk) 11:44, 13 September 2008 (UTC)

That's up to editors to judge. You have given examples where they are not likely to be available indefinitely, so may well need to be cached. Likely to be available for example are Hansard and The Times (the latter available from more than one source from 1785). Items already cached in the web archive would presumably not need to be cached on wiki as well, unless there is a prospect of that project disappearing. Some refs are not particularly critical; some have information duplicated in other sources, e.g. a newspaper carrying a syndicated story. I'm not against caching every ref on wiki, but I don't think it's essential. Ty 12:13, 13 September 2008 (UTC)

Also, not all editors will have the know-how or will to follow all these steps manually. SharkD (talk) 11:58, 13 September 2008 (UTC)

There aren't any steps yet, as there isn't any system in place. It could be as simple as editing a URL and clicking a button. Ty 12:14, 13 September 2008 (UTC)

Wouldn't a cache cause serious copyright issues? I know Google is willing to push the boundaries of fair use, but since we're a free content project, we should take a more cautious approach. Perhaps a collaboration with the Internet Archive would be a better idea, where we could ask them to go through our references and make sure their archive includes those links. JACOPLANE • 2008-09-13 12:03

Far less copyright issues than google, which is a commercial entity. It's a service already offered by WebCite. Cached refs could be marked "No Index", and only be accessible to users when the original source became unavailable. Ty 12:20, 13 September 2008 (UTC)

This is an itneresting proposal; it would be possible to implement a very simple system whereby a source could be copied onto the toolserver – obviously the text cannot be released under the GDFL so cannot be placed on Wikipedia. (I won't comment on the potential space issues.) But I think that copyright is the main concern. Sites such as google's cache and waybackmachine are the only reason I think there's even the slimmest chance that we could take it further. Many papers are freely available for reading under the condition that "no further copies can be made". I would suggest raising a query at Wikipedia:Copyright_assistance, as hopefully an expert will be able to tell us how to work the loopholes. I for one would be reluctant to begin to create a bot for this purpose without assurance that I wouldn't be bringing on a huge copyright lawsuit from all the major publishers! Martin (Smith609 – Talk) 14:46, 13 September 2008 (UTC)

I was going to mention WebCite. If someone is concerned that a reference is going to go away, why not just use WebCite directly instead of reinventing it? Anomie⚔ 15:03, 13 September 2008 (UTC)

Some pages don't archive on WebCite. I've tried to use it to archive a google cache and it rejects it. Ty 15:23, 13 September 2008 (UTC)

As a counterpoint, if a web site, which in all other ways is considered reliable, but yet does not archive pages as a matter of practice (this being different from an accidental loss of date) , can that site really be called "reliable"? There's a reason that print sources, whenever possible, are preferred over web ones in that there's always (at least, in the practical future) a copy of the print version. I'm not saying that sites that use robots.txt or other methods to block caches or archive.org aren't a problem, as long as they keep their own material around. Those that don't... that's a questionable issue. --MASEM 15:14, 13 September 2008 (UTC)

Reliability, in wp referencing terms, refers to quality of content, not whether or not a site then keeps that content forever. That's an entirely different type of reliability. Sites choose not to archive either all or some of their content, for a whole variety of reasons. Maybe it's no longer of use for them, but that doesn't mean it's no longer of use for us. Ty 15:36, 13 September 2008 (UTC)

I do realize our current definition of reliability says nothing about archiving, nor am I saying it has to; I guess I'm bringing up the point for thought: should retention be considered as part of our definition of reliable? Should we be relying on web caches for reference content? --MASEM 16:00, 13 September 2008 (UTC)

Reliable sources can include difficult to access books and even user-generated translations of foreign language content, so I'd say no, retention and accessibility are not our primary concerns when judging if a source is reliable, just authority. It is, however, going to be an increasingly significant problem as time passes. Archival of the sources for at least our featured content should probably be considered an important goal. --erachima talk 16:16, 13 September 2008 (UTC)

Print sources have their drawbacks, e.g. how often does a reviewer have the books already? More seriously Wikipedia has a lot of articles about notable topics in what could be called "popular culture", where most of the sources are web-based - the examples I'm most familiar with are computer games (and chess, to a lesser extent), but I'm sure there must be a good 100 other categories. FAs in these categories could be down-graded to "C" or even "start" class if cited pages vanish.

WebCite has 2 drawbacks from this point of view: it archives only pages that the authors / publishers have thought to archive; and it expects publishers to pay for at least some aspects of its service (WebCite FAQ), which will deter some.

From the point of view of coverage, I think Internet Archive (Wayback Machine) is a better bet: it's not academically oriented; it's free; and it's crawler driven, although the crawler is Alexa.

Re copyright, Internet Archive's info is rather scanty, but WebCite FAQ refers to a case Field vs Google, US District Court, District of Nevada, CV-S-04-0413-RCJ-LRL, which ruled that caching does not constitute a copyright violation, because of fair use and an implied license.

If we relied on either of these archives, there would still be a question of what monitoring would be required. 404s and other HTTP "error" codes are easy. The problem is URLs that are taken over by advertisers / domain resellers - these often use HTTP 301 redirects to a single "sales" page, so 301s can't be trusted. I can't think right now of a way to at least semi-automate this kind of checking, and hope someone else can. -- Philcha (talk) 15:48, 13 September 2008 (UTC)

Options 1 and 2 seem like too much overhead. Adding refs is difficult enough, with the tags and templates. Making people "register" their refs on a noticeboard would be way too much work. There's no way to make it mandatory, and if its optional, it will probably be rarely used. Option 3 has issues with copyright, and also storage capacity. Wikipedia probably has several million external links, even if only 1% are references, that's still tons of server space. In some cases, such as an online version of print media, maintaining a link isn't necessary. Its helpful, but only the details of the original publication are necessary. Mr.Z-man 16:09, 13 September 2008 (UTC)

I'm not suggesting a mandatory system, but an optional one for editors who wish to use it and have a concern that an important ref may go missing and thereby cause an invalidation of content. This would apply where the only available reference was online, not to a duplication of print media. If it is rarely used, then 1 and 2 will have very little overhead, but can fulfil an invaluable function in certain instances. The web archive often does not deep index pages or has a gap in indexing which misses out an updated page. It is also not possible to tell for 6 months or so whether it is in the web archive or not. I don't see this as being a problem for server space, as developers have said that should not be a consideration for policy, and their job is to make sure the technical backup meets the needs of the project. If it is a problem, they can tell us. The bottom line is that there can be a perfectly valid ref with important content that suddenly vanishes (this happened to me with The Times and, despite emails, I couldn't get it fixed). The content shouldn't be compromised over a technicality, which can be easy enough to fix. Ty 22:56, 13 September 2008 (UTC)

Server space shouldn't normally be a consideration for policy, but most policy proposals don't involve adding creating a massive database of text. Also, many newspapers remove articles from public access after a certain time, so that only people with paid subscriptions can read them. Bypassing this by storing an indefinite cache on our servers accessible to all seems like it would most certainly be illegal. Mr.Z-man 04:59, 14 September 2008 (UTC)

I was going to say this, but someone already did. Most proposals don't involve the sheer hugeness of disk space that you'd be talking about, especially if you're going to retain formatting. But, aside from that, remember that the content we are referencing is not free. It is written by someone with a copyright to that content; that is the bottom line, and we have to deal with it. We can't just copy other people's work without permission (even with permission, really, if we want to keep with our ideals) because it works best for us. Celarnor ^{Talk to me} 06:47, 14 September 2008 (UTC)

I agree with Z-man. 1 and 2 seem like they take far too much overhead, and option 3 isn't very likely to work in the US copyright system. Celarnor ^{Talk to me} 00:58, 14 September 2008 (UTC)

If you agree with Z-man, it won't take much overhead at all, because "if its optional, it will probably be rarely used," so it will be a resource to save some rare refs. The precedents for use in the copyright system have already been pointed out, namely google, web archive and web cite. Wikipedia is in much safer position than a commercial entity such as google. Do you have a an alternative suggestion to deal with this issue? Ty 04:01, 14 September 2008 (UTC)

Just a note, where Google and Internet Archive have court cases and specific exemptions (respectively), neither WebCite (to my knowledge) nor Wikipedia have either of these. I'd rather not get into changing Wikipedia into a resource for copyrighted full pages: Just use links to archive.org if you must. Kylu (talk) 05:34, 14 September 2008 (UTC)

That does not solve the problem of content created with valid refs that disappear and are not on archive.org. Suggestion 1 does not involve storing any material at all, and suggestion 2 only a minimal relevant amount. Ty 06:15, 14 September 2008 (UTC)

Do you really think your first suggestion would be of much use? I don't imagine very many people utilizing it; however, I do think that is the only remotely viable one of the three. Celarnor ^{Talk to me} 06:43, 14 September 2008 (UTC)

A 'solution' that opens the project up to civil suits from the owners of each and every external link cached in such a manner does not seem to be a solution in my eyes. Google has an exemption as a search engine; courts have specifically ruled that by putting your content up on the internet, you grant an implied license for purposes of locating your content via a search engine; I'm not familiar with the particulars of the IA case, but I imagine there are similar restraints regarding whatever implied license is granted for caching therein; Wikipedia would be using these for an express purpose outside of the scope of either one of those.

Please remember that that Wikipedia exists in the Real World (unfortunately, the United States), and we have to abide by whatever copyright laws, no matter how draconian, apply to where our servers are. We can't simply ignore them and store other people's content because it's convenient for us to do so. Celarnor ^{Talk to me} 06:43, 14 September 2008 (UTC)

I agree with the motivation, particularly re. pages describing modern technology, since they are likely to become obsolete and be taken down or changed. (How many web-based references will you find for the ISA bus these days? What about MCA?) However, is there a reason that the archives at archive.org aren't suitable or sufficient? Perhaps WF could work together with archive.org to ensure that the pages referenced here, even the specific versions referenced here, are archived. Could WP's software automatically add links to the archive.org copies of linked pages? Jeh (talk) 17:09, 14 September 2008 (UTC)

Archive.org is limited in that it won't necessarily cache the page you need, and that even if it does, the lag time before it becomes available can be critically detrimental; for example, an Edge ref went dead, and this affected 3 video game FAs; that was two months ago, and without a cache, we'd still be waiting for archive.org to (possibly) check it. Der Wohltemperierte Fuchs ^(talk) 22:59, 15 September 2008 (UTC)

That is why I suggested "perhaps WF could work together with archive.org to ensure that pages referenced here, even the specific versions referenced here, are archived." Let archive.org handle the copyright issues; they apparently are doing so already. Jeh (talk) 12:56, 18 September 2008 (UTC)

Yes, I proposed this in WP:VG. If there were a way to predict beforehand what the URL to an archive would be, then we could simply add the link to the future archived version when making the citation. SharkD (talk) 01:54, 17 September 2008 (UTC)

That is a good idea. However, my original motivation was because of a ref that had disappeared but was still available on google, although not necessarily forever. I don't think webarchive caches the whole of the google cache. Could the people above who have opposed the intitial suggestions kindly come up with a solution themselves. Or do we just watch refs slip away in these cases and delete valid content? There is a relevant discussion at Citing sources. Ty 01:33, 24 September 2008 (UTC)

FYI, a cache system was put in place on the French Wikipedia several weeks ago. It is provided by Linterweb, the company that operates the Wikiwix search engine. Briefly, external links added to articles are automatically cached; a link to the cached version is displayed near the corresponding external link (see Image:Capture-cache-wikiwix.JPG). Currently, only registered users can see these links by editing their monobook.js, but there's a vote to decide whether they should be displayed by default for all users. For more information, see fr:Utilisateur:Pmartin/Cache (translation) and fr:Discussion Wikipédia:Prise de décision/Système de cache#Le projet cache (translation). Korg (talk) 19:45, 26 September 2008 (UTC)

Some pages don't archive on WebCite. I've tried to use it to archive a google cache and it rejects it. Before we think about building what is essentially a duplicate of WebCite, it would be useful to know a bit more than that it does not archive 100% of what is requested there. If it accepts 99%, for example, then we should be thinking about an automated system (bot?) for archiving, and only after that is in place do we need to worry about the remaining 1%.

To me, the most challenging issue here is newspapers that put their stories on the web for free (with advertising) for only a limited time (sometimes as little as a week), and then sell access to the stories thereafter. Typically the URL changes; mostly (I think) the old URL doesn't even link to the new one (often because the archive sales site is a third party). Such stories are problematical because if Wikipedia keeps copies, the newspaper isn't going to be happy at all.

I think options 1 and 2 are non-starters. Option 1 would require a huge amount of editor time (time much better spent actually improving articles), and is likely to be plagued with a lack of endorsers (unless we really have a lot of people who want to do such drudgery), not to mention sock-puppet endorsements of bogus cites. Option 2 is an encouragement for egregious copyright violations. -- John Broughton (♫♫) 14:43, 28 September 2008 (UTC)

There is option 4, namely that if material is referenced and the ref link is later found to be dead, it is accepted that it was viable at the time the material was inserted and kept in place, maybe marked as "expired". The current system means that if a link goes dead and for some reason cannot be found elsewhere, then the information can be removed, which seems a nonsensical approach. I would like to point out that my initial suggestions were intended for exceptional cases, not to be applied across the board. Also, to avoid copyvios, for which concern has been expressed, cached references could even be deleted, so that they would be retrievable by admins if necessary. Ty 23:58, 3 October 2008 (UTC)

Then we would have vandals inserting plausible sounding hoaxes which we couldn't verify because they marked the info as having a source that expired. Abyssal (talk) 00:40, 5 October 2008 (UTC)

Do note there is quite a difference between "long-standing reference goes dead" and "reference added this morning is already dead". Anomie⚔ 02:30, 5 October 2008 (UTC)

Yeah, but how would that difference show up in the article itself? What aspect of the proposed change prevents some person from adding a hoaxed source and then immedately marking it as expired?Abyssal (talk) 10:10, 7 October 2008 (UTC)

What prevents someone from making up a quote from an obscure book, and so on? If you look in the history and see it was first added and marked expired on the same date, you would be suspicious. Or possibly more likely, people watching the article will see the addition in their watchlists and revert it right away. Anomie⚔ 15:55, 7 October 2008 (UTC)

Matters on wiki are often ones of judgement. That is the case here. If an established editor with a good record has used a ref and some time later it expires, having not been challenged in the meantime, then it would be counter-productive to start deleting material on that basis—especially if the person deleting obviously has a grudge against the article, a case which I have experienced. Ty 09:18, 10 October 2008 (UTC)

Category:Uncategorized pages is growing every day, and even with such excellent tools such as HotCat, it can be difficult to manage. I think categories are important on wikipedia for organisation and mantainance as well as article-hopping for the average reader. Is there perhaps any support for a system where a warning/marker pops up on any article being created without categories that, while not interfering with the editing windows, reminds the editor that they have not added any categories yet? It might just help cut down on the number of category-less articles out there. SGGH ^speak! 13:19, 2 October 2008 (UTC)

I have concerns with a system like that being non-user-friendly for naive editors. I'd rather let more experienced people add the categories. Is there a good tool written to ease the process of going through the list of uncategoried pages? Many of them seem to be biographies, which should be relatively easy to categorize. — Carl (CBM · talk) 14:16, 2 October 2008 (UTC)

I agree with CBM that it's undesirable to deter new editors - if we do, Wikipedia will stagnate. Articles will need to re-categorized anyway, since their scope increases as they grow. We also need a better "add category" tool: no automatic entry in the text box of whatever happens to be highlighted in the dropdown/popup menu; multiple selection to avoid having to wait for the page to refresh after each category is added; and preferably more information about what each category is meant to contain; and ideally a true search facility, as new users will not necessarily think of the first word of the right category. -- Philcha (talk) 14:42, 2 October 2008 (UTC)

Nuh-uh. Having a lot of information with some of it uncategorized is better than having less information but all categorized. This is way too creepy and probably only going to serve as a deterrent to contributions from newbie editors. Better that someone have to step in after the fact and tack on a category or two, than to have never had the article in the first place due to a lack of categorizing. Shereth 22:15, 2 October 2008 (UTC)

Perhaps it might be a good idea to place an indicator on special:newpages that would show that a given page was uncategorized? I don't think that could be done easily with .js, so that would have to go to the devs (even then, I don't know that it would be easy). --Izno (talk) 06:22, 3 October 2008 (UTC)

Would it be easier if there was a newpages patrolling bot tagging them with {{uncategorized}}? Not my favorite cleanup template when issued by a human being, given how trivial it is to at least find a relevant but imprecise top-level cat to start out with, but it might help some, if it isn't already happening. (I haven't seen it lately.) MrZaius^talk 08:36, 3 October 2008 (UTC)

So long as said bot didn't actually tag the pages as being patrolled, I think that might be helpful. I'm pretty sure there is a category WikiProject, so they could be notified? --Izno (talk) 13:41, 3 October 2008 (UTC)

That would be Wikipedia:WikiProject Categories, though the task force handling uncategorized articles is probably most relevant. -- John Broughton (♫♫) 23:29, 3 October 2008 (UTC)

• Nope Process creep. Categories help build the web. We would wish that new and IP editors would do that, but it is usually the province of regular editors. I think if we had a better category system for selection we would see fewer uncategorized pages (think of the upload screen on commons), but that would be a feature, not a restriction. Protonk (talk) 05:05, 5 October 2008 (UTC)

• is there any reason why the initial state of a new page isnt "uncategorised" instead of just having that "+" in there? that might indicate more clearly to a newbie that there was something to be filled out. cheers Mission Fleg (talk) 04:51, 7 October 2008 (UTC)

• A newbie may not know the correct category and may put it in the wrong one if forced to. It'd actually be better leaving them on the workpile so someone who knows that area of work can categorise them appropriately. A gentle reminder so those who *do* know the categories can act accordingly wouldn't go astray, though. Orderinchaos 09:14, 8 October 2008 (UTC)

• i'm not suggesting they be forced to i'm only suggesting that instead of having that '+' in there you have "uncategorised" in there exactly as if it had been tagged. thats effectively what happens now except a bot does it at some future point (might be seconds might be days) so why not have it start that way. Mission Fleg (talk) 09:49, 8 October 2008 (UTC)

• If we think that new page creators are capable of finding one or more good categories, then I think that the best solution is to use a bot to post a note on their user talk pages, telling them that more people will find the article if they add one or more categories to it. (The same bot might check for a WikiProject template on the article talk page, and, if missing, suggest to the article creator that adding such would be useful.) A bot doesn't require new (developer) code, and is easily modified (perhaps several different messages could be tried, to see which one seems to work best). -- John Broughton (♫♫) 17:00, 9 October 2008 (UTC)

The solution is to make adding a category easier. Look at what Commons does with its images.. — Werdna • talk 00:43, 11 October 2008 (UTC)

Sorry, this random thought popped into my head the other day and I thought I'd entertain it. First question: is there any technical way to implement a wiki-wide freeze on article creation? If so, I just think it would be interesting and helpful if Wikipedia had "improvement weeks", where an article creation freeze was put into effect and instead directed people to improve bad articles or send them to AfD. After all, we're shooting for quality, right? Der Wohltemperierte Fuchs ^(talk) 13:14, 3 October 2008 (UTC)

I think a lot of people creating articles would just do nothing, rather than move over to improving article, however the main benefit to your idea would be that it frees up the people doing new pages patrol for other tasks. I'm not sure that's worth the inevitable loss of contributors caused by restricting what they can do. --Tango (talk) 15:37, 3 October 2008 (UTC)

It would also free up admins who delete more than a thousand pages per day, primarily after CSD nominations. But I doubt that you'll get consensus on this (so whether it can be technically done is somewhat irrelevant), if only because some new articles are in response to breaking news. (As an aside, please note that wiki and Wikipedia are not synonyms.) -- John Broughton (♫♫) 23:26, 3 October 2008 (UTC)

It would be easily possible by adding "." to the TitleBlacklist. However I'm certainly not going to be the admin who does that :D Happy‑melon 15:31, 4 October 2008 (UTC)

Wikipedia and wiki are indeed different terms, Mr Broughton, but I'd like to note that Wikipedia and Wiki are probably synonymous. At least that's what I've learnt in Roger Ebert's blog, hehe. Waltham, The Duke of 05:28, 10 October 2008 (UTC)

Why do you want to drive new editors away? Little Red Riding Hoodtalk 20:58, 5 October 2008 (UTC)

This has been proposed in various forms in the past, up to and including locking down all but the most critical project-space pages. The usual rationale for rejection is that most people would just not contribute during the time, rather than feel forced to do something that they really don't want to do. Many would go and improve articles, but it isn't really worth the overall loss of productivity and the potential loss of new users. Mr.Z-man 02:35, 6 October 2008 (UTC)

Bad idea. Sometimes improving an existing article involves creating a new supporting article, e.g. I created Crurotarsal to support Archosaur and Evolution of mammals. Suture (anatomical), which I also created to support Archosaur, is now rather popular. -- Philcha (talk) 08:58, 6 October 2008 (UTC)

Being able to enter new pieces of information or corrections into the respective articles' editors and submit them to an area within wikipedia where wiki editors wikify what has been sent (instead of altering the article instantly) might attract those people to the wiki idea who are willing to share their knowledge, but do not want to deal with wikipedia's formal prerequisites.--Emaster82 (talk) 22:42, 4 October 2008 (UTC)

I second this and pose a related suggestion; I also think there should be some way for casual readers to be able to submit questions or requests for information that they wanted to find in the article, but couldn't. This could give editors ideas on what articles need and could give us some direction in cases where we thought an article was comprehensive but notwas actually not meeting the needs of our users. Abyssal (talk) 00:35, 5 October 2008 (UTC)

I would encourage editors who are looking for information – especially information that ought to be in our articles but isn't – to visit Wikipedia's Reference Desks. Not only are the volunteers there generally very enthusiastic about returning rapid answers to questions, but many of us also try to fill in gaps we find based on questions we received. (Explicitly noting that an article is missing info is always helpful, too.) There was a formal project to encourage this effort (Wikipedia:WikiProject Reference Desk Article Collaboration), but I get the impression that most editors just go ahead and do it without any formal framework.

Notes or questions regarding missing information might also be placed on article talk pages, but very few articles have closely-watched talk pages.

Most article prose contains relatively little markup, and one doesn't need to know anything about markup to make small corrections or additions. (An unwikified paragraph or two here and there is no great crisis, and someone will be along eventually to straighten it out.) Neophytes should be encouraged to post requests for assitance to the Help Desk; editors there are glad to offer advice, and are also willing to step in to fix any formatting problems.

New articles are often created in a somewhat, or completely, unwikified state. If the prose is serviceable, someone doing new page patrol usually fixes up the new article (formatting, wikilinking, categories, stub notices) inside of an hour or two. I don't think we need a formal process for dealing with unwikified new articles, as we already seem to be coping well. TenOfAllTrades(talk) 02:04, 5 October 2008 (UTC)

I'm very pleased with the answer above and now too think that creating an extra area for wikifiying purposes is unnecessary.--Emaster82 (talk) 17:42, 5 October 2008 (UTC)

How about just putting the note on the article talkpage? Kylu (talk) 04:29, 5 October 2008 (UTC)

There are also templates Template:Expand and Template:Expand-section for this task. --Martynas Patasius (talk) 19:19, 5 October 2008 (UTC)

I don't think non-members and passerbys know how to use Wikipedia's template system. Abyssal (talk) 22:13, 8 October 2008 (UTC)

Just throwing this out there; I'd love to see it implemented as other projects already have but it would need wide community acceptance. Please see the bottom of any Wikinews article or the sidebar of Wiktionary. These projects have implemented a feature where anonymous readers can submit feedback about articles so the project knows how it can improve. I know that it will be a good way to better learn the public's perception of Wikipedia. Many people will read something wrong, a vandalized article, or something that needs improvement, but they don't know how to fix it or that they can even edit it. They then just write Wikipedia off as worthless. A public feedback system will let us know exactly what articles need to be improved the most as well as in what way. Very few of our millions of readers ever make an edit, so we really don't know exactly what they want. This is obviously a major change that wld require wide community acceptance, but I urge you to consider this beneficial plan and perhaps implement a short testing period before making anything official. Thanks, Reywas92^Talk 02:45, 7 October 2008 (UTC)

I used to think this would be a good idea, but then take a look at all the parallels in other sites. Many news sites that used to allow comment posting have removed this feature, and I'm not even going to touch YouTube comments. Then look at Wikinews, how is this helpful? Mr.Z-man 17:48, 7 October 2008 (UTC)

Feedback would have to be via a controlled questionnaire from with little or no scope for text input. This would make things easier for readers providing genuine feedback, easier for editors analysing the results and harder for flamers, etc. Ideally such a questionnaire should be designed with some reader involvement to ensure the right questions are asked and answer options provided - probably different reader groups per article category, as e.g. readers of scientific and pop culture articles will have different expectations. This sounds difficult, so internal brainstorming might be the only option. -- Philcha (talk) 18:22, 7 October 2008 (UTC)

Also keep only 1 response per article per user id / IP address.

Only one response per IP address? You mean the entire nation of Qatar is only permitted two opinions on a given article? --Carnildo (talk) 22:25, 7 October 2008 (UTC)

Something like this was implemented on Wikia actually: wikia:central:Special:ProblemReports. I honestly think it doesn't work very well on Wikia, as only administrators of the local wiki or Wikia staff can change the status of the report, but perhaps they would be kind enough to release the extension by GFDL (I don't know if it is or not), and then it could be implemented here for autoconfirmed+. As for your concern Philcha, there is actually more textual input than a questionnaire in that format, but I'm sure the tweaks would be possible if it was felt that textual fixes were ambiguous.
That all said... this doesn't go with the Wikipedia mantra. People should fix it themselves if they see an issue, or bring it up on the talk page. i.e., I don't think it should be implemented here. --Izno (talk) 01:26, 10 October 2008 (UTC)

Not everybody's bold. We should be pragmatic and give people the lowest barrier for entry required. I think being able to say "this article needs some love" without getting wrapped up in dealing with it encourages participation (what Wikipedia is about) rather than discouraging it. And it should absolutely be available for everyone, blocked, logged-in or administrator. — Werdna • talk 00:33, 11 October 2008 (UTC)

I've been having a bunch of issues trying to figure out what all the symbols mean, though I'm starting to figure out what some of them are, like the bronze star. But there are just so many symbols (or at least to me) that I don't really get them all (e.g. one day I was looking at a page and next to German/Deutsch, I think, there was a gold star, and so I didn't know what it was and it annoyed me, tough I eventually figured out it was the equivalent to the bronze star). I think that would be very helpful. Like what does the green circle with a plus sign in it mean? That would also be helpful to new users. Thanks! Helixer (talk) 22:10, 7 October 2008 (UTC)

A gold star on an article means that it is a WP:Featured Article, the green symbol stands for WP:Good Article, the only bronze star i can think of is a WP:Barnstar. Any others?--Jac16888 (talk) 22:33, 7 October 2008 (UTC)

As you say, Wikipedia:Featured articles describes it as a bronze star. The mouseover for the star on a featured article says "Featured article", and clicking it leads to Wikipedia:Featured articles where the star is described, so I don't think any more explanation is needed. The gold star on interlanguage links to featured articles is made by {{Link FA}}. The mouseover for the corresponding language link is "This is a featured article in another language." (See for example United States). Does your browser not display mouseovers? The symbol for Wikipedia:Good articles is a green circle with a plus. Again, both mouseover and clicking it should usually explain it. If it's on a user page then it means the user has contributed to a good article. PrimeHunter (talk) 23:08, 7 October 2008 (UTC)

Sorry my bad, never even noticed that FA star was bronze, thought it was just a dark gold colour--Jac16888 (talk) 02:25, 8 October 2008 (UTC)

I would hope that the good article symbol isn't in any articles. There's been several large discussions about this, all resulting in either no consensus or a consensus to not put the GA icons in articles. Mr.Z-man 16:15, 10 October 2008 (UTC)

Ever feel frustrated by the thought that it's really hard to get Did you know credit for expanding anything bigger than a substub, and it's a big gap from there to good article? Okay, let's fill that gap. Proposing the Killer B's to thank people for raising the dreadful up to pretty good.

Killer B recognition goes to improvement drives for existing articles that start out at C-class or below, with a few requirements:

1. The article comes to full-fledged B-class work: useful overview of the subject, pretty well written, pretty well referenced, no uncited controversial stuff, no tags for serious shortcomings.
2. Double its word count (not counting lists).
3. Get it to at least 1000 words.
4. Bring it to a total of 10 or more reliable sources with inline citations.
5. Add at least 5 new reliable sources yourself (it may already have some sources before you start).
6. Do all the improvements within 1 week.

There wouldn't be any special designation for Killer B at the article, but we could keep a 'Beehive' to thank editors for their contributions and offer cute doodads for userspace. The basic setup would operate similar to GAC: anyone can review and the process works on an honor system. Durova^Charge! 20:28, 6 October 2008 (UTC)

Support I agree, but I'd be more inclined to simpily have an award, like a barnstar, awarded by common editors for such a thing --Ipatrol (talk) 00:40, 7 October 2008 (UTC)

Yes, Killer Bs would be awards similar to barnstars awarded by common editors. Durova^Charge! 00:55, 7 October 2008 (UTC)

I see, but what I was trying to say is that I don't agree with the "beehive" part of your proposal. Also you might run into issues with WP:OWN, in otherwords, who of the editors on such a page would get that award? --Ipatrol (talk) 01:00, 7 October 2008 (UTC)

Generally one or a small team of people who raised an existing article up to B class within those parameters over the course of a week. What objection do you see with WP:OWN that doesn't exist for a similar program such as DYK or GA? Durova^Charge! 02:13, 7 October 2008 (UTC)

I like the general idea, but I really dislike the actual characterisation of it - I mean come on, a bee called 'killer'? We're not in primary (elementary) school... get rid of the whole 'bee' thing, make it more like the existing barnstar system (i.e. a bit more mature, without a character), and I'll be more happy to fully support. _TalkIslander 14:01, 7 October 2008 (UTC)

Well, I'll see what else I can do. It helps to give these things some kind of personality--gets people to remember them. Suppose I found a still from an old 1950s B-movie horror flick? Durova^Charge! 20:04, 7 October 2008 (UTC)

No, see, that's the problem. I won't support it with any personality - like I said, we're not in primary school, we don't need a mascot-type-device, seriously we don't. Barnstars work, they're not a 'who, they're a 'what'. Make this a 'what' as well, and ditch any personality or character. _TalkIslander 21:47, 7 October 2008 (UTC)

Agreed. The red-white termite doesn't look appetizing, does it? NVO (talk) 14:52, 8 October 2008 (UTC)

That's 'cause you're not supposed to want to eat it. And I support the proposal. :D Abyssal (talk) 22:10, 8 October 2008 (UTC)

How about this:

The B class award I award this Barnstar to Village pump (proposals)/Archive 36 for their achivement In getting Wikipedia:Main Page to B class status.

--Ipatrol (talk) 17:04, 11 October 2008 (UTC)

Yeah, see, sadly I kinda want to squash that little stripey dude. I don't do well with the six-leggers, and I'd bet I'm not the only one. Plus that goofy grin of his...Yeah, he's gotta die. Sorry, but...CRUNCH.Gladys J Cortez 02:51, 12 October 2008 (UTC)

Hi all - when you go to delete a page via http://en.wikipedia.org/w/index.php?title=(pagename)&action=delete you are presented with a handy-dandy list of reasons for deletion that you can pick and choose from. At present, that list is simply all the Speedy Deletion criteria, plus the catch-all "other reason". I'd like to see a further reason added to that list - "Per consensus at deletion process page". Consensus at AFD, CFD, and the like is surely one of the most common reasons for deleting a page, and would be a useful extra item to have on that list. Grutness...wha? 23:53, 7 October 2008 (UTC)

MediaWiki:Deletereason-dropdown has the various reasons. MBisanz ^talk 15:14, 8 October 2008 (UTC)

Other reason: (provide link to the xFD). –xeno (talk) 15:21, 8 October 2008 (UTC)

Per Xeno, but a bit more explicitly—if a page is being deleted pursuant to consensus in a discussion, the deletion log entry should include a link to the closed discussion. Just saying per consensus at deletion process page isn't nearly as helpful, and can be confusing for someone following up if a page has been deleted more than once (was the 'deletion process page' AfD? DRV? A second or third AfD? etc.). TenOfAllTrades(talk) 16:03, 8 October 2008 (UTC)

If you try to delete a page with PROD or AFD, the default reason you get is either the deletion rationale for the PROD or a link to the AFD. Hence such an option would be redundant. Hut 8.5 06:47, 9 October 2008 (UTC)

The reason it's not there may be because such deletions should always include a link to the deletion discussion. That would not be possible if it was a dropdown option. If something is deleted at xfd, you should put something like "per [[Wikipedia:Articles for deletion/Main Page]]" as the deletion reason. --- RockMFR 17:40, 9 October 2008 (UTC)

Such a link always exists in the "what links here" links - which is why its so often not specifically included in the deletion log reasons. Grutness...wha? 00:34, 10 October 2008 (UTC)

It should always be included in the summary, as most readers are probably not aware of the what links here feature. --- RockMFR 01:59, 10 October 2008 (UTC)

The 'what links here' may include a lot of other pages – links from user space, multiple deletion discussions, AN postings, other deletion discussions, etc. – and it may not be immediately obvious in what order the linking deletion discussions took place. (Was it AfD1, AfD2, DRV? Was it AfD1, DRV, AfD2? Was it AfD1, DRV1, AFD2, AfD3, DRV2, AfD3, DRV3?) Links from the deletion log will always be in clear chronological order, and should always be deletion-specific. TenOfAllTrades(talk) 05:39, 10 October 2008 (UTC)

I've been bold and added it. Feel free to remove it if it causes problems. — Werdna • talk 00:31, 11 October 2008 (UTC)

It's been reverted (not by me, I add). I agree with the principle: the 'XfD' option should not be added to the dropdown menu unless it is possible to automatically fill in a link to the deletion discussion. Those links are vitally important, as they display whenever someone then tries to recreate the page and may be consulted to discover why it was deleted in the first place. Happy‑melon 09:56, 11 October 2008 (UTC)

It is absolutely needed to link those discussions for the reasons mentioned above. It is also more comprehensible for new users or readers ("per rfd", but also "csd g2", "U1", etc, are not) and more professional. It should be noted in MediaWiki:Confirmdeletetext, something like:

• If you intend to delete as a result of a deletion discussion, link to this discussion.

While it is easier for afds, all discussions have permanent blue links, for example for tfd, Wikipedia:Templates_for_deletion/Log/2008_October_11#Header.

All the closing guidelines, general and specific, should reflect that.

Cenarium ^Talk 23:53, 11 October 2008 (UTC)

I don't know how big a problem it is in the main wikipedia, but users quite often forget to sign their comments on talk pages of the smaller wiki I use to contribute to. How about automated signing of comments so that it cannot be forgotten or refused (if technically possible, of course)?

Alternatively, I suggest creating a box in the "Editing" column on the "My preferences" special page so that, if the box is checked, users would be reminded to sign their comments if they haven't done that yet when trying to save the talk page they have been working on. The "Prompt me when entering a blank edit summary" function works similarly.--Emaster82 (talk) 03:07, 10 October 2008 (UTC)

While not a part of the Mediawiki software itself, SineBot automatically adds signatures to most talk pages if a user forgets. User:Slakr is responsible for the care and feeding of SineBot, and might be able to give you some tips on how to implement something similar on your own wiki. TenOfAllTrades(talk) 05:31, 10 October 2008 (UTC)

Another device I didn't know of. Anyway, I might indeed contact the bot's nurse for help.--Emaster82 (talk) 14:08, 10 October 2008 (UTC)

The problem with a system-level solution is that, sometimes, users need to edit a talk page without signing. For example, I don't need to sign if I'm placing {{WPBiography}} on a talk page, or if I'm correcting someone's botched link. MediaWiki can't tell the difference between an unsigned comment and a non-discussion content edit. EVula // talk // ☯ // 23:08, 10 October 2008 (UTC)

I don't see that as a problem. We already have a box at the bottom of the edit box marked "Watch this page" which is checked by default. We could have a similar box marked "Sign this post". If we did that, and removed the signature icon at top, we would have a situation where we no longer have to ask for posts to be signed. It would be done automatically unless we asked for it not to be done. I think this change is long overdue, and I thought there was an announcement a few months ago that this feature was being developed. What happened? Even experienced users forget to sign now and then, and I get annoyed when it happens to me, so I'm hoping to see this change happen sometime. --A Knight Who Says Ni (talk) 13:06, 11 October 2008 (UTC)

Some projects do have global JavaScript that reminds users to sign on most discussion pages, and if they don't need to sign a particular edit, they just have to click "Save page" again. This feature could be limited only to IP and new users by default. —AlexSm 14:40, 11 October 2008 (UTC)

Will be sorted by LiquidThreads, and David McCabe has been hired to finish it for Wikimedia. — Werdna • talk 12:53, 11 October 2008 (UTC)

We use a variety of shortcuts to important pages on-wiki, to save ourselves typing a few characters; these invariably involve shortening the namespace prefix to an acronym. We call common namespace abbreviations 'pseudospaces' because they refer to namespaces that don't actually exist: the pages are created in the mainspace and their corresponding talk pages are "Talk:ABBR:Foo" rather than "ABBR Talk:Foo". A while ago the developers, having written the necessary underlying code, made the "WP:" prefix an actual alias of the "Wikipedia:" namespace, and similarly for "WT:" and "Wikipedia talk:". So typing "WT:FOO", you would immediately be directed to "Wikipedia:Foo", and it was impossible to create a mainspace page at "WT:FOO" in the same way that it is not (AFAIK) possible to create a mainspace page at "Help:Foo". A maintenance script was used to move all the shortcut pages starting with "WP:" and "WT:" to new locations in the Wikipedia: and Wikipedia talk: namespaces. The update was fairly painful because there were a lot of name conflicts between pages named "WP:Foo" and "Wikipedia:Foo", and a number of templates beginning with "Template:WP:...". I have been investigating the corresponding situation with other popular shortcuts such as "T:", "P:" and "CAT:", with mixed results.

From Special:Prefixindex/T: we can see the 30 or so extant "T:..." shortcuts: I have confirmed that there are relatively few potential name conflicts, and no template conflicts. In every case where there is a name conflict, the two pages are either the template target and its shortcut redirect, or two redirects to another template; the conflicts could be trivially resolved by deleting the redirect or by merging the histories of the two redirects, respectively. It would therefore be possible to implement "T:" as a namespace alias for "Template:" relatively painlessly. This would of course prevent these shortcuts from multiplying while at the same time allowing every short template name to be used as a potential shortcut. There is a small issue with the "T:..." alias: the valid article t:kort. I'm not sure what could be done with this, perhaps there is some unicode replacement for the colon (or the t for that matter!) that we could use for the main article? A redirect from Template:Kort (which would be the result of typing "t:kort" into the search bar) would have to be condoned but that's no big deal - we already have such redirects from Help: A Day in the Life to Help!: A Day in the Life, for instance). It would be nice to be able to define "TT:..." as an alias for the Template talk: namespace, but this is unfortunately the interwiki prefix for the tatar wikipedia!

The situation with the "P:..." alias is similar. There are some three hundred "P:..." pages, the majority of which have no equivalent page "Portal:...". The very few that do (see list) are without exception redirects or targets, as with the T: alias. Once again there is a minor problem in the article P:ano. There are no pages of the form "PT:...", but this is the interwiki prefix for the Portugese wikipedia so it is not possible for us to use it as an alias.

The situation with the "CAT:..." shortcut is more difficult: there are a large number of them, this time redirects without exception, but I don't think that defining "CAT:..." as a namespace alias for "Category:..." would be very helpful, as it would mean that the normal rules of category links would apply: writing [[CAT:CSD]], for instance, would result in the page being added to CAT:CSD rather than being linked to it. If there is an option to specify that "CAT:" is equivalent to ":Category:" then this would be useful, otherwise these redirects will probably have to remain. There are no pages with the prefix "CATT:" so this could be easily enabled as an alias for the "Category talk:" namespace.

There are only a handful of pages with the "H:" prefix, all redirects to Help: space; none of their alias pages exist. However there are a number of templates prefixed with "H:", associated with the bot-imported help pages from metawiki. This help system itself appears to be in disuse and needs to be rethought, so this may not be an insurmountable obstacle. "HT:" is the interwiki prefix for the Creole wikipedia.

There are no valid shortcuts with the prefix "I:" to images, and three valid articles; such an alias would also suffer from the same problems as the "CAT:" alias above. "IT:" is the interwiki prefix for the italian wikipedia. There are no shortcuts or articles at "U:", just a handful of implausible redirects, or "UT:" - "UT" is also not an interwiki prefix so could be used as an alias for the "User talk:" namespace.

In summary, the following namespace aliases could be easily created with minimal effort, with the associated benefits.

• HT: → Help talk:
• U: → User:
• UT: → User talk:
• CATT: → Category talk:

In addition, the following aliases could be created if a few issues were resolved:

• P: → Portal: – p:ano
• T: → Template: – t:kort
• CAT: → Category: – if automatic category linking could be disabled
• I: → Image: – if automatic image inlining could be disabled

I guess this is more of a status update and food-for-thought exercise than a concrete proposal at this time, but there is clearly some mileage in this and the potential to remove a lot of 'backstage' housekeeping links from the 'reader-facing' mainspace. It would also probably be a good idea to discover or plead for a solution to the problem of needing to create an article that begins with a valid wiki (or interwiki) prefix; we already have a few of these, and sooner or later someone is going to write a book entitled "Wikipedia:The free encyclopedia" or "Portal:A great SciFi novel"; our handling of these is currently quite inconsistent, a coherent approach (preferably by escaping the colon in some fashion) would be desirable. Comments? Happy‑melon 17:33, 5 October 2008 (UTC)

I think most or all of these would be unnecessary. "User" and "Help" are short enough that its not really worth saving 3 characters for a link that's more confusing. And how often do we need to link to most of the talk namespaces like category talk or portal talk where creating shortcut links would be justified? Other than WP/WT, I think the only namespace that's ever shortcut-ized is CAT and, rarely, H. Mr.Z-man 21:14, 5 October 2008 (UTC)

Solution in search of a problem, in my opinion. It's not really an issue. EVula // talk // ☯ // 02:53, 6 October 2008 (UTC)

I support the proposal, or at least the general idea behind it. If it saves typing and isn't a big deal to implement, then there's benefits, but no drawbacks, which means there is no good reason not to implement it. Criticisms so far aimed at the idea sound suspiciously like arguing "I'm not interested in it" to have a page deleted. Abyssal (talk) 11:08, 6 October 2008 (UTC)

It saves a tiny bit of typing at the expense of cryptic links and pointless shortcuts. We shouldn't be encouraging users to clutter up userspace with shortcuts to their own userspace and we shouldn't be using confusing links like H:IOUF when trying to explain to new users how to upload files. Mr.Z-man 16:46, 6 October 2008 (UTC)

I've always been wondering why there isn't a CAT shortcut for the category namespace, and have wanted to see one; I hadn't taken into consideration the complication of the dual nature of these links. Having corrected a number of faulty links to categories (including one in an archive), which actually categorised the page they were in instead, I can see a good use for a CAT: alternative to :Category:. People often forget that crucial initial colon. (On the other hand, might such an alternative cause more confusion?)

As far as other namespaces are concerned, I've never seen a reason to shorten words like User and Help, in which case the balance does seem to tilt towards over-abbreviation. The template namespace is easily accessed through {{tl}} (although there would be merit in a shortcut, mainly for template talk pages). Waltham, The Duke of 01:27, 7 October 2008 (UTC)

• Support this change. We already have CAT:s littering the "article space" so why not make it officially a namespace redirect? I also like all the other redirects, I have always wondered why WP: (& WT:) are so special. Foxy Loxy ^Pounce! 08:07, 12 October 2008 (UTC)

Dear friends,

I have begun to read "Today's Featured Article" of the Wikipedia everyday. I appreciate this effort and consider this as a very good venue for self-education. In fact I have made it my default page so that I can read it everyday.

However, I noted that the topics, at least in the past one week, concerned things that were too minor or trivial for a global audience. Today's article for example is about Trafford, a small town in England. There are countless small towns all over the world and one doesn't gain much knowledge by knowing the hundreds of thousand small towns in the world. Yesterday it was the Grass Fight during the Texas Revolution. It would have been better if the feature is on the Texas Revolution rather than the Grass Fight because majority of people didn't even know that there was a Texas Revolution.

May I make a suggestion?

Can we make the daily Featured Article a kind of long-term educational program that will widen and deepen the liberal education of Wiki readers? In making this, we can make it cover a broad range of significant human knowledge that will matter in the lifetime of a person -- covering history, science, arts, religion, philosophy, humanities, geography, etc. It can include topics that are seldom heard-of, but still of significance when learned. Here are examples:

Quarks / Strings Michelson Morley Experiment Asoka Lemmings Angkor Wat Gordian Knot Western Schism Anti-Popes The Fourth Crusade Samadhi Hundred Years' War Genome Project A priori and a posteriori Impressionism Knight Templars Ataturk Cargo cult Marianas Trench Timaeus (dialogue) etc.

Being an educator myself, I am willing to be of help in suggesting articles for the Featured Article section.

May I take this opportunity to thank all those nameless volunteers who make this truly revolutionary encyclopedia possible.

With warm regards, Vicente Hao Chin, Jr. Author, The Process of Self-Transformation

In order to be Today's featured article, an article must first be a featured article; that is, it must have been identified as one of the best articles Wikipedia has to offer. If you want the articles you mention to appear on the main page, you've got a lot of work to do getting them up to Featured standard first. Algebraist 09:24, 12 October 2008 (UTC)

See WP:TFA/R, but our TFAs have to be of general interest to a broad readership, i.e.; not only scholarly topics. SandyGeorgia (Talk) 09:29, 12 October 2008 (UTC)

Wikipedia is an encyclopedia, not an educational site, see WP:NOT. "Wikiversity", I believe, is. We didn't choose (well, more precisely, the TFA director) didn't choose Texas revolution because it isn't a featured (meaning "quality" in this context) article. Though we have more specialized featured articles, like General relativity. Cenarium ^Talk 16:08, 12 October 2008 (UTC)

Thank you for the comments. I did not realize that there was the Wikiversity. I have looked at it, and will make use of it a lot for our school. However, for the Featured Article for the Day, I still think that it would be better that the information will have a learning value. After all that is the purpose of an encyclopedia. I will try to make proposals to the Featured Article and hope that I can be of help. Thanks again!

I think there should be more simple wikis like the simple English one. How about a simple Spanish one?--Megaman en m (talk) 20:19, 12 October 2008 (UTC)

I would suggest proposing this at the meta request page. This page is for proposals for en-wikipedia. -- Imperator3733 (talk) 22:04, 12 October 2008 (UTC)

I've started a discussion to finally get rid of the shambling monstrosity that is this category and all its children.

My opinion is clear on the matter (get rid of the entire nest of prejudicial editwar bait), but this is a bold and big move and needs wide participation. Participate. — Coren ^(talk) 20:13, 12 October 2008 (UTC)

My recollection is that India has abolished the caste system, yet Wikipedia has extensive lists of different castes and who is in which. Yeesh. 199.125.109.136 (talk) 00:22, 13 October 2008 (UTC)

Incorrect. Caste remains in place, see Scheduled castes and scheduled tribes and Reservation in India. NVO (talk) 15:49, 13 October 2008 (UTC)

Would people here be interested in this discussion? Carcharoth (talk) 15:04, 13 October 2008 (UTC)

People put 'under construction' on a page to say that they are actively working on articles. But then the templates seem to hang around on the article for hours, days, and weeks. It is sometimes difficult to get them removed because people say 'I haven't finished yet, I just have to get round to it'. Sometimes people even revert removal of the template.

A reasonable proposal (I think) is to merge the templates into one. The one template would have a fixed expiry time visible in read mode. If it expires, the editor would be able to refresh it but would have to take positive action to refresh it. The current fire-and-forget design would be gone. The expiry time would be consistent with real tappity-tap editing where fingers are pounding the keyboard e.g. 15 minutes to an hour.

For more details, debate, and voting, see: Wikipedia:Templates for deletion/Log/2008 October 13. Regards Lightmouse (talk) 16:21, 13 October 2008 (UTC)

You are talking about {{In use}}. Woody (talk) 17:44, 13 October 2008 (UTC)

Actually, I am talking about them all but perhaps my comments highlight specific problems. So far we have had a novel suggestion that the sell-by date is actually *increased* from a few days to 6 months and that the current process of purging stale tags by bot is stopped and tags only be removed after individual negotiation over each tag with the person that put it there. I have the feeling that we are going backwards by making it harder to clear up after fire-and-forget editors. Sigh. Lightmouse (talk) 18:55, 13 October 2008 (UTC)

I have proposed moving List of YouTube celebrities and all its related "celebrities" to YouTube phenomena (or something similar). There are more details about the proposal here. I just want more people to see this as there doesn't seem to be much activity on the talk page. But my main is that there seems to be a lot of articles about people who had some sort of success and minor media attention on YouTube and have gone no further after, a flash in the pan. See Emmalina (currently at 4th AfD) for an example of this. --TwentiethApril1986 (want to talk?) 19:48, 13 October 2008 (UTC)

On a related issue, there is a discussion and straw poll at Wikipedia talk:Featured article candidates on whether there should be a minimum length in words for FAs of say 1,000 or 1,500 woords, and other issues. At the moment there seems no majority on this, so we are likely to continue to get increasingly short FAs - the shortest candidate I have seen was 329 words - many on small tropical storms (one reached 40mph for 1 minute) and American state roads (one a 1/4 mile long, outside a military base). The questions start here. Johnbod (talk) 11:16, 4 October 2008 (UTC)

I'll have you know that Erick reached 40 mph for about 12 hours. :-) In all seriousness, though, why does quality correlate to length? –Juliancolton ^{Tropical Cyclone} 01:10, 6 October 2008 (UTC)

That information isn't in the article - I was going from the infobox statistic, which perhaps needs to further explanation, as so often. Is this article "Wikipedia's very best work"? I don't think so, though of course it is very well done (much better than the road). Johnbod (talk) 01:18, 6 October 2008 (UTC)

Well, is the article well-written? Is it comprehensive? Is it neutral, unbiased, stable, and does it meet notability requirements? If so, what prevents it from being considered "Wikipedia's best work"? –Juliancolton ^{Tropical Cyclone} 01:23, 6 October 2008 (UTC)

I've commented on those issues at FAC, & not all the answers are yes. But the topic is just too tiny. It's worth rememberering that it's only because the little storm happened near the US, and got an official US classification, that it qualifies as automatically notable. In most places in the world weather events on this scale are not remotely considered notable here. Maybe it's time to reconsider the notability criteria. Johnbod (talk) 01:28, 6 October 2008 (UTC)

Indeed it is fairly non-notable; I completely agree that it's only notable for being designated by the NHC. However, being designated by the NHC gives a storm a large amount of notable via the media, government sources, tracking agencies, etc. Granted, a large amount of notability for a storm can be seen differently than a large amount of notability for another more widely-known subject. The notability given to any named tropical cyclone allows the subject to passe WP:N, and as a result, can support an article. That said, if an article meets WP:N, it could therefore survive an AfD. A while back, Raul said that any article which survives an AfD can become featured. Have our standards changed that much? What's wrong with a goal of getting every article featured? Now, I'm still slightly confused; "Wikipedia's best work" is named such for a reason. It's not called "Wikipedia's most notable work". Would a subject have to be notable before we can call it our "best work"? However, I understand and respect that Wikipedia is not ready for a 400-word article; hence I withdrew Tropical Storm Erick (2007) from FAC. I also understand why people might want to create a new class of Featured Content for shorter articles. (Jimbo, your thoughts on the matter would be appreciated). Cheers, –Juliancolton ^{Tropical Cyclone} 01:43, 6 October 2008 (UTC)

"Can become featured" doesn't mean "should become featured once all available online information has been compiled in a well-produced article". I can imagine (at a stretch) a fuller article on the subject I would vote for at FAC, but 329 words, no. Johnbod (talk) 01:53, 6 October 2008 (UTC)

These articles are a net benefit for Wikipedia, they don't cause any harm and doesn't violate any of our policy. From a PR point of view, they are beneficial, except if featured on the Main Page too many times. Cenarium ^Talk 01:03, 6 October 2008 (UTC)

I hope we can abide by Jimbo's plea not to take his view (too) seriously here: "It bears repeating: I am not trying to make policy here, just indicating my current thinking on these matters." if Wikia ever shut down we might be able to persuade you to his view back again! —Preceding unsigned comment added by 193.26.4.35 (talk) 11:51, 6 October 2008 (UTC)

Quality, not quantity ... – Thomas H. Larsen 07:51, 9 October 2008 (UTC)

I think this discussion belongs at the village pump, NOT Jimbo's userpage. --Ipatrol (talk) 14:37, 13 October 2008 (UTC)

The problem is that "FA" is ambiguous, since it marks articles as of the highest quality and also as elegible for "Today's featured article" on the main page. Some topics are notable but there's not a vast amount to say about them, e.g. the Signor-Lipps effect. However even if Signor-Lipps effect became an FA I don't think there would be enough content to justify a spot on the main page. -- Philcha (talk) 12:37, 14 October 2008 (UTC)

I propose to change the "wikt:" namespace, which forwards articles from Wikipedia, to Wiktionary to "d:" namespace. The letter "d" stands for dictionary, define, and definitions. An alternative coming to mind is "t:", standing for the first letter of what seems to be the second syllable of "Wiktionary". Instead of renaming the namespace, "d:" could also be only added while keeping "wikt:" intact, which would probably be better for compatibility reasons.

Unlike Wiktionary, most other Wikimedia projects have a single letter forwarding namespace, including "W:", "B:", and "S:".

One benefit is a quicker linking to Wiktionary from another project. Another one is typing "d:word" into the Wikipedia searchbox of Firefox, and getting to Wiktionary.

Thanks for reading. --Dan Polansky (talk) 13:40, 14 October 2008 (UTC)

The correct place to request this is at m:talk:interwiki map. In fact a request for this was already started there a month ago (m:talk:interwiki map#Wiktionary). MTC (talk) 14:35, 14 October 2008 (UTC)

Please see comment I made here about obtaining and recording gender (male/female) metadata. Opinions would be welcomed. Thanks. Carcharoth (talk) 02:05, 11 October 2008 (UTC)

I (Carcharoth) split this general comment off from the above announcement by me. Carcharoth (talk) 14:36, 11 October 2008 (UTC)

I'm not crazy about the use of metadata on Wikipedia. (Metadata has a double use: it can be used for auto-generating technical terms – and male/female isn't too technical – but it can also be used for "screen scraping" as used by personal information gatherers, identity thieves, and spammers. It is also a "what you see is not what you get" form of coding, or maybe I should say "what you don't see is what you get". I think that some day we'll have to consider whether metadata should be officially banned on Wikipedia, if only because it is [or could be] made redundant by existing Wiki features, and I'd be in favour of that.) We already use categories, a built-in feature of Wiki software, and the information you're seeking could be found if we used the category feature in biographies. --A Knight Who Says Ni (talk) 12:27, 11 October 2008 (UTC)

Metadata should be encouraged! I don't understand what you're on about in terms of identity theft. — Werdna • talk 12:54, 11 October 2008 (UTC)

As much as I dislike people who say "go do a Google search" as a response, a Google search of "metadata controversy" could be an eye opener. --A Knight Who Says Ni (talk) 13:11, 11 October 2008 (UTC)

Have you read metadata? I'm talking here about the organisation of article data (information in the article, not the true metadata such as article history and edits) using tags. Data on its own tends to collapse into untidy heaps. I agree that existing and future Wikipedia methods should be used, but banning metadata will never happen, if only because some data is metadata. See Wikipedia:Metadata (currently in a sorry state, but being expanded) for more. My personal interest is in at Wikipedia:Biographical metadata, though I also take an interest in the geographical side of things. Examples of metadata systems used at the moment to create synergy between different applications are the one where Wikipedia tags appear on (Google?) maps, and the links taking you to a map in general. The ISBN system is another one. Carcharoth (talk) 14:36, 11 October 2008 (UTC)

It's OK as long as it does not force additional coding on the editor and does not worsen readability of wikitext in edit window... but then who really cares? it just exists somewhere in the background, like a systme clock. Or ? NVO (talk) 18:09, 11 October 2008 (UTC)

The "additional coding" being a burden to the editor is a problem, I'll admit. The best systems would (and some do, I think) allow non-technical editors to add stuff in plaintext, and for technical editors to wrap the data in tags. Unfortunately, if the tags are not visible, maintenance is difficult. If they are visible, then editors get put off editing. Tricky. Carcharoth (talk) 19:17, 11 October 2008 (UTC)

The problem is the years of putting everything in the wikitext of articles. Ideally, much of this should be moved out of articles, to be edited separately. If its stored somewhere other than pagetext, it can also be searchable within Wikipedia. The Geodata extension I'm planning, which I've yet to start working on, would be a start to this, moving coordinate data out of the pagetext and storing in its own database table for easy searching within Wikipedia. Mr.Z-man 01:41, 16 October 2008 (UTC)

• Suggest moving this discussion to Wikipedia talk:Metadata. Carcharoth (talk) 14:37, 11 October 2008 (UTC)

There doesn't seem to be a WP:WARN for adding to an article in a language other than english. The closest one is uw-english, but it's intended for non-english communication on talk pages, rather than non-english additions to articles. Additionally, uw-english is only available in english, which is unlikely to be helpful in a situation where communication is being attempted in a person that may have only a basic grasp of the english language.
I propose:

• That a standard warning series of templates be created for this situation.
• That each template contain links to a translation of said template into as many languages as possible.
• That a similar multi-lingual template be created to replace uw-english.

I eagerly await the community's input. Horselover Frost (talk) 08:54, 11 October 2008 (UTC)

Sounds like a good idea. I wonder if there is already something like this at one of the other Wikipedias. --A Knight Who Says Ni (talk) 12:14, 11 October 2008 (UTC)

Is there any particular reason you didn't post this at WT:WARN? You also overlooked {{uw-notenglish}}. The main issue I see here is getting people to actually write translations of the templates. Anomie⚔ 14:13, 11 October 2008 (UTC)

I did overlook that one. However, it is also over-specialized (in this case, just for the creation of new pages). What we need is a generic warning for inappropriately using another language in article space. (Also, I posted the idea here rather than at WT:WARN because implementing it in the various languages would require more editor resources than WikiProject user warnings is likely to garner.) Horselover Frost (talk) 21:25, 11 October 2008 (UTC)

This could be a joint venture with other languages as well. The translations could be stored at Meta and then each language has its own template with links to the translations. Anyone from one of the other languages could write the translation, which could then be added to the templates. -- Imperator3733 (talk) 19:25, 11 October 2008 (UTC)

Have you taken a look at Category:Poor English welcome messages? I've used the en-es one on a couple of instances, and I don't know if we need to start escalating welcomes (which are pretty much level 1 warnings) to higher level level warnings once the users have had that first notice. -Optigan13 (talk) 22:03, 11 October 2008 (UTC)

Whatever Template:Welcomeen-es is supposed to be, it is really, really poor Spanish. SandyGeorgia (Talk) 22:06, 11 October 2008 (UTC)

Should we run the set of messages by WP:Translation by someone with a strong knowledge (xx-4 or xx-5) for each language, or is there a better place to find a set of translators to review those templates? Still, does anyone thing there is a need for multiple levels of (hopefully well-written) notices for people who submit non-english articles? -Optigan13 (talk) 22:48, 11 October 2008 (UTC)

I would think having an xx-4 or xx-5 do the translating would be fine and we should be able to use WP:Translation. As far as multiple levels, I would think two levels would be fine for now. If needed, we could always add another level. -- Imperator3733 (talk) 05:58, 12 October 2008 (UTC)

I've gone ahead and requested Wikipedia:Translation/Template:Welcomeen-es, although I'm not sure that is the right forum, but this is an unusual request, I was even thinking this might be somethink for meta to handle and create a series of templates where the languages and the different wikimedia foundation projects swap out. -Optigan13 (talk) 04:35, 13 October 2008 (UTC)

Someone made some tweaks to the Spanish welcome linked above, but it still has fundamentally flawed Spanish: yes, if there's a group somewhere on Wiki that has time to go through and address these issues, and if that template is a representative sample, they need serious and sustained attention. SandyGeorgia (Talk) 22:04, 13 October 2008 (UTC)

Although I can only read the English part of these templates, their patronizing tone is a disgrace. "Did you know there's a Dutch wikipedia? We don't really care that you already have 10,000 edits there, just beat it." Is it possible to say the same in less offending manner? NVO (talk) 18:51, 14 October 2008 (UTC)

Ok, found a diff for when I've used this diff. In this instance they were putting up an ad for their facebook application, so in combination with spamming, they were putting the whole page in spanish multiple times Sandbox diff. So as opposed to repeatedly telling them in templates they couldn't understand anyway that they need to stop spamming, I decided to template them to head over to es.wikipedia where they could tell them no in a way they would understand. Yes, welcoming any experienced user with a level one template or many of the templates can be seen as condescending, but I'm not sure that's the case when this is used. I've brought this up at meta:Wikimedia Forum#Welcome message templates to point to wiki projects in other languages since I think that may be the better venue, and they may be able to handle the wording and improving translations. -Optigan13 (talk) 09:15, 15 October 2008 (UTC)

Just as we have an {{editprotected}} template, how about {{editintricate}} for the talk pages of template pages with {{Intricate template}} in them? This would be used for templates which are not necessarily protected, but are just incomprehensible to all but the most technically savvy. A corresponding group or watchlist could be set up for people to watch for {{editintricate}} requests.

Thoughts? It Is Me Here (talk) 20:59, 15 October 2008 (UTC)

Probably unnecessary. Most people give a simple copy-paste template so the work is done for the admin (and I would've requested that if there wasn't one, being a technical n00b myself). If the requester can't do that, the edit probably shouldn't be performed anyway, as the {{editprotected}} should only be used after testing has been performed in a sandbox. PeterSymonds (talk) 21:27, 15 October 2008 (UTC)

I suppose we could make {{Request edit}} more generic. MBisanz ^talk 21:52, 15 October 2008 (UTC)

Hi

I have proposed some recommendations as to requirements to be a contactor on the talk page of Abuse Reports, being active there myself. Due to the nature of the work we do there and the fact that vandals (long-term or otherwise) quite often show up on their own abuse reports, I’m concerned that there is a fundamental flaw, it is currently too easy for vandals and other [ab]users to undermine the success of that forum's goal as well as people who are in-experienced. The most common way would be "Lets not and say we did" For this reason I would like to discuss and propose some guidelines for contactors only (for now).

Anyone who has worked at Abuse Reports or has an interest in it (or anyone else) is invited to discuss my proposal and / or make proposals of their own. Thanks   «l| Ψrometheăn ™|l»  (talk) 04:25, 16 October 2008 (UTC)

Sorry if this is an old horse I haven't really been involved in the numerous previous discussion about this area. I'll start with an example:

Take the recently created article Branchland, Virginia, it reads "Branchland is an unincorporated community in Albermarle County, Virginia." it is part of a series of several dozen articles (see Template:Albemarle County, Virginia), the majority of which read "XXXX is an unincorporated community in Albermarle County, Virginia.". These are all perfectly acceptable stubs with the possibility of expansion. Imagine though if you were an individual who - for whatever reason - was trying to research the different unincorporated communities of Albermarle County, Virginia and wanted to use Wikipedia. Maybe you know about the previously mentioned Branchland and manage to find its article. Finding the article you're disappointed to see that the article doesn't contain much information but heartened when you look at the navigational template and see the numerous other articles that are available. After clicking through the articles you manage to find a few (such as Free Union, Virginia) which have additional information but dozens more which only confirm the existence of the place.

Having to go through each and everyone of those articles seems like an unnecessary use of time and people wanting to use this area of the encyclopaedia might be better served if articles of this type were arranged into a list (i.e. List of unincorporated communities of Albermarle County, Virginia). The list could incorporate the names and geographic coordinates of all the communities (such as in List of United Kingdom locations: Aa-Ak) and when reliably sourced information about the different places becomes available a separate article could be written (the entry in the list could then be blue-linked and added to the appropriate navigational template). This could save anyone researching the topic from having to trudge through links that don't provide any additional information. I've used a very recently created group of articles as an example so I apologise if it not the most typical, however after randomly clicking through Category:Unincorporated communities in Virginia it does appear that there are similar short stubs elsewhere and that "listification" - at least in the short term whilst articles are being developed - might be beneficial. Again I apologise if I've misinterpreted the situation from an atypical group or am just rehashing old discussion Guest9999 (talk) 21:34, 13 October 2008 (UTC)

This is already done with some articles at least, with any articles split out using {{seemain}} - an example is something like Suburbs of Dunedin. However, for the most part, if there is a good chance of something being extendable beyond stub level then it is usual for the stub to be created for later expansion. In any case, there's nothing wrong with having both a list and the stubs, though it wouldn't help that much in the situation which you describe. Grutness...wha? 22:06, 13 October 2008 (UTC)

Guest9999, I find the 100+ one-line stubs linked to on Template:Albemarle County, Virginia absolutely sickening. I'm sorry, but they are. They contain zero useful information and they would be much better suited as a list as you recommended as you suggested with these names redirecting there. There are no coordinates, population, or any other useful information on any of these articles. While yes, they exist, they are no more than very small unincorporated communities for which there is little to no information provided by USGS or the Census. Theoretically they could be expanded, but a much better alternative at this point would be a list. I have no problem with articles on unincorporated communites, but I do have a probem with one-liners. Give me the word, Guest9999, and I'd love to whip out AWB and merge these into a single list. Reywas92^Talk 20:47, 15 October 2008 (UTC)

These articles are generally created en mass by a small group of very dedicated users. If there is a consensus to create lists rather than stubs in instances like this I think it would be better to ensure that that is how they're created in the future. Obviously any editor is free to make bold edits which can include merging and redirecting content but I think it would be better to draw up some kind of general guideline if potentially hundreds or thousands of articles are involved. Previous discussions have shown there to be a consensus that every location is includable; now that the results of that discussion are being implemented I think it might be worthwhile to look at how such material should be presented and developed within the encyclopaedia. As I see it the current situation is potentially good for article development but not so good for today's reader. Listification would allow for the same information to be included in a way that would be beneficial to anyone using the encyclopaedia today whilst still allowing article development once additional sourcing is found. It might mean that it took an extra couple of clicks to split off and add content to an article but currently it would take dozens of extra clicks for someone researching the area to see the same information as could be provided by a list. Guest9999 (talk) 22:00, 15 October 2008 (UTC)

See Wikipedia:Notability (Geographic locations), which is still a proposal. -- John Broughton (♫♫) 14:17, 16 October 2008 (UTC)

Lists are going to be the default construction in the WP:GEOBOT project, FWIW Fritzpoll (talk) 14:20, 16 October 2008 (UTC)

Thanks for the links, it's hard to come up with proposals when the Community's always one step ahead. Guest9999 (talk) 16:55, 16 October 2008 (UTC)

Have you ever been reading a diff on a talk page and said, "Hmm...I think I'll look at this in context," only to search up and down the page for the actual post because all it tells you is that the post is in line 1,037? I propose a link on (or by) each green box in a page diff that will take you down to where the addition is in the body of the page. Thoughts? SunDragon34 (talk) 06:51, 14 October 2008 (UTC)

Try the user script User:Cacycle/wikEdDiff (cross-browser compatible) which is also included in the gadget wikEd (Firefox, Safari, Chrome). It does not link but gives you more context. Cacycle (talk) 23:16, 14 October 2008 (UTC)

Copy a line of text from the diff, then use your browser's Find command (Command-F or Control-F, usually) to instantly find where on the page the diff is. EVula // talk // ☯ // 04:51, 17 October 2008 (UTC)

on the main page of www.wikipedia.com, when we type in a keyword to search, we need to type in the language too... can't we just search without specifying a language?

for example, if we search for 李克勤 on google, we don't really need to specify the language, because it is taken as UTF-8 and there is a perfect 1 to 1 match of those characters in UTF-8. There is no ambiguity...

is it because the content portion of wikipedia is so big that we want to limit the range of search? won't building a good index solve that problem? or otherwise, can we just search for all the "titles" of the whole wiki database if the user choose not to specify a language in the main box, and then down below, there is a more extensive search box where users can enter the keyword and then specify the lanugage as well? thanks.

You can search all language wikipedias at once with Google. Algebraist 08:39, 10 October 2008 (UTC)

Automatic language selection on the home page based on computer's local settings is very annoying. My computer has foreign settings, but in 99.9% of my searches I need to browse the articles in English. It is annoying to have to select English every time I open wikipedia.org. I don't want to be switched automatically into the other language.

You can't really search in www.wikipedia.com, since that's just a redirect to the actual address, www.wikipedia.org. *Dan T.* (talk) 20:39, 10 October 2008 (UTC)

If you want English specifically, then what are you doing at www.wikipedia.com or www.wikipedia.org in the first place? Go to en.wikipedia.org. Algebraist 23:12, 10 October 2008 (UTC)

Or just change your browser's preferred language to English. Firefox at least lets you have one language for the user interface and another for web content if you'd like. —Remember the dot ^(talk) 23:15, 10 October 2008 (UTC)

I agree with you, I'm having such problems too..... so anonying... --Jaswonghk (talk) 09:14, 17 October 2008 (UTC)

When I read an article, I tend to mentally emphasise linked words inside my own head. I'm sure if I read it out aloud I'd sound like a complete retard :P Is there some script that will display blue and red links in black text? It should preferably have a button somewhere on the page to quickly toggle between black and red/blue. This would allow one to read articles more naturally, as nature intended :)

When I read an article, I tend to mentally emphasise linked words inside my own head. I'm sure if I read it out aloud I'd sound like a complete retard :P Is there some script that will display blue and red links in black text? It should preferably have a button somewhere on the page to quickly toggle between black and red/blue. This would allow one to read articles more naturally, as nature intended :) Zunaid 10:19, 16 October 2008 (UTC)

While I'm on the point, can we have a similar button to toggle the display of the reference superscripts on/off? Zunaid 10:19, 16 October 2008 (UTC)

It would defenently be possible, I would reccomend you post this at Wikipedia:WikiProject User scripts/Requests though. More likely to run into someone willing to help you write that script there I think. --Sherool (talk) 12:16, 16 October 2008 (UTC)

Doing both of these things is trivial with CSS:

.reference {display: none;}
div #bodyContent a {color:black;}

Will do exactly what you want. The first statement hides completely all references, the second turns all links (external and internal) within the page text black. Add these two lines to your monobook.css to enable this restyling. Having a button to toggle it on and off, however, is a bit more tricky. Happy‑melon 13:14, 16 October 2008 (UTC)

Script request cross-posted to Wikipedia:WikiProject User scripts/Requests#Option to hide wiki-links in articles / option to hide references' superscripts. Thanks Happy Melon, however I'd really like a button to quickly toggle between the two. This would allow one to read an article normally, but still be able to quickly check out where the linked articles are.

p.s. does anyone else experience this phenomenon or is it just me? Zunaid 13:32, 16 October 2008 (UTC)

Zunaid: Yes, it is just you. Nah, kidding, it is a well known phenomenon. We even have a name for it: "The sea of blue effect." And we often say: "Avoid the sea of blue effect, only link what is relevant."

--David Göthberg (talk) 14:20, 16 October 2008 (UTC)

Sorry, but there's nothing we can do to prevent you from sounding like a retard. ;)
All seriousness aside, if you're seeing too many wikilinks, that's indicative of a problem with the article that needs to be addressed, rather than changing a setting so it doesn't bug you as much. EVula // talk // ☯ // 04:48, 17 October 2008 (UTC)

It has nothing to do with the number of links, rather it is the very presence of links themselves that is the problem. One is naturally inclined to emphasise words that appear different to the surrounding text. It is distracting. Zunaid 07:48, 17 October 2008 (UTC)

Is it just me or did someone change the navigation bar significantly:

• There is no longer an "interaction" box
• There is no longer a link to "Featured Content" :(
• The search box is now lower down on the page :(

I don't remember seeing anything about this anywhere - Community bulletin board, Signpost, Village Pump. Anyone know what's going on? Kaldari (talk) 19:01, 16 October 2008 (UTC)

Seems normal to me. Did you change your skin in the preferences?—RJH (talk) 19:38, 16 October 2008 (UTC)

The sidebar was changed. I had Main Page open before I went to class, and when I came back I opened up another page. When I noticed I had it open in 2 tabs, I went to close one, but then I noticed the changes. As far as I can tell, the change was between 18:00 and 20:00 UTC on October 16, 2008. Here's the changes:

There are quite a few changes. I don't remember seeing any discussion, though. -- Imperator3733 (talk) 20:21, 16 October 2008 (UTC)

Looks like someone changed it back <shrug> Kaldari (talk) 21:26, 16 October 2008 (UTC)

This is weird. How would someone change the sidebar text and who has access to it? -- Imperator3733 (talk) 03:03, 17 October 2008 (UTC)

There are exactly 846 people who can edit the sidebar. EVula // talk // ☯ // 04:46, 17 October 2008 (UTC)

Well, it seems most of us didn't notice any change. But just in case: I checked the three files that most likely could have caused that: MediaWiki:Sidebar, MediaWiki:Common.js and User:Kaldari/monobook.js. And none of them have been edited for several weeks now.

And the 846 people that EVula mentions are the admins.

Kaldari: My guess is that you perhaps were looking at the main page for some other MediaWiki project?

--David Göthberg (talk) 05:22, 17 October 2008 (UTC)

No, it was here on en-wikipedia. Unless both Kaldari and I are going crazy, it was changed. I only noticed it by accident, though (as I said above). If I hadn't had the old tab open, I most likely wouldn't have noticed. -- Imperator3733 (talk) 06:19, 17 October 2008 (UTC)

Well, I checked both of yours /monobook.js and you each have a call to a script in there but it is different scripts so it is unlikely that is what caused the change for both of you. There are several other javascripts loaded here at Wikipedia, so an edit to any of them could have caused it. And of course, a change to MediaWiki itself could have caused it.

But hang on, I just checked one more thing. The list of menu items you show above is the default list for the MediaWiki sidebar. So seems Wikipedia did get some hiccups and couldn't load the MediaWiki:Sidebar file for a short while, and thus gave you the default for the sidebar.

--David Göthberg (talk) 06:55, 17 October 2008 (UTC)

That could explain it. Problem solved. Thanks. -- Imperator3733 (talk) 14:38, 17 October 2008 (UTC)

Discussion appears to have petered out on the latest proposed process for removal of adminship. A straw poll has been started to assess community opinion on whether or not to proceed.

• Proposal: Wikipedia:Removing administrator rights/Proposal
• Straw poll: Wikipedia talk:Removing administrator rights/Proposal#Straw poll

Your participation is welcomed. TenOfAllTrades(talk) 15:33, 17 October 2008 (UTC)

I posted here a few months back on the possibility of a bot patrolling certain list articles or list sections and reverting the addition of redlinks, as PseudoBot currently does to the Births and Deaths sections of the date pages. I've since put in a proposal for such a bot. The selection of articles to be patrolled and the policy of operation of the bot is under discussion. Your comments on the discussion there would be welcome. Pseudomonas_(talk) 17:22, 17 October 2008 (UTC)

When editing a page, it is difficult to read a section with many references. Couldn't we change the way the editing window looks? For example, the text between <ref></ref> tags could be shown smaller or in a different color. Emmanuelm (talk) 18:10, 15 October 2008 (UTC)

I've been thinking about this. There should be a button above the editing area where you can collapse or expand references.

• Expanded form: <ref>[http://blablablablab/balablabal.pdf], blabla, bal, balabal,bala, 1998</ref>
• Collapsed form: <ref>

I believe this functionality should be provided by an extension or the mediawiki software. Eklipse (talk) 20:07, 15 October 2008 (UTC)

This would be very difficult to do 'internally', since the page text returned and displayed in the edit window is, by definition, plain text. Trying to apply markup to it would inevitably result in that markup being transferred to the saved page. Any solution to this issue would require making the editform more than a simple textarea, which is unlikely ever to be done internally. There are external editors, however, that have all sorts of bells and whistles attached. Happy‑melon 23:38, 15 October 2008 (UTC)

I guess one thing that could be done would be to have a referencing system where all the references were typed out in the references section at the end of the article and only links through footnotes (which could be less obtrusive) were included in the main body. I don't know if it would be a great system to work with in practise though. Guest9999 (talk) 23:59, 15 October 2008 (UTC)

Mangus Manske has created something that does provide much cleaner editing. If his script was implemented as a gadget, it would make it much easier for newer editors to implement. -- John Broughton (♫♫) 14:10, 16 October 2008 (UTC)

I'd wonder if we wouldn't be able to cover most of our usual functions using WYSIWYG interface. Granted, there are certain elements which would be problematic: templates and ParserFunctions would probably have to be either boxed off as virtually unpredictable, or dynamically rendered on the page (undoubtedly a computationally expensive function). Most elements would be simple to cover, however: the most basic formatting, section headers, and references could be easily ported (Knol's enviable WYSIWYG editor serves as a good proof-of-concept in this respect) with negligible loss of functionality. As long as unpredictable code can be boxed off or otherwise dealt with, we could cover most functions and fill in the others individually as code became available. Here's an example of what I'd imagine it would look well as:

Actual source: Here is some '''bold text''', ''italicized text'', and, {{damn it, my template is boxed off,|including=its|parameters}}.

Rendered in editor as: Here is some bold text, italicized text, and, {{damn it, my template is boxed off,|including=its|parameters}}.

It would probably be possible, though granted I admit my lack of a working prototype or the skills to build one: this would be a small matter of programming :P. {{Nihiltres|talk|log}} 18:35, 16 October 2008 (UTC)

In the meantime, Emmanuelm, if you use Firefox, then try the WikEd gadget (you can find it under My preferences:Gadgets), which has many helpful features in the edit window, including turning the refs a pale grey. I always use Firefox for WP now, as I can't do without it. Gwinva (talk) 06:38, 17 October 2008 (UTC)

There are WYSIWYG editors out there for MediaWiki - see the relevant section of the editor's index. -- John Broughton (♫♫) 16:18, 18 October 2008 (UTC)

Interesting. I hadn't seen those before. FCKeditor in particular seems like it is worth looking into, though from what I can tell there are issues: in particular, difficulties with images and templates in terms of the interface to insert them, and issues with the WYSIWYG part: wikitext typed into the rich editor is rendered on save while appearing dead within the editor (meaning that you don't get what you see, some of the time.) As it has a good "optional" setup that appears to fail gracefully to the normal text-area editing, I'd support it if some of the kinks were worked out: in particular, I mean the issues with inserting images and templates. {{Nihiltres|talk|log}} 17:01, 18 October 2008 (UTC)

Personally, I think instead of trying to make all the crap in the edit box look nice, we should just get it out of the edit box, or at the least rearrange it. Things like infoboxes, categories, interwikis, and metadata templates like {{coord}} could be entirely separate, things like refs could be defined in the references section and only the <ref name="foo"/> would be in the article text itself. The problem with wikitext isn't a lack of a WYSIWYG editor, its years of putting everything relating to the article into the wikitext. Mr.Z-man 18:08, 18 October 2008 (UTC)

Since we have an abortion law article, and we have abortion articles by country, why not also an abortion policy by political party article? It's relevant, since it's a very heated subject.

It would be a series of tables by country. The vertical on each table would be the major political parties in the country, and the horizontal would be either an "x" or check-mark, based on if the party is "officially pro-life", "officially pro-choice", "no official policy", "no official policy, typically pro-life", or "no official policy, typically pro-choice". What do you think? -- LightSpectra (talk) 23:21, 18 October 2008 (UTC)

We should not be using the terms "pro-life" and "pro-choice". — Werdna • talk 23:28, 18 October 2008 (UTC)

Actually, I'm not sure it's that simple - whereas in the US it's a big "taking sides" binary issue, in a lot of countries it's more nuanced, with discussion over time limits, methods of abortion, who approves the procedure, and so on. I think summarizing it in the way you suggest is applying one country's model of politics to all others. Pseudomonas_(talk) 09:13, 19 October 2008 (UTC)

Another good reason for not using the American euphemistic terminology. — Werdna • talk 10:04, 19 October 2008 (UTC)

New namespace. Notability out the window, almost anything can be included, and at a more technical level. e.g. video game enemies get their HP, weapons, attacks, defense, strategies listed, in their own article. "list" articles would not be included as normal articles, but linked sparingly (user pages, normal articles with very little information could link to more poorly sourced "list" articles. I mean, I'd rather have poorly sourced information rather than none at all.). If not this, please, please please please make a new wiki with this in mind. And that's my uhh... 44 cents, adjusting for inflation. CompuHacker (talk) 11:00, 19 October 2008 (UTC)

To be honest I don't think a list space would be a terrible idea but what you seem to be proposing is an additional encyclopaedia to run in parallel with the current English language Wikipedia to act as a dumping ground for content that doesn't meet the threshold for inclusion in mainspace. I don't see how that would really help the project as Wikipedia is not an indiscriminate collection of information. Guest9999 (talk) 01:43, 20 October 2008 (UTC)

Outside of Wikipedia, such information can be found in StrategyWiki. There is no need to create a whole namespace for poorly-sourced, unencylopedic content. - SigmaEpsilon → ΣΕ 02:05, 20 October 2008 (UTC)

This proposal refers to internal links to already created pages. Entering text into an editor, we can create an internal link by adding double square brackets around a phrase which agrees with the title of a wiki page. Couldn't such agreements be pointed out to us automatically? A background color, for instance, could highlight phrases like "internal links" after having typed them into the editor with the double square brackets being set when double-clicking on the highlighted phrase. Every possible internal link could be represented that way and we would just have to double-click those which we want on the page. Another background color could be used for possible links to disambiguation pages, which would give us the opportunity to adjust the possible links so that they would link to specific pages rather than disambiguation pages. Of course, internal links would still have to be created the old way if we wanted phrases to link to pages with which they do not agree, i.e. if piped links are required.--Emaster82 (talk) 23:43, 17 October 2008 (UTC)

But Wikipedia has articles on lots of common words. Almost everything would be highlighted. Dendodge|Talk^Contribs 12:29, 18 October 2008 (UTC)

That's not the case in the smaller wiki I use to contribute to. The proposed feature would be rather helpful there. Wikipedia can evidently do without it, though.--Emaster82 (talk) 14:40, 18 October 2008 (UTC)

You should bring this up at Bugzilla. This page is for proposals for en-wikipedia only. -- Imperator3733 (talk) 15:25, 18 October 2008 (UTC)

I first thought it might be a good idea for wikipedia, too. Bugzilla seems to be for reporting bugs only. Or do they also deal with proposals?--Emaster82 (talk) 14:25, 21 October 2008 (UTC)

(This message was originally posted on MediaWiki talk:Revision-info, but I realized that the Village pump may be an more appropriate forum)

Currently, when I go through articles history, I often have to see how an article has improved since a certain date; but there is no easy way to do so using the existing message. (I.e. I have to insert "&diff=curr" in the address bar) Is it possible to update the message to read as follow (Without it having the external link icon, of course)? G.A.S^talk 06:23, 17 October 2008 (UTC)

That link would be a good idea, as long as it doesn't have the external link icon. I would assume there's some way of removing it, probably with CSS. -- Imperator3733 (talk) 15:20, 18 October 2008 (UTC)

<span class="plainlinks">[link]</span>. Dendodge|Talk^Contribs 16:14, 18 October 2008 (UTC)

Maybe I'm wrong, but it doesn't look like there is any way to do this without a software update. There isn't a parameter for the revision id being viewed, and {{REVISIONID}} doesn't seem to work in the message. OTOH, just below the box you should see "(diff) ← Previous revision | Current revision (diff) | Newer revision → (diff)", and each of the "(diff)" links does what it seems like it should. Anomie⚔

The software fairy paid a visit. You guys owe me a cookie. — Werdna • talk 01:28, 20 October 2008 (UTC)

Here you go - have as many as you want. -- Imperator3733 (talk) 01:36, 20 October 2008 (UTC)

I started enacting this update (you don't need <span class="plainlinks"></span>, by the way, as we manually encode the <a> elements for this message, meaning they don't get the special CSS for external links applied to them automatically), but realized quickly that we have the "(diff) ← Previous revision | Current revision (diff) | Newer revision → (diff)" that Anomie mentioned. Do we really need this update? (if yes, I'm still willing to implement it.) {{Nihiltres|talk|log}} 15:58, 21 October 2008 (UTC)

I have a question (or proposal?) about some fundraising that I would like to do that involves Wikipedia. I'm concerned that it might create a conflict and would like some feedback. Since June I have been working on revising the lemur articles (under WP:PRIMATES) and have started to make good progress. (See Ring-tailed Lemur and Ruffed lemur for examples of my work.) I have also been selected by Azafady to volunteer in Madagascar between October and December 2009. This volunteer opportunity is highly relevant to my career goals, so I am very excited.

In order to go and help with their conservation work, I need to raise at least £2,200 (~$4,000) to fund my volunteer activities. In the past, people have come up with many creative fundraisers for Azafady, including sponsorships for marathons, climbing mountains, etc. Since I am working to enhance as many lemur articles as possible, I was thinking I could ask friends, family and my local community to pledge donations for every article re-write, successful GA review, DYK and successful FA review. (And if Wikimedia were especially generous, maybe I could mention it on my user page or on the WP:PRIMATES page.)

In short, I was hoping to put my volunteer fundraising and Wiki editing together in order to benefit everyone. Not only would I get to pursue my dreams in Madagascar, but the Malagasy people would benefit from my volunteer work, lemurs would benefit from both the conservation work and a more informed public, and Wikimedia would get numerous GAs and FAs under WP:PRIMATES.

I realize that Wikimedia Foundation is non-profit and in the business of soliciting its own donations. I am hoping this fundraiser of mine will not cause any conflicts. If so, maybe we can work something out? What does everyone think? (BTW, I've sent a letter to Wikimedia specifically asking this question, and a volunteer gave me a tentative thumbs-up, directed me here to get more feedback from the community, and told me a more official note from Wikimedia was forthcoming.)

Thank you for your time. - Visionholder (talk) 04:12, 20 October 2008 (UTC)

• Seems a noble idea to me and, though I know nothing about this area, I'd be surprised if there wasn't a way to sidestep any potential conflicts. From Wikipedia/Wikimedia's position, I guess it's tantamount to receiving sponsorship on the understanding that Wikipedia articles will benefit. I remember seeing a page here somewhere that listed users offering incentives (mostly financial) to other users for working to improve articles, which seems in the same ballpark and presumably has Wikipedia/Wikimedia's blessing. If the scheme gets off the ground, add my name to the list of people to inform and request sponsorship from. Sardanaphalus (talk) 05:07, 20 October 2008 (UTC)
  • Wikipedia:Bounty board, MyWikiBiz, take your pick --NE2 07:07, 20 October 2008 (UTC)
    • Wikipedia:Rewards_board seems to be another one. Unfortunately, none of them direct attention the correct way. I don't want to solicit people to edit the lemur pages; I want to edit them. The money also needs to go to Azafady (under my donation account), not Wikimedia. And MyWikiBiz definitely seems like the wrong way to go, from what I can tell. Anyway, I may wait until I receive an official reply from Wikimedia about if and how to proceed. In the meantime, I'll keep watching here for feedback. (And thank you, Sardanaphalus! I will keep you posted!) - Visionholder (talk) 23:41, 20 October 2008 (UTC)

In an effort to follow the ruling of the Arbitration Committee to "work collaboratively to develop a generally accepted and applicable approach to the articles in question" in Wikipedia:Requests for arbitration/Episodes and characters 2, I am proposing a sitewide fiction survey in order to accomplish that. The first draft of the survey is in my userspace and I would appreciate feedback on it before it goes forward. Any comments, suggestions, criticisms, edits to the survey, etc are welcome. Thank you. --Pixelface (talk) 04:17, 22 October 2008 (UTC)

Problem. We have this huge list of stub templates, which seems to ever grow longer, and is basically used to categorize "stubs". However we already have a category system, which as far as I can tell is perfectly fine (maybe not browsing them though, see below). So in essence we have two overlapping categorization systems which leads to duplicate work by the Wikipedians who perform the already pretty tedious tasks of handling new/raw articles. Besides, the stub categorization is not as comprehensive as regular categories.

Proposal 1.

• Divorce "stubs" from categorization. The relevant information is that the article is a stub, categorization provides the information for sorting.
• Improve category browsing, so filtering stubs in & out is possible.

I would also like to point out that assessment of articles is pretty much generalized now to all articles on Wikipedia thanks to many wikiprojects, yet stubs seem to be a special case, which leads me to another related proposal:

Proposal 2

• Harmonize the rating of articles. Stubs or featured articles, the idea is the same, it gives an indication as to the quality of an article. Sorting and browsing featured articles should be no different from sorting and browsing stubs. Withdrawn per NVO's rationale, I can see how that would not be viable. Equendil Talk 10:01, 25 September 2008 (UTC)

I leave the "how" aside on purpose for now, however Wikipedia:Category intersection might be relevant here. Equendil Talk 10:49, 23 September 2008 (UTC)

I agree with Proposal 1, and would support removing all the stub categories as soon as there is decent category-intersection browsing. Pseudomonas_(talk) 11:37, 24 September 2008 (UTC)

Second that. As for "harmonization", it requires an overhaul of present-day practice when a B grade is granted by a single editor at will, and A grades are issued within wikiprojects (very small groups). As long as this practice continues, there will be differences in treatment of different groups. I don't see how this can be remedied - there's too many A/B articles to be handled trough wikipedia-wide channels like FAR. It needs to be decentralized, so accept the inevitable. NVO (talk) 09:48, 25 September 2008 (UTC)

Agree with Proposal 1. The huge list of stub templates is a liability. We should only have one system of categorization. --Kleinzach 01:09, 6 October 2008 (UTC)

As pointed out below, Proposal 1 would make the whole reason for having stubs - to make it easier for editors to find them - unworkable. There are very good reasons for having two separate category systems, a stub one for editors and a permanent one for readers, and this proposal would render the work of editors looking for a reasonable number of articles to sort through in order to find ones they can expand impossible. It may be a chore to sort stubs in the current way, but removing that system would bee a giant step backwards for ease of editability. I would hope that your support of this proposal is not due to your recent run-in with WP:WSS, Kleinzach, but I would suggest that it became clear during that debate that you did not fully understand the reasons why stubs are sorted the way they are, and that could well be an explanation why you would think that Proposal 1 would work. It wouldn't - at least not in a way that would provide anything but a detriment to Wikipedia. Grutness...wha? 01:18, 6 October 2008 (UTC)

See Equendil's proposal above. A competing system of categorization makes it more difficult for content-contributing editors to locate and maintain sets of articles. I've worked with stubs on five projects - ranging from one with no stub types at all, to one with 40+ (see here) - so I've had a lot of experience of this. One of the problems with the WP:WSS is the assumption by that project that they understand categorization better than the editors who are actually writing the articles. --Kleinzach 02:13, 6 October 2008 (UTC)

Yes, it's Equendil's proposals I'm referring to. They simply won't work in the way that stubs do as far as enabling editors to find stub articles, for the reasons given below. And though you may have had a lot of experience at this, your recent discussions with WP:WSS made it clear you still don't really understand why stubs are sorted the way they are or how they are different from Stub-Class assessments. Equendil's propossals would work very well with Stub-Class assessed articles, but very poorly with stubs. As for WP:WSS's assumptions that they understand articles better than the wikiprojects working on those articles, there are two comments to make: 1) we don't - we regularly discuss the best way to split articles with the wikiprojects concerned (though it has to be admitted that sometimes these discussions have been accidentally missed), and 2) many, if not most, stub types are for areas in which there are no specific wikiprojects. Grutness...wha? 05:09, 6 October 2008 (UTC)

And many of them cover multiple projects creating other problems. --Kleinzach 05:18, 6 October 2008 (UTC)

To the best of my knowledge, no editor has ever brought a complaint to WP:WSS relating to problems causedd by a stub template being used by multiple projects - if they had we would have striven to find a way around such problems. Quite the opposite is the case, in fact, using the same stub type for several projects tends to help when those projects need to work together on articles. You did mention that you found problems with stub types in use on different projects during recent discussions at WikiProject:Opera, but IIRC it was quickly pointed out by other members of both projects how it was actually an advantage, and the split of stubs relating to opera went ahead to the satisfaction of almost everyone related to that project. Again, the proposals laid out by Equendil would work beautifully with Stub-Class articles, which do relate directly to individual WikiProjects; they would however be ineffective with stubs. Grutness...wha? 05:31, 6 October 2008 (UTC)

That's a mischaracterization of discussions elsewhere, but this is not the place for forensics. For the sake of other contributors, please keep on topic. --Kleinzach 05:48, 6 October 2008 (UTC)

My last sentence in the above, which pointed out again that the Proposal confuses and concatenates Stub-Class and stub, is exactly on topic, as it is an important point at the heart of the discussion on this proposal. As to the rest, I was simply replying to your comment about multiple projects using the same stub types - a comment which itself has no bearing whatsoever on the proposal, and is delightfully vague exactly what these supposed "other problems" are (problems which, as I said, have never been commented on at WP:WSS). If you would care to keep to the topic yourself, any responses I make will also be on topic. Grutness...wha? 07:41, 6 October 2008 (UTC)

It's not the purpose of the system of stub types to be "comprehensive". The purpose is to enable sorting of stub-sized articles into categories of reasonable size, according to their primary notability. In order for this to be reified from the permcats directly, one would need not only category intersection, but also category union -- in arbitrary combination indeed; one would need the categories to already exist on all the articles in question, and to have some way of indicating which of those categories are of primary topic-sorting significance. As none of those is presently the case, I don't see such an idea as being foreseeably viable.

Stub-tagging and stub-sorting is also not about "grading" articles in the sense of the ever-more-byzantine "1.0" classification system (which introduced the "stub class article" concept many years after the guideline-defined idea of a "stub", without ever actually clarifying if they were the same or not). Unless the idea is simply to abolish the one in favour of the other, I strongly suggest keeping discussion of the two separate. Alai (talk) 16:39, 28 September 2008 (UTC)

I agree - there is a large-scale misunderstanding over the several different uses the word "stub" has on wikipedia - the proposals above seem to be confounding two of them (stub and Stub-Class, which are entirely different things). Also, as Alai points out, the current system is designed primarily to provide stub categories of a size best suited to browsing by editors. Overhauling the system in the ways suggested would remove that and make the job of picking and choosing stubs to be expanded harder, not easier; an editor might have to search through several permcats to find even a handful of stubs on a relevant subject, whereas now every stub category, theoretically at least, should have between about 60 and 600 articles. Though stub-sorting is a chore, it does provide benefits for editors that the proposals would lose. Grutness...wha? 23:10, 28 September 2008 (UTC)

Support prop 1; this definitely annoys the heck out of me and I agree with the rationales provided. Der Wohltemperierte Fuchs ^(talk) 01:17, 6 October 2008 (UTC)

How about just assign these stub templates to the related WikiProject?

It seems to me that these are similar to WikiProject talk page banner templates, in that they indicate the "type" of article. The difference would simply be to not include the "word" WikiProject in the stub template text. (since it would be placed in mainspace.) So for example, WikiProject Comics places "Comics-related stub" templates.

So essentially, if there isn't a WikiProject, perhaps there shouldn't be a related stub template? - jc37 01:20, 6 October 2008 (UTC)

That would be terrible, and also completely unworkable - first you'd have to work out exactly what is and what isn't covered by a project (something often the members of a project can't decide), and then you'd have to accept that there would be a big pool of stubs that would never be sorted because they fall outside the aegis of every project. Even if you were to accept that, you'd have the problem of stubs which fall within the boundaries of several different projects, and also the problems that would occur when a new wikiproject forms, or when an established wikiproject becomes moribund. There's also the problem that has arisen in the past where editors not part of a wikiproject feel intimidated about editing a stub article if it is marked as being maintained by a specific WikiProject (as the banner templates say). It is vital that editors aren't put off improving articles and are actually encouraged to edit. Stub templates are worded in an attempt to encourage this. Assessment banners, though they do not actively discourage editing, can have this effect due to their connection with a "closed group of editors", i.e., a Wikiproject. Your comment about the similarity with Wikiproject banner templates is, however, true, and is exactly the point that has been made here - that people do confuse the two even though they are different systems. This project arose when assessment templates used "Stub-Class" as one of the assessment levels even though there was already a long-standing stub system in place that was unrelated to it - the system we are currently discussing. Grutness...wha? 05:41, 6 October 2008 (UTC)

Assigning stub templates to the related WikiProject would indeed be good and practical approach. --Kleinzach 02:19, 6 October 2008 (UTC)

Stubs are deliberately kept separate from all wikiprojects for the exact reason you outlined above - that quite often they are to be used by multiple projects. In other cases, there are no relevant wikiprojects for particular stubs. There is a perfectly acceptable system which is used by wikiprojects, but it is not stubs - it is Stub-Class articles, part of the assessment process used by individual projects. Grutness...wha? 05:41, 6 October 2008 (UTC)

What is a stub? Here is the definition used by the Version 1.0 Editorial Team:

The article is either a very short article or a rough collection of information that will need much work to become a meaningful article. It is usually very short, but can be of any length if the material is irrelevant or incomprehensible.

That's it. It's not a categorization system of Byzantine complexity. It's a short article. --Kleinzach 10:51, 7 October 2008 (UTC)

And thus you prove my point. What you've just described is actually a Stub-Class article, not a stub. The definition of a stub is at Wikipedia:Stub. It is through the confusing and conflating of these two completely different definitions that this proposal has been made and moch of the argument in favour of it has been made. As pointed out above, Stub-Class might well work very well with the proposal. Unfortunately, stubs (as defined at Wikipedia;Stub, would not. It would have been better had Stub-Class (often incorrectly shortened to "stub", as here, just to add to the confusion) been called something completely different when the assessment scheme was inaugurated. These points were alluded to by Alai, above. Unfortunately, to do so now would be to increase editors' confusion even more. Grutness...wha? 00:02, 8 October 2008 (UTC)

The definition of a stub at Wikipedia:Stub is:

A stub is an article containing only a few sentences of text which is too short to provide encyclopedic coverage of a subject, but not so short as to provide no useful information.

That's essentially the same definition as offered by Version 1.0 Editorial Team. --Kleinzach 00:32, 8 October 2008 (UTC)

I'll reply to a few objections here :

• "and this proposal would render the work of editors looking for a reasonable number of articles to sort through in order to find ones they can expand impossible" - How so ? An editor would not have to go through the whole list of stubs to find an article, instead he would make use of regular categorization to narrow the subject (listing only stubs mind you)
• "one would need not only category intersection, but also category union". Ok, I don't see that one, intersection would not only provide a way to intersect a current existing category with a unique "stub" category, it would also make a major and much needed category overhaul possible, meaning, as above we would have much better populated "primary" categories that would not need a set union with other unrelated "primary" categories. In fact you would probably want to rebuild the current stub tree as refined intersections for browsing (eg "American actor stubs" -> "American people" & "Actors" & "Stub" ).
• Confusing Stub-Class and stub. As pointed out by Kleinzach, their definitions are essentially the same. While the quite simple concept of a stub evolved into this stub sorting !wikiproject to make up for flaws in category browsing, that's precisely what I'm proposing to address.

I do not advocate nuking stub categorization as long as no viable solution exists regarding category browsing, for that matter I do not advocate nuking stub categorization at all, only to keep stub tagging and categorization separate, meaning that categorization efforts would not be duplicated. It would make little difference to an editor looking for stubs to expand (though they would surely benefit from browsing stubs through full blown categorization).

I also wanted to leave the "how" aside, as the intersection proposal is not necessarily the only one or best one (it would be possible to replace categories with a more simple system of keywords, and/or implement data mining schemes, or make rating of articles an attribute for instance), it is one possibility however, that's workable. I realize it may be too early, the proposal being based on a feature that does not exist yet, but then again, discussing future directions is what proposals are for. Equendil Talk 17:09, 14 October 2008 (UTC)

The proposal was supported by Equendil, Pseudomonas, NVO, Kleinzach, David Fuchs, and jc37. (It was only opposed by Grutness and Alai.)

The consensus was in favour of the proposal. --Kleinzach 07:34, 21 October 2008 (UTC)

• I also oppose the proposal(s) for the technical and organizational reasons put forth by Grutness and Alai. Her Pegship (tis herself) 04:30, 22 October 2008 (UTC)
• I too strongly oppose the remaining proposal for the reasons so clearly stated by Alai and Grutness. - Dravecky (talk) 23:32, 22 October 2008 (UTC)

The idea for this proposal came to me while at Talk:Sandwich. An argument over there was about if a sandwich required leavened bread to be classified as such. This struck me as very odd, as I know that a sanwich is a bit of food between to bits of bread. Even a (wise) proposal by an un-involved user was ignored. This got me thinking about a new guideline: Wikipedia: Common Sense. Here's my (rough) draft:

Wikipedia:Common Sense

Sometimes users can cite policies so much down the slightest wording, that it causes uneeded argument.

E.G. This article states that "milk is milk". It does not cite a reliable source that states that milk is milk. -Mr.Verifiability

These arguments an become long, tedious, and, due to stuborness on both sides, are very diffcult to resolve. The solution is to use common sense.

E.G. Because it is a generally accepted fact that milk is indeed milk as evidenced by the name, among other thing, and there has been no known soures stating that milk is not milk, the article should state that milk is milk. -Mr.CommonSense

This does not mean that all, or even most facts can go uncited. It simply means that basic facts, supported by common sense, do not need to be cited.

There it is. [[User:Tutthoth-Ankhre|Tutthoth-Ankhre~ The Pharaoh of the Universe]] (talk) 19:12, 3 October 2008 (UTC)

Support

1. Support My propsal. [[User:Tutthoth-Ankhre|Tutthoth-Ankhre~ The Pharaoh of the Universe]] (talk) 19:12, 3 October 2008 (UTC)

Oppose

1. We shouldn't need a rule that tells people to use common sense, they should just ... use common sense. That being said, something like this is also open to abuse. One person's common sense is another person's fringe theory POV. Mr.Z-man 19:16, 3 October 2008 (UTC)
2. Mr. Z man says it all. No need for something like this, and it will be misused. Protonk (talk) 05:06, 5 October 2008 (UTC)
3. I imagine that if an explicit "common sense" exception was added to WP:V we would probably observe some creep as to what counts as "common sense". It is much better to simply leave it unspoken that common sense always applies. For all means make it a user essay if you want though, it's not a bad point but I don't think we need another guideline that really brings nothing new to the table and would be heavily prone to abuse. - Icewedge (talk) 07:03, 5 October 2008 (UTC)
4. Common sense is culture-dependent. Obviously, not everyone has seen a sandwich in his life. -- Taku (talk) 02:17, 8 October 2008 (UTC)
5. I believe that would work in theory but fail in practice due to the opposes outlined above. Foxy Loxy ^Pounce! 07:32, 12 October 2008 (UTC)

Commenting

1. One thing I've learned is that common sense is uncommon. Begging the question won't make silly people sensible. - Denimadept (talk) 19:30, 3 October 2008 (UTC)
2. It would be nice to have some sort of common sense guideline. Like this one, Wikipedia:Common Sense. Better still, this one, WP:Ignore all rules. In general, people do use common sense whilst editing here, and for those who don't, telling them to do so probably isn't going to help. Really the best thing to do in a situation where people are being pedantic about the rules, is to point them to IAR and hope that they get it--Jac16888 (talk) 20:06, 3 October 2008 (UTC)
3. As Jac16888 has pointed out, we already have a number of pages that discuss common sense. You'll find more at the "common sense" topic in the editor's index. -- John Broughton (♫♫) 23:22, 3 October 2008 (UTC)
4. While I like the idea, I suspect this guideline would take the prize for the most universally ignored guideline on wikipedia (and that's saying something...). --Ludwigs2 02:24, 8 October 2008 (UTC)
5. In this specific "sandwich" example, I would like to see citations and use of the talk pages, and a resolution with plenty of neutrality and the like. And I'll also say right now that if a "common sense" policy ever were enacted, I would likely be among the first to argue WP:IAR as differing view points and values, or even general diversity across cultural / regional / socio-economocic or any other demographics is the way of life. --Kuzetsa (talk) 23:18, 22 October 2008 (UTC)

The example is pretty poor. "Milk is milk" would never be written in an article.. it's somewhat demeaning to our readers to suggest that they might not know that A ≡ A. However, let's suppose an article said that "Milk is an opaque white liquid produced by the mammary glands of female mammals". Maybe everybody knows that, and maybe we don't need to cite our sources for that "common knowledge". However, what is hurt by citing it? It's a low priority, but if somebody finds a source, then there's no reason not to include it. By the same token, it would be a little silly to remove such a statement from an article. And for those nitpickers who need a policy for everything, I think "mathematical truisms", and "common knowledge" are listed as exempt from citation anyway.

Now, if we had a Wikipedia:No, you don't need to propose a policy for that! policy, then we'd be talking... — Werdna • talk 00:32, 16 October 2008 (UTC)