Jump to content

Wikipedia:Village pump (proposals)/Archive 68

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

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

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

Proposal to add "<br>" to Wiki markup before "[[Category:]]"

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

1T. Reasons for above:
"<br>" saves a line between lines for a list, as for example, the following hypothetical case:

1. [text]

2. [text]

3. [text]

versus:

1. [text]
2. [text]
3. [text].

Already, "<br>" is commonly used in templates, for example Template:Economics sidebar, to avoid unnecessary space between lines. It would be used more frequently elsewhere if it were better known and more accessible through the Wiki markup list of symbols.

Thank you for your consideration. --Thomasmeeks (talk) 14:50, 30 December 2010 (UTC)

MediaWiki currently outputs XHTML, so please use the XHTML <br />. The MediaWiki software uses HTML Tidy to convert <br>, </br>, <br/> and the like to a proper <br />. This is not done on editnotice pages and MediaWiki interface pages, which will cause problems. The use of invalid XHTML also cause problems when an article is ported to a wiki that does not use the HTML Tidy option.
In your example, using # will create an ordered list:
# [text]
# [text]
# [text]
User:MarkS/Extra edit buttons has an option to add a break button. ---— Gadget850 (Ed) talk 15:57, 30 December 2010 (UTC)
I would oppose this. Using an extra blank line looks cleaner and is more intuitive. We should only use HTML when there's no equivalent wikisyntax. As for putting blank lines in a list, why would you do that? It just makes it inconsistent from all other other lists in articles. It probably violates some obscure section of the MoS, but I CBA to look. Mr.Z-man 19:32, 30 December 2010 (UTC)
2T. On the 15:57, 30 December 2010, OK. That was quick. I accept (if I have correctly understood) that I should have at included a forward slash in the proposal: <br />, not <br>. In above example, using # will create an ordered list if it is enclosed in <pre></pre>. So, it seems to accomplish what my proposal is intended to facilitate.
But without <pre></pre>, the above example of using #s would result the following:
  1. [text]
  2. [text]
  3. [text]
versus here (with use of <br/>):

1. [text]
2. [text]
3. [text].

The latter avoids possibly undesirable indenting, and unnecessary space between each line.
So, I still believe that <br /> would be more widely understood and thus used than <pre></pre> if <br /> was included on the Wiki markup list available in the Edit mode.
On the 19:32, 30 December 2010 edit above, that's an opinion. In a paragraph, a list with extra spacing between lines looks non-intuitive. In a non-paragraph list, I have no objection to extra space between lines as the default. Thank you. --Thomasmeeks (talk) 20:00, 30 December 2010 (UTC)
I see no problem with usage of <br/> in sidebar templates, like Template:Economics and Template:Thermodynamics. General use in lists within articles seems unwise. EdJohnston (talk) 20:39, 30 December 2010 (UTC)
3T. Well, here's an example that is responsive to the broader point I was trying to make, which was not only about templates. It is truncated from the last Lead paragraph of Economics of religion. The bulleted points are separated by <br>s:

Recent research on the subject has expanded on various fronts.[1] These include:
• religious services as consumer goods[2]
• religious organizations as firms[3]
• religious benefits, costs, and markets[4]
• economic analysis of religious doctrines and incentives[5]

One could add a line of space rather than <br> between the bulleted lines, as below:

Recent research on the subject has expanded on various fronts.[6] These include:

• religious services as consumer goods[7]

• religious organizations as firms[8]

• religious benefits, costs, and markets[9]

• economic analysis of religious doctrines and incentives[10]

But the latter would accentuate the difference between it and other paragraphs (because of the space line between bulleted points) compared to the other paragraphs in the Lead of Economics of religion, which would be unnecessary and undesirable I think most people would agree. --Thomasmeeks (talk) 21:42, 30 December 2010 (UTC)
Please, no. The <br /> is a line break, meant to break a line, as in poetry. You are trying to misuse it for the formatting of space between lines, when the lines are separate and complete on their own. If you must have different spacing for list items, approach it with CSS properties like padding and margin in mind; please don't try to add inappropriate markup to an already complex system. This is a hack in search of a bug.
It also happens that I don't think we need increased spacing between lines. The examples you provide look fine both ways, so I'm rather convinced in the direction opposite to what you wanted: no need to change anything.
Also, if I could make a suggestion for the future: when adding an example like the above, please just use <ref>dummy_ref1</ref> or something, rather than paste an extra 13 KB or so into this page just to produce a [superscript effect].
Regards, — JohnFromPinckney (talk) 04:30, 31 December 2010 (UTC)
4T. No, no, no, J. Just the opposite (regrets if my wording seemed to suggest otherwise). <br /> would save space between lines. Acknowledging its use for poetry but excluding it for a prose paragraph is simply a preference. Intentionally making prose paragraphs look more dissimilar is choice that one can make, but it may not serve the reader well distracted by the dissimilarity.
5T. (I regret that I'm came across the following point only here rather than earlier.) In The Chicago Manual of Style indexed under "lists, vertical," the first reference is to a "Vertical Lists" chapter subsection. None of the examples there have added space between the vertically listed lines in paragraphed lists. The same thing in WP for a list is facilitated by <br />. This is supportive of the above proposal (as modified) to add "<br/>" to the Wiki markup list before "[[Category:]]".
Thank you for your consideration. --Thomasmeeks (talk) 13:24, 31 December 2010 (UTC)
if you want to make a bulleted list, just use the * wikicode for one. We shouldn't be making lists manually anyway. You don't need to use HTML line breaks or extra space to make a list. Mr.Z-man 18:48, 31 December 2010 (UTC)
I agree. I provided a technically correct answer, but now that I understand more of the intent, I see the stylistic issues. ---— Gadget850 (Ed) talk 19:42, 31 December 2010 (UTC)
6T. Well, I don't think that a preference should turned into a wp:guideline. Rather, I believe that Wiki markup list, including <br />, should facilitate reducing the difference in appearance of other paragraphs and a paragraph with a vertical list. In that regard, per the above example:

[Lead sentence:]

  • [text]
  • [text]
  • [text] without <br />
works less well IMO than:

[Lead sentence:]
• [text]
• [text]
• [text] with <br />

Thank you. --Thomasmeeks (talk) 20:34, 31 December 2010 (UTC)
If we want to change spacing around lists, we can do that with a change to the global CSS. Requiring people to manually use bullet symbols and put HTML line breaks to make a list, when we have simpler syntax to accomplish almost the exact same thing is asinine. Its not a style preference, its using a built-in feature of the wiki software, as well as HTML, rather than doing things in an unnecessarily complicated manual way. Note that the wikisyntax version produces a <ul> in the HTML, so there's also more semantic value than plain bullet points and line breaks. We should be making editing easier, not harder. Even with a simple-ish way to insert them, its still significantly more inconvenient than typing a character that exists on standard keyboards. In this case, the guideline already exists at Wikipedia:Manual of Style (lists), which states "do not double-space the lines of the list by leaving blank lines or extra HTML <br> tags after them." Mr.Z-man 22:19, 31 December 2010 (UTC)
7T. Per above ("If we want to change spacing around lists, we can do that with a change to the global CSS".), maybe. But in the meanwhile, so radically changing the above proposal just to avoid adding <br /> to the Wiki markup list seems complicated. However, if someone would effects such a change, that might be an appropriate time to object to <br /> in the Wiki markup list.
8T. "Requiring" saving of space between lines (which is not the proposal in this section) is different from "facilitating" line-space-saving (which is the proposal here).
9T. Of course, the proposal above would facilitate saving space between lines per Wikipedia:Manual of Style (lists), not adding unnecessary space lines.
10T. A paragraph-embedded list could be without bullet points (as indeed both lists in The Chicago Manual of Style indexed under "lists, vertical" cited at (5T) above were).
11T. I don't think that excluding <br /> from the Wiki markup list makes it easier to edit. Quite the opposite.
Happy New Year. --Thomasmeeks (talk) 13:11, 1 January 2011 (UTC)
Using newlines in lists will break screen readers; see Wikipedia:Manual of Style (accessibility)#Lists. ---— Gadget850 (Ed) talk 14:20, 1 January 2011 (UTC)
There is basically no reason to use <br /> in regular editing. There is a direct wikisyntax equivalent for it. So far the only reasons you have been able to give are for one particular type of templates, which represent only a tiny fraction of the editing done on Wikipedia, and to make lists in a way contrary to the way lists have been made on Wikipedia for the past 9 years or so just to achieve a minor padding difference. Mr.Z-man 16:29, 1 January 2011 (UTC)
12T. I have added more numbering above to refer to points in my Edits. IMO the default way of making an embedded list in a paragraph does not need to be bulwarked by making it inconvenient to do otherwise (per (8T) above).
13T. I mentioned templates twice (at (1T) & (3T)) -- once in passing (at (1T), the other time to say that <br /> was not only useful in templates (at (3T)).
14T. On the other point, see my (corrected & now labelled) (10T) above for starters. To recap from (10T), what is done in The Chicago Manual of Style as to a vertical list embedded in a paragraph should be facilitated (not required) in WP (per {2T,5-6T, & 8-9T)). A default way of making a list in a paragraph is not really an argument against an alternative method if it would improve on the default per (2T, 3T, 5T) comments and examples. --Thomasmeeks (talk) 20:49, 1 January 2011 (UTC)
It is more than the default way, it is the accepted, correct way. Your suggestion may be a slight style improvement, but its a huge loss in every other area. You're losing a lot of usability by having people use HTML line breaks and manual bullets/numbering rather than a simple asterisk or number sign. You're entirely losing the semantic value of an HTML list. And you're losing significant accessibility for users with screen readers as Gadget850 mentioned. Why do we need multiple ways to make a bulleted list? A trivial style improvement is not sufficient justification for essentially doubling the complexity of list-making in wikitext. Wikipedia:Manual of Style (lists) explains how to make an unbulleted list. Mr.Z-man 22:05, 1 January 2011 (UTC)
15T. I think that most will correctly understand (14T) above (slightly corrected) as not advocating an imposed format on anyone or removing the default options. --Thomasmeeks (talk) 02:56, 2 January 2011 (UTC)

16T. Per above and for the record, here is a comparison (adapted from 3T above) of the difference in appearance between (A) using a default-list procedure for an embedded vertical list in a paragraph form and (B) using "<br />" instead:

(A) default-list example:

Recent research on the subject has expanded on various fronts.[11] These include:

  • religious services as consumer goods[12]
  • religious organizations as firms[13]
  • economic analysis of religious doctrines and incentives[14]
  • religious services as consumer goods.[15]
(B) "<br />"-list example:

Recent research on the subject has expanded on various fronts.[16] These include:
• religious services as consumer goods[17]
• religious organizations as firms[18]
• economic analysis of religious doctrines and incentives[19]
• religious services as consumer goods.[20]

They are both vertical-list paragraphs, but (B) is less "loud" in not calling undue attention to bullet points in the paragraph by virtue of bullet size and coloration. For late-comers, that's the point of the above proposal to add "<br />" to the Wiki markup list.

P.S. I acknowledge points of unclarity on my part on some earlier Edits above and express regrets that they may have unduly & unsettlingly extended discussion here. --Thomasmeeks (talk) 13:56, 3 January 2011 (UTC)

Please understand that simply repeating your viewpoint is not going to garner more support. Several editors have stated that your proposal is completely redundant to the existing method of creating HTML based lists, and that your method breaks normal HTML semantics that is essential to accessability. With that in mind, I am closing this discussion. — Edokter • Talk — 15:48, 3 January 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Enabling "compare" feature between pages using the same infobox

Main article: Bugzilla:26530

Title pretty much says it all. Please see the main article for the original proposal. Feel free to comment here if you don't have a Bugzilla account. Kind regards, and a Happy New Year 2011! :) Rehman 02:39, 1 January 2011 (UTC)

  • Oppose, using your example of comparing camera (specs?) the only reason you need to that information is you are looking to buy a camera, Wikipedia is not a shop or a mean to advertise products, that job should be left to the shops themselves to sell their products. -- d'oh! [talk] 06:13, 1 January 2011 (UTC)
No, you got me wrong. I did not mean just electronics or "buyable" items. It could be anything, from ships, aircrafts, waterfalls, power stations, you name it... Rehman 07:21, 1 January 2011 (UTC)
I can understand where you are coming from, but I doubt anyone would want to compare the displacement of two ships or compare the power capacity of two power stations. I can only see this feature getting used as a shopping feature, which in turn might force editors to add more unless data to the already bloated infoboxes. -- d'oh! [talk] 13:13, 1 January 2011 (UTC)

Tennis Players at On going competitions

I have on numerous occasions seen half completed sections where people have started filling in about a current tournament that the player is participating in and not completed the addition as to the result. Therefore I propose after a tennis tournament begins and until that players participation has ended that nothing should be added, as it can make pages look messy with half completed additions. Djbrewer89.240.53.224 (talk) 00:59, 5 January 2011 (UTC)

That would be nice, but I don't think we have the mechanisms to make it happen. I have made similar suggestions for the medal tables at Olympic Games and similar events. They always remain a mess during the Games because of fans adding the results of their own heroes and ignoring others. A number of editors always agree it would be a good idea to wait until it's all over, but there is no way of managing the enthusiastic but naive editors who never look in places like this. HiLo48 (talk) 01:15, 5 January 2011 (UTC)
Agreed. Short of having a cadre of admins watching every sporting event and semi-protecting it during the event, the best thing to do is just accept that, when something is occurring - be it breaking news, a sporting event, or an election - there will be a certain amount of chaos. Just like the actual news, except sometimes on Wikipedia people forget to clean up. But it gets done, eventually. --Golbez (talk) 02:54, 5 January 2011 (UTC)

ArbCom reform

I've written an essay called WP:ArbCom reform. Comments welcome. PhilKnight (talk) 15:10, 6 January 2011 (UTC)

Change to make more users upload own work to Commons

It has been suggested to make a change of upload form to make more users upload own work to Commons. Feel free to comment here. Users can still chose to upload to en-wiki if they want to (they just have to click a different link). --MGA73 (talk) 20:03, 6 January 2011 (UTC)

Template:Namewarning

I've created {{Namewarning}} to add to userpage templates like {{Banned user}}. The purpose, as the documentation states, is to reduce the labelling effect of having templates that effectively say "X is a bad guy, he got booted off Wikipedia!" on user pages. So I'm proposing that this be added to appropriate userpage templates. Rd232 talk 08:56, 18 December 2010 (UTC)

Personally, I think this is obvious. Pretty much everyone knows that an online screen name is in no way verified as being associated with a real person. I just don't see the need for such a template. Tiptoety talk 05:35, 20 December 2010 (UTC)
"pretty much everyone"? everyone knows WP usernames are unverified? I doubt that. And what about those who don't? Besides, even if everyone on planet earth knows, there's no obvious harm in acknowledging it, and there is some benefit: the labelling This Person is BANNED From Wikipedia does upset banned users, and such upsetness isn't helping them to let go of Wikipedia, is it? (And, spelling out why that matters: WP:SOCK.) Rd232 talk 08:40, 20 December 2010 (UTC)
Regardless of whether you think this will often be useful, there are surely some cases where it will help. This is the sort template that we should have had already. — Gavia immer (talk) 04:47, 22 December 2010 (UTC)
I can't imagine a good reason not to use this template. The more we can do to avoid offending individuals who haven't done anything, the better. Nyttend (talk) 01:15, 28 December 2010 (UTC)

Call me a moron who happens to have a Bachelor's Degree in math, but I have no clue what that template is supposed to mean. –MuZemike 02:19, 31 December 2010 (UTC)

You're a moron who happens to have a Bachelor's Degree in math, and I'm not sure either. -- RoninBK T C 10:58, 8 January 2011 (UTC) What? S/he asked...

Statistics

I would like to suggest that you restart to put on your site, maybe inside the FAQ's, statistics about the wikipedia. For example, Which version of Wikipedia has the largest number of articles (top 50)?, which article appears in most languages?, how many users does the Wikipedia in Esperanto have per month? Per day? What is the ranking of usage among the different versions?

Feel free to add any other data you might feel interesting for users to know. Thank you very much! Emerson Werneck (Brazil) —Preceding unsigned comment added by 200.198.220.5 (talk) 11:01, 7 January 2011

Would you happen to be referring to something like Special:Statistics? -- RoninBK T C 07:32, 9 January 2011 (UTC)

Proposal for an alias to templatespace

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Result: Not enacted There does not appear to be a widespread consensus for enacting this proposal. --Jayron32 03:23, 11 January 2011 (UTC)
Previous discussions: Wikipedia:Village pump (proposals)/Archive 36#Namespace aliases, Wikipedia:Village pump (proposals)/Archive 41#new shortcut namespaces, Wikipedia:Village pump (proposals)/Archive 56#P: and T: namespace aliases, Wikipedia:Village pump (proposals)/Archive 57#Make "T:" a shortcut to refer to templates, Wikipedia:Village pump (proposals)/Archive 59#User talk space abbreviation

Proposal 1: For navigation purposes (not for transclusion purposes, but for editors/readers of templates), T: should be made into an alias for templatespace.

Proposal 2: U: be made an alias into template talk space.

This proposal results from the need stated at WP:RFD on Wikipedia:Redirects for discussion/Log/2010 December 29 about the need for the pseudo-namespace redirects sitting in articlespace prefixed with "T:"

These would work like [[WP:]] and [[WT:]]

184.144.166.27 (talk) 19:03, 30 December 2010 (UTC)

  • Support T: for Template (having to type "Template:foo" in the search box when I need to get there is such a pain in the neck); but U: for Template talk seems counter-intuitive to me: wouldn't TT: do it? A. di M. (talk) 19:29, 30 December 2010 (UTC)
  • Oppose We have "WP:" and "WT:" because many people use those all the time; few people would have much real use for these other shortcuts. Also, people would think that "U:" goes to a namespace that has something to do with the letter U, i.e. the User namespace. And pointing "U:" to the User namespace saves a whole 3 characters, which is really not worth it. "TT:" is not possible, as it is the interlanguage prefix for the Tatar Wikipedia. "T:" would conflict with articles such as t:kort and article redirects such as T: The New York Times Style Magazine, and I'm really not convinced that saving 7 characters is really worth it for the vast majority of cases. Anomie⚔ 21:00, 30 December 2010 (UTC)
    • Those can be fixed, since all the linguistic keywords also conflict with articles, so the articles are named using the technical restriction template. "W:" is already reserved. 184.144.166.27 (talk) 04:29, 31 December 2010 (UTC)
      • Sure, they can be fixed. But is the added complexity and the hassle of having to fix them worth saving people typing 7 characters in the rare cases {{tl}} cannot handle? IMO, it is not. Anomie⚔ 17:16, 31 December 2010 (UTC)
  • Oppose. You can just use {{tl|TEMPLATENAME}} to make shortcut links, and searching doesn't especially require the use of shortcuts because you can omit the prefix entirely in most cases and still get good results. There's no need for the mess involved in implementing a namespace shortcut. — Gavia immer (talk) 21:17, 30 December 2010 (UTC)
    • Can you elaborate on that? If I type "Convert" in the search box at the top right corner, the page I'm taken to has nothing to do with Template:Convert. A. di M. (talk) 21:49, 30 December 2010 (UTC)
      • Assuming you have "Search in all namespaces by default" checked in your preferences, searching on the name of a template will turn it up without having to specify the namespace prefix. The "go" functionality always prefers the main namespace, so when there's an article by that name it will go there, but searching will get it right. Try something like Special:Search/uw-test2 to see what I mean. — Gavia immer (talk) 02:23, 31 December 2010 (UTC)
  • Support I would absolutely love this. In fact, I was rather surprised when I first discovered it wasn't possible to just use "T:"(as "WP:" and "WT:" are). It becomes infuriating when you have to navigate between several different templates, and type the prefix for every single one. Also, simply omitting the prefix and relying on the search results is often more time-consuming than simply typing the prefix out in the first place. I don't see any real reason not to do it, provided the kinks can be worked out (which I am sure they easily can). Something like "TP:" might be better than just "T:" though. --Dorsal Axe 21:56, 30 December 2010 (UTC)
  • Conditional support. I would say TL: for templates, instead of just T:, with TT: for template talk. If I'm not mistaken, we are talking of a local project-space shortcut, not an interwiki shortcut, so I don't think TT: would conflict, but I'm not really sure. Rehman 02:08, 31 December 2010 (UTC)
    • It would conflict: should "[[tt:foo]]" go to a template or the Tatar Wikipedia? Also, BTW, TL is the code for the Tagalog Wikipedia. Anomie⚔ 03:36, 31 December 2010 (UTC)
      • Is there something wrong with "[[t:foo]]"? I know I'd find it convenient. Rd232 talk 16:23, 31 December 2010 (UTC)
        • The question was whether "TT:" as a shortcut prefix would conflict with "TT:" as the interlanguage prefix for the Tatar Wikipedia. There is no prefix conflict at the moment with "t:" as a prefix, although there are two articles/article redirects that would have to be moved. But how often are templates in general (i.e. T:DYK is an exception, not the rule) linked or visited directly in ways that {{tl}} cannot handle that saving 7 characters is worth the added complexity and the inconvenience of not being able to have these articles at their current titles? Anomie⚔ 17:16, 31 December 2010 (UTC)
  • Oppose per Anomie who summed up my concerns. Also because of the fact that it would restrict possible future article titles, and because existing pseudo-namespace shortcuts already do the job in cases where a shortcut would be needed such as high-traffic pages. The majority of pages in the Portal talk:, Template talk:, and Category talk: namespaces are very low traffic so it's not worth it for those either. -- œ™ 05:43, 31 December 2010 (UTC)
  • Oppose per Anomie. Unlike WP, where hundreds, if not thousands of shortcuts existed, there are only a handful of templates that are linked to with the shortcuts. Mr.Z-man 18:18, 31 December 2010 (UTC)
  • Oppose per Anomie (and can we shove this into "perennial proposals" after this, this comes up about twice a year) ? —TheDJ (talk • contribs) 19:56, 31 December 2010 (UTC)
  • Support Good idea, more convenient.--Patrick (talk) 20:43, 31 December 2010 (UTC)
  • Support Typing "Template:" in full is a pain, and the shortcut WP: also saves "only" seven characters but is nonetheless useful. There are many commonly used templates for which shortcuts could be made. Although this would not be much help for linking to templates, it would make searching easier. Intelligentsium 22:04, 31 December 2010 (UTC)
    • Note that no shortcut is needed for using or linking to (since we have {{tl}}) templates, only for entering templates into the search bar to go directly there. How often does that really happen, compared to how often people link to Wikipedia-namespace pages? Anomie⚔ 23:37, 31 December 2010 (UTC)
  • How about TM: for Template: and (possibly) TMT: for Template talk:? These wouldn't conflict with any language codes. A. di M. (talk) 15:47, 2 January 2011 (UTC)
    TMT is the language code for the Tasmate language, actually. --Yair rand (talk) 16:45, 2 January 2011 (UTC)
  • Oppose. This comes up far too often. Can't someone make a project page fully explaining most of the reasons why additional namespace aliases are a bad idea? --Yair rand (talk) 16:48, 2 January 2011 (UTC)
  • Comment how about setting up a namespace solely for shortcuts? say --:xyz which can point to a page any namespace, but the --: namespace is reserved for redirects (ie. shortcuts). 184.144.161.173 (talk) 20:40, 2 January 2011 (UTC)
    • So templatespace shortcuts would be called --:T:xyz and templatetalk --:TT:xyz, and similarly for all other ones. Then we migrate all these pseudo-namespace redirects from articlespace into this new shortcutspace. That would include MOS:xyz pseudonamespace CNR shortcuts. 184.144.161.173 (talk) 20:44, 2 January 2011 (UTC)
      • Because that defeats the purpose. The shortcuts are designed to be quick and easy to remember, and easy to type. Moving them to another namespace would require people to learn all new shortcuts. It would break all the existing links to the shortcuts. And for templates, "--:T" only saves 4 characters over "Template." CNRs don't really cause any significant problems, most of the "arguments against" on Wikipedia:Cross-namespace redirects are pedantic nonsense. Mr.Z-man 20:56, 2 January 2011 (UTC)
  • Oppose -- Magioladitis (talk) 00:17, 3 January 2011 (UTC)
  • Oppose. T: isn't useful enough to justify any hassle at all, and there is hassle; U: is just a straight up bad idea. —chaos5023 (talk) 22:37, 3 January 2011 (UTC)
  • Oppose It's honestly not that big of a deal. "Wikipedia" and "Wikipedia talk" take longer to write than "Template". /ƒETCHCOMMS/ 23:22, 3 January 2011 (UTC)
  • Support I think this would be very helpful and convenient. Template and Wikipedia have an almost equal amount of letters, too. Would prefer TT for template talkspace, or similar, and TL would be fine for templatespace also. --Whitehorse1 00:33, 4 January 2011 (UTC)
    • As has been said, neither TL nor TT are available for namespaces, as they're both language codes. Mr.Z-man 00:55, 4 January 2011 (UTC)
      • Yes, my support is for a 1 or 2 character alphabetical alias, either 'T', 'TT', 'TL' or 'TP' (covers each syllable), or T$omeletter. Basically support an alias with the specifics of which 1 or 2 letters being of lesser concern--suffice to say that ultimately having 'T' in there somewhere (probably at the beginning) would make sense. Whitehorse1 01:07, 4 January 2011 (UTC) Edited to add: te: is taken, however tm: and tp: seem to be free. ...didn't try other letters of the alphabet.
  • Oppose and send it to the PEREN namespace. :| TelCoNaSpVe :| 01:12, 4 January 2011 (UTC)

No one else has commented here for a week. Time for someone uninvolved to close this? Anomie⚔ 01:57, 11 January 2011 (UTC)

 Done. I will leave it to someone else to add this to WP:PEREN if they wish. --Jayron32 03:23, 11 January 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
Thanks. I wrote something up at WP:PEREN#Create shortcut namespace aliases for various namespaces. Anomie⚔ 04:01, 11 January 2011 (UTC)

A dedicated page for better user feedback gathering

When typing in WP:Feedback or WP:Complaints I notice the pages they lead to don't actually lead to pages that allow newbie users to express their comments and concerns about their Wikipedia experience. There seems to be no systematic feedback gathering mechanism that would help Wikipedia identify what concerns users have and what needs to be addressed to improve the Wikipedia experience. A page or project dedicated to sorting through the major complaints and systematically identifying the importance of various issues should be established. As things stand, Wikipedians may have a vague idea that certain issues are important but there is no organized feedback data to quantify what issues are the most pressing. A feedback or complaints page should be setup where a registered user can lodge their feeling on a certain issue. In the current setup such feedback will simply disappear into the ether of archived discussions. Lambanog (talk) 13:41, 7 January 2011 (UTC)

AFAIK, the Village Pump(s) are the venue such comments. Perhaps redirect the above to here? Rehman 13:52, 7 January 2011 (UTC)
The problem with the current setup here at the village pump is that the data is disorganized. Someone expresses an opinion on an issue and then after a brief discussion the opinion or view gets sent into a black hole of oblivion. To better account for these views there needs to be a more permanent way of recording them that stays current and up-to-date. I'm thinking of a suggestion thread or feature request system that actively solicits votes that do not expire. For example currently there are perennial proposals that supposedly do not have community consensus. How do we know? Because of one or two votes held three years apart participated in by at best a couple hundred of people? How about the opinions of all those people that may have become interested in the issue since but were not part of the active debate? How do they weigh in? Will they still be around the next time someone is able to organize and active push to clarify the issue or would they have long since abandoned the project because it was not addressed when they were available to provide input? Lambanog (talk) 14:06, 7 January 2011 (UTC)
Okay, now I'm leaning towards your side on this one, because I have come across this issue quite often (see #WP:Requested merge on this page, for example)... Rehman 16:24, 7 January 2011 (UTC)


In principle this seems a good idea, although lots of details would need to be worked out. It would need to be made as simple as possible. How would the comments be sorted into manageable, useful data?
It's not at all obvious to readers and brand new editors how to give feedback, so discussions end up skewed towards the views of more established editors. Many discussions of policy, eg. vandalism, article protection, deletion policies, have large effects on occasional editors but it seems their views aren't heard enough. Any process that gathers views from a wider selection of people has my support. --Physics is all gnomes (talk) 19:54, 8 January 2011 (UTC)

Generally, ideas disappear "into the black hole of oblivion" because there's not enough people who want the feature. Or, in the case of WP:PEREN, it's already been discussed to death and clearly won't happen. There's really no point revisiting items listed in WP:PEREN unless and until some pretty major changes happen to Wikipedia's rules & guidelines. Each item on that list is pretty well detailed. — The Hand That Feeds You:Bite 23:55, 10 January 2011 (UTC)

Wikipedia-wide collaboration proposal

I've been seriously wondering why there isn't a Wikipedia-wide collaboration currently operating. I've only been here for maybe a year or two but I've been looking at some historical and “semi-active” collaborations (eg WP:IDRIVE and WP:SPOT, and it seems like these have lost momentum and just faded out. This truly saddens me, because I think that a large collaboration like this would truly capture the philosophy of Wikipedia.

Therefore, I am proposing a completely new collaboration in the form of an independent WikiProject ("WikiProject Collaboration"?), which would improve some of WP’s larger, more mainstream articles, especially the one which would be too much for an individual editor to handle. Articles would be nominated just like any of the Wikiproject-specific collaborations, but might run longer (up to 2 months, perhaps) depending on the size and scope of the article. The project would also be advertised better so hopefully more people would participate. I believe that successful operation of this sort of project could greatly benefit the encyclopedia by improving some of the more important, yet lower quality articles. Of course, the topics would be rotated in a similar manner as WP:TFA to prevent people from losing interest in contributing.

I am posting this here to see if there would be support for such a project, and to see if anyone would be interested in participating. If there is no strong opposition I would like to create it. —focus 04:44, 8 January 2011 (UTC)

Because I think that the format could be greatly improved and it could be much better advertised if it was created from scratch. The existing projects are known for going inactive every so often, so I think that discourages some editors from participating at all. On the other hand, if a new project was created with better organization, recruitment methods, and incentives for participation, I think it would attract more intrest and hopefully never become completely inactive, as long as there are a few people to keep it going. —focus 14:44, 8 January 2011 (UTC)
The principle is well established from previous examples; the question is how would a new incarnation be better. Whether that's "from scratch" or a revival of something existing, or something new with old things merged in doesn't matter so much. One thing such a Collaboration could do is make use of tools such as user:Mr.Z-man's "popular pages" listings (eg Wikipedia:WikiProject Venezuela/Popular pages), trying to identify key pages and crossovers between WikiProjects and bringing in multiple wikiprojects to the collaboration. Anything WP:CSB-related can always use a boost, and there might be creative/systematic attempts to find crossovers from CSB topics to more popular ones. Something like WP:CRS might also help, to draw people in, as might use of something like {{CotM}}. Good idea, lots of work - good luck... Rd232 talk 19:35, 8 January 2011 (UTC)
The main reason that I'm suggesting starting it from scratch is that I think it should clearly be a standalone wikiproject. For example, take a look at WP:GOCE. Everybody is allowed to copyedit, but the people at GOCE are the ones wo will do it more often. That's the idea: everyone would be allowed to contribute to a collaboration, but the members of the project are the ones who actively work on the articles, as well as run the technical processes. I also have ideas (barnstars for edits, guidelines on nominated articles, active recruitment, etc) which I think would be easier to "get right the first time" than to implement on an existing set of rules and procedures. Focus (talk) 01:41, 9 January 2011 (UTC)
Fine. My point is that the main concern is the amount of effort put into designing and then promoting the collaboration. As experience shows, it needs to be done well to be sustainable (though I guess even a shortlived attempt might be worthwhile, and achieve something, even if it just nudges people to think about these things). Rd232 talk 10:40, 9 January 2011 (UTC)
Go for it focus. You have my support and help. Drop me a line on my user page if you have your idea sketched out and/or what I could do to help :) Shabidoo | Talk 01:08, 12 January 2011 (UTC)
Thanks! I'm going to develop the page design in my userspace, then do some recruiting and hopefully have it running by February. Focus (talk) 01:40, 12 January 2011 (UTC)

Vote to Vote on a New Request for Adminship Format

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Motion: The way we select admins should be changed. This will be done by allowing anyone to propose a new method and having someone second it. Discussion on each method can be held and amendments can be proposed and seconded. If the proposer accepts the amendment, it will be changed; in the case that the proposer of the method does not accept the amendment, a simple majority vote will decide on which method will continue. If the amendment is accepted, the proposer and seconder of the amendment will become the proposer and seconder of the method. After a period of a month, every method that was proposed and seconded will be put forward for a simple majority vote, and after two weeks the method with the highest percentage of votes will be implemented.
Proposer of the motion: A930913
Seconder of the motion:

There are three votes you can choose: for, against or abstain.

For
Against
Abstain
  • Oppose A solution looking for a problem. WP:PEREN already includes "RFA is broken". Unless you propose saying exactly what is broken, there is no reason to go through with this. The community is already totally confused on what to fix. We don't need to document that indecision. This also seems to propose that Wikipedia runs on votes. It doesn't. I would be wholly opposed to any "solution" to this (non-)problem which does not actually follow WP:CONSENSUS. --Shirik (Questions or Comments?) 09:12, 11 January 2011 (UTC)
    While I agree that this is a totally un-wiki way of tackling the issue, this oppose rationale makes no sense at all. You agree that the community is confused and undecided about how best to fix RfA, yet claim that that's not a problem?!? This is certainly completely the wrong way of tackling the issue. But if someone can find the right way to address it, that's a discussion which badly needs to be had. Happy‑melon 11:52, 11 January 2011 (UTC)
    I believe what Shirik was trying to say is that this "motion" isn't saying anything beyond "The way we select admins should be changed". Everything else in this "motion" is complete and total legalese. Polling is not a substitute for discussion, and this user is just creating a poll without any significant question. -- RoninBK T C 12:46, 11 January 2011 (UTC)
Yuyp, I think this is a classic example of process creep. WP:CREEP --Errant (chat!) 12:50, 11 January 2011 (UTC)
yeah, this is not an actual proposal, so this isn't going anywhere. — The Hand That Feeds You:Bite 13:32, 11 January 2011 (UTC)
While I'm not sure I entirely comprehend all the stuff there about amendments and seconding, it looks to be at the same time overly bureaucratic (due to the over-reliance on votes) and chaotic (since any 2 people can put a proposal through to the full community vote). This has almost no chance of succeeding. The end result is going to be a dozen different proposals, none of which gets more than 10-30% community support. If you want to actually get the majority of the community behind something, you have to present a limited number of options, ideally no more than 2 or 3, where one is the default of "no change." And a simple majority is never going to be accepted, it would need at least 60%. Mr.Z-man 15:02, 11 January 2011 (UTC)
That's the point of this first part. Once it is determined that people want change, the people who vote here that they want change are effectively voting for the method that gets the highest vote in the latter stages. 930913 (Congratulate/Complaints) 15:11, 11 January 2011 (UTC)
That's just not going to work. Horribly arbitrary and bureaucratic. — The Hand That Feeds You:Bite 16:09, 11 January 2011 (UTC)
  • No, just... No. We don't have a vote on the request to have a motion to form an exploratory committee to determine if there is an issue which needs investigating. Just... Look, if you have a proposal for a change to the RFA system, propose that change. There's no need to seek permission to do so. I don't expect it to get very far, but its going to get farther than this poorly thoughtout metavote. --Jayron32 18:50, 11 January 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Create articles about individual cables published by WikiLeaks

250,000 leaked "cables" are expected to be published in the next few years by WikiLeaks. Main story: United States diplomatic cables leak. I checked the whole discussion about the policy for linking to the leaks, discussing their contents etc. There's a huge work going on to keep Contents of the United States diplomatic cables leak updated with summaries of the most relevant cables.

In my opinion, each of these cables is going to trigger important discussions worldwide and affect the future of world diplomacy. All mainstream media are giving frequent reports on the latest releases referring to individual items of the list.

Each cable has a unique ID (e.g. "10MADRID86") that follows a well-defined grammar (see Template:Cablegate). This is the way those cables are referred to in citations by secondary and tertiary sources. In my opinion, it makes sense to create an article for each cable with the ID as the article name. It is pretty unusual for me to google for an individual cable on the basis of its "official name" and not find a Wikipedia article explaining what it is!

I'm not proposing to cite any part of the leaks here, neither am I suggesting that we should state that those documents are genuine or that their content is a correct depiction of reality. I just believe that those documents exist, because I've seen them, and that they are encyclopedic enough because a lot of people is talking about them; therefore I think that we should mention them and say what each of them is and provide a link that proves our statements. The best source for the statement "10MADRID86 is a document published by WikiLeaks; WikiLeaks states that it is the leak of a classified US embassy cable" is a link to the WikiLeaks page for 10MADRID86. Notice that the legal team of WMF has declared that linking to WikiLeaks is not illegal in Florida - there are already loads of links to WikiLeaks in several articles of the English Wikipedia.

(This proposal was originally made in the Bot request page, because we can easily create those articles automatically by fetching the new cables on a daily basis from WikiLeaks - I was actually volunteering to create the bot; however, first we have to decide whether we need or not articles about individual cables.) --MauroVan (talk) 21:54, 3 January 2011 (UTC)

Does each of the 250K cables pass WP:N? Of course not. So there should be an article about all of them because...? Instead, create articles about the ones that pass WP:N and can be cited to news coverage, and leave the rest in the parent article. → ROUX ₪ 22:09, 3 January 2011 (UTC)
The problem with this is that a lot of the news coverage is not really about the cables themselves, but their content. The cable is the source for the news article, not the subject. The content is mostly what's newsworthy and where most of the coverage is. The fact that the articles may mention the specific cables or even quote them may contribute to notability, but simply being used in a news article is not a guarantee of notability. I think if a cable is used in multiple reliable sources, then it may deserve an article – written by a human – but all 250k of them are certainly not inherently notable. We don't even know the content of 99% of them. For all we know, they're being released in order of most interesting and 200,000 of them will be so boring they'll barely get coverage. And the last thing we need on Wikipedia is a quarter million more bot-generated sub-stubs. Excluding the other future articles that will be created, that would make nearly 7% of Wikipedia into stubs about the cables. Mr.Z-man 23:21, 3 January 2011 (UTC)
I agree—there's no way each of those 250,000 cables are notable enough for an article. Their text is probably better off in Wikisource, though, if OK legally with the whole confidentiality whatnot. /ƒETCHCOMMS/ 23:24, 3 January 2011 (UTC)
Thanks for the comments.
I realise that it is objectionable whether each cable passes WP:N. It's a case similar to other sets of multiple items... the set itself is surely notable, perhaps not all individual items are; but in order to give a coherent presentation of a large collection of structured information, we can create a series of articles linked to each other. Silly examples: check how many detailed articles are linked from Outer Plane (RPG stuff) or List of Scrubs episodes (a TV series); what makes Githzerai or My Therapeutic Month notable enough to have their own article if not the need to give a thorough description of the knowledge domain that comprises them?
However, I agree that a series of lists (in table format) of the cables coming from each embassy would probably be more appropriate. Those cables that receive sufficient media coverage outside WikiLeaks (somebody could say that being published on WikiLeaks is a huge coverage in itself, but they are published uncommented) will then have their own article, maybe.
BTW, I never heard that the cables were released in order of importance. So far, this has not been the case. They are just clustered with unknown criteria (apparently, according to their subjects) and released cluster by cluster to avoid overwhelming the public with raw data and give time to the journalists to analyse them as soon as they pop out. This is also good for us.
Please let me know your opinion about the lists-of-cables-by-origin proposal too. --MauroVan (talk) 11:27, 4 January 2011 (UTC)
Lists of cables leaked might have some value on Wikipedia. Agree that putting them on wikisource would be better than putting them on wikipedia, however other threads on this subject have raised the question of whiter or not the leaked cables in the public domain. The pervaling opinion is "ask the WMF first" on account of the ambiguous nature of U.S. government copyright release. If the government releases it themselves it is clearly PD unless explicitly stated otherwise. However if the government creates something and it is released by others then the law is not at all clear. Therefore Support a list, but Strong Oppose articles on each cable, and just as importantly, Ask the WMF before coping the text into Wikipedia namespace. Linking to sites like the NYT that carry the text, however, is fine. Sven Manguard Wha? 19:28, 5 January 2011 (UTC)
  • This is a hilariously bad idea. Unlike towns, these cables don't inherently represent anything of persistent interest (despite the importance of the overall leak and of a small fraction of the individual cables). So the very best way to sensibly ration the articles we have on the cables is to at minimum restrict them to those which a human cares enough about the cable to start an article. Creating 200k+ articles with a bot and waiting for a human to come by and update them is complete folly, even without the glaring notability, BLP and potential privacy issues. Protonk (talk) 01:41, 12 January 2011 (UTC) Edit: not to mention copyright concerns! Protonk (talk) 01:42, 12 January 2011 (UTC)
Thank you for your collaborative attitude, Protonk. Fortunately in a brief interval of sanity between my frequent phases of folly, I had already tried to address concerns like yours; please read the whole discussion above. BTW, notice that even during my hilarious deliria I have just asked whether it makes sense or not to have articles about individual cables; maybe they do not need to be about each individual cable and maybe they do not need to be created by a bot.
However, IMHO it is more reasonable and likely to attain a consensus to restrict the scope of the proposal to just creating lists of cables by origin. Please let me know your opinion about this.
PS: There are no copyright concerns, because nobody has ever proposed to cite any part of the text of the leaks (which would not be illegal in Florida, in any case). --MauroVan (talk) 11:48, 12 January 2011 (UTC)
Lists of cables by origin are already available at cablesearch.org (select "By Source" in the menu and choose a location). Each list entry seems to be that cable's subject, which is part of the text of the leaks. Quite apart from the legal and ethical issues, copying leaked primary sources doesn't sound like encyclopedia-building. Given that we wouldn't be adding any value to the lists, what encyclopedic purpose would republishing them serve? - Pointillist (talk) 12:33, 12 January 2011 (UTC)
Hi Pointillist, I'm not sure I got your point. Of course this material has been already published elsewhere, actually it's been published in several places and this is precisely why it is encyclopedic. We never publish "new" stuff, we always republish information that can be found elsewhere. The "purpose" is the same as (re)publishing the List of sovereign states or the List of Nobel laureates, data that can be easily found elsewhere too. We want all (important) human knowledge to be accessible on one website.
About the titles, I have not proposed to use the titles: I have proposed to use the IDs, like 08BELGRADE1097, to identify the cables. However, citing the title of something is not copyright violation, of course, otherwise we'd not be allowed to mention any book or movie or whatever.
Finally, I (and Wikipedia's legal advisors) do not see any legal issue in providing links to the leaks or listing them. What do you mean? Etichal issues are more personal than legal ones, but I still do not believe that there is any ethical issue involved here, it's a fact that these leaks exist and we have to talk about them if we believe that they are notable enough, whatever our opinion on the leaking is. Also those who believe that WikiLeaks should not have leaked them should be interested in showing what the leaks' contents are and why spreading them was harmful (the leak already happened, we cannot stop it just by censoring information about it on Wikipedia! and the WikiLeaks critics never said that the problem with the leaks is that ordinary people can read them... They hold it that the problem is with political bodies and armed groups reading them, and they do not need Wikipedia to read them). --MauroVan (talk) 14:00, 12 January 2011 (UTC)
Do you mean something like this? (I've included the timestamp because the IDs don't sort sequentially otherwise):
2006-10-17 06:06:00 #06BELGRADE1681
2008-10-22 14:02:00 #08BELGRADE1097
2009-07-29 13:01:00 #09BELGRADE765
2009-09-03 13:01:00 #09BELGRADE841
2009-10-22 15:03:00 #09BELGRADE1222
If the cable's subject is missing, a list like that isn't important human knowledge (is it?) and I'm still not clear how it would help our readers. By comparison, your List of Nobel laureates example adds value in that it links the names to the relevant wikipedia articles, which is not a task we would expect external sources to do reliably. I suppose List of sovereign states has some navigational use too, despite the issues about OR and weasel words. - Pointillist (talk) 16:41, 12 January 2011 (UTC)
Glad I could help. If you've eliminated the idea of creating the articles en masse with a bot then that still leaves the question of whether the articles should be created at all. In that case the question is really not one which can be solved via centralized discussion as the role of normal editing should suffice. As for the copyright issue, if you aren't even going to cite the cables themselves then the question becomes even more superfluous. If there is extant news coverage of a specific cable sufficient to meet WP:N and our other inclusion guidance then we can be doubly sure that normal editing will give us something approaching the "right" number of articles on cables. If you want to make a list of cables on some specific subject where the only real unifying characteristic is that the cables were A: leaked and B: cover the same basic subject, godspeed. I doubt that such a list will be terribly helpful, but it is a (relatively) free country. Protonk (talk) 17:16, 12 January 2011 (UTC)
IMO listing the IDs is informational because these IDs provide unique references to all cables, which can be searched online etc. It's like List of mantis genera and species (not "terribly helpful" either :-) ): the informational content is the names of the things. Moreover, it has navigational purposes, which also applies to the cables' list for those cables that may be regarded as notable. However, I do not suggest a mere list of IDs but a table with relevant information for each cable, like
  • Original date
  • Release date
  • Destination
  • Link to the cable content (outside Wikipedia)
  • Subjects (tags are already provided by WikiLeaks and other sources)
  • Links to articles on mainstream media about that individual cable
We can also include the title, which is not part of the text and whose citation does not violate any copyright, or we can not include it if there is a good reason not to. My opinion is to include it but it is not a key point of the proposal.
Besides this, I agree with the last contribution by Protonk. Let's use ordinary editing on a few significant cases and then if a pattern emerges a bot can help for the dirty work (of creating lists, not individual articles which clearly seems more controversial). --MauroVan (talk) 17:37, 12 January 2011 (UTC)

Template:Uw-Unverified Death?

Having watched yesterdays Gabrielle Giffords mess and todays Richard Winters mess at ANI. I am convinced a single level warning template ( simliar to Template:uw-biog4im ) would be advisable. Any one agree? The Resident Anthropologist (talk) 23:50, 9 January 2011 (UTC)

I'd suggest only in the case of really obvious stuff (vandalism). In the case of the first example,, I believe it actually was reported that she had died for a short period and then it turned out she was alive and in the case of the second, there's a good chance it's legitimate, but we don't have any reliable sources. It's sort of bitey, otherwise. HalfShadow 23:54, 9 January 2011 (UTC)
ABC news still reports that she (Giffords) is still alive. I believe that we should not say that she is dead until it is confirmed, and the news says that she is following simple commands. I no longer visit A.N.I., so I had no idea of the existence of the apparent piles of horse apples that are/were sitting over there. [|Retro00064|☎talk|✍contribs|] 00:09, 10 January 2011 (UTC)
Indeed Gabrielle Giffords may not be the best example. But its serious thing and we should treat it as such and may be add link to encourage discussion on the article talk page? The Resident Anthropologist (talk) 00:24, 10 January 2011 (UTC)

I agree with the spirit of this, but think a talkpage template would just be a way of underlining the drama. I think we probably need clearer guidelines about current events. The problem is nothing more than editors wanting to be too close to the cutting edge. If that could be reigned in even a fairly small amount, that would solve things. --FormerIP (talk) 00:37, 10 January 2011 (UTC)

Here's a novel, untested idea. You could, you know, try to maybe communicate with editors and ask them questions, direct them to policies and guidelines, and attempt to converse with them. You know what advantage that has? They learn more about how Wikipedia works. You know what disadvantage that has? None. If they refuse to listen you, they get the same block as if you left a template, but for those users that don't deserve a block, they get the impression that Wikipedia is populated by real people who care about them rather than mindless bots that drop incomprehensible form letters on their talk page. --Jayron32 00:57, 10 January 2011 (UTC)
In addition to that, a relevant editnotice template might be helpful. Rd232 talk 13:20, 10 January 2011 (UTC)
Agree with Jayron. They probably think they're being helpful, a warning template is an overly aggressive response. --Physics is all gnomes (talk) 13:25, 10 January 2011 (UTC)

I would have to question the usefulness of such a template as far as AGF is concerned. I mean, the former was caused by a media gaffe, while the latter by a very good effort by the family to keep everything quiet. I mean, it's hard to blame individual editors for something that was outside of their control. –MuZemike 15:07, 12 January 2011 (UTC)

Agreed. Pat Burns was another case where the media incorrectly reported someone as dead. Several people, myself included, updated the article trusting that the media was correct. To through a L4 warning template at good faith editors is not advisable. In most cases, there will be no remarkable drama about the death of an individual, and for those that do attempt false reports, I'd just classify it as vandalism. Resolute 15:25, 12 January 2011 (UTC)

"Today's Featured Picture" is usually flowers, insects, or a panoramic view of a town. I suggest more active images. One of my favorites was of a jet plane breaking the sound barrier.

Today's Featured Picture is selected from Featured Pictures. These are nominated and discussed at Featured Picture Candidates. We have a number of excellent photographers who specialize in the subjects you mentioned, so that's why you're always seeing them on the Main Page. If there's an image you think deserves to be a Featured Picture, feel free to nominate it. You'll want to check the Featured Picture criteria first, though, and possibly ask for input at Picture peer review. Cheers. Makeemlighter (talk) 02:47, 13 January 2011 (UTC)

Suggested new feature in RC

I want RC to be able to show edits with any tag or hide non-tagged edits. That would make it easier to fight vandalism.T3h 1337 b0y 03:05, 12 January 2011 (UTC)

Already been done - User:Lupin/Anti-vandal tool --Nat682 (talk) 06:23, 14 January 2011 (UTC)

Mission to Find the Most Supported Alternative to RfA

I am trying to find the most supported alternative method to RfA at User:A930913/RfA. Input is appreciated. 930913 (Congratulate/Complaints) 20:10, 13 January 2011 (UTC)

The previous incarnation of this process is still on this page with hat templates, and there is no reason for this incarnation to behave any differently, except that the userspace page will just be ignored rather than archived. The meta-process that you're working with is fundamentally juxtaposed to the accepted methods of researching community consensus. Jumping straight to "what do people want to replace RfA with" is skipping too many stages and is certain to result in no conclusive outcome. You want to be a lot more methodical in asking first what people feel is wrong with RfA, a discussion which is best suited to an RfC format. Happy‑melon 21:14, 13 January 2011 (UTC)

Album release date search by date

Wikipedia has a huge database of album release dates, however, at this time they are only searchable by music year. This is a very time consuming way of searching for albums released on a specific date. Would it be possible to implement an album release date search by date? — Preceding unsigned comment added by Infinat (talk • contribs) 16:02, 9 January 2011 (UTC)

Just to comment on this; if there was a way to search across table cells, a search string like "2010 albums" "released 14 December 2010" would actually have worked quite well. However, since the word Released and the actual release date are placed in different table cells in the album info box, it simply doesn't at the moment. The closest I could get while actually hitting any decent results at all was by stripping out the released in the search string, as such; "2010 albums" "14 December 2010", which of course doesn't really work as intended, since the date could be anywhere on the page. I suppose something could be done with the infobox album-template to facilitate this, but I'm clueless as to exactly how (if it is indeed possible). Omnomymous (talk) 17:53, 14 January 2011 (UTC)

Rename "Categories" to "Tags"

Though there's a fine line between them, Wikipedia should probably follow the general internet practice of calling these things "tags" instead of "categories".

As a practical bonus I think it might help steer development of organization and search functions in the right direction, ie. doing more of the things other websites generally do with tags. I don't have examples on hand smartass. I think you get the idea. Equazcion (talk) 14:58, 12 Jan 2011 (UTC)

I'm confused why you decided to call no one (and everyone?) a smartass despite there being not a single response to your proposal. --Golbez (talk) 22:50, 12 January 2011 (UTC)
Pure make-work. Next bright idea? Fences&Windows 23:39, 12 January 2011 (UTC)
Sure thing: Next one would be to institute some sort of rule regarding a required level of usefulness and demonstrated thought in proposal responses, rather than allowing "sux, next"-type answers. Equazcion (talk) 23:48, 12 Jan 2011 (UTC)
Rule zero: Don't insult the people you're proposing to. --Golbez (talk) 14:08, 13 January 2011 (UTC)

Okay, putting the relatively bad proposing method aside, I think this is reasonable. The purpose of "categories" is much more widely known as "tags" on the internet. But yeah, the change would be very very very difficult to adapt to, not to mention how difficult it would be to implement... Rehman 14:31, 13 January 2011 (UTC)

Personally I get the impression that "tags" are seen as more informal than "categories"—you don't hear people talking about "tag hierarchies"—but I don't think the way we name the metadata is preventing us from thinking about the possibilities. If you're talking about being able to search using combinations of metadata, then we already have that to a limited extent (e.g. incategory:1954 births incategory:Evolutionary Psychologists) but that only works if you already know the exact categories. The missing link is being able to search using supercategories (e.g. look for "Psychologists" AND "1950s births" and find Steven Pinker in the results because he belongs to sub-categories of both Category:Psychologists and Category:1950s births). According to Wikipedia:Category intersection this has been "a desired feature for quite some time". I'd like to go even further, so we could publish list articles that are constructed dynamically from metadata searches, rather than (for example) maintaining List of Nobel laureates and List of Jewish Nobel laureates separately. But I'm not holding my breath for any of this. We can't even attach a citation to a category on an article page, which is the most basic starting point for having a verifiable semantic web. - Pointillist (talk) 15:05, 13 January 2011 (UTC)
Oops, I should have mentioned that Magnus Manske has written a powerful category search called CatScan2 that runs on toolserver. - Pointillist (talk) 15:18, 13 January 2011 (UTC)
(edit conflict)The problem is not only that at this site we use the name "categories", but also that the word "tag" is already used for something else (maintenance and copyright licence templates, informally known as "tags"). To change the words would be highly chaotic, and I'm not sure if the trivial benefits really compensate that. Regardless of this "usual meaning", it's also usual that each major web site has its own interface, which may or may not be similar to others. I think that web surfers should be already aware that they shouldn't take functions or namings for granted, and categories are already enough intuitive so that the casual web surfer can understand or at least suspect whaat are they about. I mean: Barack Obama has, at the end of his entry, the links "Categories: 1961 births, 21-st century presidents of the United States, African american academics", and so on. What else can someone understand those links to be for, other than for the purpose we give them? --MBelgrano (talk) 15:26, 13 January 2011 (UTC)
Let's not forget that we also already have "tags" as applied to revisions by the EditFilter extension. Happy‑melon 15:54, 13 January 2011 (UTC)
That's true but I don't think it is irrevocable: it would be just as effective to call them "flags" (e.g. Flag: possible vandalism, Flag: references removed). - Pointillist (talk) 16:56, 13 January 2011 (UTC)
I think "category" would be more widely understood by non-native speakers of english: tag is quite a recent, technobabble word.--Physics is all gnomes (talk) 17:43, 13 January 2011 (UTC)


Not only do I agree with the last comment, I would go further. Not only would "categories" be easier to understand by non-native speakers - it would be easier to understand by native speakers of English, especially those new to the world wide web. After all, Wikipedia already has many "tags" - such as the recent deaths tag - so calling categories tags would only confuse people. ACEOREVIVED (talk) 21:38, 14 January 2011 (UTC)

move link to disclaimers to top of page

The link to Wikipedia's disclaimers is currently at the bottom of every page, which, in my opinion, is the worst possible place to put it. It should be at the top or in the bar on the side of the page so that people can click on it and look at the disclaimers without being forced to scroll through the entire page. Does anyone else agree? --Nat682 (talk) 06:27, 14 January 2011 (UTC)

Yes. Peter jackson (talk) 14:40, 14 January 2011 (UTC)
No. The use of disclaimers at the bottom is an internet standard. That's where anyone would seek it. Besides, once someone has read it and accepted it, there's no longer any reason to read it again, that's why they are always left at some remote and unobstrusive section of the page.
And more: the fact that "Wikipedia must say this" does not equal "All readers must read this". Some people is already aware of what can be expected from a web page or not, and what risks may be in their usage. I don't need a wikipedia disclaimer (or any web page disclaimer, for that matter) to know that if I had health problems I should consult a real doctor. MBelgrano (talk) 16:21, 14 January 2011 (UTC)

Previous discussion: Wikipedia talk:Spoiler#RFC: Change prominence of site disclaimer link in default skin. Anomie⚔ 00:45, 15 January 2011 (UTC)

New idea

It is a common practice to highlight stuff when we read. It increases productivity and is very helpful for future references. I myself feel great need of it whenever I reference wikipedia. I believe it will also be helpful to a lot of wikipedians. If you think this functionality is worth providing on wikipedia, pls support this proposal. To be clear, my idea is about one common highlighting of articles for all users. I read another proposal asking for personal highlighting functionality to users, I know its too complex to be implemented.

--59.162.23.4 (talk) 16:10, 4 January 2011 (UTC)

I don't see how this could be implemented. Highlighting is only helpful for the individual, because what's important to one person is useless to another. Plus, we deal with enough vandalism. I won't go into it (per WP:BEANS), but there's a ton of ways to abuse this. — The Hand That Feeds You:Bite 18:15, 4 January 2011 (UTC)
You already can, but please don't. It doesn't really make the page easier to use and can look really shitty, especially after several people with differing ideas about what's important go through it. 69.208.12.211 (talk) 19:04, 4 January 2011 (UTC)
The only way I could see this happening is something like a Firefox extension installed on your browser that keeps your highlights in your computer's memory. In fact if you did it right, it wouldn't necessarily have to be specific to Wikipedia, but would work on whatever website you wanted to use it on. That way, there's no server-side changes that would have to be made, or any extra load on the servers. It sounds like a useful idea, and I hope you can find a programmer willing to do it, but it's not something we would want to implement here on the server side of Wikipedia. -- RoninBK T C 04:43, 11 January 2011 (UTC)

For modern browsers, at least, it wouldn't be too hard to write something (using localStorage and JavaScript) client-side that would allow a user to make highlights on their own system and view them later. The biggest issue would be to come up with a way to identify what you wanted to highlight in a way that would be reasonably resistant to later article edits. - Jmabel | Talk 17:35, 15 January 2011 (UTC)

List of: Sources Considered Unreliable for wikipedia citing

Moved from Wikipedia:Requested lists
 – -- œ™ 08:23, 9 January 2011 (UTC)

Such sources would include atleast media organizations that serve as mouth piece for a totalitarian regime, articles, published books, and websites promoted or created as a means for inciting hatred and propaganda. (for example persecution campaigns in Communist china) Scientists who are also politicians, publishing works supporting a claim because they have an incentive or motive, OR they could be inflicted (e.g: life risking or jail risking situation) if they refuse to - as stated above in a totalitarian controlled country.

the guidelines in: http://en.wikipedia.org/wiki/Wikipedia:RS show some other examples. I suggest to create a list, so that lies and false "facts", would not pollute wikipedia so much.

Sometimes there are true facts even when a source is in a conflict of interest, however banned sources would be those that repeatedly post content that would be considered defamation in western societies, or repeat as "facts" that which have already been disputed by well respected organizations (think: United Nations, the US congress, etc.)

That's my proposal. -- —Preceding unsigned comment added by 212.150.174.178 (talk) 16:54, 8 January 2011 (UTC)

Would determining which sources are 'reliable' in this manner a POV in itself? After all, NPOV does not mean adhering to the POV of well-respected organisations. Kayau Voting IS evil 11:05, 9 January 2011 (UTC)
Good point. I can forsee an epic edit war about the inclusion or exclusion of Fox News alone... -- RoninBK T C 05:01, 11 January 2011 (UTC)
I have begun a user essay to list some of the sources that may not be reliable, see User:Fences and windows/Unreliable sources. Fences&Windows 01:00, 11 January 2011 (UTC)
Information needs more than just a reliable source to be considered reliable, and should be handled on a case-by-case basis. Including MSNBC next to Fox News would at least remove the appearance of partisanship. Saying that Fox news isn't mainstream though, and not including MSNBC is just neglectful. The Chinese and Russian news sources should be trusted for a variety of facts, not necessarily on opinions of national matters or for accurate estimates, but they can be trusted for a variety of non self-serving material. A basic reference list for what a source is and who publishes would be better than a list of who is partisan and therefore can't be trusted which will only waste time by generating long, non-consensus gaining discussions. --AerobicFox (talk) 00:39, 15 January 2011 (UTC)
Generally, it's not so much a matter of saying a source is outright unreliable as indicating what biases to look out for, though of course there are exceptions. Yes, there are extreme cases - satire venues that play at looking legitimate, such as the Onion or fiction in the shape of a tabloid, such as Weekly World News - but (for example) Al-Ahram is a perfectly good source on the official views of the Egyptian government, though not on those of the opposition. Also, for example, in the U.S. both The Nation and National Review are near their respective ends of the political spectrum, but both try to be rather scrupulous with the facts. On the other hand, the publications put out by the followers of Lyndon LaRouche are minefields: independent of the opinions expressed, they are liable to be 90% factual, with a few outright, often borderline libelous, fabrications thrown in, which makes them useless as a source. - Jmabel | Talk 17:45, 15 January 2011 (UTC)

Can we strip the Grove's Dictionary of Music and Musicians (1909, UK) for articles?

I was looking for some info on some obscure music topics, and found a good full article in Grove's Dictionary of Music and Musicians on GoogleBooks. The thought occurred to me: it's a 1909 UK publication, much of the material is technical enough that being dated or having old-school tone isn't a huge problem. Is there some way, similar to with the 1911 Britannica, that we can just strip entire articles wholesale, slap up a {{Groves1909}} template, and call it good? Further, since it has good OCR with limited typos, is there any way we can automate such rather than start a new article and cut-paste for each individual topic? MatthewVanitas (talk) 03:09, 12 January 2011 (UTC)

Not to rain on your parade, but why not write your own text and just cite the source? Most of the text dumbs from Britannica 1911 and other PD works date from the VERY early days of Wikipedia to give the encyclopedia some content. This isn't much of a problem anymore, so I don't see the pressing need to wholesale copy text from other sources, even IF they are PD... --Jayron32 03:11, 12 January 2011 (UTC)
I don't know what your topic is, but using the 1909 Grove can be very risky -- musicology and music theory have come a long way since then, and it's easy to incorporate errors that were corrected half a century ago. I strongly suggest finding a more recent source, for example the equivalent article in the current New Grove, and writing about it in your own words. For example, in the early days of my involvement here, 2004-2005, I spent a lot of time correcting some outrageous musicological errors imported from the hundred-year-old Catholic Encyclopedia and 1911 Encyclopedia Britannica, and often wished we'd never imported those articles. You can still find traces of them, or maybe even wholesale dumps in out-of-the-way places. Antandrus (talk) 03:16, 12 January 2011 (UTC)
Hmmm, my primary interest would be to cover topics that are no longer covered in modern published sources. That is, things still of long-term notability, but "obsolete" enough to not be prioritised in modern printed sources. As an example, I recently did the article stock-and-horn for an extinct Scottish peasant musical instrument. I could also see covering musicians and groups (opera companies, etc) of interest in the period. I'll look to comb through the OCR of 1909 Groves and see if I can wholesale pluck a few articles that are specific enough that they are unlikely to have become obsolete over time. Is there any way to get a tag such as {{Groves1909}}, similar to the 1911 tag? I'll still be footnoting it as per usual, but a more visual representation of "pretty much came straight from an old book" might be helpful. MatthewVanitas (talk) 22:52, 12 January 2011 (UTC)
I'd suggest looking if the dictionary is already available somewhere online already (The Internet Archive perhaps?), not copying from it but writing your own articles (those could be much shorter), and link or reference the dictionary in the Further Reading section. —Ruud 23:03, 12 January 2011 (UTC)
If it is not available online yet (and really in the public domain), I would suggest doing this on Wikisource instead of on Wikipedia. —Ruud 23:06, 12 January 2011 (UTC)

The 1900 version is up on WikiSource, I might just stick to using that: http://en.wikisource.org/wiki/Grove%27s_Dict._of_Music . Is there some way to find out if the 1909 is kosher too? Also, I'm thinking I might try to make this a little more refined than simple copy-paste, at least some trimming, and then all the wikilinking and whatnot. So still think it'd be better on WP vs. WS. I did also note there's a general "taken from a work out of copyright" template with a crossed-out-© logo at the bottom, so I can use that instead of making a new Grove's template. MatthewVanitas (talk) 23:25, 12 January 2011 (UTC)

Don't just strip it: improve it. Something written that long ago will need substantive and stylistic updating in a major way. Tony (talk) 00:53, 16 January 2011 (UTC)

Proposal : Deprecate specifc CSD for older images, and amend others

Fairly simple proposal, given that AFAIK the number of images without a license is shrinking.

Proposal is to amend the CSD criteria so that a CSD for no-license or no-source cannot be applied to an image uploaded prior to January 1st 2011. This means that images without a license or source posted before this date would have to go via PUF or FFD to ensure an 'appropriate' discussion took place. Images may of course still get deleted, but at least there would be a documented disscussion (and possible attempt to find sourcing/correct license)

Further to this, it would be appreciated if F2 and F8 which relate to images on Commons were reworked.

F2 is currently used for both 'blank'/missing or damaged images AND for images that are Commons ones with local details, These are different issues, and thus should be on different tags.. The issue of local details should be F8(b) whereas the current F8 should F8(a). Tools like TWINKLE should also be updated to make the distinction.

Sfan00 IMG (talk) 16:09, 13 January 2011 (UTC)

Oppose I'm not sure why such images would get a free pass; what happened to Wikipedia policy on January 1, 2011 that changed how such images are treated by policy? --Jayron32 18:19, 13 January 2011 (UTC)

Oppose CSD: It can be a good idea to take old files to PUF or FfD instead of tagging them with a CSD. But I see no reason why we should make it a rule always to do so. No matter what gets tagged admins should always check files before they delete them so if a file is tagged by a mistake an admin will fix the problem.

F2/F8: F2 is used for deleting file pages where there is no image on enwiki. I see no reason to change that. --MGA73 (talk) 18:41, 13 January 2011 (UTC)

Oppose per Jayron32. The existing framework has worked well for getting reducing the number of no-source/no-license images. I don't see why we suddenly need to start having a discussion for each of them that nobody had happened to notice before this month. DMacks (talk) 21:03, 13 January 2011 (UTC)

Weak Support One possible reason for doing something like this is for older images where the original uploader may no longer be active, and the file itself may not be being watched. Taking the file to IFD rather than speedying it may give more chance for problems with the file to be resolved rather than the file because more people will be aware of the problem. I would think, however, that the proposed cut-off date is too recent - maybe something like a couple of years.Nigel Ish (talk) 20:11, 15 January 2011 (UTC)

Special logo for the tenth anniversary

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
Result: Implemented. -- Cobi(t|c|b) 00:00, 15 January 2011 (UTC)

I realize that this is short notice, but I propose that we use this site logo from 00:00 UTC until the tenth anniversary ends in all time zones. Opinions? —David Levy 22:45, 14 January 2011 (UTC)

If there are no licensing constraints, I support it. Titoxd(?!? - cool stuff) 22:46, 14 January 2011 (UTC)
Pretty much of the same opinion as Titoxd. --Dorsal Axe 22:48, 14 January 2011 (UTC)
Go for it :D [stwalkerster|talk] 22:53, 14 January 2011 (UTC)

Note: The puzzle piece and numerals are from the Wikimedia Foundation's official Wikipedia tenth anniversary artwork. The word "years" is rendered in a free typeface. —David Levy 22:55, 14 January 2011 (UTC)

I see no problem with it, but ultimately this had better move quick if you want it up in time. -Marcusmax(speak) 22:58, 14 January 2011 (UTC)
I agree with this move. User:Zscout370 (Return Fire) 22:58, 14 January 2011 (UTC)

I'd suggest we try to knock up something based more closely around the globe, a-la File:Wikipedia-logo-vi balloons.png, but I definitely support doing something to celebrate. Enwiki has an awfully stiff upper lip about giving undue prominence to any culture-specific event, but I think we can all agree that this anniversary is exactly as global as the project itself. Shame that it's been the 15th for half a day in Fiji already... Happy‑melon 23:00, 14 January 2011 (UTC)

As noted above, the black "10" puzzle piece is the Wikimedia Foundation's official Wikipedia tenth anniversary logo. I simply tweaked it to include the word "years." —David Levy 23:06, 14 January 2011 (UTC)
how about this?
Mumble mumble meh. It just seems a bit more Google-esque to keep the globe and add 'bells and whistles' to it, rather than changing it altogether. But I definitely support doing something. Happy‑melon 23:14, 14 January 2011 (UTC)
Your suggested graphic is nice, but it has the wrong dimensions and doesn't indicate the celebration's nature. I also think that we should use the official artwork. —David Levy 23:18, 14 January 2011 (UTC)
It's also using the old globe... :( It's the same height but stretched so that there's space for the balloons without pushing the globe off-centre (the image is centred in the sidebar, don't want it to be out of line). Incidentally, <folorn hope> can we please use this for St Patrick's day? </folorn hope> Happy‑melon 23:23, 14 January 2011 (UTC)
Isn't the width more important? —David Levy 23:32, 14 January 2011 (UTC)
  • Can't stay logged in at the moment, but this is BarkingFish - you can CU me if you need proof :) I personally don't support the idea, to me the puzzle piece says we're completing the ball, as it were. The logo with the missing pieces says we're not finished, this to me looks wrong. Sorry. I guess if the rest of you want it, go ahead. Just my opinion. BarkingFish 23:40, 14 January 2011 (UTC)

How about using the original Wikipedia logo (the one after the american flag)? --Church of emacs (Talk) 23:17, 14 January 2011 (UTC)

That would be cool for those of us who recognize it, but most people wouldn't understand the reference. —David Levy 23:20, 14 January 2011 (UTC)
  • Whatever we decide to do (I personally prefer David's 10 jigsaw piece, since it makes sense what we are celebrating, and the original logo is sort of obscure), sysadmins have changed the site's configuration so that we can upload over File:Wiki.png and locally override the logo. Titoxd(?!? - cool stuff)
    • (ec) The new puzzle piece logo I think is more suitable - it's more descriptive of the event. IMHO, it's not saying we're finishing the puzzle either, as it's a single piece, and there are clearly more missing. If anything, it's showing we're adding another piece to the puzzle. It's suitable for the event, more so than the balloons logo. The original logo I think will just confuse people even more. [stwalkerster|talk] 23:33, 14 January 2011 (UTC)
  • I like the image posted here, if we can use it. - Denimadept (talk) 23:29, 14 January 2011 (UTC)
So what's the word on this logo? There's only ten minutes to go. Is the logo going ahead? --Dorsal Axe 23:50, 14 January 2011 (UTC)
Looks like it. \O/ Happy‑melon 23:52, 14 January 2011 (UTC)
 Done -- Cobi(t|c|b) 00:00, 15 January 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Lol, look at the file history of File:Wiki.png... :D Happy‑melon 00:02, 15 January 2011 (UTC)

I lol'd Titoxd(?!? - cool stuff) 00:04, 15 January 2011 (UTC)
Yeah I noticed that too. I also lol'd. --Dorsal Axe 00:06, 15 January 2011 (UTC)
I'm a bit late to the discussion, but I noticed the 10 Years logo and came here to say "Great Idea!" and very well implemented. Thank you all. First Light (talk) 17:54, 15 January 2011 (UTC)

How to get rid of the new logo, should you wish to

Thanks to Guandalug and myself on freenode, you can get rid of the new logo (guandalug) and have a "normal" one for the day, and also ditch the orange banner on the front page (me). Simply add this line: 

#p-logo a { background-image: url("http://upload.wikimedia.org/wikipedia/commons/7/7f/Wikipedia-logo-en.png") !important; }

to your .css file for your skin (monobook.css, vector.css, whatever) and do a deep reload (see the instructions there).

To remove the orange jigsaw banner thingy, add this to your .css file: 

#mp-banner { display: none; }

save the content, deep reload, and enjoy.

Not everyone likes the new choice, and people should be given an opportunity to know how to remove it.

BarkingFish 12:25, 15 January 2011 (UTC)

Giant banner

I understand the giant banner during the fund raising drive, but it's over, do we really need it to advertise wikiquote or the 10th anniversary? My specific objections are:

  1. It's gigantic and in the way
  2. My P4 1.8 hangs for a second while doing the ajax magic. On every page it's very annoying

My proposed solution:

  • Main page only

Before someone suggests it, no I don't want to create an account, hack it out of my personal monobook, and login every time I visit the site. --72.144.177.129 (talk) 02:11, 12 January 2011 (UTC)

Seconded Shabidoo | Talk 01:03, 12 January 2011 (UTC)
@72.144.177.129: So basically, even though there is an easy fix, you refuse to do so just to stand on "principle". Good luck with that. --Jayron32 03:13, 12 January 2011 (UTC)
↑ This. If you don't want to see banners, a login is a simple solution. Choosing to not have a login means you can't remove items like this. — The Hand That Feeds You:Bite 15:55, 12 January 2011 (UTC)
Jayron that's not exactly an easy fix. Sure, it's doable, but presumably other readers will have the same problem as the OP, and we can't expect them all to register accounts and change their settings, just to get rid of the banner. There are arguments for the banner, but the effect on readers with slow loadtimes and small screens deserves consideration.--Physics is all gnomes (talk) 17:50, 13 January 2011 (UTC)
Thanks Physics. Even if I did go the register route, I would have to login on all the different devices I use every time I visit the site. It's very annoying. A text only banner would be better, or main page only, but regardless it seems the giant java script powered banner is here forever. --65.3.255.75 (talk) 12:30, 15 January 2011 (UTC)
Bothers me, too; started a section in the miscellaneous VP (since we don't have a central [real] village pump anymore). ¦ Reisio (talk) 01:46, 14 January 2011 (UTC)
I'd like the giant banners gone too, from every page and they should not come back for any reason less than the end of the world. - Denimadept (talk) 22:56, 15 January 2011 (UTC)

I agree with 72.144.177.129 - the banner is annoying and slow on old computers. Main page only would be the best solution --Nat682 (talk) 06:21, 14 January 2011 (UTC)

I just wanted to add that as of this morning, more than 50% of the main page is banners and ads and toolbars. giant banners main. Content pages luckily only have the giant coloured banner. I have a P4 1.8 GHz Toshiba with a 15" 4:3 LCD. Do I need to get the "gigant-tech billion trillion pixel 500 inch rockin awesome HD charged plasma time traveling super screen" to view wikipedia now?? :( --65.3.255.75 (talk) 12:38, 15 January 2011 (UTC)

You can click the [x] button to dismiss the banner. --Dorsal Axe 13:18, 15 January 2011 (UTC)
It keeps coming back. --72.153.214.200 (talk) 21:55, 15 January 2011 (UTC)
It stays away for me, when I'm not logged in. When I delete cookies, then it comes back. Are you not allowing cookies, perhaps? First Light (talk) 22:53, 15 January 2011 (UTC)
Maybe noscript or ABP or TACO are preventing it. I'm not a fan of cookies and only allow for my webmail to work. --72.153.214.200 (talk) 00:01, 16 January 2011 (UTC)
No Cookies=Banner    Cookies=No Banner   It looks like you'll have to choose your lesser poison. First Light (talk) 00:14, 16 January 2011 (UTC)
Or wikipedia could stop spamming people with a gigantic AJAX banner.... I know, it's crazy, but it just might work! --72.153.214.200 (talk) 00:27, 17 January 2011 (UTC)
Or, you could make an exception to your filter. The world doesn't revolve around your needs. — The Hand That Feeds You:Bite 16:07, 17 January 2011 (UTC)
Apparently it revolves around the need for Jimmy to plaster his face all over the 4th busiest site on the internet. I never expected this to go anywhere, WP is far too mired in it's hateful bureaucracy to ever respond to the needs of it's individual citizens. You're right, of course, "HandThatFeeds", I should just suck it up and like it. --72.153.214.200 (talk) 12:40, 18 January 2011 (UTC)
Never said you had to like it. But, yeah, several options were offered and you rejected all of them. So "suck it up" would be the best response. — The Hand That Feeds You:Bite 18:30, 19 January 2011 (UTC)
Actually, it revolves around the need for the 4th busiest site on the internet to continue to exist... -- RoninBK T C 18:34, 19 January 2011 (UTC)

On the overly anthropocentric focus of some anatomical articles

I've been looking over various articles on anatomy, and noticed that there are quite a few inconsistencies amongst them. For instance, the articles Nose, Eye, Penis, Bone, Teeth, Jaw, and to some degree Brain and Heart, all have a rather general, non-anthropocentric view on the subjects they are explaining. However, other articles, like Mouth, Intestine, Foot, just about every single article related to the female reproductive system (vagina and clitoris to mention a couple), and to some extent Hair, Ear and Tongue, in my opinion, do not.

My proposal is that we (continue to) move everything specific to any single species to its own page (specified with the species' name in parenthesis), unless it consists of only a few lines of text, as to achieve a more neutral representation of each subject. This has already been done for nearly all of the articles I mentioned at the start of this post (see Human nose, Horse teeth and Human eye for examples on this), but there are still a number of glaring exceptions.

(I wrote a few replies earlier to posts pertaining to the issue on this discussion page and this one as well, but I thought it would probably be more appropriate to bring it up here... sitting around waiting for someone to reply to those could take a while, after all.) Omnomymous (talk) 22:36, 12 January 2011 (UTC)

Ah ha. I have also noticed this and would love it to be addressed, I've bought it up at the countering systematic bias wikiproject and at biology wikiproject, but people weren't tremendously interested. I obviously completely agree, but I think one problem we face is that relatively few sources address these topics from a non-human perspective which can make it difficult to create articles that give an overview. I guess it's really a case of WP:SOFIXIT if you can, I for one would support any changes like these. SmartSE (talk) 13:22, 15 January 2011 (UTC)
Interesting to see that this issue has been presented several times before, albeit met with such mixed opinions. I suppose you're right about the sources detailing non-human anatomy being somewhat sparse(r), which, if we move mostly everything specific to humans into their own articles, could result in leaving some of the main articles rather desolate (obviously not something we want). Also, since I'm neither a biologist/doctor/veterinarian/etc. nor having English as my first language, writing articles on highly technical matters such as anatomy can prove to be both quite challenging and time-consuming, but I'll probably give it a go anyway. I guess I'll just have to rely on people correcting my mistakes as they are spotted.
Oh, and many thanks for the welcome, by the way (didn't want to cause any clutter on your talk page) :) Omnomymous (talk) 20:27, 15 January 2011 (UTC)
My view is that Wikipedia should be anthropocentric. It is read, so far, exclusively by anthropoi. So basically I think your whole project is misguided. --Trovatore (talk) 20:34, 15 January 2011 (UTC)
So just because you're a human means you don't want to know about other organisms? A counter to your point, is that I know exactly what the human penis looks like and how it works, but there are a great variety of different penis forms, which our article barely touches on at the moment. Why deny a reader of finding out more about the anatomy of other animals, just because we're human? SmartSE (talk) 19:38, 16 January 2011 (UTC)
Absolutely, the anatomy of animals should be covered. I just think there's nothing at all wrong with a so-called "bias" to humans.
Specifically, I think that, say, kidney should treat the human kidney first and primarily. Kidneys in general should be perhaps a separate article. Not sure what the title should be. --Trovatore (talk) 20:11, 16 January 2011 (UTC)
  • Completely agree with OP - seen this problem a lot. Some anatomical articles deal exclusively with human anatomy, some throw in a mixture of human and comparative, some are primarily written in the general perspective with a little mention of human thrown in. It's that inconsistency that's the problem, not the anthropocentricity. The obvious solution would be to emphasise the distinction (e.g. as is done with Human brain vs Brain, Human heart vs Heart). TheGrappler (talk) 03:50, 16 January 2011 (UTC)
My own suggestions on how to improve on this matter can now be found here, if anyone's interested (probably not). Input is of course welcome. Omnomymous (talk) 02:29, 17 January 2011 (UTC)
Seems rather redundant to me. Most people will be coming here to read up on how their own body works, with how animals' variations work being secondary. In fact, if an animal's organ varies significantly, that should be covered in the article about the animal. — The Hand That Feeds You:Bite 18:33, 19 January 2011 (UTC)

Pending Changes on talk pages

How can we implement pending changes on talk pages? Mine is continually vandalized by a sock IP, so I don't want them removing stuff, but I do want legit IPs to be able to leave queries. I was directed here from Wikipedia:Village_pump_(technical)#Pending_Changes_on_talk_pages CTJF83 chat 00:15, 13 January 2011 (UTC)

That wouldn't help you. You would still see it, you would still need to revert it. The only difference pending changes would make is that IP users wouldn't see the comments if they visited your talk page (at least not by default). Amalthea 16:48, 13 January 2011 (UTC)
Well good, then the vandal IP/new user wouldn't see the removal of content. Is it possible to do, or no? CTJF83 chat 04:55, 14 January 2011 (UTC)
Erm, yes, an IP would see the removal. If anything, an IP would sometimes not see the vandalism, that's what it was designed for.
It's technically possible to put your talk page under PC protection, yes. But I wouldn't do it since it doesn't really help you. If your talk page is regularly vandalized by non-autoconfirmed accounts then I'd just go straight to semi-protection, I would think that with the history of your talk page it should never be a problem. Amalthea 13:12, 14 January 2011 (UTC)
IP would see the removal? I thought PC was designed to not show any edits to IPs/new users until confirmed by an experienced user. CTJF83 chat 21:40, 14 January 2011 (UTC)
Anonymous users are by default presented the last revision marked as reviewed. Revisions are marked as "reviewed" either a) manually by a WP:REVIEWER reviewing a pending revision or b) automatically if an (auto)confirmed user makes an edit based on a reviewed revision (like when he reverts).
Any anonymous user still has a link to show the most recent revision, which is also shown directly after he edits the page. Amalthea 12:43, 16 January 2011 (UTC)

Display thumbnail images of article editors on page

When editing an article you should have the option to include a thumbnail image of you from your profile in a section of each article e.g. 'People who have contributed to this article'. Clicking on the thumbnail will display the public parts of that user's profile and what other articles they have edited. The idea is to help give people a sense of reward and recognition if they want it as well as allowing users to more easily see who's behind the articles. — Preceding unsigned comment added by SquareRootofBlue (talk • contribs)

If you go to the history tab of any article, you will see the contributors, each with a link to their contributions. Adding images would simply be gaudy and akin to a messageboard, and imo, is not necessary. Resolute 23:29, 16 January 2011 (UTC)
No offense to anyone, but after meeting some of the people here at one of the tenth birthday meetups, I'm not sure I want to see photos of everybody. I know I'm definitely not a visual treat for the eyes. -- RoninBK T C 19:05, 17 January 2011 (UTC)

Too much added strain on the server to make up for added benefits, IMO. --AerobicFox (talk) 23:45, 18 January 2011 (UTC)

Most editors don't have a "thumbnail image of (them)" on Wikipedia, so this is a non-starter. — The Hand That Feeds You:Bite 18:40, 19 January 2011 (UTC)

Missing media bot

Just a random idea that I came across, It would not be that hard to write a bot that searches inter-language links for media/files that are free and being used on other languages, but our article is missing images, and then leave a talk page note about the possible inclusion of said media. Thoughts? ΔT The only constant 17:41, 19 January 2011 (UTC)

The only problem I can think of is that the articles may not have someone familiar with the other language. It would at least be a start, though, so I'd say it's a good idea. — The Hand That Feeds You:Bite 18:53, 19 January 2011 (UTC)

Cleanup template suggestion

I think we should have a cleanup template for all lists that begin with "This is a list..." or the like, since the list MOS disallows that. Check out a sample one at User:TenPoundHammer/Sandbox 2 and tell me what you think. Ten Pound Hammer, his otters and a clue-bat • (Otters want attention) 19:25, 19 January 2011 (UTC)

No, we shouldn't have a cleanup template whereby the number of keystrokes to enter the template exceeds the fix. If all you need to do is remove a single, 4-word phrase, from the lead of the article, then do it. If the problem is more pronounced than a few words, then there is {{Self-reference}}. See Wikipedia:Avoid_self-references#Think_about_print, which is a short paragraph because its pretty cut and dry. --Jayron32 19:44, 19 January 2011 (UTC)
Never mind then. I didn't know that template existed. Ten Pound Hammer, his otters and a clue-bat • (Otters want attention) 19:46, 19 January 2011 (UTC)

Developing the format for the future

The problem is that often users can be overwhelmed by the vast oceans of information now available on most topics. Experts in the various fields can apprecaite the amount of high quality information you can find, but casual users, younger users, or non-native speakers might find certain articles rather unapproachable. For example, I have a degree in physics, but I'm not always looking for the maximum amount of scientific data on each topic I look up. Sometimes I'd like to see a summary version. Also, we home school our daughter and would like to let her do some research on different topics, but most articles are a bit beyond the capabilities of an eight year old, but given how ubiquitous Internet use is even for users her age, I think this issue needs to be addressed for the future.

A short-term solution to this would be to have two versions of each article, basic and pro / expert. The basic article would be a general overview of various topics for the casual / younger user, the pro / expert article would include all information given on a topic. The basic article could be the default with a link to switch to expert, or users could choose to browse basic or expert when they first connect.

A longer-term possibility would be to label each entry section according to the level of education required to understand it and have the users create profiles listing their levels of education (primary, secondary, undergrad, grad) in various areas (ie. chemistry, physics, history, linguistics, etc) and then show them (or highlight) the sections that would most likely appeal to them specifically and either hide or minimize sections that contain information that would probably not concern them.

An interesting proposal; have you taken a look at the Simple English Wikipedia? Airplaneman ✈ 23:41, 18 January 2011 (UTC)
Theoretically, our existing WP:Summary style should make this a non-issue. In practice, we're a work-in-progress and thus some articles need help in this area. --Cybercobra (talk) 00:29, 21 January 2011 (UTC)

Wikipedia:WikiProject Animals/Draft capitalization guidelines

I request your feedback and/or modifications to this proposal. If you think that it has worth, I would like to post an RfC, notify relevant groups, then announce it at Wikipedia:WikiProject Manual of Style. Anna Frodesiak (talk) 15:33, 21 January 2011 (UTC)

Parliamentary editing

Like the Wikipedia:Congressional staffer edits, I've noticed many anon ip edits originating from the Houses of Parliament, in much the same vain. I've got two ip's here, but I'm sure there are many more.[1] [2] [3] [4]

Could we search for more? Gareth E Kegg (talk) 01:08, 22 January 2011 (UTC)

http://www.tomscott.com/wikiparliament/ Fences&Windows 01:46, 23 January 2011 (UTC)

Junior Eurovision Song Contest participants

Why are JESC participants not taken seriously? Most of them only have three categories: "(nationality) singers)", "Living people", and "(nationality) singer stubs". I mean, come one. I like Francesca & Mikaela's article, because it contains everything that it needs--"Maltese female singers", "Maltese pop singers", "Maltese singer-songwriters", "Living people", "Junior Eurovision Song Contest Participants", "Gozitan singers", and "Pop singers". All of those categories make sense. MickWithoutGlasses has made cleanup to Sonja Skoric's article. I like what he did to it. Can we do that with every JESC participant? — Preceding unsigned comment added by Floatingforever (talk • contribs)

So do it. You don't need to propose it here. Fences&Windows 22:29, 23 January 2011 (UTC)

request board for sources behind paywalls

Lots of great sources are behind paywalls. Would it be useful to have some sort of request board where editors can ask for a particular source (say a journal article or an obituary or something) and then someone with access to a university library can send it to them? Some universities even have a service where you can request that a librarian scan certain pages from books for you. I'm thinking that requests would have to be specific enough that they could be handled in a couple of minutes. Does this seem like a good idea? GabrielF (talk) 01:59, 24 January 2011 (UTC)

Wikipedia:WikiProject Resource Exchange ---— Gadget850 (Ed) talk 02:01, 24 January 2011 (UTC)
Awesome, thank you! GabrielF (talk) 02:59, 24 January 2011 (UTC)

Change to the main page - Wikipedia in the news feature

Can I suggest that the main page has a "Wikipedia in the news" feature? On January 14, 2011, Wikipedia was covered on the Radio Four news, and also on the PM programme that precedes it - it would be nice to think these features got prominent coverage in Wikipedia.ACEOREVIVED (talk) 21:43, 14 January 2011 (UTC)

I don't think Wikipedia is in the news often enough to justify such a section --Nat682 (talk) 01:08, 15 January 2011 (UTC)
I agree with Nat682. --vgmddg (look | talk | do) 01:22, 21 January 2011 (UTC)
Though it may be useful for the WikiPedia article. - ʄɭoʏɗiaɲ τ ¢ 17:06, 27 January 2011 (UTC)

Infobox picture parameters

Is there any way to standardise these? I've noticed that different infoboxes seem to have different requirements and unless you know the syntax from previous experience it's trial and error to get the right format. I've noticed the following :-

  • blah.jpg - the filename with no other information renders correctly in the infobox.
  • file:blah.jpg - as above but the file (or image) prefix is required.
  • [[file:blah.jpg]] with optional size parameters - as per inserting an image anywhere else.

There may be others.

Is there any reason why different infoboxes should use different syntax to add an image? Can we get a infobox policy to require a single format type so any infobox can have an image added without having to work out which permutation of syntax is required to get the image to display? Exxolon (talk) 17:35, 22 January 2011 (UTC)

AFAIK, every infobox should use the standard {{Infobox}} skeleton. Using that would standardize all these fields, I think. May I ask what infobox you are referring to? Rehman 02:51, 23 January 2011 (UTC)
Examples...
I cannot find an example of the second format immediately but I'm pretty sure some infoboxes use it. Exxolon (talk) 05:27, 23 January 2011 (UTC)
Yes, those were created rather differently, irespective whether they use {{Infobox}} or not. Standardising seems like a good idea. IMO, this has to discussed at Template talk:Infobox or WT:IBX. Rehman 07:35, 23 January 2011 (UTC)
Infoboxes should all be standard. And it's either now or never. If you're going to get them standardized (will be a massive cooperative job), you should compile a list of all the nonstandard things. That way, you can fix them in one sweep.
A semi related thought: We should have a way of inserting an infobox from the edit bar. It should allow you to type the links, images, etc in appropriate fields. Just the problem is, for that, we need a mass drive to create huge lists of parameters, accepted input, and comments on input in Javascript. I was thinking of writing this script myself, but then I just peeked at CAT:INFOBOX, got scared, and abandoned all hope. ManishEarthTalk • Stalk 16:12, 23 January 2011 (UTC)
I agree; whatever things that needs fixing, it's either now or never. I am ready to help if someone could create the list and a coordination page. Perhaps at WP:Infobox? We would also probably need to modify the WP:IBX. Inserting infoboxes from an edit bar seems too complex and confusing, as you mentioned. ;) Rehman 01:37, 24 January 2011 (UTC)
Just passing the image parameters through {{image}} at some point would allow all three syntaxes to be used interchangeably. Happy‑melon 16:30, 25 January 2011 (UTC)

Village Pump archival

Could each Village Pump discussion not be closed until they have had at least one response? Simply south...... 16:57, 24 January 2011 (UTC)

Hmm...this is your one response; go ahead and archive it. Mono (talk) 00:57, 25 January 2011 (UTC)
Feel free to go through the archives to find good but abandoned ideas and breathe new life into them. Fences&Windows 01:30, 25 January 2011 (UTC)
Arbitrary response rules aren't helpful and are easily subverted. Sometimes a topic just doesn't end up meriting any comment. --Cybercobra (talk) 04:43, 25 January 2011 (UTC)
Wow. I see the whole jaded response thing hasn't gotten any better since I left (to put it lightly). It's been pointed out before, but friendly reminder, those users who are too sick of responding to bad ideas to be nice or dare I say civil about it might feel rejuvenated after having stepped away from this page for a few weeks. Someone else is guaranteed to step in and fill the role in your absence. this comment is not directed at Cybercobra, btw Equazcion (talk) 07:41, 25 Jan 2011 (UTC)
So it was directed at me then? Charming. Perhaps you should follow your own advice. Fences&Windows 21:07, 25 January 2011 (UTC)
Not at you specifically, Fences, although I think your response above along with Mono's are both somewhat indicative of the kind of impatience I'm referring to. I'll gladly take my own advice, in terms of being welcoming to people who come here to make suggestions; I feel I do pretty well there, but if anyone thinks otherwise they can let me know. If you're saying my advice above somehow precludes one from pointing out behavioral problems they notice on this page, then I don't think you understood my meaning. Equazcion (talk) 23:12, 25 Jan 2011 (UTC)
I think this proposal would only encourage half-hearted responses and lead to mediocre, half-thought-out discussions. If an idea deserves responses, then just try again in a month or two and hope for meaningful responses. ...comments? ~BFizz 18:31, 28 January 2011 (UTC)

Support needed for Wikipedia QnA website to open

Moved here from WP:ANI by Skomorokh 18:12, 24 January 2011 (UTC)

Hi,

Wikipedia is a great system to organize a set of articles, and it has a large help system as well. But newcomers and mid-termers alike would have lots of similar questions about the system, specific guidelines, or techniques of writing articles.

StackExchange, a free Question and Answer network of websites would start a website dedicated to Wikipedia and Wiki questions if the community only supports the project by voting for it. This website would have a very unique set of features that cannot compare with the way Wikipedia handles questions, simply because it is different. In Wikipedia questions are added to pages, much like a forum. In StackExchange, questions are added to a database that is searchable where each question can be voted for by the community.

  • Database of questions, listings by vote, or by newest/oldest
  • User accounts with ranking system per user based on helpfulness
  • Answers are voted for by users, and best answers show on top
  • Tagging and searching for questions by tag (eg. 'syntax', 'images', 'audio')

I'm writing here to call for the support of Wikipedians around the world, simply for our own benefit. If we can vote for this site and visit it regularly to answer questions then Wikipedia could grow so much faster since newcomers would have an intelligent and easy-to-use platform for their questions and troubles.

  1. Please start on this proposal page.
  2. You'll need to login (link on the top)
  3. Then you have to click the "Follow" button (or "Commit", if available)
  4. When the site begins you will get a link to it on the same page.

Thank you!

Tom Jenkins (reply) 14:16, 24 January 2011 (UTC)

  1. We usually don't vote on stuff.
  2. There's something called Yahoo! Answers, where some Wikipedia users (including at least one banned user) try to answer WP-related questions. It usually doesn't work out that well.
  3. You can't eliminate stupid people. It's really not that hard to figure out something on Wikipedia (we have the help desk and the IRC help chat and the {{helpme}} tag for a reasons), so why take it completely offwiki and ask that people actually spend time on a whole other site to answer even more questions? There's little point in running two help desks at once.
  4. I checked out the proposal site. "My MediaWiki based site is getting hit by spam. What should I do to deal with it?" has nothing to do with Wikipedia (and the answer would probably be to install an anti-spam extension and change the usergrouprights/registration process). Yet this is marked as "great on-topic example". Similarly, "What is a wiki champion? What do they do? Do you need one?" seems like nonsense to me, and "As a website administrator, what steps are to be taken, to stop misusing public wikis?" is another example of a "great example" that is actually irrelevant to Wikipedia.
In short, I just don't think it's worth the effort. /ƒETCHCOMMS/ 22:26, 24 January 2011 (UTC)
Hi Fetchcomms,
You see the proposal was originally intended for public wikis, but has grown in scope to include Wikipedia as well. Any Wikipedia related questions would be accepted. And there are some good ones in the list if you care to see.
StackExchange does work out well with users, and believe me it would make your job of helpdesk much easier. You could even link duplicate questions up and merge their answers. Answers are rated by vote so the best answer appears on the top. See Cooking or Photography for an example.
Tom Jenkins (reply) 04:01, 25 January 2011 (UTC)
FWIW I agree Tom. The best online example is the most mature, StackOverflow which (like all the sites) has a meta version for discussing how stackoverflow runs, ensuring continuous improvement. The results are fast and accurate. Great users get reputation, and hence more rights (like, eventually, moderation privileges). It works really well. Perhaps, like Wikipedia, it is counterintuitive so you really need to "try before you buy [into the idea]". --Robinson weijman (talk) 07:46, 25 January 2011 (UTC)
Let me just say that taking help offwiki is not a good idea. We can't control who answers questions and we can't control the quality of the answers. We see this issue on the IRC help channel, too—you have new users trying to help but they end up misleading people all over the place. There's nothing wrong with people asking questions elsewhere, and you don't need community support for it, but it's just not the best way to help people in the end. /ƒETCHCOMMS/ 15:54, 25 January 2011 (UTC)
What's wrong with the WP:Help desk? I mean that literally— are there questions there that would be better asked off-wiki? And it has years of archives to look up previous answers. ---— Gadget850 (Ed) talk 16:14, 25 January 2011 (UTC)
I don't know if anything is wrong with a specific site (like WP:Help desk). However, many questions on talk pages (here and on MediaWiki) go unanswered for weeks or months - some are never answered. That rarely happens on the StackOverflow sites. Really, I encourage everyone to post e.g. a programming question on StackOverflow (or a cooking question or a computer user question or a photography question or... whatever (see full list at bottom of each link)) and see for yourself what the response rate is like. --Robinson weijman (talk) 21:24, 25 January 2011 (UTC)

There are good reasons why we don't want to move part of our activities elsewhere, and there is the ever-popular reason: Not invented here. This proposal is definitely not going to result in any action on the side of the Wikipedia community. At most it will lead to a small number of users going to that site. The idea that "Wikipedia could grow so much faster" because of a kind of external help desk seems incredibly naive to me.

Basically this is just advertising for a site that I first heard about a few days ago (after an editor mentioned MathOverflow, which links to StackOverflow because it uses their software). I propose closing this thread. Hans Adler 21:41, 25 January 2011 (UTC)

I think that this merits exposure, since it has the potential to improve Wikipedia (indirectly), and Wikipedians might be interested in it. But I would disagree to any proposal for "official" WP support of this, unless Stack Overflow Internet Services Inc. handed it over to the Wikimedia Foundation. ...comments? ~BFizz 18:27, 28 January 2011 (UTC)

User2User Conversation page

So I had an idea earlier tonight, and I am rather conflicted about whether I like it or not. Nonetheless, I wanted to give you guys something to chew on, if it hasn't been discussed before.

Sometimes, user talk pages can be a mess. There are different variations of how people like to deal with it. Some people can't commit enough time to Wikipedia, and just let them pile up without archiving. Some people insist that a conversation take place in only one spot, much like an article talk page. Some people will only put messages on each others talk pages with Subject title and Re:Subject Title. Some people even have nice templates to put on another users talk page to let them know they left a message for you on their talk page! It seems a bit inefficient, considering that the only goal of each user it to know what was said when.

Why not take one approach and keep it in one spot: one talk page per 2-user pair that have a conversation, with all messages presented chronologically with all text from recipients together with replies (similar to iChat and text messaging on iPhone). Believe me, I am not a Mac fan, but it makes it a lot easier to trace back through a conversation. It may be a big software challenge I imagine, and I can recognize it would destroy the culture around a lot of people's user talk pages and how we converse now.

Hence, why I just left it without a decision and dropped it here, in case it hasn't been suggested before. --Natural RX 07:40, 25 January 2011 (UTC)

keep a page for each user pair makes little sense, as prior history is often irrelevant to new discussions and discussions can often involve multiple parties. It is an interesting idea however to make a page for every discussion. Feel free to try it out: Just create a user talk subpage for each new discussion (for example User talk:Natural RX/example discussion) and then transclude this on the user page of both parties (with curly brackets: {{User talk:Natural RX/example discussion}}). I am pretty sure it will break archive bots though, but it would certainly make communicating with new users easier for both users have the full conversation on their own talkpage. Yoenit (talk) 09:09, 25 January 2011 (UTC)
Good idea, but if you want it integrated into the wikipedia framework, you should propose this idea on the MediaWiki website, the wiki engine that Wikipedia actually runs on. -- Tom Jenkins (reply) 09:28, 25 January 2011 (UTC)
This sounds much like the proposal for Mirror Bot. Personally, I find the whole plan overly complicated and prefer just watching the original page for replies, with a {{talkback}} if it's urgent or seems to have been missed. Anomie⚔ 14:03, 25 January 2011 (UTC)
Well, talkback's get tedious and sometimes unecessary. It's easier to maintain separate watchlists for conversations. Just use Special:RecentChangesLinked / (linkpage) , and on the linkpage keep links to all discussion pages. It shouldn't be too hard to write a script that allows you to maintain multiple watchlists easily, but I don't have much time right now, and I already have a few scripts pending. Anyone else taking up the challenge? ManishEarthTalk • Stalk 16:02, 25 January 2011 (UTC)
And this proposal is less tedious and sometimes unnecessary? ;) Anomie⚔ 16:59, 25 January 2011 (UTC)
It won't be tedious if it's a script... Just have some more "watch" buttons which add/remove pages via AJAX. ManishEarthTalk • Stalk 10:45, 26 January 2011 (UTC)
More interface clutter, and it's still tedious (even if by script) to have to create these pages and notify the other user. You could as easily have a script to just post the talkback. Anomie⚔ 17:21, 26 January 2011 (UTC)
I'm not saying to notify the other user. I'm saying that multiple watchlists can solve this problem. I have a talkback script already (no AJAX, tho). It adds a talkback tab to user and user_t pages, which, when clicked, preloads the tb template into the editpage. You just have to replace {{subst:currentuser}} with the talk page if the talkback is for a discussion page.
//Talkback link
if(wgCanonicalNamespace == "User_talk" || wgCanonicalNamespace == "User"){
 
var talkpage="User_talk:" + wgPageName.split(":")[1];
var link="http://en.wikipedia.org/w/index.php?title="+talkpage+"&action=edit&section=new&preloadtitle=Talkback&preload=User:Manishearth/Tb"
addPortletLink('p-cactions',link,'Talkback','ca-tb','Talkback', 't')
//document.getElementById('ca-tb').style.background='green'
}

ManishEarthTalk • Stalk 03:19, 27 January 2011 (UTC)

Actually, this problem would become obsolete once LiquidThreads is introduced to enwiki (I dunno when they'll release it from labs), as Special:Newmessages will bea centralised thread center. ManishEarthTalk • Stalk 01:20, 29 January 2011 (UTC)

A 'Follow' Button

Hello, I am Nivedit Mishra and I have a new idea. Why not there be a Follow button on the top of every user page so that people who like the user can follow him and become his followers and they will be notified of all activities of him/her. And, that user could also follow others. Please let me know if you agree with this idea.

Regards, Nivedit Mishra 04:30, 24 January 2011 (UTC)

There's already the ability to see their contributions... as someone's contributions are 100% what anyone can be concerned about on Wikipedia, the feature you request already exists. --Golbez (talk) 04:44, 24 January 2011 (UTC)
WP:NOTMYSPACE Wikipedia is social, but not a social network ManishEarthTalk • Stalk 06:21, 24 January 2011 (UTC)
Let's not encourage wikistalking. --Cybercobra (talk) 04:34, 25 January 2011 (UTC)
That might help people keep track of adoptees' and vandals' edits, but we already have RSS feed for that. Kayau Voting IS evil 04:24, 31 January 2011 (UTC)

Having multiple watchlists

Why not allow multiple watchlists? (e.g. Special:Watchlist2, Special:Watchlist3, etc.) to track different pages? --Perseus, Son of Zeus ✉ sign here 16:47, 24 January 2011 (UTC)

  • Whilst it would would be good to separate categories, templates, project pages etc, my biggest concern is that one already takes a long time to load and so having multiple would increase waiting time. Too much and too long time. Simply south......
Technical limitations I believe. It's been suggested before, and I think this is why it's never been done. --Dorsal Axe 16:55, 24 January 2011 (UTC)

Currently, all the watchlist data is stored together: every single user's watchlist is bundled together in one massive table, with your user id (a number unique to each user) as one key and the page id (another number unique to each page) as another. So when you go to your watchlist, the software goes to the table and finds all the rows which match your userid, and then goes and gets recentchanges for them; and conversely when someone edits a page the software gets all the rows which match the pageid, and does operations like sending email notifications if that's enabled. So having more than one watchlist per user would require not keying the data by userid, which would be a very substantial and complicated change. Happy‑melon 19:34, 24 January 2011 (UTC)

What about filtering after retrieving the list -a bit like the drop-down namespace menu already does- to add custom filters (e.g. by category)? --Cyclopiatalk 15:56, 25 January 2011 (UTC)
But what do you filter on? There is no more data in the watchlist table other than user, and page. Applying filters to the pages based on the nature of the pages is very straightforward, because that data is easily available. The point is that there is nowhere to put extra user data, to record that a user wants this item on their watchlist to appear in lists 1 and 3. Happy‑melon 16:14, 25 January 2011 (UTC)
I admit I don't know how the watchlist mechanism works, but from your description this just means to put a new column in the watchlist table, something that seems more technically feasible than changing the data key. --Cyclopiatalk 22:35, 25 January 2011 (UTC)
Except that it's an absolutely massive table...When you have something like Wikipedia, a *lot* of things simply doesn't scale well enough... T. Canens (talk) 06:21, 26 January 2011 (UTC)
Yes, about 31 million rows. Altering the structure of a table like that is enormously resource-intensive. Happy‑melon 13:39, 26 January 2011 (UTC)
This is the closest you can get to multiple watchlists I think, other than filtering my namespace (which is useful). Airplaneman ✈ 19:42, 24 January 2011 (UTC)
This came up recently. You can have another declared account for another watchlist. Or you can simply cut and paste a new watchlist into your existing account, storing your normal watchlist somewhere in the meantime. Fences&Windows 01:32, 25 January 2011 (UTC)

You can edit your watchlist as raw text. Why couldn't you edit another raw text file and run that through recent changes and have a drop down menu to switch between you various watchlist text files? - ʄɭoʏɗiaɲ τ ¢ 06:25, 26 January 2011 (UTC)

This seems to be a common request. See the script I suggested here. I'd love to make the script, but I'm not too free at the moment, ant I'll probably forget about it. Anyone who knows the basics of Wikipedia AJAX can do it. If anone wants, I can give guidance/ an outline of the script. ManishEarthTalk • Stalk 10:50, 26 January 2011 (UTC)
If anyone wants the UI code for creating a tabbed watchlist page with tabs like the prefs page, here it is (It does nothing about the watchlists, just makes it easier to organise.):
var prefStarted=false
var inter;
function startPref(page,title,heading,formID,handler){
	if(wgPageName==page&&document.getElementById("bodyContent")){
		document.getElementById("bodyContent").innerHTML="<FORM class=visualClear id="+formID+"><UL ID=preftoc></UL><DIV ID=preferences class=jsprefs></DIV></FORM><DIV class=visualClear>"
		document.getElementById("firstHeading").innerHTML=heading
		document.title=title
		prefStarted=true;
		if(handler){
			handler()
		}
	}
}
var sections = 0
function addSection(buttonName,sectionText){
	if(!prefStarted){
		setTimeout("addSection('"+buttonName+"','"+sectionText+"')",1000)
		return;
	}
	document.getElementById('preftoc').innerHTML+="<LI ID='prefbutton-"+sections+"'><A HREF='#prefsection-"+sections+"' onclick='openSection("+sections+")'>"+buttonName+"</A></LI>"
	document.getElementById('preferences').innerHTML+="<fieldset id='prefsection-"+sections+"' class=prefsection>"+sectionText+"</fieldset>"
 
 
	sections++
	openSection(0)
 
 
 
}
 
function openSection(section){
	if(!prefStarted){return}
	for(i=0;i<sections;i++){
		document.getElementById("prefbutton-"+i).className=""
		document.getElementById("prefsection-"+i).style.display="none"
	}
	document.getElementById("prefbutton-"+section).className="selected"
	document.getElementById("prefsection-"+section).style.display=""
}

//Example
startPref("Special:MultiWatch","My Multiwatch","MultiWatch","MyFormName",myHandler)
//Makes pref page at special:Multiwatch (By overwriting the "Special page does not exist"), with a window title My multiwatch, and a header Multiwatch, form name MyFormName
//When the page is loaded, myHandler() will be called to fill in the page
function myHandler(){
	addSection("Main","blah blah content blah"); //creates a section with title "main", and content as blah blah etc
	addSection("Threads", "blah blah more content");
	addSection("Boom", "blah blah and predictably blah");
	// etc etc
	openSection("Main"); //Focuses on the section
	//If you want to access a section via document.getElementById(), the id is prefsection-(index), where index is 0,1,2,3..., in the order that the sections were created (in this example, Main has an index 0, and Threads has an index 1)
}

I might come back with more codes if I feel like it. ManishEarthTalk • Stalk 12:05, 26 January 2011 (UTC)

NOTE: THis proposal will become obsolete once LiquidThreads is enabled. I don't know when, but it should be soon. ManishEarthTalk • Stalk 15:58, 30 January 2011 (UTC)

"Like" or "dislike"" button

Agreed. What has probably already been discussed, would be a feature like Facebook has, where one can click a "like" or "dislike" button. That would provide editors with feedback. I often wish we had that feature. -- Brangifer (talk) 17:15, 28 January 2011 (UTC)
A "like" button for edits actually sounds like a really good idea to me; a trust metric system might not hurt either. Also, some form of simple survey for a given page revision, for example, the "what do you think of this page" survey used at http://en.wikinews.org — has that been discussed before for WP? ...comments? ~BFizz 18:11, 28 January 2011 (UTC)
Wikipedia is not facebook, and things that are useful at one site are not so useful at the other. "I like it" s a highly informal feature, and suits very well a site that is precisely meant for informal activities, such as sharing vacation photos or making groups such as "Bender rules!" or "Join the robot anti-human army". Here in wikipedia, it won't work, and we already have better ways to provide feedback MBelgrano (talk) 18:24, 28 January 2011 (UTC)
You certainly have a right to disagree, but that doesn't negate the ideas of others. You feel no need. Fine, no one would force you to use it. Others feel a need. Respect them rather than diss them. It can be a quick and useful informal tool for an editor to gauge if they're heading in the right direction. Note "informal". It should never replace other, more formal and usually time consuming methods which often occur after an editor has gone too far down the wrong path. This idea can have a preventive effect. -- Brangifer (talk) 18:57, 28 January 2011 (UTC)
No, it won't work. Ratings work for comments, but not for pagehistories as we use them. Nobody is gonna read every edit in a page history and rate them like they do comments on youtube videos. If there is a problem with a particular edit you talk to or warn the editor in question, if you think a edit is especially good you hand out a barnstar. The argument "if you don't like it, don't use it" is total bullshit as this is a change which would effect every wikipedia editor. Yoenit (talk) 19:35, 28 January 2011 (UTC)

Well, I don't really see a need (not from my POV, from the POV of the whole Wikipedia) for a like/dislike button. Any feedback can be put on talk pages and in the form of barnstars. If an editor makes a mistake, notify him. He'll not think the worse of you. If you think an editor did a good job, hand out a barnstar. Like MBelgrano said, f we had a like/dislike button, it would infact do the opposite of what you want it to do. Editors might not check their likes/dislikes , and even if they do, they won't take it too seriously. Barnstars/messages are forthright and hard to ignore. Another thing, MBelgrano is not 'diss'ing you. It's just another example of the forthright attitude most users hold at Wikipedia.ManishEarthTalk • Stalk 01:34, 29 January 2011 (UTC)


Voting is powerful; however, there are concerns about voting Wikipedia:Polling is not a substitute for discussion. Zulu Papa 5 * (talk) 02:12, 29 January 2011 (UTC)

There's another difference between Wikipedia and Facebook. Here in Wikipeda, there's the need to set apart the articles from their subjects, but things in Facebook are simpler, it's just the subject. Consider that I expand some portion of the Adolf Hitler article, giving more detail about some overlooked topic of his administration, carefully keeping a neutral point of view and citing some good history book as reference. More than one would vote "dislike", not because of the edit itself, but because of the "ugh, Hitler" factor MBelgrano (talk) 02:20, 29 January 2011 (UTC)

The issues we deal with here are much more complicated than "Like"/"Don't like", so this type of "information" is useless. We've already got talk pages where we can have detailed discussions about specific issues. So why would we need a feature that allows us to make superficial critiques in addition to serious ones? -- Mesoderm (talk) 02:30, 29 January 2011 (UTC)

Agreed. While I think a more systematic method for feedback than a talk page post would be good, something this simple wouldn't help editors at all. Worse, it could be actively confusing, with people trying to guess why their edits were "disliked." Mr.Z-man 02:38, 29 January 2011 (UTC)

Wikipedia already has policies against exactly this sort of thing. For example, look at Wikipedia:Arguments to avoid in deletion discussions#Personal point of view. Our personal opinions are the least important reasons for contributing to any content here. HiLo48 (talk) 02:43, 29 January 2011 (UTC)

Although I also oppose the proposal, you shouldn't reject it simply as "it's against policy", try to elaborate it a little more. And notice that "Arguments to avoid in deletion discussions" is not policy, but an essay. Personal points of view are discouraged and likely to be dismissed, but not forbidden MBelgrano (talk) 03:00, 29 January 2011 (UTC)

A note on the talk page saying "nice edit there" is probably more effective, and doesn't require fancy software changes :) -Fennec 04:02, 29 January 2011 (UTC)

There is a pilot for article feedback; see mw:Article_feedback and mw:Article_feedback/Public_Policy_Pilot/FAQs. ---— Gadget850 (Ed) talk 12:48, 30 January 2011 (UTC)

Your feedback, suggestion

I have seen that one of the articles that I created the Cheshire, Connecticut, home invasion murders has an Your Feedback section in the bottom of the article. I find that really useful as people can grade the article on a number of important subjects sutch as readability etc etc.. My suggestion is that we have sutch a Your Feedback section on All articles on Wikipedia, I believe that it would be really useful for editors to see what is needed to be done and see the grade changes. It would be really helpful and in the best interest of upgrading the overall article standards on Wikipedia. It makes unclear thing very clear.--BabbaQ (talk) 12:56, 29 January 2011 (UTC)

The feedback feature is a pilot program, part of Wikimedia's Public Policy Initiative. Currently, its been put on a few pages as a test. They'll expand as time passes. More info at mw:Article_feedback, mw:Article_feedback/Public_Policy_Pilot/FAQs. If you want to see all of the articles with feedback enabled, see Category:Article_Feedback_Pilot ManishEarthTalk • Stalk 15:19, 29 January 2011 (UTC)
OK, well it would be really good if this feature was to be put on every single article in the future.--BabbaQ (talk) 15:33, 29 January 2011 (UTC)
I believe the long-term goal is to indeed rollout a feedback feature on every single article. For now, they're just trying to determine what the most effective design and implementation is. --Dorsal Axe 20:42, 29 January 2011 (UTC)
I hope they are also monitoring whether this is actually a good idea. I'm still concerned that this could prompt readers to complain about articles instead of improving them. ϢereSpielChequers 21:51, 30 January 2011 (UTC)

Integrate stats.grok.se into "Page" menu

Resolved
 – Feature already available on article History page. Mesoderm (talk) 18:05, 30 January 2011 (UTC)

It would be very useful to have the "Page" menu (in Vector skin) have an option "Traffic stats" that looks at the current month's traffic for that article on stats.grok.se. Where would be the best place for me to suggest this change? Thanks, Mesoderm (talk) 06:25, 30 January 2011 (UTC)

This has been suggested quite frequently IMO. If this is ever going to be implemented, it has to be global (standardized on all wikis). Hence, depending on the outcome of this discussion, you may want to propose this at Meta. Rehman 07:30, 30 January 2011 (UTC)
OK, thanks. I will do that now. Mesoderm (talk) 07:52, 30 January 2011 (UTC)

This is already linked from History → Page view statistics. ---— Gadget850 (Ed) talk 12:44, 30 January 2011 (UTC)

Oops, sorry about that! I never noticed it before. Thanks :) Mesoderm (talk) 18:04, 30 January 2011 (UTC)

Contents pages navigation proposal

A proposal to add topical links to all of the contents pages has been made. As part of that proposal, the navigation bar at the top of these contents pages would look like this.


All who read this invitation, please respond to the proposal, Portal talk:Contents#Adding topical links to contents pages navigational headers and footers, as you see fit. Regards, RichardF (talk) 15:40, 30 January 2011 (UTC)

Expanding Wikipedia

The following was obviously first sent as an email to Jimmy Wales. Please excuse my ignorance of the procedured at Wikipedia.
Dear Jimmy Wales,
You have probably received many congratulatory letters and expressions of gratitude for founding Wikipedia but another one can't hurt. In particular I am grateful for the many scientific articles, especially in the area of quantum physics/chemistry that helped in preparing new courses.
Recently you made a statement about expanding Wikipedia and apparently you meant geographic expansion. May I suggest a different aspect of expansion, one that may deepen the impact of your splendid innovation.
Let me confine the discussion to something of which I have some knowledge,namely, quantum theory. Following the main article on quantum mechanics there is a long of links to other articles in what amounts to an "e-index". As a start towards the "deepening", one might have an e-Table of Contents so as to provide more structure; of course, the article itself has links to sub-areas but a compact list such as a table of contents is an aid to seeing the structure of a subject and,as such is a valuable learning tool. If prepared by by an expert(not the writer) it could indicate the need for articles in fields not yet covered.
In a broader view, one might consider the following:
Quantum theory, in its 110 years has completely changed the nature of physical theory and , via the laser and semiconductor devices revolutionized our technology( including the device on which this letter is being written and the means of delivering it.) Among its subfields(with some overlaps) are

  • Qunatum Field Theory and Elementary Perticle Physics
  • Atomic Theory
  • Quantum Chemistry and Molecular Physics
  • Quantum Optics
  • Theory of the Solid State
  • Many-body Theory
  • Quantum Computing
  • Quantum Information
  • Quantum Control
  • Quantum Transport
  • Nuclear Physics
  • Quantum Gravity ( at least the attempts)

The subject calls for an encyclopedia of its own; Wikipedia could serve as the agent of implementation. Such a work would combine the ease of use of Wikipedia in a more formal framework. You no doubt have a good grasp of how this might be done, should you wish to do so. The advantages of an on-line encyclopedia , with its links and its ease of updating, might encourage scientific and academic institutions to help support Wikipedia by increasing its recognition as a learning and a research tool.
Let me again thank you and also wish you and your enterprise good luck.
Sincerely,
Bernard Rosen — Preceding unsigned comment added by 70.21.193.244 (talk • contribs)

[5] Really? Gareth E Kegg (talk) 22:52, 30 January 2011 (UTC)
I love this idea. --Anthonyhcole (talk) 00:33, 31 January 2011 (UTC)
Sounds a bit like what the WP:Outlines project is doing. See Outline of quantum theory. -- Ϫ 01:33, 31 January 2011 (UTC)

Turn on OpenStreetMap gadget to all users

Wikipedia is free project as “free speech”, not as “free beer”. And Wikipedia must use and help others free projects. OpenStreetMap is very useful project for Wikipedia, best source of map data. I suggest to install (how?) in English Wikipedia OSM gadget (what is this?), which already turn on in German, French, Norwegian and Russian Wikipedias. If you agree, vote "Yes". --TarzanASG (talk) 06:05, 30 January 2011 (UTC)

This would be a replacement for the currently used m:WikiMiniAtlas system? --Yair rand (talk) 04:52, 31 January 2011 (UTC)
I don't know. Maybe. According to community decision. --TarzanASG (talk) 01:23, 1 February 2011 (UTC)

Also, your first sentence is mistaken. Wikipedia is free in the sense of free beer, not free speech, as the website is run by a private organization, and is therefore not bound by the US constitution. RadManCF ☢ open frequency 00:26, 1 February 2011 (UTC)

(No, it actually is in the sense of free speech, but that's not really relevant here.) --Yair rand (talk) 00:38, 1 February 2011 (UTC)

Watchlist collaboration notice

A year ago there was a debate (Wikipedia:Village pump (proposals)/Archive 54#Main page feature suggestion) about doing a collaboration item on the main page. This got quite a lot of support but ultimately there was too much objection to get it off the ground.

There has been an abundance of regular collaborations like COTW, ACID, and most WikiProjects, but they continually die out because they require editors to seek them out. A project like this requires opt-out canvassing of some type to be functional. A recent example of this type of collaborative canvassing was for MediaWiki talk:Watchlist-details#Notice to help reference BLPs, and it was extremely successful. Check out the graph on that discussion and see how dramatic a difference it made. It attracted editors who were not necessarily following the village pump or other avenues. I think the BLP referencing drive proves this is a workable proposal.

I'd like to propose an item added to the watchlist with a link to a different vital article collaboration each week. This would be a simple, one-line item added to MediaWiki:Watchlist-details like:

This a new periodic collaboration project. Rather than hiding it in some obscure project page as we've done, we put a direct link to the article on every editor's watchlist every week. Any editor that's not interested can dismiss it forever and never see it again. If we can get even a dozen people to work on our most important articles at the same time, we'll see a tremendous improvement the quality of those articles. It's great that our featured/good articles are so obscure and diverse, and that is an important part of Wikipedia's mystique. But many of our most important articles are perennially deficient (especially in sourcing, but also MOS compliance and flow) because they're such a daunting task to improve. Many editors will be happier to work on these important articles if they are not working alone.

If there is a mixed consensus on this, as there was with the main page proposal, I'd like to at least propose some type of a trial period, even two weeks, to see if it has any kind of take. —Noisalt (talk) 00:36, 31 January 2011 (UTC)

This would be a powerful collaboration, but who would pick the articles? Titoxd(?!? - cool stuff) 01:14, 31 January 2011 (UTC)
My guess is a moderated vote much like WP:TFA. The best system would become apparent through practice. The process we choose shouldn't be the biggest sticking point, but I would hope to keep it to major articles (either WP:VA or an ad hoc system). —Noisalt (talk) 01:53, 31 January 2011 (UTC)

A new look for thumbnails

Screenshot 2.
Screenshot.

I'd like to bring in some CSS from Wikinews—I like it there and it looks great here. Since the redesign, the thumbnail box has looked out of place and this is a clean solution that looks good in monobook. Implementation would involve adding 

div.thumbinner { background:#FFFFFF; border:0; }
div.thumbcaption { font-size:90%; }

to MediaWiki:Common.css. Mono (talk) 00:37, 20 January 2011 (UTC)

I like it. Fences&Windows 02:51, 20 January 2011 (UTC)
support Arlen22 (talk) 23:30, 20 January 2011 (UTC)
oppose If the text is "floating in the air", it can easily be confused with the rest of the text MBelgrano (talk) 00:18, 21 January 2011 (UTC)
While I don't think this is a realistic concern for the example shown, that uses left-floating images. I do agree that it could be much more confusing on the right hand side; it may only work with justified text. Happy‑melon 14:29, 21 January 2011 (UTC)
The image link icon (presently absent) *could* be used left-justified on right-side images, right-justified on left-side images to break the caption text from the body text. --MASEM (t) 14:45, 21 January 2011 (UTC)
It looks great, I don't think there's any danger of it confusing anyone. Fences&Windows 22:32, 23 January 2011 (UTC)
I like it. Airplaneman ✈ 08:35, 24 January 2011 (UTC)

Oppose Mostly, I don't like the look of it. Also, it is fixing a non-existent problem. It seems to be fixing a problem with the horrible 'Vector' thing; the better solution is to ditch Vector. It looks less like a real book. And FSM-knows how many things it'll break. The border serves to associate the caption with the image. And, it is a hack - changing it to be white-background. Chzz  ►  04:10, 29 January 2011 (UTC)

Life is a hack. And Vector is here to stay, whether you like it or not. If it looks awful on other skins, then we could implement it for Vector only. TBH, the current border looks nothing like a book. Plus, we aren't a book. I doubt it will break stuff, until you can prove it. The text is aligned and formatted to distinguish the caption from the text, as well. Mono (talk) 03:10, 1 February 2011 (UTC)
Here is a bit of a caption with a background color
  • Not necessarely opposed, but perhaps we can do a better job then the Wikinews design. The icon for one should stay, and the text should maintain its background. And the font-size should NOT be further reduced. — Edokter (talk) — 23:58, 29 January 2011 (UTC)
We can keep the icon and the text size, if we want to. Mono (talk) 03:10, 1 February 2011 (UTC)
  • Support Slimmer, simpler, more elegant. But keep the "expand" icon. --Anthonyhcole (talk) 02:43, 30 January 2011 (UTC)
  • I don't like the floating caption, and I do like having the caption enclosed within the boundary: it clearly distinguishes it from the adjacent main text. Tony (talk) 02:51, 30 January 2011 (UTC)
  • I don't like it either. Unfortunately the latest example only shows (to me anyway) how much easier it is to distinguish the caption on the current thumbnail boxes than the proposed ones. I wouldn't be opposed though if someone removes the inner border, and changes it so that the box is merely underneath the image instead of surrounding it. --Dorsal Axe 18:54, 30 January 2011 (UTC)
  • I'm all for re-thinking the thumbnail design, but keep in mind that Wikinews doesn't get near our traffic or editors. Meaning that people there are more likely to know how to place images so the text does not confuse readers, and the readers know what to expect. We need something more fool-proof. Also, there must be something to indicate that the images can be expanded, even if it isn't our current icon. ▫ JohnnyMrNinja 11:41, 2 February 2011 (UTC)

"You have messages" bar needs to be placed on side of page, not top

The big orange/yellow (?) bar that suddenly appears at the top of a page when someone has written on the talk page needs to be moved for the following reason:

  • It appears only at the top and isn't visible when one is further down on a page, including when writing in the editing box. Sometimes important updates or messages directly related to what one is writing aren't seen until the page has been saved, which means the message gets read too late. Several times this has caused unnecessary conflicts, misunderstandings and embarrassment.

I suggest it be placed on the right side of the page so that it is always visible, no matter where one is on a page, also while editing. -- Brangifer (talk) 21:52, 20 January 2011 (UTC)

Conflicts, misunderstandings and embarrassment can be avoided if all concerned would examine the time stamps in the edit histories and talk page messages.
—Wavelength (talk) 22:08, 20 January 2011 (UTC)
Of course, but that's after the fact. Edit conflicts constantly occur, and in efforts to help each other we sometimes alert each other to changes or things that are happening elsewhere. That information, if received in time, will help us alter our behavior so we don't make an edit in response to what was there, but is no longer. The situation has changed during that time. I'd sure like to have received an alert before saving an open edit window. I often have up to twenty tabs open at once, some with open editing windows, and while on another page I could have received that alert, looked at the message on my talk page, and then either altered my proposed edit or not made it at all since it's out of date. Even though it's often innocent, with no bad feelings, it's still irritating and a waste of time. -- Brangifer (talk) 22:23, 20 January 2011 (UTC)
I thought it only appears anyway when you refresh the page? Placing it on the side would only make users less likely to notice it. Yoenit (talk) 22:26, 20 January 2011 (UTC)
e/c The message bar does not "suddenly appear" while in the middle of editing an article. Yoenit is right. It will only show up when you refresh the page, go to a new page, or hit the edit button—after someone leaves a message. In which case you are then at the top of the page and will always see the message bar. You would probably have to talk to the developers if you want a message alert to appear while you have a page open or in the middle of editing. First Light (talk) 22:30, 20 January 2011 (UTC)
If I may suggest it is probably possible to program a skin change of somekind that would allow the user to opt to recieve it on the side or the bottom rather than the top! That programming is a bit above my skill level but if they can make things like twinkle and the various other scripts it seems reasonable to believe its possible. --Kumioko (talk) 22:39, 20 January 2011 (UTC)
Do you mean like a "floating" notification? Otherwise I'm not sure it would make much difference. --Dorsal Axe 22:51, 20 January 2011 (UTC)
A message notice on the side still wouldn't solve Brangifer's issue of wanting to be notified of a message while he is in the middle of editing an article. Only some sort of instant message alert would solve that. First Light (talk) 22:55, 20 January 2011 (UTC)
You guys have come up with the ideal situation.....a notification while editing, no matter where you are. Good idea. Yes, I imagine someone could make it as an add-on or something else. Any genius programmers here?! Got a job for you that I'm sure many would appreciate. -- Brangifer (talk) 00:26, 21 January 2011 (UTC)
But which is the need to bother with all this? Which process in wikipedia is that important that someone must be notified right away, and can't wait some minutes to end reading or writing and receive the message when saving or opening a new page? MBelgrano (talk) 04:41, 21 January 2011 (UTC)
I agree with MBelgrano, but whoever wants the code, try changing the CSS of the talk pg header to
display:inline;position:fixed;top:295px;left:0px;z-index:2

I would also rejigger its size... Maybe just keep an exclamation mark image. This doesn't look too hard... I'll try it... ManishEarthTalk • Stalk 06:01, 21 January 2011 (UTC)

How 'bout this? 
if(document.getElementById('mw-youhavenewmessages')){
document.getElementById("bodyContent").innerHTML+='<div id="newmessagefloat" style="display:inline;position:fixed;top:295px;left:0px;z-index:2"><A HREF="http://en.wikipedia.org/wiki/User_talk:'+wgUserName+'"><img src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/Nuvola_apps_important.svg/25px-Nuvola_apps_important.svg.png" alt="You have new messages" /></a></div>';
}
  • I support the idea of making a change that allows editors to be alerted at once to a message on their talk page. The side is also a good idea. FaceBook does this on one's active threads, for example, though it fades away after 10-15 seconds. I'm not programmer so I can't help with the coding, I'm just in favor of the concept. Hopefully the devil will not be in the details. I commend Brangifer for posting the proposal. Jusdafax 07:37, 21 January 2011 (UTC)
  • (I hate edit-conflicts...) To be able to pull that off, you would need some sort of script that constantly pings the server to determine whether or not you have a new message. Implementing that on the server side, (i.e. for everybody,) would be a bad idea, because it would terribly increase the load on the servers. You might be able to write a monobook.js/vector.js script that pings the server every X seconds, and gives a "You Have Mail" style popup. That way only the people who want/need that feature would be hammering on the servers, kinda like how Lupin's Anti-vandal Tool works. -- RoninBK T C 08:06, 21 January 2011 (UTC)
  • Well, that wouldn't be a problem, except for one thing: How do we determine if a user has read the messages or not? I mean, to show a 'new message' box, you must know that the message is new. I don't think there's an open (available to us) server request that can tell you if there are new messages. One solution is, whenever a user checks his talk page, store the date/time in a cookie/usersubpage (cookie isn't good because then you'll invariably get a newmessage box on a new computer). That way, all non-self edits to the talkpage after that time can be regarded as a new message. This shouldn't be too hard, except my AJAX is rusty and I've never used it on Wikipedia. But it's a bit extreme. There really is no need of having an auto-edit happening every time you view your talk page, just so you can get a realtime update. No message is that urgent. If enough people ask, though, I might try making it. If you want a more competent developer who knows his way around AJAX (and probably realtime stuff), I would try poking User:TheDJ. ManishEarthTalk • Stalk 13:49, 21 January 2011 (UTC)
  • I believe you can use uiprop=hasmsg from the api to check if a user has an unread message. Not 100% sure. And polling should be kept to a minimum, cause if many users do such polling, you'll bring the servers down (or rather, your tool will be blocked by the sysadmins). Hopefully one day in HTML5, it be possible to do some sort of push message. —TheDJ (talk • contribs) 14:11, 21 January 2011 (UTC)
  • hasmsg seems correct. Could you just write the Ajax code for me? I'll write the rest. I propose we make the timeout five minutes for normal pages, and a bit less for edit pages, as you only linger long on edit pages, which is where this tool is required. I don't know about you, but I don't stay on an article page exclusively for long. Comments on the timeout? Thanks, ManishEarthTalk • Stalk 15:48, 21 January 2011 (UTC)

There are two situations where one can miss a message: (1) While working on an edit and (2) when one hops directly to a lower section on a page. This happens to me several times a day/night where I follow a section link, or return to a section I was on. Sometimes I notice the flash of color before the top of the page disappears from view, but sometimes I don't notice it. The bar is up there all that time, but doing no good. Moving the bar to the side would solve this problem.

The problem of constantly pinging the servers was mentioned above. This could be limited if the script or whatever only worked when one was in editing mode. The rest of the time things would function exactly as now. -- Brangifer (talk) 02:28, 22 January 2011 (UTC)

Even if you go to a subsection of an article, and miss the new messages warning, it would still appear at the next page you visit. The warning only dissapears when you actually check your user page. MBelgrano (talk) 02:44, 22 January 2011 (UTC)
Exactly. You don't sit reading subsections for long. Only when you're editing will you be stuck there for a long time without opening any new pages. Then how about this? The above script will be used on all non-edit pages (maybe with a bigger icon), and the AJAX-ping method will be used on edit pages. What should be the timeout? 5 Minutes? ManishEarthTalk • Stalk 03:11, 22 January 2011 (UTC)
@MBelgrano: Of course, but that's not the point. The whole point is that some messages need to be read and acted upon as quickly as possible. If I'm editing or reading for a long time in one spot, I'm not getting the urgent message. Sometimes I'm working on complicated edits with lots of refs and I may even leave the PC and do something else, then come back and continue. There can go 15 - 45m. easily. I often work on very controversial stuff and long, heated discussions on talk pages are the rule of the day. I can read something on the talk page justifying an edit, go and work on it, and in the meantime the consensus has changed. Someone might wish to discuss it with me on my talk page, but I'm not getting their message. What happens is that I end up making a non-consensus edit, or maybe one that could be misunderstood as edit warring. I wouldn't deliberately do that, but it could appear that way. I understand from your comments that you haven't walked in my shoes and that you therefore consider my concerns to be illegitimate, but maybe you should just AGF and recognize that we all have different experiences and needs here. The change I'm suggesting wouldn't hurt anybody, not even you. -- Brangifer (talk) 03:15, 22 January 2011 (UTC)
@Manishearth, moving the bar to the side will solve part of the problem and using the script only while working with an open edit window will limit pinging of the servers. -- Brangifer (talk) 03:19, 22 January 2011 (UTC)
That's what I'm saying. The above script does not hit the servers. It only detects if there's a newmessage bar and accordingly generates an exclamation mark sign on the side which floats with the scroll. I'll write the editpage pinging part once someone gives me the API request AJAX code. ManishEarthTalk • Stalk 04:04, 22 January 2011 (UTC)
It's pointless to remind me to assume good faith, because I'm not accusing anyone of anything. My point is simply that the interface and processes of Wikipedia allow to do things at one's pace, without needing to rush. Consensus can hardly change in mere minutes, if it does, it means that the discussion is still going on. We can see, link and retrieve older revisions, and we can leave and re-join discussions at any moment. MBelgrano (talk) 04:10, 22 January 2011 (UTC)

Well, the world is kind of used to the Web 2.0 instant updates etc etc, though I do agree with you. And anyways, whats the worst thing that can happen if you don't see your talk page for a few minutes? If you make an edit which you wouldn't have done after seeing the talk page, it can be reverted. I propose we drop the proposal. ManishEarthTalk • Stalk 08:28, 24 January 2011 (UTC)

Yeah, this proposal isn't something that can be done through Wikipedia's current code. Branfinger is wanting push notifications, which would probably require Ajax or JavaScript coding to work. — The Hand That Feeds You:Bite 14:37, 25 January 2011 (UTC)
It can be done through WP's current code. You just ajax-request once a few minutes. But it can load the servers. ManishEarthTalk • Stalk 15:48, 25 January 2011 (UTC)
Or you could have an irc client running in the background in the recent changes channel and have it ping you when your nick comes up. -- Ϫ 05:19, 2 February 2011 (UTC)
One day... ONE DAY when I get the time (read as never), I'll probably create a desktop Java notification client which'll notify new messages, watchlist changes, etc, etc (Customizambe for WP:AIV, etc). ManishEarthTalk • Stalk 11:24, 2 February 2011 (UTC)
Hahah! One days.. I got a lot of those! ;) œ™ 11:33, 2 February 2011 (UTC)
I even have a list of scripts/programs that I'm supposed to do. I use it to blackmail myself sometimes, but it doesn't work :P ManishEarthTalk • Stalk 15:18, 2 February 2011 (UTC)

Strips to replace floating boxes for portals, books, and sister projects

Although templates such as {{Portal}}, {{Wikipedia-Books}} and the various sister project box templates (like {{Wikispecies}} or {{Commons}}) have their uses, the floating boxes seem to get in the way or receive inconsistent placement within articles. Personally, I prefer the French version of the template {{Portal}}: Modèle:Portail In particular, I like the first example, which puts all the portals in a strip that spans the width of the article. It is used at the end of the article, right before the categories are listed. For example, see the bottom of Réserve spéciale d'Ankarana. I would love to see something similar, especially since many articles belong to multiple portals and/or books, as well as link to numerous sister projects.

Some templates such as {{Wikispecies}} or {{Sister project links}} are capable of grouping multiple entries, but you come back to the alignment and placement issues. Even if this proposal doesn't standardize whether people use boxes or strips, I would at least like to see strip templates created for these types of links. I tried figuring out the code of Modèle:Portail, but for some reason the coding befuddled me. First, would someone be willing to create these templates so that they would look and behave like the example I provided? Second, should we standardize on such formatting for the sake of consistency... for the same reason categories are always found in the same place? – VisionHolder « talk » 00:49, 23 January 2011 (UTC)

Apparently every portal has its own template (like fr:Modèle:Portail cinéma) which uses the template fr:Modèle:Méta lien vers portail. It also uses a bunch of CSS class to style the whole thing. (Copying the French example below:)
--Yair rand (talk) 22:49, 23 January 2011 (UTC)
So is this something that can be easily done, although in a more organized fashion? – VisionHolder « talk » 22:58, 23 January 2011 (UTC)
Those templates are not used at sections with text in prose anyway. They are used at "See also" or "External links" sections, which are just a small bulleted list of short items at the left, and shouldn't conflict with floating boxes at the right. MBelgrano (talk) 17:13, 28 January 2011 (UTC)
True, but the "External links" section is just above the navigational templates and categories. Furthermore portals and books are not external links. In other words, these things belong in this general area, but not in that section. Moreover, if you have two or three right-floating boxes, they take up a lot more space than the list of links, creating a lot of white-space. The best way that I can think of doing it is to offer something like the category bar, but ones specifically for portals, books, and interWikis. As it stands, portals are rarely linked within articles, resulting in very low hit counts for portals that are not displayed on the main page every day. maybe if we had a consistent place for them (as well as books and interWikis), they would be included more often and get more traffic. – VisionHolder « talk » 04:30, 29 January 2011 (UTC)

Last night, I made a few templates in my user space for this, and now I would like some feedback. The template tentatively named {{Portal bar}} could look looks like this:

The template tentatively named {{Book bar}} could look looks like this: {{Template:Book bar|Lemurs|Subfossil lemurs|Mesozoic mammals of Madagascar}} I have not made a demo for an interWiki bar yet because I have tentatively created a demo for something I'm calling the "Subject bar" (User:Visionholder/Template:Subject bar):

This one is currently static and not a functional template yet, and I am not skilled enough with style sheets to make it look perfect, so please consider its potential and not its current appearance. What this demonstrates is how this information could be presented in one cohesive unit. Since not every article will belong to a book or have interWiki links, the template would adjust the appearance accordingly. Again, this has several key advantages. First, it puts these links in a proper context. They are not "External links", so that is not where they belong. Instead, books, portals, and interWikis are all WikiMedia-related links, so this grouping make sense... to me, at least. Second, this eliminates the formatting issues created by having floating boxes that align to the right or left. Third, by having a standardized way for presenting these links, portal/book/interWiki links could be more commonly used and even added by bots or AWB. The increased usage might mean increased traffic for all three types. – VisionHolder « talk » 19:16, 29 January 2011 (UTC)

Nice work. I like the idea of having this as an option for changing the presentation of these links. Let me know if you want any help making a functional version. Plastikspork ―Œ(talk) 19:52, 29 January 2011 (UTC)
Thank you very much for your offer to help code the template. I will definitely need help, particularly with the style sheets. (Let's put it this way: I aspire to being a novice at style sheets.) For the moment, though, if you are good at style sheets, I would greatly appreciate help in making the static demo look more presentable. Code simplification for all the existing demos would also be appreciated. All I ask is that you preview your work before saving since they are on display here. – VisionHolder « talk » 20:06, 29 January 2011 (UTC)
I prefer the strips to the floating boxes --Guerillero | My Talk 20:19, 29 January 2011 (UTC)
I greatly prefer the strips. They're more noticeable, they don't break pages like the floating boxes do, and they would have a consistent placement. I'm all for it. It would be really cool if we could merge them all into one big multiple-use template. --Dorsal Axe 20:31, 29 January 2011 (UTC)
I'm not too keen on this. If the goal is to generate traffic to portals and books, that probably won't work. The lower something is in the article, the less clicks it gets. The "see also" section is where people go to when they want related links. It you move it at the bottom, they'll be considered a footer by most people and will skip them , and they'll be as ignored as categories. Also, personally I would place books above portals as in my experiences books are generally a bit more directly related to the article, if not, they are roughly of equal relevance. For example, a Canadian Prime Minister will often have a Portal:Canada link, but he will also have a Book:Prime Ministers of Canada.
I do agree that something needs to be done about the general ugliness, but I'm not sure exactly what. Maybe devising an "{{Internal project links}}" based on {{Sister project links}} would be better? Headbomb {talk / contribs / physics / books} 20:49, 29 January 2011 (UTC)
Oh and for the sake of transparency, I'm with PediaPress, although I'd say what I said above regardless of that affiliation. Headbomb {talk / contribs / physics / books} 20:51, 29 January 2011 (UTC)
It's fine if you don't care for it. I don't expect everyone to like it. But unless someone can provide some tangible alternative solutions, we might as well attempt to develop this. Also, I have no problem putting books before portals. The part about increased traffic was just speculation, and that's why I listed it last in the benefit list. As it stands now, most articles don't even link to portals, books, or inerWikis, so it's hard to say for certain. (But what you pointed out is a very valid point.) When you suggested "{{Internal project links}}" based on {{Sister project links}}, are you talking about another floating box? If so, again you run into the problem of making a potentially large floating box fit within a potentially small section of an article, once again causing formatting issues. This is why I think bars are better. If you want, we can try to devise a more unified "bar" to contain all three... – VisionHolder « talk » 21:22, 29 January 2011 (UTC)

Templates {{Portal bar}} and {{Book bar}} have gone live if people would like to start playing with them. The "Subject bar" will probably be under development for a little while. In the meantime, continued feedback would be greatly appreciated. – VisionHolder « talk » 23:49, 29 January 2011 (UTC)

Why not ask the people at WP:AWB to add these templates to their program after you've finished developing them. That way, all the pages can be made neater. ManishEarthTalk • Stalk 11:09, 31 January 2011 (UTC)
That's a good suggestion! I will certainly do so. Thanks! – VisionHolder « talk » 13:33, 31 January 2011 (UTC)
Hold on! This was a discussion for an alternative way to show the portal links, not for a new standard method to display those boxes. This should not be added to AWB unless you have wide consensus all pages should be changed to this standard. Yoenit (talk) 14:23, 31 January 2011 (UTC)
I wasn't going to do it right away. And anyway, consensus requires people to actually respond. That's partly my fault, though. I'm getting closer to having a working template that integrates all three potential bars. (See the new demo above.) Once it's ready, I should probably start over with a brand new post. – VisionHolder « talk » 03:24, 1 February 2011 (UTC)
Why not start a spearate thread (I dunno where) on this once the templates are perfecter? ManishEarthTalk • Stalk 14:44, 31 January 2011 (UTC)

Why does anyone want to visit portals anyway, instead of just visiting the article for whatever topic they are interested in? I think the reason nobody visits them is that they serve no useful purpose. Mesoderm (talk) 14:56, 31 January 2011 (UTC)

Well, I do use the portals when doing research... But I don't think most non-editors know of their existence. Anyways, thats kind of unrelated. Here, we're trying to remove the ugliness from the floating boxes. Anyways, I've opened up a section below to ask for a change of format. — Preceding unsigned comment added by Manishearth (talk • contribs)

Set strips as default format?

Please discuss/consensusvote here on whether or not the above proposal should be made the default style all over Wikipedia. — Preceding unsigned comment added by Manishearth (talk • contribs)

Let's not discuss this here. This heading is growing stale. Anyway, I've just finished the template and published it: {{Subject bar}} Let me find an appropriate forum to get feedback, and if the good significantly out-weighs the bad, I'll bring it up again. – VisionHolder « talk » 08:06, 2 February 2011 (UTC)

Subject bar template

The new combined template is now completely coded. I have put in the main space at {{Subject bar}} for testing and comments. I also made a post about it at Wikipedia talk:Manual of Style (layout). There is a sandbox version for more major edits. Everyone is encouraged to stop by there to learn more and make comments. – VisionHolder « talk » 15:43, 2 February 2011 (UTC)

Indicate that the tab is a redirect

It is really confusing when you end up on a talk page, and you click on the article tab and it's a redirect, and you click back to the talk page and it isn't the same one. This happens a lot when you are going through articles by assessment categories, but also just old links. What about either A) a different color for the tab or b) changing the word "article" or "project" or whatever to the word "redirect"? There's a lot of twisty little passages around Wikipedia. ▫ JohnnyMrNinja 03:12, 29 January 2011 (UTC)

Which redirects to Colossal Cave Adventure and shows (Redirected from Twisty Little Passages) under the title. ---— Gadget850 (Ed) talk 04:22, 29 January 2011 (UTC)
No, I meant that metaphorically. In a few of the ancient computer games (also [Zork I), there were times when you'd get lost in "twisty little passages", and you'd end up a place other than where you intended to go. Sorry if that was muddled. ▫ JohnnyMrNinja 04:30, 29 January 2011 (UTC)
I am literally referring to the text that shows under the page title when redirected. I am quite familiar with those games. I owned all of the Infocom games at one point. And I played Colossal Cave Adventure on a system used to test nuclear missiles. ---— Gadget850 (Ed) talk 05:14, 29 January 2011 (UTC)
Got it, so if you were to follow this link to Talk:Sonic Colours, and think "Why has this article been marked with an NA assessment?", and then you click on the article tab, and then you click on the talk tab, you are in a different place. I know that the redirect text is there, that is aimed at people using wikilinks, not tabs. Being redirected by a tab is non-standard and unexpected. You can read the text of a link and see that it says Sonic Colors and then click and see that you are in the article Sonic Colours. When you click on a tab you see "Article", so you are more likely to miss it. I realize that this isn't earth-shattering, but it would just make maintenance a little easier. ▫ JohnnyMrNinja 05:37, 29 January 2011 (UTC)
I would redirect that particular talk page. But I really like the idea of colour-coding or marking tabs if they are a redirect. I tend to experience the same sort of thing; many talk pages redirect to a more centralised talk page, so I inadvertantly click to go back to the article/page, only to find it's something else completely. --Dorsal Axe 20:37, 29 January 2011 (UTC)
It's possible to color links (either the text color or the background color) with User:Anomie/linkclassifier.css. It should be possible to color redirect-links by adding importScript('User:Anomie/linkclassifier.js'); // Linkback: [[User:Anomie/linkclassifier.js]] to your Special:Mypage/monobook.js (or your Special:Mypage/vector.js if you use the vector skin) and then adding e.g. A.redirect { background-color:color:#88ff88; } to your Special:Mypage/monobook.css (or Special:Mypage/vector.css). – sgeureka t•c 15:07, 31 January 2011 (UTC)
Thanks, I was kinda hoping this could be sitewide, but this is a start. ▫ JohnnyMrNinja 05:42, 3 February 2011 (UTC)

Here's a couple of suggestions to make Book Creator and/or Infoboxes better

Hi all. My potential proposals relate to "Book Creator" and "Infoboxes". I downloaded a PDF with one article in a book that I created under Book Creator. I viewed the PDF, and the Infobox for the article on Super Mario Bros. didn't have any information in the "Release Date(s)" field. So I went back to Book Creator, viewed the Super Mario Bros. article again, and clicked the "+" button by the Release Date(s) field in the Infobox to show other dates. I figured that since the "+" was opened, that the release dates would show up in a new PDF after running the Book Creator again. I did what was necessary to re-download a new file that I was hoping would have the Release Dates available. But the new PGF also left the Release Date(s) field empty.

So, I have 2 proposals; we would probably just use one but not the other:

Proposal #1: Change all of the Wikipedia articles that have "+" options in the Infobox and eliminate the "+" option so all the information is visible and thus will show that info in the PDF's 'Infobox', which might be a pain.

Proposal #2: (If possible)--Update Book Creator so that it has the capability of showing ALL of the information available in Infoboxes. Another consideration in that proposal would be to make the Infobox in PDF's to be more similar to Wikipedia's alignment and appearance.

Sorry about the length. Cheers, 24.10.181.254 (talk) 01:34, 1 February 2011 (UTC)

The second proposal is clearly better from a user perspective. I was also wondering why infoboxes appear on the screen in parallel with the text, but the book creator seems to change that layout to centering them on the page. Perhaps it is a result of the difference in fonts. Racepacket (talk) 12:30, 1 February 2011 (UTC)
I like #2 better too personally. I also am curious why the infoboxes are centered in PDF's etc.

Like respondent #1 and #2, I prefer my second proposal better. I really wish Wikipedia knew how to fix that. I don't know if it is fixable, but it would make their Book Creator so much better. The purpose behind Book Creator (as I understand) is to make this information available for offline viewing, so it would make perfect sense (if it's possible) to make ALL of the information to be available, rather than most of it. And like Racepacket said said, it would be nice if the format (i.e. the alignment of Infoboxes, etc) was more akin to Wikipedia's format. I really hope this idea gains some momentum; or at the very least, that someone comes out and says, "Sorry, it wouldn't work, and ____ , ____ , and ____ are the reasons why it won't work. Maybe someday in the future."

I think my text wasn't formatted that good, so I'm going to try again in bold and see if it catches any more eyes:

Proposal:

Update Book Creator so that it has the capability of showing ALL of the information available in Infoboxes. Another consideration in that proposal would be to make the Infobox in PDF's (and ODF's) to be more similar to Wikipedia's alignment and appearance. 24.10.181.254 (talk) 02:57, 2 February 2011 (UTC)

Difference between revisions for long pages

This is a copy of what I posted to the idea lab, but not much traction there, except that it's a good idea. So I bring it here for further review.

I notice that long pages (like two that I keep up with, Cold War and Lima) take a very long time to load. When I'm only looking a diffs between revisions, I typically don't need to have the diffs and the whole page load. I just want to see the edited part at the top. There should be a button or something that will load the "current" page under the diff, if you need it to load for some reason. Otherwise, the rest of the page doesn't need to load. There would be less server load if that happened, and looking through a group of diffs one after the other would be a lot faster. Hires an editor (talk) 02:54, 1 February 2011 (UTC)

Try checking the box that says "Do not show page content below diffs" in the Misc section of your preferences. To get this functionality for a specific diff, add "&diffonly=1" to the end of the URL, as described at Wikipedia:Complete diff and link guide#How to display only the diff. Graham87 03:43, 3 February 2011 (UTC)
Oh, I've just noticed that my first suggestion was already mentioned in the discussion at the idea lab. Graham87 03:45, 3 February 2011 (UTC)

Use more randomisation

We now have the Wikipedia:Comment request service which will help to mix up input to WP:RFCs. This same approach (and presumably the same bot) could also make requests for input for all sorts of other things, including Wikipedia:Editor review, backlogged pages like WP:FEED, etc. We could also use the random suggestion approach more widely than that; for example to randomly suggest to editors (based on criteria like activity, participation in dispute resolution, participation in topics under arbitration) that they nominate themselves for editor review. Basically, this is quite a fertile approach for reducing the problem of different parts of Wikipedia often becoming the territory of a handful of editors, and we should try and use it more widely now we have the proof-of-concept implemented. Rd232 talk 14:48, 2 February 2011 (UTC)

Propose to Thank editors for each contribution

Propose to have a "Thank You" note as part of each edit contribution. I guess this could be an standard, or even opt-in or opt-out. The idea is to thank the donors for their contributions with each edit they submit. It's a typical fun(d)rasing method for all to be happy. Zulu Papa 5 * (talk) 16:23, 28 January 2011 (UTC)

I'm unclear about this proposal. Do you mean a thank-you message on the talk page or simply a text in the interface (e.g. "...See the Terms of Use for details. Thanks for your contribution to the sphere of free knowledge.")? The first would double the number of entries in the data base. In any case, if it's purely mechanical, I personally see no value in it. --Stephan Schulz (talk) 17:04, 28 January 2011 (UTC)
Good point about being mechanical ... the intention was to be thoughtful and considerate of folks contributions to Wikipedia, spread some good faith, ya know. Zulu Papa 5 * (talk) 02:08, 29 January 2011 (UTC)


Nice idea in theory, but would it make Wikipedia look too messy if we implemented this? ACEOREVIVED (talk) 21:09, 3 February 2011 (UTC)

Unifying of discussion templates

Before scrolling down, please study the table below very thoroughly. I know these templates are currently well "established", but please see my comments at the end after studying the table.

Ref. Template Usage Renders as (notice line breaks, text formatting excluded, small text are my comments)
WP:AFD:
A1 {{Afd2}} First entry == PAGENAME ==
      PAGENAME (edit|talk|history|links|watch|logs) – (View log)
      (Find sources: "PAGENAME" – news · books · scholar · free images)
REASON.
Original template syntax
{{subst:afd2 | pg=PAGENAME | cat=CATEGORY | text=REASON}} ~~~~
WP:FFD:
B1 {{Ffd2}} First entry == FILENAME ==
       FILENAME (delete | talk | history | links | logs) – uploaded by UPLOADERNAME (notify | contribs | uploads).
* REASON.
Original template syntax
{{subst:ffd2|FILENAME|Uploader=UPLOADER|Reason=REASON}} ~~~~
B2 {{Ffd2a}} Consequent nominations
       FILENAME (delete | talk | history | links | logs) – uploaded by UPLOADERNAME (notify | contribs | uploads)
Original template syntax
{{subst:ffd2a|FILENAME|Uploader=UPLOADER}}
WP:CFD:
C1 {{Cfd2}} For deletions == CATEGORYNAME ==
      CATEGORYNAME - (edit|talk|history|links|watch|logs)
      Nominator's rationale: REASON.
Original template syntax
{{subst:Cfd2|CATEGORYNAME|text=REASON. ~~~~}}
C2 {{Cfm2}} For mergers == CATEGORY1NAME ==
      Propose merging CATEGORY1NAME to CATEGORY2NAME
      Nominator's rationale: REASON.
Original template syntax
{{subst:Cfm2|CATEGORY1NAME|CATEGORY2NAME|text=REASON. ~~~~}}
C3 {{Cfr2}} For renames == CATEGORY1NAME ==
      Propose renaming CATEGORY1NAME to CATEGORY2NAME
      Nominator's rationale: REASON.
Original template syntax
{{subst:Cfr2|CATEGORY1NAME|CATEGORY2NAME|text=REASON. ~~~~}}
C4 {{Cfc2}} For conversion to article == CATEGORYNAME ==
      Convert to article CATEGORYNAME to ARTICLENAME
      Nominator's rationale: REASON.
Original template syntax
{{subst:Cfc2|CATEGORYNAME|ARTICLENAME|text=REASON. ~~~~}}
WP:RFD:
D1 {{Rfd2}} First entry == CURRENT-REDIRECT ==
* CURRENT-REDIRECT → CURRENT-TARGET (links to redirect • history • stats)
REASON
Original template syntax
First template, if just one entry:
{{subst:rfd2|redirect=CURRENT-REDIRECT|target=CURRENT-TARGET|text=REASON.}} ~~~~
== CURRENT-REDIRECT ==
      * CURRENT-REDIRECT → CURRENT-TARGET (links to redirect • history • stats)
Original template syntax
First template, if used with 2 or more entries (If used with D2):
{{subst:rfd2|redirect=CURRENT-REDIRECT|target=CURRENT-TARGET}}
D2 {{Rfd2m}} Consequent entries * CURRENT-REDIRECT → CURRENT-TARGET (links to redirect • history • stats)
Original template syntax
2nd (to one before last) template, if 3 or more entries:
{{subst:rfd2m|redirect=CURRENT-REDIRECT|target=CURRENT-TARGET}}
* CURRENT-REDIRECT → CURRENT-TARGET (links to redirect • history • stats) REASON
Original template syntax
Bottom template, if 2 or more entries:
{{subst:rfd2m|redirect=CURRENT-REDIRECT|target=CURRENT-TARGET|text=REASON.}} ~~~~
WP:TFD:
E1 {{Tfd2}} Deletion discussions == TEMPLATE1NAME ==
      TEMPLATE1NAME (edit|talk|history|links|watch|logs|delete)
      TEMPLATE2NAME (edit|talk|history|links|watch|logs|delete)
      ...+20
REASON
Original template syntax
{{subst:Tfd2|TEMPLATE1NAME|TEMPLATE2NAME|text=REASON. ~~~~}}
E2 {{Tfm2}} Merger discussions == TEMPLATE1NAME ==
      TEMPLATE1NAME (edit|talk|history|links|watch|logs|delete)
      TEMPLATE2NAME (edit|talk|history|links|watch|logs|delete)
REASON.
Original template syntax
{{subst:Tfm2|TEMPLATE1NAME|TEMPLATE2NAME|text=REASON. ~~~~}}
WP:MFD:
F1 {{Mfd2}} All MfD uses == PAGENAME ==
REASONING
Original template syntax
{{subst:mfd2| pg=PAGENAME| text=REASON}} ~~~~

As some of you may have realized, the following changes may seem possible:

  • Proposal 1A: B2's functions could be merged into B1. It could be done by either:

    1). Modifying B1 to function like E1 (supporting a few dozen entries in one template), or

    2). B1 could be modified such that simply excluding |reason= would function as B2.

  • Proposal 1B: C2, C3, and C4, could all be merged into C1, by renaming default parameters such as |1= to titles such as:

    |MergeCat1=

    |MergeCat2=

    |RenameCat1=

    |RenameCat2=

    This would easily enable the combining of these separate templates. An additional feature that could be added, which doesn't exist currently, would be to modify the merged-C1 to function like E1 (supporting a few dozen entries in one template), something like:

    |MergeCatA1=

    |MergeCatA2=

    |MergeCatB1=

    |MergeCatB2=

  • Proposal 1C: D2's functions could be merged into D1. It could be done by either:

    1). Modifying D1 to function like E1 (supporting a few dozen entries in one template), or

    2). D1 could be modified such that simply excluding |text= would function as D2.

  • Proposal 1D: E2 could be disposed. E1 could simply hold an additional parameter |type, with the content being either deletion or merger, thus making way to implement the functions of E2.
  • Proposal 2: All of these templates could be merged to one. This seems a bit "definitely oppose" or "impossible" on the first thought, but it does seem possible. For example, all the parameters could simply start with something like:

    |AFD-PAGE1=

    |AFD-PAGE2=

    ...

    |AFD-PAGE20=

    |AFD-PAGE1-CAT=

    |AFD-REASON=

    |FFD-FILE1=

    ...

    |FFD-FILE20=

    |FFD-UPLOADER1= (note)

    |CFD-MergeCatA1=

    |CFD-MergeCatA2=

    |CFD-MergeCatB1=

    |CFD-MergeCatB2=

    |CFD-RenameCatA1=

    |CFD-RenameCatA2=

    The list goes on...

  • Note 1: Template functions (such as: (edit | watch | talk | history | links | logs) for all namespaces/files, and (notify | contribs | logs | talk) for creator/uploader), will be same for all variables.
  • Note 2: Either Proposal 1x or Proposal 2, would require substantial alterations to many pages (deletion request pages), tools (twinkle), editors (custom tools and bots), and many more areas.

    But on the other hand, it unifies all key templates into one; greatly reducing confusion, pooling of editors' dedication, and makes it easier to keep an eye on for damages by accident or vandalism. Changes could also be made once and for all, instead of changing templates for each.

  • Note 3: The corresponding page templates (the ones placed on the pages, such {{Ffd}} as compared to {{Ffd2}}) could all be merged as well. But of course, thus would be much easier than the changes to the above templates.

I hope you understand what I am trying to say here, took me the whole day trying to put this proposal right :) Please avoid comments like "oppose - too complicated to carry out", and discuss the real technical issues on implementing this. I intend to move this to WP:VPR in about a week, if no serious issues are seen. Kind regards. Rehman 11:33, 8 January 2011 (UTC)

Discussions (VP Idea Lab)

I don't understand at all, because all you've done is paste in a table of code. Can you write out in prose what the aim of this is? What is the current problem, what is the solution, and how can it be implemented? Fences&Windows 00:14, 9 January 2011 (UTC)
OK, I guess I understand the proposal (more or less)... Essentially, in each case you want to take several templates that perform similar functions and create a new template that would perform all those functions depending on parameters, right? That doesn't seem to be very difficult to do (for example, the new template might be made into some sort of adapter, more or less like in the Adapter pattern). But I am not sure if that is advantageous... For example, you say "[...] it unifies all key templates into one; greatly reducing confusion, [...]". But is it really so? I am afraid that users will use the wrong parameters more often than they are using the wrong templates... Also, in many cases the "unified" template is going to be more complex and harder to edit than each of the previously existing templates. Thus I doubt if the change will result in "pooling of editors' dedication"... So, may I advise you to list the benefits of such change in a little more detail before moving to another "Village Pump"..? --Martynas Patasius (talk) 23:38, 11 January 2011 (UTC)
The likeliness of a user making a mistake is actually much more slim than the current format. Because, if this method is used, the template will only function if a parameter is given. And since all the available parameters will not be displayed on all discussions pages (for instance, at RFD, only the parameters relating to RFD will be shown), the probability of someone accidentally placing a param like |CFD-MergeCatB1= at FFD is near 0. If no parameters are shown (or a non-existent parameter is entered), we could make it to display a nice big red error message.
Also, this template will not be any harder to edit than trying to edit these current separate template. It'll only be longer. Like the benefits of other templates, a unified template greatly improves ease of maintenance and protection; one has to edit one template to make a wide change (vandalism blocked by protection), rather than many.
Another minor advantage, which is not related to this proposal: Currently, all other wikis are trying their best to get separate venues (FFD, RFD, ect) like en.wiki, but they either don't have the resources (templates), nor do they are able to translate the contents there to use. And oddly, these template could actually function on other wikis. To overcome this, 4547 went into construction. So, in the near-future, these types of "key templates" will be on Commons. And it is this "unified template" that has to be there. This is just another future step, nothing to do with this proposal.
If you are interested, we could start working together on this "unified template", and see where it takes us...
--Rehman 11:59, 12 January 2011 (UTC)
Update: I will start working on Proposal 1x now, and will post links here once the template is ready... Rehman 01:31, 23 January 2011 (UTC)
This depend upon "Reasonably efficient interwiki tranclusion" Bug 9890. That is awaiting developer resource last time I looked (in fact the test-bed had been switched off, it is apparently back on now), so great to have this ready, but I suspect not particularly urgent. Rich Farmbrough, 18:06, 28th day of January in the year 2011 (UTC).

Discussions (VP Proposals)

I have moved the above proposal to this (proposals) Village Pump. I am still working on the template, and may take a lot more time. If no clear objections are shown within a week, I will move this to WP:VPRPP to avoid it dying out. Rehman 03:30, 31 January 2011 (UTC)

I saw this on the idea lab, but it's still not really clear to me how the benefits (which seem really minor) justify the (seemingly major) change in usage. I agree that it shouldn't be more difficult, but it will A) Require all existing tools that use these templates (Twinkle) to be fixed, and for people who don't use the tools B) require "regulars" to learn the new template and C) significantly lengthen the name of the parameters (in some cases by more than 4x, or adding named parameters where none previously existed). I think this could be better if it didn't rely so heavily on named parameters. It would probably be safe to assume that the first parameter is always the page being discussed. Most of the rest could be shortened by not having separate parameters for different processes and either using the NAMESPACE parser function to determine the namespace of the supplied page or, even better, BASEPAGENAME to determine the process page that the template is being used on. That will take care of problem C, and possibly make the templates easier in some cases. A and B could be mitigated by redirecting the current templates to the new one. Mr.Z-man 04:26, 31 January 2011 (UTC)

Proposals 1A.2 and 1C.2 are incorrect: The first template includes the section header, while subsequent templates must omit the header. This cannot be done just by checking for the presence of a "reason" parameter. As for the rest, I'm inclined to agree with Mr.Z-man in considering that the proliferation of named parameters is going to increase confusion and errors and make the template code itself far more complicated, increasing the chance of improvements breaking something. It seems like a solution in search of a problem to me. Anomie⚔ 04:49, 31 January 2011 (UTC)

I noticed that WP:SFD templates are missing from the table. Ruslik_Zero 14:09, 2 February 2011 (UTC)

SfD creates new complications - at times, a category and its stub tag(s) are nominated together for some action, and nominating each on a separate line will make the nomination harder to understand. עוד מישהו Od Mishehu 09:09, 3 February 2011 (UTC)

The Edittools are too far down the edit page

Why are the MediaWiki:Edittools placed where they are on the edit page? They would definitely be more useful sitting at-hand, directly below the edit box, rather than in and amongst the edit warnings. Anxietycello (talk) 18:40, 1 February 2011 (UTC)

Even though the edittools is somewhat redundant to the new toolbar, I agree it is too low. In fact the whole edit page could do with a cleanup/overhaul; it is simply too crowded down there. — Edokter (talk) — 01:50, 2 February 2011 (UTC)
I couldn't agree more. I would suggest that MediaWiki:Edittools be moved to sit just below the edit box, and the edit warnings that are (oddly) included in it, be merged into MediaWiki:Wikimedia-editpage-tos-summary, which should then be re-formatted (what's with the small font..?) into something a bit more welcoming and informative, something like:

  We happily welcome you to edit Wikipedia, however, please note:

  • Please post only encyclopedic information that can be verified by external sources. Please maintain a neutral, unbiased point of view.
  • All text that you did not write yourself, except brief excerpts, must be available under terms consistent with Wikipedia's Terms of Use before you submit it.
  • When you click Save, your changes will immediately become visible to everyone. If you wish to run a test, please edit the Sandbox instead.
  • If you do not want your writing to be edited, used, and redistributed at will, then do not submit it here.

Anxietycello (talk) 13:30, 2 February 2011 (UTC)

It would be really cool if the en.wiki edit interface could be made like that of Commons; notice the location of the EditTools? Rehman 13:34, 2 February 2011 (UTC)
Nice... Took me a few seconds to find though. — Edokter (talk) — 16:36, 2 February 2011 (UTC)
That is definitely much better that what we have over here. Why has that not been implemented here? Anxietycello (talk) 13:23, 3 February 2011 (UTC)

Stylize "save page" button?

It can be difficult sometimes to tell whether you're logged in or not when editing a page. Though there is an indication at the top of the page (the user links), that isn't always very apparent or even visible before you press "save page."

One neat, clean way to make it more obvious when you're logged in is to style the "save page" button (for example, making it green with white text when you're logged in). That way, it becomes much more apparent that you're logged out when the button isn't green and noticeable.

Could or should something like this be implemented here on the English Wikipedia? --MZMcBride (talk) 01:27, 28 January 2011 (UTC)

Could? No problem (requires some javascript though to detect if the user is logged in). Should? There is already a big notice above the edit box notifying users they are not logged in. — Edokter • Talk — 01:36, 28 January 2011 (UTC)
Yet another reason to favor Monobook (or any non-default skin for that matter) over Vector. ;P --Cybercobra (talk) 06:32, 28 January 2011 (UTC)
Last time I checked there's a huge notice if you're not logged in. I'd rather not stylize anything, as that's a slippery slope to hideous user design. —Noisalt (talk) 07:27, 28 January 2011 (UTC)
@MZMcBride; you could do it manually for yourself if you like. Just add a new line containing "#wpSave { background-color: #629909; color: #fff; border: 1px solid #4F8000; }" to Special:Mypage/vector.css. Will turn the save button green when you are logged in :) --Errant (chat!) 14:40, 28 January 2011 (UTC)
Script challenged: with the " marks or without? Thanks. Wordreader (talk) 18:08, 28 January 2011 (UTC)
While it's true that this can easily be accomplished with client-side javascript or personal styling, it's not a bad idea to do it site-wide. It doesn't have to be white-on-green; something subtler would probably do the trick. Or perhaps just change the text of the button to "Save page (anonymous contribution)" when not logged in. Relying on the big template when you're not logged in is, imho, not a good solution. Large blocks of text (read: more than 5 words in today's ADHD society) simply beg to be ignored. ...comments? ~BFizz 18:18, 28 January 2011 (UTC)
Without. --Cybercobra (talk) 21:39, 29 January 2011 (UTC)

Hmmmm. Why do I have a feeling of dėjà vu? Oh right. A similar discussion can be found in the Pump archives. There's a bit of CSS there to make the save button/editbox/etc green. Apparently it was liked by many people. Enjoy! ManishEarthTalk • Stalk 01:43, 29 January 2011 (UTC)

I like Cybercobra's idea, actually. Just changing the button to say "Save page (anonymously)" would be a reasonable, inoffensive solution. Who would be able to change this if we came to a consensus on it? —Noisalt (talk) 20:04, 1 February 2011 (UTC)
I think "anonymously" or "anonymous contribution" is misleading for new users, who presumably make up a large proportion of IP editors. Because it's not anonymous in the layperson's sense of the word - the system stores your IP address, and people can work out where that's registered to. Having an account is more anonymous, because other users can't see your IP address.--Physics is all gnomes (talk) 17:03, 4 February 2011 (UTC)

BOT CREATORS: Bot to fix erroneous placement of references

NOTE: This is NOT about "within" references. That's a whole different matter and is dealt with already.

Reference placement errors are amazingly common, and I suspect a bot could fix this common problem. (BTW, newbies aren't the only ones who make these errors. ) With two exceptions, the errors are these:

1. A reference should be placed IMMEDIATELY AFTER any punctuation or word, IOW, there should be NO SPACE BETWEEN the reference and the punctuation or word.

2. There should be no spacing between adjacent references.

Examples of what it looks like on a page
  • Correct: content and comma followed by two refs,[21][22]
  • Wrong: space after the comma and space between refs, [23] [24]
  • Wrong: comma after refs[25][26],
Examples of code used above
  • Correct: content and comma followed by two refs,<ref>Journal 1</ref><ref>Journal 2</ref>
  • Wrong: space after the comma and space between refs, <ref>Journal 1</ref> <ref>Journal 2</ref>
  • Wrong: comma after refs<ref>Journal 1</ref><ref>Journal 2</ref>,

What think ye? Is this doable? -- Brangifer (talk) 05:04, 31 January 2011 (UTC)

AFAIK the only reason this hasn't happened before - assuming there aren't (m)any odd cases where the punctuation is deliberately arranged - is because it's largely a pointless edit. Maybe it could be added to a bot making lots of edits already? - Jarry1250 [Who? Discuss.] 09:06, 31 January 2011 (UTC)
When did they change WP:REFPUNC from "use the existing style" to "after punctuation always"? I must have missed the discussion. Anomie⚔ 12:14, 31 January 2011 (UTC)
The debate took place on the main MOS talk page During the months of September/October last year see Wikipedia talk:Manual of Style/Archive 117#Punctuation and inline citations. I am against Bots making this change. I think consensus should be sought on the talk page of an article first first. -- PBS (talk) 12:39, 31 January 2011 (UTC)
It's got good consensus and is most likely to be an editing mistake rather than a style choice (really, who would choose to do that :P). But agreed, there seems no real need to bot update all instances. --Errant (chat!) 12:41, 31 January 2011 (UTC)
Yes, there's no dispute over this (very clear consensus in the MOS discussion) and no need to discuss it on the talk page of every article. If someone wants to make a bot to do this, I'd say go for it.--Kotniski (talk) 13:15, 31 January 2011 (UTC)
Ah, a discussion among the MOS denizens not advertised anywhere else. Situation normal for MOS then. Anomie⚔ 23:53, 31 January 2011 (UTC)
What I imagine a bot won't fix is common occurrences like these:
  1. someone deletes a statement they don't like, but leaves the ref, which thus attaches to the immediately preceding statement
  2. someone adds a statement between a statement abnd its ref, thereby hijacking the latter
  3. someone changes a statement they don't like, while leaving the ref in place
All of these lead to false citations, usually carelessness, not deliberate falsification. Peter jackson (talk) 11:59, 1 February 2011 (UTC)
I currently have 5,398 items on my watchlist, plus their talk pages, and I run into this constantly. I'm sure it's usually carelessness or just because people, especially newbies, aren't aware of the MoS. A bot could catch lots of these errors and that would lessen the load significantly for editors who correct whatever errors they find, which is part of what I do in between major editing. -- Brangifer (talk) 06:08, 4 February 2011 (UTC)
AWB fixes those in its General Fixes. Rich Farmbrough, 15:16, 4 February 2011 (UTC).

Proposal - Turn on RefTools gadget by default

Overwhelming consensus for implementation. Happy‑melon 23:40, 1 February 2011 (UTC)

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

The modified toolbar
An example of a template dialog

People ask me all the time why adding and editing references isn't easier on Wikipedia considering how much we emphasize it (and revert editors who don't do it). So I always tell them about the RefTools gadget and they're like, "Wow, that's awesome!". So considering how incredibly useful it is to performing a task that has become fundamental to editing Wikipedia, why don't we turn it on for everyone by default? It isn't obtrusive to editors who don't want to use it (since it's just a small dropdown in the editing interface) and it's really great for editors that do. The way this would be implemented technically is that refRools would be removed from MediaWiki:Gadgets-definition and added to MediaWiki:Common.js/edit.js instead. Kaldari (talk) 02:43, 7 January 2011 (UTC)

I'm not positive on this, but some gadgets can tax the servers in certain ways, or have other subtly undesirable side effects, such that it may be bad for Wikipedia, or for some users, to enact them "across the board". I have no idea if this is one of those, but it may be. --Jayron32 03:20, 7 January 2011 (UTC)
I can't see how this feature might put excessive load on the servers. There are indeed performance considerations with things like Popups, which have to get a lot of data from the servers, but RefTools pretty much just injects new HTML, with a couple of commons images; a drop in the ocean compared to normal server load. Happy‑melon 13:17, 7 January 2011 (UTC)
With the caveat others have expressed of "provided there are no major technical problems likely to be caused, I'm changing to "support". It's a fantastic (kudos is not a good enough word) tool and will increase the quality of our footnoting (it's already going to increase the quality of mine). I can see potential improvements to it, though (eg not have separate "pages" and "page" fields). If enough support comes together to implement it, there should be discussion with User:Mr.Z-man about timing and developing a launch version. --FormerIP (talk) 03:08, 8 January 2011 (UTC)
  • Unless there's some kind of technical issue, this will be fantastic. sonia♫ 03:43, 7 January 2011 (UTC)
  • I just spent some time playing around with the tool. My comment above notwithstanding, if there are no technical problems with this feature, I would completely and wholeheartedly support the addition of this to the standard editing box. It really rules. --Jayron32 04:03, 7 January 2011 (UTC)
  • Support. Easy to use. ---- CharlesGillingham (talk) 06:21, 7 January 2011 (UTC)
  • Support, iff there are no technical issues. The tool is a pretty cool thing. Wonder how possible is it to merge it into the default edit interface, and make it a global tool... Rehman 07:30, 7 January 2011 (UTC)
  • Support. I'm aware that there are issues about some cite templates affecting page load times, but I doubt that the editing tool would itself cause those problems. --Tryptofish (talk) 23:57, 7 January 2011 (UTC)
  • Oppose. Many styles of citation are acceptable in Wikipedia, and this tool only supports one of the styles. Editors are responsible to use the style that already exists in an article. Turning this tool on by default will give editors the impression that this is the official style and it is ok to barge into an article and change all the citations to the cite xxx style. Jc3s5h (talk) 00:52, 8 January 2011 (UTC)
    • That's a fair point, but I think there's also a case for saying it was going that way anyway. --FormerIP (talk) 01:25, 8 January 2011 (UTC)
      • Articles which are standardized to alternate citation styles are relatively rare these days on Wikipedia. I think the number of articles this change would positively affect (not to mention improving the newbie learning curve) would far outweigh the potential cost of correcting citation style in a handful of articles. Kaldari (talk) 01:34, 8 January 2011 (UTC)
        • This would be an improvement. The cite xxx templates have inherent advantages over all other forms of citation/footnotes, and their requirement by policy would greatly improve the references on the encyclopedia. - ʄɭoʏɗiaɲ τ ¢ 03:50, 20 January 2011 (UTC)
  • The only significant technical issue that I know of is that it doesn't work correctly in IE. It functions, but it just inserts the ref in some random place. I was hoping this might just fix itself in IE9, but it still seems to do it in the current IE9 beta. I haven't had time to investigate it, so I don't know how difficult this would be to fix. Some of the error checks are buggy, but that shouldn't be too difficult to fix. As for multiple citation styles, that should be no problem as it can be customized for use with almost any template, though it won't work well with the Harvard templates at the moment, and it doesn't support plain text references. I'm currently working on a version that can autofill citation details given an ISBN, PMID, or DOI. Its basically done, I just haven't had the time to finish it. Mr.Z-man 04:13, 8 January 2011 (UTC)
    • Actually, on IE9 at least, it seems to depend on compatibility mode settings. With one setting, it inserts it in (almost) the correct spot. I can't tell whether compatibility mode is on or off though since the interface is too vague (its the one where the squiggly rectangular thing is blue). Mr.Z-man 21:06, 8 January 2011 (UTC)
    • I personally use Wikicite most of the time to generate my citations, browser independent but Windows specific, (not tried it under Wine in Linux yet.) But this tends to illustrate my only problem with this proposal. It would seem to promote one tool at the exclusion of others. -- RoninBK T C 07:44, 9 January 2011 (UTC)
      • No one is saying you have to stop using Wikicite. Pretty much every function of WikiEditor is also available through other tools, but that doesn't negate their usefulness or the fact that having them all in one place without having to install a lot of separate tools is quite convenient. Kaldari (talk) 19:37, 10 January 2011 (UTC)
  • Support as a nudge towards good practice (full, semantically coded citations) MartinPoulter (talk) 20:34, 8 January 2011 (UTC)
Please don't anyone else call it a "nudge", or I'll puke and withdraw my support. --FormerIP (talk) 20:36, 8 January 2011 (UTC)
  • Support You are more likely to get good referencing if you make it easy. JJ Harrison (talk) 01:07, 9 January 2011 (UTC)
  • Support Seems like a great idea and it will hopefully help newcomers learn how to properly use citations. On a separate note, I tried to add the script to my monobook and then I reloaded my page (I have Google Chrome) like it told me to. However, it doesn't seem to have changed or added said toolbar to my editing page. What did I do wrong? SilverserenC 01:42, 9 January 2011 (UTC)
Think maybe in needs to go in User:Silver seren/vector.js. --FormerIP (talk) 01:47, 9 January 2011 (UTC)
Tried, but no, still doesn't work. :/ SilverserenC 01:50, 9 January 2011 (UTC)
Have you refreshed? Also have you installed the most up-to-date version Wikipedia:RefToolbar_2.0? --FormerIP (talk) 02:00, 9 January 2011 (UTC)
Yes, I have and i've been using the code for 2.0, yes. SilverserenC 02:11, 9 January 2011 (UTC)
I have no more advice left in my pockets, then, sorry. --FormerIP (talk) 02:13, 9 January 2011 (UTC)
It's alright. Hey, once this proposal is enacted, it should end up working anyways, so no worries. SilverserenC 02:20, 9 January 2011 (UTC)
You must use the Vector skin for it to work, methinks. Mono (talk) 04:20, 10 January 2011 (UTC)
  • <edit conflict>Support. Note that a discussion in Wikibooks regarding adding RefTools to the preferences resulted in no consensus, though, for the reason that Jc3s5h put forward. Kayau Voting IS evil HI AGAIN 02:15, 9 January 2011 (UTC)
  • Support - Good call. -      Hydroxonium (talk) 23:41, 9 January 2011 (UTC)
  • Support, if tweaked to make it more user-friendly. Mono (talk) 04:17, 10 January 2011 (UTC)
  • Support My personal experience is that the difficult of citing sources is one of the main reasons people say they don't edit wikipedia.--Banana (talk) 23:43, 12 January 2011 (UTC)
  • Support unless there is any technical reason hindering this. 03:28, 13 January 2011 (UTC)
  • Support fully. Why have this as an opt-in when its one of our most useful tools? ThemFromSpace 03:34, 13 January 2011 (UTC)
  • Support - using RefTools is a wonderful idea. Darth Sjones23 (talk - contributions) 04:45, 13 January 2011 (UTC)
  • 'Support I can see only advantages. Yoenit (talk) 11:45, 13 January 2011 (UTC)
  • Conditional Support. The issues with IE need to be worked out before this is made standard for everyone. I hate IE with a passion, but it is a widely used browser.--Danaman5 (talk) 15:53, 13 January 2011 (UTC)
    • Agreed. It shouldn't be too difficult to get this to work at least as well as the other WikiEditor components (for example, table insertion). I'll look into it further if Mr.Z-man doesn't get a chance to. Kaldari (talk) 18:39, 13 January 2011 (UTC)
  • Support I don't use it, but I've tried it and think it would be great for most new editors instead of trying to figure it out by themselves. Experienced editors can disable if they want. -Atmoz (talk) 17:31, 13 January 2011 (UTC)
  • Oppose Some people's computers are slow so pop up boxes makes it even slower. Maybe allow people to opt-in, not opt-out. Madrid 2020 (talk) 21:26, 13 January 2011 (UTC)
    • Using RefTools would be completely optional and collapsed by default. The only way it would ever show up is if you uncollapse the Cite toolbar and select one of the citation templates to insert. You would still be free to write citations manually in the WikiEditor if you like (if for example you had an extremely slow computer). Kaldari (talk) 21:37, 13 January 2011 (UTC)
  • Support any step toward better referencing (in this case, by making it simpler/easier) is a step in the right direction in my book. Andrew Lenahan - Starblind 00:41, 14 January 2011 (UTC)
  • Support unless there are technical problems with implementation (e.g., bugs for certain browsers, very slow load times, etc.). Guoguo12--Talk--  02:44, 14 January 2011 (UTC)
  • Support. I was seriously concerned when it disappeared a while ago - until I saw that I was not logged in.  Sandstein  07:10, 14 January 2011 (UTC)
  • Conditional oppose Maybe I'm missing something, since I don't use RefTools, but I think there are some issues here. As much as I support the desperately needed improvement of our editing interface, including easier references, hard-coding a particular solution to a problem that currently has many competing solutions may not the best strategy. There's a number of different tools for this purpose: WikiCite, ProveIt, RefTools, Universal Reference Formatter, RefLinks,etc. These are all good attempts and each have different uses,strengths and weaknesses. Is Reftools that much better than the rest? Has it been bug-tested more than the others and in all situations? Is it compatible with all browsers, other userscripts, slow bandwidth, etc. Is it supported by the most actively coders or being developed by someone? I think those questions need to be ironed out before putting it on everyone's editing page.Ocaasi (talk) 11:30, 14 January 2011 (UTC)
    • As the developer of the script, I may be slightly biased, but I can answer some of the questions.
      • Of the tools you listed, only Reftools and Proveit are integrated into the editing interface. Universal Reference Formatter and RefLinks are Toolserver tools. Reflinks only expands plain URLs into citations, its not really the same type of tool. URF seems to mainly support journal citations. WikiCite is a standalone program that only works on Windows and does not appear to be actively developed. Reftools is the only tool that I know of where the available citation templates are not hardcoded into the script itself. I designed it so that users can add templates in their personal JS pages with a minimal amount of JavaScript knowledge required.
      • Its been tested on every major browser. Its currently only semi-compatible with Internet Explorer; it works, but not ideally so. Other than that, there are a few minor bugs that should be easily fixable. It should be compatible with all user scripts and should be no slower than the rest of the new "enhanced toolbar," for people who can't use the enhanced toolbar, there is also a version for the old toolbar, though it isn't customizable.
    • I'm currently the sole developer for the "main" version of the script (though help is always appreciated!). The version for the old toolbar is maintained by User:Apoc2400. Mr.Z-man 16:11, 14 January 2011 (UTC)
      • I've used ProveIt a little bit, but not a lot. My impression is that it is pretty functional, but a bit intrusive. It actually puts a panel outside of the editing box that scrolls with you when you move. Perhaps someone else who has used it more can chime in with a better comparison between RefTools and ProveIt.--Danaman5 (talk) 16:54, 14 January 2011 (UTC)
      • I've used both a little bit, prove-it is more "powerful" with its support for readding references and automatic detection of references on a page, but its much more of an "add-on" whereas reftools is smoothly integrated with the user interface and simpler. Prove-IT is also a lot newer and probably less polished than reftools (for example proveit doesn't play nice with wikied, whereas afaik reftools does). Adding reftools as a default option makes sense and would help a little bit towards simplfying one of the most damaging examples of complexity on wikipedia with no real cost, technical users who dislike it can always disable the functionality, while it is easy to see it being potentially helpfull to editors (new or less new) who have not yet explored the gadget options and features. Ajbpearce (talk) 19:11, 14 January 2011 (UTC)
        • Thanks for the thoughtful response Apoc, and for working on RefTools. My concerns are that we: 1) make sure the code plays nice with other browsers, userscripts, and add-ons; 2) don't discourage ProveIt's development, since it's a great thing too; 3) get some help for you (Apoc) to bolster the features and deal with support issues; 4) check with the Usability team to make sure we're not duplicating or missing better integration opportunities; 5) run this through Village Pump technical, the Foundation tech team, the Tech-mailing list, and either the Wikipedia-list or the Foundation-list (misplaced there, but would get worthwhile attention). If those things can be put in place then I think this is a great idea. Ocaasi (talk) 00:53, 15 January 2011 (UTC)
  • Support — as long as the technical overload on the servers is not excessive. I think it is quite good now, but would also expect that the User Interface will be tweaked/improved in future releases. One very large problem in Wikipedia has been that, although verifiability and reliable source citations are required, it has been very user unfriendly for new editors to get over the learning curve where they regularly cite the claims they insert into articles. I think this is one more positive step in the emergent evolution of Wikipedia that will help in this regard. N2e (talk) 18:39, 14 January 2011 (UTC)
  • Oppose - Reftools clashes with Editools when running IE - see here - unless someone sorts this then this proposal would severely restrict the ability of anyone using IE from editing Wikipedia.Nigel Ish (talk) 19:15, 14 January 2011 (UTC)
    • Note that this isn't the issue with IE that I noted above. That discussion is from June 2009, which means its referring to the version for the old toolbar. I can confirm that the new toolbar version does not cause any problems with the edittools. Mr.Z-man 20:55, 14 January 2011 (UTC)
      • But the "enhanced" editing toolbar is only in Beta, which editors have to select. And it still doesn't seem to work properly for me - with the reftools gadget selected and the enhanced toolbar selected, I don't get the cite button and both the edittools and "enhanced" toolbar don't work consistantly - for example - they appear to work as I am typing here and now, but if I edit another page then they don't. The default should be the option that works for everyone, all the time, not an option that doesn't work for some people.Nigel Ish (talk) 10:41, 15 January 2011 (UTC)
        • The enhanced toolbar has been the default now for several months, it isn't considered a beta anymore. Without knowing more details, I can't say why it may not be working for you. Mr.Z-man 16:02, 15 January 2011 (UTC)
          • If the enhanced toolbar is the default - why is it in the beta section of the preferences page? In addition, has this proposal been implemented now?@ I ask this as I now sem to have no way to get rid of reftools - even when I un-select it in preferences, the cite buttons are still there and edittools doesn't work.Nigel Ish (talk) 17:13, 15 January 2011 (UTC)
            • It sounds like you may be having JavaScript caching issues. This would explain why turning the gadget on and off is not working consistently for you. Bug filed about the "Beta" status: https://bugzilla.wikimedia.org/show_bug.cgi?id=26750 Kaldari (talk) 21:47, 15 January 2011 (UTC)
              • The problem still persists on another computer, where edittools doesn't work and the reftools button does nothing - however, if the general opinion is like that expressed by User:Manishearth - i.e that people who use IE don't matter, then feel free to try and drive me away from Wikipedia.Nigel Ish (talk) 19:18, 21 January 2011 (UTC)
                • The issues with IE should be fixed now. The version for the new toolbar, but with dialogs disabled, was broken in IE. This version of the script used the same form as the one for the old toolbar (the newest one requires the dialogs to be enabled), which still broke edittools, but this should now be fixed on all versions. Mr.Z-man 06:58, 22 January 2011 (UTC)
  • Support - long overdue, makes life easier for almost everyone here. Of course it should be possible to turn it off for people that use other tools that may potentially clash, but it's too useful not to have it by default (I thought it was already this way!) --Cyclopiatalk 19:46, 14 January 2011 (UTC)
  • Support Absolutely. Considering that Wikipedia is based on reliable sources and references, a tool for creating them should be front and center—not just an option that is invisible to newer editors. First Light (talk) 02:58, 15 January 2011 (UTC)
  • Support Integration and continue to improve the editor. Would be nice to see diberri's tool combined into it.Doc James (talk · contribs · email) 05:12, 16 January 2011 (UTC)
Yes just noticed them. Well done. Will definately speed up my editing... Doc James (talk · contribs · email) 05:19, 16 January 2011 (UTC)
Will IE users need to reinstall? --FormerIP (talk) 01:27, 19 January 2011 (UTC)
Just clear your cache and you should get the new code. Kaldari (talk) 20:47, 19 January 2011 (UTC)
  • Support implementing Reftools asap. The new autofill option makes it the perfection companion for everyday editing (together with Zotero). Keep on the good work. One suggestion though: trim automatically white spaces before and after the ISBN. Zotero-like reference sharing within a Wikiproject or between wikipedias is the next step. --Alberto Fernandez Fernandez (talk) 09:33, 18 January 2011 (UTC)
  • Support I love refTools and can't imagine living without it. New editors will find it much easier to add references if this is available.--SPhilbrickT 01:06, 19 January 2011 (UTC)
  • Support. I've been using it for so long that I was recently shocked to realize that it was a gadget that new users had to enable. Lack of references is one of the biggest issues I see on Wikipedia today. Anything we can do to point new and inexperienced editors in the right direction is an enormous help in tackling this problem. Citing sources is one of our most basic values, but it's a ridiculously complicated and non-discoverable procedure without RefTools. Zachlipton (talk) 07:50, 19 January 2011 (UTC)
  • Support.--WS (talk) 12:49, 19 January 2011 (UTC)
  • Conditional Support. I use refTools, but with Firefox. If the IE problems have been fixed, go for it. It's especially good for newcomers, as they can just filling the blanks - only {{cite doi}} is easier, but this is only for academic articles. --Philcha (talk) 21:25, 19 January 2011 (UTC)
  • Cond'l Support I would install it for the chrome/fFox people (atleast as a beta gadget), and then finish up the IE testing. That might take care of most of the editing populace. Most people (no offense IE users) smart enough to edit Wikipedia are also smart enough to scrap IE. ManishEarthTalk • Stalk 18:06, 21 January 2011 (UTC)
  • Support - Yes yes yes! I just tried turning it on after being here 2 months and can't believe how much easier citing is now! Unless there are significant accessibility or technical problems, go for it.--Physics is all gnomes (talk) 14:03, 23 January 2011 (UTC)
  • Support - Its the first thing I show new users how to do when I help them set up accounts. I have found it invaluable as a WP:Campus Ambassador, Sadads (talk) 20:27, 23 January 2011 (UTC)
  • Hell yes provided there are no technical issues. I've always thought the number-one-most-ridiculous-thing about Wikipedia is that we are very strict about citations, and yet offer no straightfoward way of adding them at all (by default). This is an absolutely fantastic and logical idea, and in my opinion we need something to be implemented into the interface ASAP. I guess I'm just amazed that it's taken ten years before somebody raised the issue... --Dorsal Axe 22:16, 23 January 2011 (UTC)
  • Support I didn't realize it wasn't already on by default. Tim1357 talk 01:57, 24 January 2011 (UTC)
  • Support absolutely. It takes some time to write citations manually, this will help the whole community, new users and experienced editors. Polyamorph (talk) 12:11, 24 January 2011 (UTC)
  • Support Anons don't have vector.js's or Prefernces, this would be perfect. --Perseus, Son of Zeus ✉ sign here 20:54, 25 January 2011 (UTC)
By my count that is 37 Supports, and 3 opposes that seemed to have been worked out. Consensus anybody?AerobicFox (talk) 16:45, 24 January 2011 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Is there any reason to delay implementation?

Can someone switch this on now, please? --Anthonyhcole (talk) 14:13, 29 January 2011 (UTC)

Good luck, it'll probably just be archived like the rest. I don't see the point of this noticeboard anymore if everyone agrees to a proposal but noone is in the position to implement it. Supported or not, it just gets archived and forgotten about. -- Ϫ 05:17, 31 January 2011 (UTC)
Requested on (what I believe to be) the appropriate MediaWiki talk: page. --NYKevin @286, i.e. 05:52, 31 January 2011 (UTC)
Thanks for that. -- Ϫ 06:08, 31 January 2011 (UTC)
I was about to implement the request, but ran into some problems while trying to use it, and commented there. Please see if you can reproduce the issues I mentioned, and if so, implement a fix, before we activate it wiki-wide. --Waldir talk 00:09, 1 February 2011 (UTC)
Just one question though, per my vote above, will this change effect all wikis, or just en.wiki? And if just en.wiki, why not make it global? That way, we could really avoid making each wiki a totally different site. Rehman 06:21, 31 January 2011 (UTC)
Why on earth would you want that? --Yair rand (talk) 06:29, 31 January 2011 (UTC)
This is purely local. Other wikis need to get consensus on their own wikis. Titoxd(?!? - cool stuff) 06:30, 31 January 2011 (UTC)
Thanks, Titoxd. Was just wondering if this was a global change... Would be nice if it was though, but I agree we should gain consensus first. — Preceding unsigned comment added by Rehman (talk • contribs)
Am I misunderstanding what this tool does? I thought this was a tool to make using English Wikipedia reference templates easier. --Yair rand (talk) 06:46, 31 January 2011 (UTC)
You are correct. Other wikis are completely unaffected by this discussion at all. Titoxd(?!? - cool stuff) 07:00, 31 January 2011 (UTC)
Okay, so where does the discussion have to occur for the Tool to actually be turned on (added to the default availability for users)? Is this discussion necessary but not sufficient? N2e (talk) 03:35, 6 February 2011 (UTC)
Discussion regarding implementation is best done at Mediawiki talk:Common.js, where all sitewide javascript is discussed. Most of our scriptheads hang out there. — Edokter (talk) — 04:01, 6 February 2011 (UTC)
I'm waiting on the MediaWiki 1.17 deploy (which includes ResourceLoader) before turning this on for everyone. It was supposed to be deployed last week, but it's been delayed until this Wednesday. Kaldari (talk) 20:33, 14 February 2011 (UTC)
  1. ^ • Laurence R. Iannaccone, 1998. "Introduction to the Economics of Religion," Journal of Economic Literature, 36(3), pp. 1465–1495.
       • _____, 2006. "Economy," in Handbook of Religion and Social Institutions, Ch. 2, pp. 21-38.
       • _____ and Eli Berman, 2008. "religion, economics of," The New Palgrave Dictionary of Economics, 2nd Edition, v. 7, pp. 82-90. Abstract and Table of Contents.
  2. ^ • Corry Azzi and Ronald Ehrenberg, 1975. "Household Allocation of Time and Church Attendance," Journal of Political Economy, 83(1), p p. 27-56.
       • Steve Bruce, 1999. Choice and Religion: A Critique of Rational Choice Theory, Oxford. Description and chapter-preview links.
       • Andrew Clark and Orsolya Lelkes, 2003. "Deliver us from Evil: Religion as Insurance,", Papers on Economics of Religion. Abstract.
       • Peter Hedström and Charlotta Stern, 2008. "rational choice and sociology," The New Palgrave Dictionary of Economics, 2nd Edition. Abstract.
       • Laurence R. Iannaccone, 1995. "Voodoo Economics? Reviewing the Rational Choice Approach to Religion," Journal for the Scientific Study of Religion," 34(1), p p. 76-88. Pre-publication copy.
       • Lawrence A. Young, 1997.     Rational Choice Theory and Religion. Routledge. Description, chapter- preview links, pp. v-vi. and 2-page review.
  3. ^ • Brooks B. Hull and Frederick Bold, 1989. "Towards an Economic Theory of the Church," International Journal of Social Economics 16(7), pp. 5-15.Abstract.
       • Robert B. Ekelund, Jr. et al., 1996. Sacred Trust: The Medieval Church as an Economic Firm. Oxford. Description and chapter-preview links.
       • Roger Finke and Rodney Stark, 2005. The Churching of America, 1776-2005: Winners and Losers in our Religious Economy, 2nd ed. Description and chapter-preview links.
  4. ^ • Laurence R. Iannoccone, 1992. "Religious Markets and the Economics of Religion," Social Compass, 39(1), p p. 123-31.
       • Jonathan H. Gruber, 2005. "Religious Market Structure, Religious Participation, and Outcomes: Is Religion Good for You?" Advances in Economic Analysis & Policy, 5(1), Article 5.Abstract.
       • Linda J. Waite and Evelyn L. Lehrer, 2003."The Benefits from Marriage and Religion in the United States: A Comparative Analysis," Population and Development Review, 29(2), pp. 255–276.
       • Robert B. Ekelund, Jr., Robert F. Hébert, Robert D. Tollison, 2006. The Marketplace of Christianity, MIT Press, Description and chapter-preview links, p. v.
       • Harold G. Koenig, Michael E. McCullough, and David B. Larson, 2000. Handbook of Religion and Health, Oxford. Description and scroll to chapter-preview links.
  5. ^ • Pablo Brañas-Garza and Teresa García-Muñoz, 2001."The Big Carrot: High Stake Incentives Revisited," Papers on Economics of Religion.
       • Edward Glaeser and Spencer Glendon, 1998. “Incentives, Predestination and Free Will,” Economic Inquiry, 36(3), pp. 429-43. Abstract.
       • Holley Ulbrich and Myles Wallace, 1983. "Church Attendance, Age, and Belief in the Afterlife: Some Additional Evidence," Atlantic Economic Journal, 11(2) p p. 44-51. Abstract
       • Timur Kuran, 2004. Islam and Mammon: The Economic Predicaments of Islamism. Princeton. Description and Chapter 1, "The Economic Impact of Islamism" link.
  6. ^ • Laurence R. Iannaccone, 1998. "Introduction to the Economics of Religion," Journal of Economic Literature, 36(3), pp. 1465–1495.
       • _____, 2006. "Economy," in Handbook of Religion and Social Institutions, Ch. 2, pp. 21-38.
       • _____ and Eli Berman, 2008. "religion, economics of," The New Palgrave Dictionary of Economics, 2nd Edition, v. 7, pp. 82-90. Abstract and Table of Contents.
  7. ^ • Corry Azzi and Ronald Ehrenberg, 1975. "Household Allocation of Time and Church Attendance," Journal of Political Economy, 83(1), p p. 27-56.
       • Steve Bruce, 1999. Choice and Religion: A Critique of Rational Choice Theory, Oxford. Description and chapter-preview links.
       • Andrew Clark and Orsolya Lelkes, 2003. "Deliver us from Evil: Religion as Insurance,", Papers on Economics of Religion. Abstract.
       • Peter Hedström and Charlotta Stern, 2008. "rational choice and sociology," The New Palgrave Dictionary of Economics, 2nd Edition. Abstract.
       • Laurence R. Iannaccone, 1995. "Voodoo Economics? Reviewing the Rational Choice Approach to Religion," Journal for the Scientific Study of Religion," 34(1), p p. 76-88. Pre-publication copy.
       • Lawrence A. Young, 1997.     Rational Choice Theory and Religion. Routledge. Description, chapter- preview links, pp. v-vi. and 2-page review.
  8. ^ • Brooks B. Hull and Frederick Bold, 1989. "Towards an Economic Theory of the Church," International Journal of Social Economics 16(7), pp. 5-15.Abstract.
       • Robert B. Ekelund, Jr. et al., 1996. Sacred Trust: The Medieval Church as an Economic Firm. Oxford. Description and chapter-preview links.
       • Roger Finke and Rodney Stark, 2005. The Churching of America, 1776-2005: Winners and Losers in our Religious Economy, 2nd ed. Description and chapter-preview links.
  9. ^ • Laurence R. Iannoccone, 1992. "Religious Markets and the Economics of Religion," Social Compass, 39(1), p p. 123-31.
       • Jonathan H. Gruber, 2005. "Religious Market Structure, Religious Participation, and Outcomes: Is Religion Good for You?" Advances in Economic Analysis & Policy, 5(1), Article 5.Abstract.
       • Linda J. Waite and Evelyn L. Lehrer, 2003."The Benefits from Marriage and Religion in the United States: A Comparative Analysis," Population and Development Review, 29(2), pp. 255–276.
       • Robert B. Ekelund, Jr., Robert F. Hébert, Robert D. Tollison, 2006. The Marketplace of Christianity, MIT Press, Description and chapter-preview links, p. v.
       • Harold G. Koenig, Michael E. McCullough, and David B. Larson, 2000. Handbook of Religion and Health, Oxford. Description and scroll to chapter-preview links.
  10. ^ • Pablo Brañas-Garza and Teresa García-Muñoz, 2001."The Big Carrot: High Stake Incentives Revisited," Papers on Economics of Religion.
       • Edward Glaeser and Spencer Glendon, 1998. “Incentives, Predestination and Free Will,” Economic Inquiry, 36(3), pp. 429-43. Abstract.
       • Holley Ulbrich and Myles Wallace, 1983. "Church Attendance, Age, and Belief in the Afterlife: Some Additional Evidence," Atlantic Economic Journal, 11(2) p p. 44-51. Abstract
       • Timur Kuran, 2004. Islam and Mammon: The Economic Predicaments of Islamism. Princeton. Description and Chapter 1, "The Economic Impact of Islamism" link.
  11. ^ X
  12. ^ X
  13. ^ X
  14. ^ X
  15. ^ X
  16. ^ X
  17. ^ X
  18. ^ X
  19. ^ X
  20. ^ X
  21. ^ Journal 1
  22. ^ Journal 2
  23. ^ Journal 1
  24. ^ Journal 2
  25. ^ Journal 1
  26. ^ Journal 2
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_68&oldid=1145855259"