Wikipedia:Village pump (proposals)/Archive 4

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

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

---

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

Differentiating article quality and completeness from length

The current article assessment scheme lumps length, completeness, and quality together. However, there are some very short articles which are quite complete, either because the topic is very narrow or because very little reliable information can be found (eg. Choco Taco). Such articles are often assessed as stub- or start- class because of their length, an assessment which implies nothing about completeness or quality. However, stub- and start- assessments are often used to indicate the quality and completeness of articles which do have significant room for improvement. Because of limitations on scope and sources, not all articles have the capacity to become FAs, but it would be helpful if quality and completeness were assessed separately from length, so a reader or editor can know if an article is the kind of stub that is incomplete or of poor writing quality or sourcing, or the kind that isn't likely to ever be more than a stub. — Swpb^talk.edits 17:15, 6 November 2007 (UTC)

IMO, all articles should be able to be FAs, if the total body of knowledge on a particular subject only amounts to a couple paragraphs, and the article is well written and sourced, there is no reason why it should fail the FA criteria. Comprehensive is not the same as long. If there isn't enough info on a topic to make more than a 2 sentence stub, the article should probably not exist or be merged into a broader topic or a list. Mr.Z-man 20:47, 6 November 2007 (UTC)

If every article were long, we would be an unusable collection of essays, not an encyclopedia. The beauty of hyperlinking is that you can have a whole bunch of targeted articles and avoid redundant treatment of things within individual articles. I think most articles max out and reach their peak effectiveness at what some people would rate a "Start" class, or more generally, a "B" article. I think I'm agreeing with Z-man, though, it's just a matter of how we would use the terminology. The problem only arises when people think that every article ought to strive for FA status, and conceive of FA as a 30KB article with three images, fifty citations, a three paragraph lead, etc. I mean, how much can you really say about Croxetti? Wikidemo 23:13, 6 November 2007 (UTC)

So you agree then, it's a problem that a short, comprehensive article will often receive an assessment that is meant to indicate an article in need of work. What can we do about it? — Swpb^talk.edits 05:06, 7 November 2007 (UTC)

End the "assessment drives" that so many projects use. People skim over the article for 10-30 seconds and give it a rating. They may have no prior knowledge of the specific subject and it mainly depends on the reviewer. If its short, it will be marked as stub or start class; if it is longer and has plenty of inline citations it will be a B class. The time would be much better spent improving articles, at the least a quick copyedit/spellcheck. But "assessing" articles is easier and since it does more articles (and gets more edits) it looks more productive. Mr.Z-man 05:14, 7 November 2007 (UTC)

In my experience article ratings can bear very little relation to the actual quality of the article. I always assumed it was because they were assigned once and then never looked at again, and then over time a poor article might have become good, or, as sometimes sadly happens, a good article might have become poor. Maybe you're right though. Maybe some ratings are pretty meaningless to start with... Matt 02:48, 8 November 2007 (UTC)

Z-man is right. End the "assessment drives" which do little of value, and in fact actively degrade the quality of the encyclopedia. Last summer there has such a "drive" on the Wikipedia biography project, where teams of people, mostly completely ignorant of the subject at hand, rated article quality: usually they devoted fifteen to twenty seconds per article before tagging them "stub", "start", or "B", clearly looking only at length and whether or not there was an infobox or a picture. It was a ridiculous waste of time and angered a lot of editors, one of whom is writing this. The article "assessments" for the most part, projectwide, are worse than useless. Antandrus (talk) 02:53, 8 November 2007 (UTC)

Of course, I'm not saying assessing itself is useless. If someone takes the time to read the whole article and either has some background knowledge or does some research on the subject, they can do a real assessment of the article and give specific suggestions on improvement besides "make longer, needs infobox, needs picture, longer intro, more sources, etc." Mr.Z-man 16:38, 8 November 2007 (UTC)

In general, I would say that FA's and GA's are good. Beyond that, ratings seem to be rather arbitrary; and just because an article is not rated GA or FA does not mean that it is not very good (so I agree with others above on that point). Antelan ^talk 05:54, 8 November 2007 (UTC)

I wouldn't say Choco Taco is complete. How does it sell? Why is the ice cream low fat? What are related products? Competitors? What has been the critical or commercial reaction to it? Is it a major product of its original company? Of its huge conglomerate? What does "Choco Tacos have been sold at some Taco Bell restaurants" mean - when? why? how many? What about the Taco Bell restaurants that don't sell them - why? Are there different flavors than vanilla with peanuts? Why or why not? They're sold in Italy - famed for Gelato, to such an extent that complete garbage that has never seen an Italian gets called "italian style" - so how do they sell there? What was the reaction to the introduction? Are they sold in other places besides the US and Italy? Why or why not? Many of the references are bare links, they really should have publication dates, author names, and titles. Even so, it's not a stub, since it does have useful references and a picture, but it is no way complete. And note, that's the requirement for B-class, "a majority of the material needed for a completed article." Not a certain specific length, but more than half way to comprehensiveness. This is a collaborative project. That means that other people's opinions matter. Evaluation matters. Note the line at the bottom of the page you're editing: "If you don't want your writing to be edited mercilessly or redistributed for profit by others, do not submit it." Surely if you accept your writing being edited mercilessly, you shouldn't object that much to it being evaluated and critiqued. --AnonEMouse ^(squeak) 20:13, 8 November 2007 (UTC)

Style guide on providing examples

I couldn't find a style guideline on providing examples in articles.

Is there one?

If not, we need one. Wikipedia:Examples - shortcut: WP:EX

Images presented as examples abound on Wikipedia.

As for examples presented in text form, the phrase "For example" came up in a Google-specific search of Wikipedia 137,000 times! "Some examples" turned up 7,400 times, and "Examples include" came up 7,000 times. "E.g." showed up 101,000 times.

The closest thing to a guideline I could find was an essay stub called Wikipedia:Give examples.

The featured article Hoysala architecture includes a list of "some famous" and "notable" examples.

For an article that is filled entirely with examples, see Examples of groups, an expansion page of Group (mathematics).

For a treatment of examples in the real world, see List of mathematical examples.

Policies trump guidelines, and the relevant guideline here would be WP:NPOV. The mere selection of an example has been argued by some to be POV. I tried to include an embedded list of some geographers as examples of participants in the field over at Wikipedia:Featured list candidates, and it was opposed on the grounds that examples were inherently POV. Yet the same article had an image in almost every section which posed as an example of a topic from the respective section, the images selected in precisely the same way as the geographer links, and nobody objected to the pics.

My guess is that, in addition to a style guideline on examples, an exception or clarification to WP:NPOV would need to be made to accomodate the presentation of examples.

I look forward to reading your thoughts on this matter: What should the guideline on including examples in an article say?

The Transhumanist    07:30, 8 November 2007 (UTC)

Vandal tools?

It might be useful to give an indication of a curse word introduced in an edit in the watchlists. The curse word could be drawn from a list. This would invite people on vandal patrol to look more closely.

Also, vandals can sometimes get away with murder by making 2 or 3 or 4 edits in a row, and so that to revert their actions, one has to roll back several edits. Providing tools that alert one to this problem, or to make this sort of revert of multiple edits would be very handy.--Filll 22:14, 8 November 2007 (UTC)

• "Anti-Vandal tools" would be more appropriate header here.
• Having user-specific or project-specific list of "bad words" is an interesting idea, but I suspect it has too many drawbacks. Like using too much server resources, for example.
• Have you seen Wikipedia:Recent changes patrol and meta:Anti-vandalism ideas?
• You can revert multiple edits: go to hisory, select radio buttons, press "Compare..." button, then press "undo" link on the right. Unfortunately there is no predefined edit summary. I have a script to automatically create that summary and I can publish it if you're interested ∴ AlexSm 23:17, 8 November 2007 (UTC)

See Wikipedia:Recent changes patrol#Monitoring where multiple ant-vandal tools are listed. I am not familir with all of the ones listed, but Lupin's Anti-Vandal Tool does just what you are suggesting—it uses the RC feed to check diffs against a list of common vandal terms.--Fuhghettaboutit 23:55, 8 November 2007 (UTC)

Wikipedia:Requests for comment/Anon page creation

Please see Wikipedia:Requests for comment/Anon page creation - let's try and come to a consensus either way on what we want to do about this. Ryan Postlethwaite 01:44, 9 November 2007 (UTC)

Have history for individual sections of a page

It should be possible to access the history of individual sections of a page. This would save considerable search time!

This describes a change to the MediaWiki software, which should be filed on Bugzilla rather than here. That said, although it would useful, this idea would very difficult to implement. How do you deal with changes, additions, and removals of page sections? — Jonathan Kovaciny (talk|contribs) 16:18, 8 November 2007 (UTC)

Effectively it is possible by transcluding the sections. However, then you lose the combined history of the whole page. A new software feature could be the possibility to merge the history of a page and those of the pages transcluded in it.--Patrick 16:38, 8 November 2007 (UTC)

The clear and obvious disadvantage would be that such sections are not necessarily permanent in any article, so such a limited search would be of only limited usefulness. Objectionable content could be moved to a different section to escape observance for instance, and that wouldn't appear in a "section search". John Carter 20:25, 8 November 2007 (UTC)

The probability of developers being willing to rewrite huge chunks of the MediaWiki software to be section-based rather than page-based - even if that were a good idea, which it's not (consider how easy it is today to move text from one section another, versus two separate transcluded sections) - means that the probability of this happening is somewhere between nil and zero. (And I have no idea what "saving considerable search time" means.) -- John Broughton (♫♫) 01:50, 10 November 2007 (UTC)

I suppose this refers to finding the edit where a particular change was made, to see who made it and possibly find an explanation in the edit summary. The automatic edit summary of section editing is also very helpful, but people do not always apply section editing.--Patrick 11:26, 10 November 2007 (UTC)

The best way to do this would be to have the page history sortable or filterable to show just the changes made to a section. This might miss the creation of a section for those cases where people add a new section to the last one (instead of using the + symbol), or edit the whole page instead of a section, but it would give a reasonable history for a section. Carcharoth 12:36, 10 November 2007 (UTC)

I suppose this refers to finding the edit where a particular change was made - sounds likely. There are are other solutions for this, though not particularly widely known: WikiBlame and User:AmiDaniel/WhodunitQuery.

And I agree that sorting or filtering could be useful, not requiring much developer effort. -- John Broughton (♫♫) 14:31, 10 November 2007 (UTC)

Newbie experience

With m:Edit Wikipedia Week coming up, I was thinking about how confusing Wikipedia is for newbies. There really is no clear short path for getting started editing. No newbie wants to read pages of crap; they want to start editing. No newbie wants to try to go to the community portal to find tutorials etc. The help pages and the community page are terrible for new users. For example, Wikipedia:New contributors' help page and other assorted help for new users should be at the top of the help page and prominent.

Also, most of the welcome pages I have seen are not very helpful for new users. Is there a better welcome page that can be placed on newbie pages? Maybe we can designate a certain welcome page as an official Wikipedia Week welcome page.--Filll 14:19, 9 November 2007 (UTC)

One of my coming projects is a "new contributor's guide" or such, or checking we have a good starting point for how-to, core policy and information, and caveats, for "newcomer editors". feel free to nudge, it's already on my "wiki to-do" list. FT2 ^{(Talk | email)} 21:38, 9 November 2007 (UTC)

You might want to include a link to the index. -- John Broughton (♫♫) 01:42, 10 November 2007 (UTC)

Wikipedia:Flagged Revisions

I was taking a look at the Flagged Revisions proposal and found the link to m:Wikiquality. Is the "Revision tagging" section accurate? Has the beta testing period ended without any scalability/security concerns? If so then I think we should start a new widely advertised discussion about if we are going to use Flagged Revisions and how we will configure it. FunPika 23:34, 9 November 2007 (UTC)

Last time I checked, live testing had not yet begun. Dragons flight 23:46, 9 November 2007 (UTC)

This wiki was linked to on the Flagged Revisions page. So...we have to wait for a new test wiki to appear under a .wikimedia.org subdomain, or was that linked wiki actually the live test? FunPika 23:54, 9 November 2007 (UTC)

I believe the plan was to test it on the German Wikipedia before deciding on whether to make it available on other wikis, but there has been some technical problem that has delayed testing at that scale. Dragons flight 00:02, 10 November 2007 (UTC)

Why would it be tested on the German Wikipedia, or any live project for that matter? FunPika 00:11, 10 November 2007 (UTC)

I believe Flagged Revisions are in operation on Dutch Wikipedia. Nick 14:34, 10 November 2007 (UTC)

I checked their special:version page and FlaggedRevs were not there, and I could only find traces of RC patrol enabled in the logs. FunPika 17:45, 10 November 2007 (UTC)

Wikipedia:Peer review/volunteers

Sign up, one and all. Marskell 14:22, 10 November 2007 (UTC)

Section bar

I've got an idea for the Section bar. Usually it says just "Edit", but I thought it might help if the section bar had "Edit", "History" and "Watch" like an article does. It would help navigation, because on longer pages, instead of having to scroll allllll the way down to the section you want, you could just have it on your watchlist so it'd be right there when you need it. And as for "History", instead of having to weed out one revision from thousands, you could just see the history of the section you're working on. That would help because you could see any prior vandalism. Just an idea. Best, --Gp75motorsports 23:11, 2 November 2007 (UTC)

MediaWiki does not support watchlisting of sections, and from what I understand of it, it probably never will on grounds of practicality. For example, how would it cope with renamed or removed sections and titles? Adrian M. H. 23:15, 2 November 2007 (UTC)

Wow, I was just about to create a section on a similar point, specifically, being able to view the history of just a single section. I'm sure it's been discussed before, and maybe someone has even created a javascript solution for it, but it's something that I'd find a great help. Sure some sections get renamed, but a lot of them don't and I don't see why it would be difficult to do technically. -- DatRoot 14:21, 3 November 2007 (UTC)

Yes, it has been raised on numerous occasions. It is not just about section titles; that was, as my wording suggested, one example. I gather that there is a far more fundamental incompatibility in the way in which the whole watched page system works that would prevent it from being possible. But I am not a MediaWiki expert, so you might want to have a word with an MW developer and get an explanation from them. Adrian M. H. 22:56, 3 November 2007 (UTC)

That a page has changed gets written to the database; that a section has changed does not, currently. Since editors often edit the entire article and, while doing so, change sections, or edit one section and split it in two, there isn't any point in trying to use the section numbers as a tracking device; if changes to sections were somehow to be tracked, the software would have to dynamically calculate this every time an edit was change, probably at least doubling the server load when saving an edit. In short, putting a section on one's watchlist is almost as difficult (conceptually) as putting a sentence on a watchlist, from a programming viewpoint. -- John Broughton (♫♫) 18:34, 4 November 2007 (UTC)

That is all true, but it can be done another way. As people usually edit a section by clicking on its own edit link, the name of the section edited is usually stored at the beginning of the comment field for the edit. So all the server would have do is an extra check that the comment field starts with "/* sectionName */". It wouldn't work if the section got renamed or an edit was made to the section via the page's main edit tab, but it would still be a large improvement of what we have now (nothing).

So I'd have thought it was technically feasible, probably for the watchlist, and certainly for page histories; the only issue being the cost of doing the extra text query on the comment field. -- DatRoot 01:23, 5 November 2007 (UTC)

"Usually" isn't good enough for a watchlisting feature, especially when someone wanting to avoid the watchers can easily avoid it, and string comparisons are relatively expensive. You also forgot that it won't work if someone edits the supersection or subsection (e.g. you watch the === header and someone edits the containing ==, or vice versa), or if someone simply manually edits the part of the edit description inside /* */. Anomie 12:17, 5 November 2007 (UTC)

(unindent) Yes, there are lots of ways to break it that I didn't list, though their occurences are rare. However I accept it probably wouldn't be good enough for an official watchlist feature, but I don't see why it can't be used on article histories. Of course it can be done easily with javascript, but then you have to load a longer list in the history page in the first place before filtering it. -- DatRoot 13:31, 5 November 2007 (UTC)

The bottom line is that there is zero chance of getting the developers to work on a watchlist enhancement that works about 80 percent of the time, and also smacks of ownership (as in - "I made a change to this section; I want to watch for changes to it, but I don't care about the rest of the article"). If you want to create a JavaScript alternative, more power to you. -- John Broughton (♫♫) 16:23, 6 November 2007 (UTC)

I had assumed it would be more for Q&A pages such as this one, where one wouldn't want to miss responses to questions they had asked or replied to. But I conceed the point and won't push it any further. -- DatRoot 17:44, 6 November 2007 (UTC)

Why doesn't someone construct one? Then we could test it for a month, and if most people didn't like it, then we'd drop it. --Gp75motorsports 23:20, 11 November 2007 (UTC)

Constructing it in the first place is the main difficulty. The reason is that it would be fairly complex to look at every revision in a page's history and see if a particular section was changed then list that on a separate history list. When sections are renamed and moved around, it becomes even harder for the software to distinguish what section was what. Tra (Talk) 00:05, 12 November 2007 (UTC)

I don't mean to be able to move individual sections, just do all the other stuff I listed above in the original statement. --Gp75motorsports 02:44, 12 November 2007 (UTC)

How About an iPhone Version of Wikipedia?

The main site is pretty difficult to navigate on the iPhone screen--an iPhone optimized site would be incredible.

We could program it to show just the article intro and 2 or 3 links. --Uncle Ed 13:42, 10 November 2007 (UTC)

You should have a look at Wapedia, which provides simplified versions of Wikipedia articles. I sometimes use that on my PSP. --Dapeteばか 17:24, 11 November 2007 (UTC)

Please help with template

I do not understand the template instructions for Template:RfCpolicy. I have asked for help there but have received none. This is what I am trying to add to Talk:J. Vernon McGee - the following template:

{{RFCpolicy | section=RfC:Should articles be verified and referenced !! reason=Editor removes tags without fixing the problem, as if [[WP:OWN]] !! time=~~~~}}

I have been trying for almost two hours now. I cannot understand what I am doing wrong. It shows up on the talk page but not on the RfC list Thanks! --Mattisse 17:15, 11 November 2007 (UTC)

Fixed.--Fuhghettaboutit 17:36, 11 November 2007 (UTC)

Sub-sections introduction included

On pages where there is a whole article covering it in depth e.g. see 'main article' or 'see also' editors usually write a brief paragraph on it, but editing the sub-article doesn't update any sections that link to it and the info may get out of kilter. My suggestion is a template/special link that inserts the lead of the sub article into the main page - thus articles would be consistent with their sub articles.

Flaws I can think of are; that an editor would have to go to the subpage to edit the text found on a page, may have to be jigged for release versions (have to store the text from the subpage intro with the main) and tailoring to fit with rest of the article, but I think the removal of redundant editing and increased accuracy would more than make up for this, any ideas? Leevanjackson 12:03, 12 November 2007 (UTC)

I just suggested this about a week ago, but the discussion was recently archived. Here's how the discussion went, starting with my original proposal:

On many important articles, there are one or more sections that branch into related "child" articles, typically using the {{main}} template. In these sections there is a summary of the child article, usually two or three paragraphs. For example, in the Minnesota article, there are twelve child articles corresponding to various sections (e.g. Geology of Minnesota, History of Minnesota, Climate of Minnesota, etc.). The problem is that the child article and its corresponding summary paragraph in the parent article are not always updated together, so inconsistencies may arise from time to time. Also, people tend to add to the summary instead of the child article, so the summary text grows while the child article does not. I propose that the summary text be moved from the parent article to the child article and put inside <includeonly> tags, and the whole text of the article itself be put inside <noinclude> tags. Then, in the parent article, instead of having actual text, the parent article will just transclude the child article. For example, in the Minnesota article, we would change this: == Geology of Minnesota == {{main|Geology of Minnesota}} Minnesota contains some of the oldest rocks found on earth, ... ... ... (six paragraphs of summary text) to this: == Geology of Minnesota == {{:Geology of Minnesota}} And the Geology of Minnesota article would be changed to this: <includeonly>Minnesota contains some of the oldest rocks found on earth, ... ... ... (six paragraphs of summary text)</includeonly> <noinclude>(full Geology of Minnesota text)<noinclude> Advantages Summary of child article is now fully visible to editors of the child article (and vice versa), so it will be easier to keep them in sync. People interested in the child article but not the parent article don't need to keep the parent article on their watchlist. People not interested in some sections of the parent article won't be bothered by changes made to those sections because they didn't add the child articles to their watchlist. Child article summary can be transcluded to multiple parent articles. For example, Geology of Minnesota could appear in both the Minnesota article and a new "Geology of U.S. States" article. Disadvantages Much more difficult for new editors to figure out how to edit summary sections in the parent article, since the text is now actually in the child article. People interested in the entire parent article will need to manually add all of the child articles to their watchlist. Transclusion of numerous child articles in the parent article may increase server overhead. Thoughts? — Jonathan Kovaciny ([[User talk:Jonathan Kovaciny|talk]]|contribs) 15:16, 1 November 2007 (UTC) Thoughts This looks like an attempt to workaround the lack of mw:Extension:Labeled Section Transclusion. Doing this on articles would be a bad idea for technical reasons at present due to the template limits; I like the idea from a non-technical point of view, though. --ais523 15:53, 1 November 2007 (UTC) If the includeonly tags are left out the lead section of the child article could be used as the summary in the parent article. An undesirable effect would be the bolding of the selflink to the parent article.--Patrick 17:40, 1 November 2007 (UTC) Creating summaries of each child article (or each article period) would be a massive, but perhaps useful, change to Wikipedia. The parent/child distinction breaks down, though because the organization structure is a web, not a tree. An article may be the child of more than one parent, in which case the summary in each parent article would necessarily be different because it has to be relevant to the parent. The mini-summary would be useful for all kinds of purposes, though. What would the relationship be to the lead? In general, because of this forking problem, I think summarizing articles within other articles should be discouraged. That's what hyperlinks are for. The forking of content is actually a huge organizational problem around here. If you're lucky the child article at least has a hyperlink to every place the subject is discussed. In practice, a thing may be talked about in many articles that don't even link to each other.Wikidemo 20:37, 1 November 2007 (UTC) The problem is that a lead section for a child article has to presume that the reader knows nothing about the subject - so, for example, the Geology of Minnesota article begins "The geology of Minnesota is the study of the rock, minerals, and soils of the U.S. state of Minnesota, including their formation, development, distribution, and condition." Putting the words "the U.S. state of Minnesota" into a section of the article "Minnesota" makes no sense. In short, you can't use exactly the same text for the lead section of a child article and a section of a parent article. For what it's worth, the {{sync}} template, designed to point out where significant divergence exists, seems underused. -- John Broughton (♫♫) 00:25, 4 November 2007 (UTC)

–Copy-n-pasted by — Jonathan Kovaciny (talk|contribs) 14:32, 12 November 2007 (UTC)

Ah I see walking over previously trod ground! But I'd like to add a couple of points; the technical problems could be overcome with time and limiting the depth of child-articles maybe? As for the content of the lead - I don't get the Minnesota Geology lead, it doesn't give a succint summary of the geology and merely serves to spell out in dictionary form it's article's title should be more like 'Minnesota's geology is mostly made up of igneous ...', so some leads need work but I get the point about relevance to the main article. When there is a sub-article however it is usually arrived at from a parent article and the reader will be familiar with the material, e.g. list of pharmaceutical companies in china wouldn't be the first thing a user would type in, it would be reached from pharmaceutical companies in china, so with some careful editing it's lead could be stripped down to match this. I think for a number of articles (particularly scientific ones) the pros still outweigh the cons Leevanjackson 18:32, 12 November 2007 (UTC)

Proposal to tweak Template:cite web

There is currently a proposal at Template talk:Cite web#Automatic date wikilinking to tweak Template:cite web for automatic date wikilinking. Any thoughts? —Remember the dot ^(talk) 03:21, 13 November 2007 (UTC)

Olympics on the Main Page

Wikipedia started out as an encyclopedia six years ago, but nowadays it's much more than that: we're quickly becoming one of the leading news portals in the world. See for instance the Virginia Tech shootings. This will be no different at the 2008 Summer Olympics in Beijing. For the past few weeks, I've had something on my mind wrt the upcoming Olympics, and I am looking for community input, to see how others think about this. I want to raise the idea of putting a box specifically about the 2008 Summer Olympics on the Main Page. In what I had in mind, it would contain all the latest results, upcoming events and other news. That way we can provide people with the information they might be looking for, while reducing the load this might put on ITN. The best location for this would be right above or right below Today's Featured Picture, in a similar size and format. If it helps the discussion, I can create a lorem ipsum in my userspace. Aecis^Brievenbus 20:13, 22 October 2007 (UTC)

Probably better would be a prominent box on the Main Page directing folks to the coverage on Wikinews. -- Kesh 22:34, 22 October 2007 (UTC)

I think this is a great idea. Pretty much everything that happens in the Olympics will be documented on Wikipedia. Maintaining extremely up-to-date statistics and information gathered from international sources is what Wikipedia does best. People will be coming here for information about the Olympics, so we should definitely try to provide this information on the Main Page. --- RockMFR 23:40, 22 October 2007 (UTC)

• How would the format be different than what was posted on ITN when the 2006 Winter Olympics was going on? [1] [2] [3] Zzyzx11 (Talk) 01:51, 23 October 2007 (UTC)

That display listed only a minimum of news. What I had in mind is a threeway box:

1. News (results of important events, positive doping tests, world records, etc.);

2. Latest results (the medal winners of e.g. the 5 latest events);

3. Upcoming events (the events to be held that day).

The latter probably shouldn't include the heats of athletics or gymnastics, but might include for instance the finals at any sport, and individual matches to be held that day for team sports (handball, volleyball, baseball, basketball, field hockey, football). Aecis^Brievenbus 21:17, 23 October 2007 (UTC)

I've noticed that the idea is still a bit too vague to discuss. I'll use the next few days to create a draft version of what I had in mind in my userspace. That should also give me the opportunity to develop my own thoughts. I'll come back when I have something a bit more tangible. Aecis^Brievenbus 21:59, 23 October 2007 (UTC)

This would have to be maintained by an admin, since anything displayed on the Main Page is protected. Corvus cornix 22:58, 23 October 2007 (UTC)

Obviously, yes. And being a journalist, a sports lover and a Wikipedian, I'm more than willing to do a large chunk of the work, if and when real life obligations allow me to do so. Aecis^Brievenbus 23:06, 23 October 2007 (UTC)

You might also want to discuss this at Wikipedia talk:WikiProject Olympics to get some feedback from like-minded editors. Andrwsc 23:17, 23 October 2007 (UTC)

No, I'm not sure we should devote an entire section to this. There's loads of other events that could be added to the main page - what makes the Olympics so special? Tom Sauce 00:19, 24 October 2007 (UTC)

I can't imagine it actually being on the Main Page, but transcluded, just like all of the other sections are. Corvus cornix 03:32, 24 October 2007 (UTC)

Transcluded, added, the same thing... Tom Sauce 14:30, 24 October 2007 (UTC)

@Tom Sauce: The Olympic Games are the largest event in the world, in terms of money involved, in terms of the number of people and countries involved, in terms of the number of viewers, etcetera. I don't think we should include every single event on the Main Page, but the Olympic Games are not just another event. I think the Games are worth making an exception for. And this wouldn't be on the Main Page forever; the Games will start an August 8, 2008 and will end on August 24. That is just over two weeks. Say we put it on a few days before the Games start and take it off a few days after the Games have ended. That would mean that this would be on the Main Page for about three weeks. I think that's reasonable.

@Corvus Cornix: It would obviously be transcluded, like all the other sections on the Main Page.

Aec·is·away ^talk 14:32, 24 October 2007 (UTC)

I understand the Olympics are a huge thing. However, I disagree with putting up a huge box for three weeks. I'd agree with adding a well graphically designed, yet small message, along the lines of "Click here for news about the Olympics" . So anyways, it would link to some page (don't know if on Wikipedia or Wikinews) where the up-to-date information would be presented, with no restrictions concerning space. What do you think? Anyways, glad to see this matter brought up early, it's good not to be under time pressure. Puchiko (talk • contribs • email) 18:44, 24 October 2007 (UTC)

It's not difficult for those interested to find the proper article, but you might consider a banner at the top of the Olympics page during the event. The Olympics may be a big media event, but it's not very big on Wikipedia. Go look at the articles about recent Olympics and you'll find there are not many articles and most sports got minimal coverage and updating. A few dozen edits a day during the event is not much activity, and descriptions of the opening and closing ceremonies does not provide much information about the sports activities. (SEWilco 19:01, 24 October 2007 (UTC))

I've created a draft version at User:Aecis/Olympic sandbox, to give you an impression of what I had in mind. It uses the results of the 2004 Summer Olympics, in a completely random order. The formatting is all over the place, but you gotta start somewhere. The page shows three sections. The first, Latest news, is similar to ITN, and contains all the news that might be included on ITN. This would reduce the load on ITN, giving us the opportunity to present non-Olympic news there. The second sections contains the latest results. The number of results shows would obviously have to be decided by consensus, but four is probably ideal for the browser size. The third section contains all of the day's events, and could work like the Template:POTD protected on the Main Page, using CURRENTYEAR, CURRENTMONTH and CURRENTDAY2. When a final listed in the Today's finals section has finished and the Olympic champion is known, it can be removed and moved to the Latest results section. Example: Povetkin defeats Aly in the final of the men's super heavyweight boxing. It will be put on first place in the Latest result, pushing athletics to second place, table tennis to third and basketball to fourth, and pushing rowing off the Main Page. Aecis^Brievenbus 20:17, 24 October 2007 (UTC)

As a member of the Olympic WikiProject, a project that has systematically organized hundreds of pages related to the Olympics, I can say that anything that would further our project's reach would be greatly appreciated. The Olympics, as it has been argued, are a wonderful uniting force, and thus I would say that it would be great to display up-to-date results.

My problem with this lies in the fact that an entire box would be dedicated to the Olympics. As much as I would like this (and I will pay close attention to this proposal to help make something of this nature come to fruition), one major problem is the lack of space on the main page. Overcoming that, it is a little unfair to devote a large section of the main page to this one event. Granted, it is, again, a very important event that should be overlooked by no one (but who are we to say that?).

In short, there is no doubt in my mind that Olympics should be somehow represented on the main page, and it is great that this is being discussed now. We already have pages set up for the 2008 Games, the main page of which is already choc-full of information. Perhaps what we could do is just incorporate a sub-box, or section atleast in the ITN box. I think this is what has been done in the past. But I will look at the mock-up, and see how I (and other members of the project) could come up with a viable compromise. Jared (t)  20:36, 25 October 2007 (UTC)

Would a Portal:2008 Summer Olympics be better suited for presenting this kind of information? And if so, would a link to the Portal from the Main Page for the duration of the Games address some of the concerns raised above? Aecis^Brievenbus 20:53, 25 October 2007 (UTC)

Portal:Olympics already exists, and ought to be refreshed for use during a specific Games. Andrwsc 20:59, 25 October 2007 (UTC)

I know, but that Portal is quite general, as it should be. It would lose balance if it were too focus on the 2008 Summer Olympics too much. Having a daughter Portal about the 2008 Summer Olympics gives us the opportunity to provide people with the information about a current event they are or might be looking for. If they then want to know more, we can direct them to WikiNews, to Portal:Olympics and to the article Olympic Games. Aecis^Brievenbus 21:05, 25 October 2007 (UTC)

The Olympics don't deserve to be covered on the main page to any greater extent than any other current event. It would be undue weight to give them their own section while they were going on. Atropos 03:26, 26 October 2007 (UTC)

Wikipedia doesn't seek to be a news service and it shouldn't try to be a news service. We should aim to be verifiable, not first. With the nature of Wikipedia being what it is, we could end up with all sorts of article vandalism by all manner of neardowells that would mean keeping the information accurate would be difficult - especially so if the information is on the front page. With something changing as fast as this we could end up with all sorts of problems, from edit conflicts to false information from vandals. Keeping on top of it would be a huge challenge to those who tried to do it. I'm not saying I don't like the idea, simply that I can foresee considerable problems with it. B1atv 18:01, 26 October 2007 (UTC)

@Atropos: how about having a link on the Main Page to either a portal or an article about the 2008 Olympics, for the duration of the Games? (If that link is to be included in ITN, it would obviously have to be brought up with Template talk:In the news and Wikipedia:In the news section on the Main Page/Candidates first.)

That would actually be a pretty good idea. A lot more maintainable than trying to add news items to the main page about the Olympics. So many things would be happening it wouldn't really be easy to decide which should be ITN and which shouldn't. I think including a little bolded link centered at the top of ITN "For information about the 2008 Summer Olympics, see this portal" would be totally acceptable. Atropos 03:44, 3 November 2007 (UTC)

@B1atv: the risk of vandalism exists for every current event, whether its the latest Harry Potter, the death of an important person, a controversial cartoon or a sports event, and at every article admins will struggle to keep up with the pace of vandalism. Seen the movie, got the T-shirt. That will be no different for the 2008 Olympics. But I don't see how that should keep us from covering relevant news items altogether. Aecis^Brievenbus 11:56, 29 October 2007 (UTC)

Portal proposal

In view of the above discussion, there appears to be no consensus for putting a box about the 2008 Summer Olympics on the Main Page. I withdraw that proposal/suggestion. However, there appears to be some support for creating a Portal about the 2008 Summer Olympics, and putting a link to that Portal on the Main Page. I want to bring that specific suggestion up for discussion again. Aecis^Brievenbus 14:41, 3 November 2007 (UTC)

Personally, I don't think the idea of creating a portal for a specific version of anything is a good idea. Perhaps a link to and regular updating of the existing Portal:Olympics would be a good idea. However, I do not see that there is any reason a separate portal for the current Olympics. John Carter 15:40, 3 November 2007 (UTC)

IMHO, that's not the point of portals. If it's just going to be updates about Today At The Olympics, that would be better off as articles. Kolindigo 00:19, 4 November 2007 (UTC)

I tend to disagree with you. As outlined in WP:PORTAL, Portals are "useful entry-points to Wikipedia content", intended to "help readers and/or editors navigate their way through Wikipedia topic areas". A Portal like this will allow readers and editors to find their way through the myriad of articles we have that are related to the 2008 Summer Olympics. Articles about events, athletes, venues, countries etc. at the 2008 Olympics. During the Games, the Portal can inform readers of what is going on at the Olympics, and when the Games are over, the Portal can inform readers of what has gone on. The Portal can add to our article 2008 Summer Olympics, because a Portal is able to present information in a way that a Wikipedia article can't. Aec·is·away ^talk 16:57, 7 November 2007 (UTC)

That sounds like a good idea; we should have a special main page variant for olympics and a visible link from main page directing users to the olympics-themed main page.-- _{Piotr Konieczny aka Prokonsul Piotrus | talk} 18:25, 13 November 2007 (UTC)

Article "Bookshelf"

I don't know if this is the right place to voice this or not, but I think there should be a "reading list" section in your personal pages that users could add pages to so that they can come back and read them at a later time. I am constantly opening other articles from links in the text of pages I'm reading until I have somewhat like 20 tabs open in one Firefox window. Ultimately, I end up with four or so such windows, and I go to great lengths to avoid closing Firefox so that I don't lose them. The problem is that I don't have enough time in one sitting to read all of the articles that catch my interest--especially when I'm already doing research for some project. I have to imagine that I'm not alone in this, and I wish there were a list like the wishlist on Amazon.com (and similar sites)--one that didn't watch for changes, but simply held a list of pages for later reference. I don't know much about the Wikipedia community--I spend enough time reading the articles; if I started editing them, I'd probably never stop. But if you agree with me and you know how to bring this suggestion to the Wikipowers-that-be, lend a hand to a fellow Wikipedia addict.—Preceding unsigned comment added by Sleepisplayedout (talk • contribs)

Using your browser's bookmarks function would be the easiest route. Or manually add them to your userpage. --Quiddity (talk) 07:52, 13 November 2007 (UTC)

You can do this yourself. Create User:Sleepisplayedout\Bookshelf and add whatever you want to. Corvus cornix 19:40, 13 November 2007 (UTC)

Actually, User:Sleepisplayedout/Bookshelf would be a better choice, since the software would see the / and consider the page an extension of User:Sleepisplayedout and therefore part of your personal userspace. —Remember the dot ^(talk) 19:48, 13 November 2007 (UTC)

Whoops, you're right, sorry about that. Corvus cornix 21:24, 13 November 2007 (UTC)

Another way would be to simply watch them. But if there's something that you really liked and it got removed or changed, you could possily do this for older revisions. Best, --Gp75motorsports 01:23, 14 November 2007 (UTC)

Doozy of a Proposal

my proposal is soft edit blocks of every article that is on the main page for 24 hours, as to curb a heavy amount of vandalism. Any one agree? Doc Strange 17:35, 13 November 2007 (UTC)

Actually, only admins can edit the main page. So no worries. --Gp75motorsports 17:49, 13 November 2007 (UTC)

He means the articles linked from the main page. For which see Wikipedia:Main Page featured article protection and Wikipedia:For and Against TFA protection (specifically about the featured articles, but applies equally to all links). --Quiddity (talk) 18:11, 13 November 2007 (UTC)

Yeah. --Gp75motorsports 01:20, 14 November 2007 (UTC)

Making accounts universal.

Thought it would be a nice idea to make accounts using the WikiMedia Foundations set of web-sites universal. That is, that a user will be able to create an account on Wikipedia and also be able to use the same account on WikiBooks, WikiQuote, etc. Didn't see this on any of the FAQ's and thought I would throw it out there.

See m:SUL. O₂ (息 • 吹) 23:44, 13 November 2007 (GMT)

Yeah. The whole idea behind having different accounts for each Wikimedia site is to encourage the user to create different usernames in the hope that the user won't use the same name in every website, so your talk pages don't get unreasonably flooded. They could have universal account creation, but they don't for privacy reasons. --Gp75motorsports 01:19, 14 November 2007 (UTC)

Actually, not really. It is just that it wasn't there at the beginning and it will take quite a bit of technical changes to get this up and running. It is planned, but we have no idea when it will actually be done. Cbrown1023 talk 02:15, 14 November 2007 (UTC)

Just to clarify, the comments made above about the reasons for not implementing (privacy and flooding) are entirely untrue. It is a very high priority, however, as Cbrown1023 said, it is difficult to implement. --MZMcBride 05:28, 15 November 2007 (UTC)

Manual of Style entry for navigation boxes

It seems to me that a MOS page (or a new section on the Wikipedia:Guide to layout page) is needed for navigation boxes. There seems to be a wide variety of styles, although that is converging somewhat as Template:Navbox is being used more frequently. It might be a good idea to more strongly recommend that meta-template for navboxes. I've also seen several different placement styles — most common is grouped together at the very end of the article, after the references or external links sections, but I've also seen them appear as the content of the "See also" section (instead of a bulleted list), or even stranger, as the content of a main article section (such as Inverness#Areas of the city). Again, I think some MOS guidelines could be beneficial here. Andrwsc 21:34, 14 November 2007 (UTC)

ProteinBoxBot referencing

This ProteinBoxBot's plan of use was proposed here and some consensus was formed that that use would require reliable sourcing in the 10,000 articles to be created by it. The implementation appears to not be strictly adhering to that consensus. Please see User talk:ProteinBoxBot#Unreferenced articles are being created and apparently in large numbers.--Fuhghettaboutit 15:50, 10 November 2007 (UTC)

Problem has now been resolved. -- Tim Vickers (talk) 17:19, 16 November 2007 (UTC)

WP: pseudo-namespace

Cross-namespace redirects are generally not allowed, however, an exception for WP: has been created due to its cost vs. benefit of keeping/eliminating it. Somewhat recent changes in the software now allow for there to be namespace aliases. This would eliminate the cross-namespace redirects from (Main) to Wikipedia. The alias would mean that WP: = Wikipedia: , so a page like WP:WS would equal Wikipedia:WS. While most people would probably agree that a total ban or total allowance of cross-namespace redirects is not a good idea, this particular cross-namespace type is one that can be easily fixed by the developers if on-wiki consensus is demonstrable. Please comment below. Cheers. --MZMcBride 00:22, 11 November 2007 (UTC)

To make it clear: it should be the same as with "Project:" which is another alias for "Wikipedia:", e.g. right now you can use Project:About ∴ AlexSm 07:54, 11 November 2007 (UTC)

Support

1. --MZMcBride 00:22, 11 November 2007 (UTC)
2. Why not? Mr.Z-man 01:12, 11 November 2007 (UTC)
3. Duh Will ^(talk) 01:46, 11 November 2007 (UTC)
4. What could go wrong? FunPika 01:57, 11 November 2007 (UTC)
5. The main problem I can see is that if there was ever a notable concept with a name beginning with WP: there would be problems as its article would be forced into the wrong namespace, although this situation should hopefully be rare enough that it could be fixed with, say, a template at the top of the article about technical restrictions in the title. Apart from that, this seems like a good idea. Tra (Talk) 02:23, 11 November 2007 (UTC)

   Which is already a problem with things like "Help:", "Q:", and anything else that is already a namespace or interwiki shortcut. See Wikipedia:Naming conventions (technical restrictions)#Colon. There's even a template for it already: {{namespace}}. Anomie 02:37, 11 November 2007 (UTC)

6. I see no problems with this and would like to see it happen. Cbrown1023 talk 03:37, 11 November 2007 (UTC)
7. As noted below this seems like a no brainer but if the developers want a show of support, here's another. Question: what about "WT:"?--Fuhghettaboutit 06:49, 11 November 2007 (UTC)
8. Support for both WT and WP, I can't even conceive of a reason that this could possibly be objected to. Seraphimblade ^{Talk to me} 07:43, 11 November 2007 (UTC)
9. Support, of course ∴ AlexSm 07:54, 11 November 2007 (UTC)
10. Well I guess I should say support for the record too. --Sherool (talk) 08:52, 11 November 2007 (UTC)
11. It helps a lot when pages are in the right namespace; otherwise special-case code has to be put into bots and scripts all over the place. --ais523 13:20, 12 November 2007 (UTC)
12. Provided I understand the mechanism correctly, this seems like a no-brainer technical solution to a long-standing problem. -- nae'blis 18:29, 13 November 2007 (UTC)
13. Seems like a great solution. —Remember the dot ^(talk) 19:39, 13 November 2007 (UTC)
14. Support per Seraphimblade, avoids these so-called "unprintworthy redirects".--h i s ^{s p a c e} _{r e s e a r c h} 12:23, 14 November 2007 (UTC)
15. If we must show support then here is mine, for sure. I would hate for all those redirects to ever discover we have labelled them unprintworthy. Imagine how they might rebel - we should give them their very own home as soon as we can. Splash - tk 23:37, 16 November 2007 (UTC)
16. Support - I understand the reluctance to change (things seem to work pretty well), but there seem to be some advantages, the developers wouldn't have worked on this unless they thought there was a good reason, and no one has indicated any technical or conceptual problems that will result from the change. -- John Broughton (♫♫) 23:43, 16 November 2007 (UTC)

Oppose

1. Sorry, but I'm not convinced that this would actually do much good. Having WP: links be in the main article space is a technicality, and creates silly redirects, especially in the case of WP shortcuts that link to userspace pages (like WP:PROBLEMS, WP:GRFA, WP:BOOBOOS, or the all-important WP:EVULA). EVula // talk // ☯ // 01:28, 12 November 2007 (UTC)

   This sums up the arguments for keeping or removing cross-namespace redirects. Whether or not you agree they should be allowed, this solution partially fixes the problem by keeping the (Main) namespace more "pure". The reason for namespaces is to separate content; the more the line is blurred, the worse off we are. While this solution wouldn't eliminated cross-namespace redirects, it would get a lot of redirects that are currently in the (Main) namespace into a namespace that is not intended strictly for articles. --MZMcBride 22:09, 12 November 2007 (UTC)

   I'm still not terribly convinced that this is an issue, but that could ignorance more than anything. I did find another cross-namespace redirect, though, in WP:MAGIC. EVula // talk // ☯ // 16:44, 13 November 2007 (UTC)

2. This strikes me as being a solution in search of a problem. --Carnildo 02:31, 12 November 2007 (UTC)

   See above, specifically here. --MZMcBride 22:09, 12 November 2007 (UTC)

3. I am going to side on the side of oppose here. Why make more work for the devs when the current system works fine? If the results are identical from the user end (I can still type the WP shortcuts I need to find commonly used pages) then why is this needed? --Jayron32|talk|contribs 07:19, 12 November 2007 (UTC)

   See above. --MZMcBride 22:09, 12 November 2007 (UTC)

4. What problems are there that will be fixed when this is added? It's not like people will see the change in the tab at the top ad the aren't counted as articles. The Placebo Effect 07:25, 12 November 2007 (UTC)

   First, shortcuts like WP:Articles for deletion won't have to be added by hand but instead will be created automatically; second, there won't be a need to explicitly exclude the WP: redirects from database dumps; third, WP: redirects won't then show up in searches for articles, but will show up in searches for project pages (the Go button will be unaffected); fourth, it will reduce special-casing in bots and scripts (imagine a bot that analyses redirects in article space, for instance to create a list of 'see metasyntactic variable' entries for a paper encyclopedia; it would need a special case for redirects starting WP:); fifth, the current situation is a hack, and hacks tend to cause more problems as time goes on. --ais523 13:25, 12 November 2007 (UTC)

Discussion

Do you have a link to a bugzilla page (or similar) about this? Tra (Talk) 00:50, 11 November 2007 (UTC)

6313. --MZMcBride 01:27, 11 November 2007 (UTC)

Thanks. Tra (Talk) 02:23, 11 November 2007 (UTC)

• Asuming it's actualy that easy why would we even need to demonstrate consensus for that? If they can make all pages prefixed with "WP:" officialy part of the Wikipedia: namespace by simply adding the apropriate alias string to the settings somewhere they should have already done so the moment the feature was implemened. Can't think if a single reason anyone would object to that, presumably the job que would just do a one time run though to update the namespace ID for those pages. No one would even see any difference, the only practical difference wold be that those shortcuts would no longer clutter up search results in the main namespace or uselesly hang around in DB dumps of just the main namespace. The "CAT:" type redirects might be a little trickier since making "CAT:" an alias for "Category:" would cause all regular links to that redirect to suddenly add the page to the category instead and such, but for the WP ones it seems like a no brainer to me. --Sherool (talk) 01:11, 11 November 2007 (UTC)

A bug was opened before namespace aliases existed. The bug is still open, however, developers are far more willing to make changes like this if they know that there won't be a backlash or outcry requiring more of their time and energy. --MZMcBride 01:27, 11 November 2007 (UTC)

The developers don't like to do things like this unless they are sure the community completely agrees with them, I believe they also say in the bug above that they need to see consensus. (Although many feel this is a no brainer, the developers still won't do it. ;-)). Cbrown1023 talk 03:37, 11 November 2007 (UTC)

Hmm actuly after having slept on it I just though of one little thing that might cause some issues. If I understand this correctly by making WP: an analias for Wikipedia: it would basicaly mean that you would get to the same page if you type "WP:CSD", "Project:CSD" or "Wikipedia:CSD", they would all be the exact same page in NS:4 right? So just out of curiousity, what happens if there is a conflict with an exsisting page? For example we already have redirects like "WP:Signpost" and "Wikipedia:Signpost". How would cases like that be dealth with? Still support the idea naturaly, just wondering if this issue is something they know about and is on top off. --Sherool (talk) 09:16, 11 November 2007 (UTC)

The redirects in the (Main) namespace must be deleted before the change takes effect or they will be stuck in MediaWiki purgatory. They'll still exist, but it will be impossible to edit them or see their history, or do anything with them. Pages like "WP:Signpost" would still work because it would become "Wikipedia:Signpost", which would then redirect to "Wikipedia:Wikipedia Signpost", however, if the change is made without first deleting all of the redirects in the (Main) namespace, it will be impossible to edit (or delete) "WP:Signpost". Basically, it comes down that once consensus is shown, the redirects will have to be quickly deleted and then immediately following the alias would have to go active. --MZMcBride 16:27, 11 November 2007 (UTC)

If that's the case, has a master list of all "WP:" shorcuts been compiled and has it been thoroughly checked for completeness? How will this work exactly in the future. Say down the road a policy/guideline is created called Wikipedia:Zoology. How would we make WP:Z redirect take one to that page?--Fuhghettaboutit 17:11, 11 November 2007 (UTC)

In the future, "WP:Z" will be exactly equal to "Wikipedia:Z", in the same way that "Project:Z" currently works. In order to have "WP:Z" go to "Wikipedia:Zoology", a redirect would be created at "Wikipedia:Z" that would point to "Wikipedia:Zoology". The list of all redirects can be obtained here. Obviously, once there is a consensus to implement this change, more work will be needed before the devs can activate the namespace alias, namely "moving" the redirects from (Main) to Wikipedia: and then deleting the pages in the namespace immediately preceding the activation of the new alias. --MZMcBride 17:51, 11 November 2007 (UTC)

Same way you'd make Wikipedia:Z redirect to that page: create a redirect. The only problem with all that is that we could no longer have different content at WP:Z and Wikipedia:Z. Anomie 17:58, 11 November 2007 (UTC)

Interesting question. I notice that WP:Signpost and Wikipedia:Signpost end up at the same page, so that's just a technical problem. More interesting would be name conflicts where the eventual target is not the same. I've compiled a list of naming conflicts at User:Anomie/WP-Wikipedia name conflicts. Anomie 17:58, 11 November 2007 (UTC)

I just got a little more insight into how this would work. A script would be run be one of the sysadmins (developers) that would move the pages to essentially the "same place", unless there is a conflict, in which the script would move the page to a predefined place where there would be no conflict. In sum, the devs know how to resolve the issues and will do so after implementing the change. Worries regarding breakage should be left to the devs, they only want to know if this change is wanted or not. --MZMcBride 18:11, 11 November 2007 (UTC)

The devs have a script that runs through all the uses of the new namespace on pages and automatically resolves duplicates when possible. When it can't, it will rename one of the pages to a different name and churn out a list of pages that need to be checked manually. I'd imagine that it might be reasonably long, but wouldn't be too hard to fix (mostly with the 'delete' button on pages which will have become redundant). No pages end up stuck in limbo as a result. --ais523 13:19, 12 November 2007 (UTC)

Isn't that what Anomie has kindly listed 2 comments above? There are about 60 mismatches. --Quiddity (talk) 19:35, 12 November 2007 (UTC)

Yes, pretty much. But it's still useful to know what names the script moved the pages to because they would have been inaccessible at the old name. And the script has to be run anyway to merge the WP: pseudonamespace and Wikipedia: namespace together. --ais523 11:30, 14 November 2007 (UTC)

As mentioned at bugzilla:6313, don't we then need MOS: WT: CAT: P: etc to be included in this fix too? --Quiddity (talk) 21:08, 12 November 2007 (UTC)

All of those but MOS: seem like they'd fall very easily under this same proposal. Why does that one even exist?!? -- nae'blis 20:46, 14 November 2007 (UTC)

Yes, WT:, CAT:, and P: would also be better and easier to maintain as namespace aliases. MOS: is debatable. If it were up to me, I would probably move them all to the WP: namespace. —Remember the dot ^(talk) 21:23, 14 November 2007 (UTC)

The problem with CAT: is how it's currently used and how the software interprets it. If [[CAT:Whatever]] suddenly equaled [[Category:Whatever]], it would screw up a lot of things. As for WT: and P:, if / when the WP: change is done, I see no problem with fixing those as well. --MZMcBride 00:02, 15 November 2007 (UTC)

The reason for "MOS:" and against moving them all to "WP:" is that most of the useful shortcut keywords for the "WP:" pseudo-namespace have already been taken, usually by WikiProjects, and similar mnemonics are needed for the MOS's fairly large number of guideline pages. If anything, the projects should probably be divested of their "WP:" shortcuts and use "WPP:" instead (some already do, and have for over a year and a half at least, but it hasn't gone far enough in that direction yet). — SMcCandlish [talk] [cont] ‹(-¿-)› 22:46, 8 December 2007 (UTC)