Jump to content

Wikipedia:Village pump (proposals)/Archive 67

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, 215

Proposal to close the Working Group Wikipedia

Since this wiki is relevant only to the English Wikipedia project, I have decided to place the proposal here instead of meta, where they would normally decide whether to close down Wikimedia wikis. This is not a real encyclopedia even though it is registered under the .wikipedia.org domain name. It is an entire wiki dedicated to a single issue on the English Wikipedia. I do not believe that we should have wikis opened for every incident on any Wikimedia wikis; we would not have to open some new domain called http://wg.ur.wikipedia.org for example. And anyway, according to this wikiproject and its associated report from 2008 this wiki should have been closed as the disputes for the wikiproject have been resolved. :| TelCoNaSpVe :| 05:29, 22 November 2010 (UTC)

It is de facto closed. I think the sitenotice that appears when you try to view any page illustrates that. Killiondude (talk) 06:36, 26 November 2010 (UTC)

Collapsible {{Infobox musician awards}}

Hi, the template {{Infobox musician awards}} is extremely long and very difficult to navigate as it constricts all the tables present beside it. Hence I was proposing to have the awards portion of the template as collapsible, so that it would not constrict the tables. Also it looks more professional. An example of such a manually coded collapsible template can be found at List of accolades received by Precious. I am not very good with coding in HTML hence don't know how to change the template to reflect the collapsible thing. The linked article uses this code.

{{!}} colspan=3 {{!}}<br> {{{!}} class="collapsible collapsed" width=100%<br>  ! colspan=3 style="background-color: #D9E8FF; text-align: center;" {{!}} Awards and nominations<br> {{!}}-<br> What say everyone? — Legolas (talk2me) 09:56, 22 November 2010 (UTC)

That infobox uses a nested, collapsible table. The best way to address is to discuss this on the template's talk page (Template talk:Infobox musician awards). — Edokter • Talk • 13:17, 22 November 2010 (UTC)

Alternate accounts from Contributions page

Simple suggestion: link alternate accounts (WP:SOCK#LEGIT) from a user's Contributions page. This would require a simple software change (unless somebody has a clever way to do it without that), with an additional entry in Preferences for alternate accounts, and then a link to the other account(s) being given at the top of the page. We already have templates for the user page, but this would be clearer and harder to miss, and more convenient. Rd232 talk 13:36, 25 November 2010 (UTC)

Right spot for this? Is there a way we can make auto-confirmed or some other criteria of user, to allow said user to link to black listed links? It is a ridiculous when I can't show a link in a GAC to a website, because other users, use it for spam. CTJF83 chat 02:32, 23 November 2010 (UTC)

It is technically possible for a user group to have a right which makes them exempt from the spam blacklist. I don't know if the right exists yet, but even I know how to make one for this. And that's saying something :P Ajraddatz (Talk) 03:45, 23 November 2010 (UTC)
Is this the right place then to implement such a user right? CTJF83 chat 03:50, 23 November 2010 (UTC)
Looking at the user rights proposal at the top, I'd say so. However, since this would involve developing a new right, it might be better in the technical section. I don't know, though. Ajraddatz (Talk) 03:56, 23 November 2010 (UTC)
No. A quick look at WT:WPSPAM reveals several spammers who have spammed Wikipedia for more than a year. MER-C 02:02, 26 November 2010 (UTC)
And how many of those were users, let alone autoconfirmed? The right could be added to the reviewers group, which adds some significant control to it, and stops it from being a barrier to experienced editors. Ajraddatz (Talk) 23:53, 26 November 2010 (UTC)

Editnotice bot

Problem: We have a system of editnotices which is currently basically only maintainable by admins. We can expand this in a way that remains safe (the core problem is that editnotice vandalism would be particularly hard to detect and fix for most editors.) Proposal: create a bot which maintains editnotices on the basis of templates added to the article talk page. Category:Editnotice templates would be expanded, and a standard editnotice template added by the bot into the editnotice if it finds an appropriate template request on the talk page. For example, if it finds {{British English}} on the talk page it adds {{British-English-editnotice}} to the page's editnotice. It would operate from a fully protected list of templates, translating the talkpage request templates into editnotice templates (which would themselves be fully protected).

As a slight variation, it would also be possible to do the same thing based on categories within the article, rather than templates on the talk page; this would work in exactly the same way, with a protected list of categories to be translated to editnotices. I'm not quite sure if this is better, it's perhaps marginally more intuitive(?) and perhaps likely to be implemented more widely (perhaps over-used?), but the template method would ensure a note on the talk page as well if appropriate, which may be useful.

Why? Because it'll make it much easier to use editnotices much more widely, eg to advertise Arbcom restrictions at the edit stage exactly where it's needed, to pick one example. In terms of possible overuse, because it's controlled by a bot and a central list, it should be relatively manageable to keep track of and ensure it's only used where necessary (eg, the bot could only apply the editnotice template if the request applies to a page within a certain category). Comments? Rd232 talk 02:15, 26 November 2010 (UTC)

I am undecided whether I support the idea or not, but User:AnomieBOT II already has tboverride so it can do the job if the community supports the idea. One thing to consider is the possibility of editors warring over e.g. whether {{British English}} belongs on the article or not. Anomie⚔ 02:47, 26 November 2010 (UTC)
Fair enough on the possibility of warring - but we have that already, and the bot can have speed limits built in (so not constantly adding/removing editnotices) or even detect edit warring over the talk page templates and ignore til there's some stability. Rd232 talk 02:59, 26 November 2010 (UTC)
If you are going to note the language variation, we might as well get the rest of the article style options. ---— Gadget850 (Ed) talk 15:17, 26 November 2010 (UTC)
That was just an example. The proposal is for the system; it's good to know what the content might be (and I agree other style options could be included; it would probably need a custom template with different style parameter options to squeeze them in reasonably neatly), but it's totally open-ended about how the community uses it. Rd232 talk 15:57, 26 November 2010 (UTC)
I agree that this sort of style issue is probably more widespread (usually by misinformation rather than malice) than many others and wouldn't object to a system like this. It might serve to make edit notices somewhat more (safely) useful as well, which is always nice. Ale_Jrbtalk 15:25, 26 November 2010 (UTC)
I think editnotices like {{British-English-editnotice}} should be used only when there is demonstrable cause, as editnotices can have a small destabilizing effect on editors. If there are requests for bots to edit editnotices, I think they should be considered on a case by case basis through BRFA. For what it's worth, we may have per-category editnotices at some point in the (distant) future, which could provide better solutions to such issues. Cenarium (talk) 01:32, 27 November 2010 (UTC)
I've just voted for those bugs - that would be good to have. But the pace of development is slow enough that it might be worth doing this anyway. If we have concerns about specific editnotices we can either leave them off the central bot list completely, or require a clear consensus for the relevant template or category to be added. Rd232 talk 01:44, 27 November 2010 (UTC)

Creation of Special:SuffixIndex

I think that an additional special page to complement Special:PrefixIndex would greatly help users in searching for certain pages with certain suffixes; see this discussion for more information. (Sorry if there was a discussion before about it that I did not see; if anybody finds one, please link it here so that I know better the next time. Thanks.) :| TelCoNaSpVe :| 01:45, 21 November 2010 (UTC)

If you want to find articles whose titles end in ville, you can enter *ville in the search box and click on the Search button. [1]
—Wavelength (talk) 02:21, 21 November 2010 (UTC)
Ah, but Special:Search/*/FAQ does not give any FAQ subpages. :| TelCoNaSpVe :| 05:54, 23 November 2010 (UTC)
This is a long standing bug btw - bugzilla:10808. Basically its inefficient in the current db schema (currently pages are stored in alphabetical sorted order, so you can hop right to the first page that starts with some prefix, but to hop to the first page that ends in some prefix, you have to look at the title of every page, and there is a lot of pages). It could be made to be efficient, but (from what I understand) there is not enough interest for it to be deemed worth the effort currently. Bawolff (talk) 04:52, 28 November 2010 (UTC)

Annual CSB Improvement Drive

Proposal: every January, for the whole month, organise a prominent Wikipedia:WikiProject Countering systemic bias Improvement Drive. By "prominent", I mean prominent, with a watchlist notice, WP:SIGNPOST coverage, and coordinated outreach to non-English Wikipedias. A key part of the Drive would be a landing page where editors can find out more about the issues, and investigate what aspect of CSB improvement they might be interested in. I imagine that a part of this might be a sort of Wizard or Guide, as a way for example to suggest to people interested in Baseball what aspects of Baseball are systemically neglected, i.e. with a listing of underserved baseball topics outside the US. Besides which, it would be part of the Drive itself, especially in the first year, to construct such a Wizard/Guide; I'd expect individual WikiProjects to play a particular role here in kicking things off. Basically, the core points of the proposal are (i) try to harness people's existing interests in a way they might like but haven't thought of; (ii) improve understanding of the nature of the CSB coverage issues (iii) generally raise the profile of CSB issues. Rd232 talk 11:42, 24 November 2010 (UTC)

Yes, let's do it! Probably essential to create a to-do list during December to make this happen, as well as breaking down the task in meaningful ways: geographical bias (make A, B, C, D... articles reflect a worldwide view), underrepresented groups on Wikipedia list, etc.--Carwil (talk) 14:22, 27 November 2010 (UTC)

Newcomers' help page

I'd like to propose that we link Wikipedia:New contributors' help page a lot more from places that might rather increase the number of newcomers finding somewhere helpful and friendly to go. I'm looking at MediaWiki:Anoneditwarning, perhaps also MediaWiki:Semiprotectedpagewarning and MediaWiki:Protectedpagewarning. I'd also like it to be linked from an editnotice seen by new accounts who are not yet auto-confirmed, but I'm not sure there's any way of targeting them. The proposal is associated with my proposed redesign of that page (Wikipedia_talk:New_contributors'_help_page#Redesign), which will make it a friendlier landing page and better able to cope with an increase in traffic. Pre-emptive counter to one inevitable objection: if it generates too much traffic and overwhelms the page and we can't figure out a way to handle it, we can get rid of the links again. I feel the more we have issues with declining editorship, and the larger and more complex Wikipedia gets, the more effort we need to put into easing newcomers into becoming Wikipedians, rather than remaining readers or just dipping a toe in and finding it too hard. Linking this help page more prominently would help a little, but I'd love to hear any other ideas. Rd232 talk 22:15, 24 November 2010 (UTC)

Do it. Fences&Windows 22:25, 25 November 2010 (UTC)
Thanks. I'd welcome some help with the redesign, incidentally - I'm happy with the basic approach but I can't quite get the layout to look right. Wikipedia:New contributors' help page/header-redesign. Why don't the boxes line up? :( Rd232 talk 22:49, 25 November 2010 (UTC)
There used to be a link to the new contributors' help page on Help:Contents; but since the redesign of that page, one has to click through "Ask a question" down near the bottom to get to a page with a not-very-prominent link. That may be one reason why people clicking on the "Help" link on the left side of a WP page are failing to find the NCHP. Deor (talk) 22:46, 27 November 2010 (UTC)

Is an article on the gender of objects, animals and countries possible?

Hello you all the English speaking wikipedians in the world. Please excuse my approximative English, I'm a froggy. Some months ago, I asked a question on the Reference Desk (languages) about the gender of non humans things in English. I was thinking particularly about ships and boats etc.. I got many interesting answers such : a ship is "she", a boat is "it" with the joke "How to recognise one from the other? Answer: You can put a boat on board a ship".

I learnt that most means of transportation are "she" except trains (without knowing why, he said). But what about motobikes? About bicycles?

Please notice that it would help EVERYBODY whishing to improve his/her English and that even my wife, an English teacher (fairly good at English) doesn't know everything about that. Her grammar books, for example are not comprehensive on this subject.

For example this page: http://en.wikipedia.org/wiki/Gender_in_English#Modern_English doesn't speak about trains, bicycles, mountain-bikes, etc...

One of the answers, consideriging that these kinds of questions are frequent on that Desk proposed that it would be a good thing to write an article on that subject.

All that introduction to ask you if you could creat an article on this subject or, more simple, enhance the one I quote above.

Thank you very much for everything you do. Jojodesbatignoles-Rheims-France---90.18.67.249 (talk) 13:33, 27 November 2010 (UTC)

I wonder if there is a misunderstanding of the whole idea of gender here. Nouns do not have gender in English in the same way as in other languages...we really do have neuter definite articles ("the" rather than just French "le" vs "la"). It's not that "ship" is a female noun, but that a specific ship is usually considered as a female object. And very few objects are treated as any gender at all (almost everything is just "it"). It would be interesting to find the origin of ships being "she". DMacks (talk) 20:36, 30 November 2010 (UTC)
Ships have been referred to as "she" since at least the time of the Phoenicians, because it was the custom to dedicate a ship to a goddess, under whose protection she sailed. (Brasch, R (1969). How Did it Begin?) Jojodesbatignoles-Rheims-France may be on to something, perhaps there is a need for an article to explain why some objects are often considered to be female. Malleus Fatuorum 21:14, 30 November 2010 (UTC)
I support an article called Grammatical gender in English and I have pre-emptively added it to my watchlist.
—Wavelength (talk) 22:08, 30 November 2010 (UTC)
There is already Gender in English which seems to cover this topic adequately; I've redirected the suggested title there. It could use expansion. Dcoetzee 01:43, 1 December 2010 (UTC)

Suggestion

For example:

War is now/current continue. is available in a Wikipedia text

Please not use the now and current words. you must warning the all members on this issue. Now and current words is remove.

Becuase;

For example:

War is now/current continue text with now or current word is write at 1 September 2009 I am see the this text at 1 June 2010.

maybe the war ended on 1 June 2010. I am think war is still continue.

Please warning the robot and members which correcting errors. They/We are remove this words. They/We are change with a more appropriate sentence and the words

88.235.131.60 (talk) 14:45, 27 November 2010 (UTC)

Use of "current" depends on context. If there is a use of the word "now" or "current" that is no longer current, an editor would simply have to change it. Wikipedia changes. It's impossible to say that certain words cannot be used on this site, especially without any real context. Is there a specific article you think needs to be changed? Ian.thomson (talk) 14:52, 27 November 2010 (UTC)
{{As of}} addresses this. Fences&Windows 23:39, 27 November 2010 (UTC)
See also Wikipedia:Manual of Style#Precise language. PrimeHunter (talk) 05:18, 28 November 2010 (UTC)
{{when}} --Cybercobra (talk) 02:43, 29 November 2010 (UTC)

Article on Jimmy Wales (Internet Meme)

Hey Guys, its been a while

Would it be appropriate yet to write an article on the new internet meme revolving around Wikipedia founder Jimmy Wales? Several notable media sources have covered the rise of this meme and I am not sure if it fufills general notability guidelines for inclusion. Thanks.  Marlith (Talk)  17:57, 27 November 2010 (UTC)

I'd start with a small and balanced look at Wikipedia's fundraising efforts within Wikipedia, avoiding the recentism and naval-gazing of focussing on the furore around Jimmy's face staring out at us. Fences&Windows 23:04, 27 November 2010 (UTC)
Alright, thanks. I just felt that the significant attention that it has garnered might be worth a general summary. Either that or the new meme can be part of the currently existing articles regarding Wikipedia's fundraising.  Marlith (Talk)  01:23, 30 November 2010 (UTC)
A good secondary source is [2]. Note however that KnowYourMeme wiki is not licensed compatibly, so you can't copy it directly. Dcoetzee 01:26, 1 December 2010 (UTC)
Try adding material to History of Wikipedia#Fundraising. Fences&Windows 01:36, 1 December 2010 (UTC)

Censored mode and Uncensored mode

Here's an idea: There should be a mode select for articles with cussing, sex references, gore, e.t.c., that censores and uncensores all these things. 82.13.79.52 (talk) 07:57, 24 November 2010 (UTC)

Please see Wikipedia:Wikipedia CD Selection for that sort of thing. Doing it in Wikipedia itself has been suggested a number of times and is very heavily opposed. However if you want to write an add-on for some browsers to do various types of commonly desired censorships please do, I think it would help Wikipedia reach more people who currently avoid it. Various other types of censorship you might like to consider are - evolution for creationists, liberalism climate change, abortion and Obama for republicans, Xenu for scientologists, guns and violence for liberals, you could even redirect selected articles like 9/11 to a different site that more conformed to their beliefs for taliban readers. Provided it was obvious to the readers that wikipedia was no longer being accessed I think this would help in bringing Wikipedia to people and showing them what they are missing. Dmcq (talk) 10:43, 24 November 2010 (UTC)
The made-for-schools version of Wikipedia is probably the best option at this point in time. Killiondude (talk) 06:32, 26 November 2010 (UTC)
Probably not, as it's made for schools, and I'm no good at programming. Are there any add-ons for censorships around that I could use? 82.13.79.52 (talk) 16:56, 29 November 2010 (UTC)
Probably not. Killiondude (talk) 17:12, 29 November 2010 (UTC)
ME: :( That's too bad. I don't like sex refrences, gore, cussing, e.t.c.
Voice: GIGANTIC PUSSY!
ME: No, I am not a...
Voice: GIGANTIC PUSSY!
ME: Stop it!

82.13.79.52 (talk) 08:47, 1 December 2010 (UTC)

Special:Undelete and Special:RevisionDelete

Currently, DeleteRevision merely marks the contents of deleted revisions as unavailable, and admins may noticed such that revisions do not show up under Special:Undelete. In order to delete a revision the "normal" way, an admin still has to delete the entire page and then restore the revisions that they want to keep. It would be nice if DeleteRevision had an actual "delete" function. --Ixfd64 (talk) 23:05, 28 November 2010 (UTC)

There's no real reason to use the old way of deleting a revision. Special:RevisionDelete should be considered the "normal" way now. Mr.Z-man 23:29, 28 November 2010 (UTC)
As in Special:RevisionUndelete? :| TelCoNaSpVe :| 23:57, 28 November 2010 (UTC)
I find that the old method (delete&restore) is "cheating" the average person looking at the history. I think the only time it should be done is in cases of history merges. עוד מישהו Od Mishehu 09:47, 1 December 2010 (UTC)
Per ZMan, there should be no reason to use the previous method. Also, TelCo, I don't think that you really understand the RevDel interface... Revisions are restored the same way they are deleted. Ajraddatz (Talk) 19:18, 1 December 2010 (UTC)

Proposal to add something to default Vector Skin

Please check out this page, look in the bottom left of the screen, and scroll down to see my proposal in full effect. I made this myself and I think a modified version of it would be a usefull, cool and maybe even necassary tool, especially for those with slow scrolling like me. It would help with long articles if you randomly or purposely decide to search another article. A Word Of Advice From A Beast: Don't Be Silly, Wrap Your Willy! 03:37, 28 November 2010 (UTC)

I'm afraid it doesn't play along with the expandable toolbox, and probably not with interwiki links either. That's the standard problem with absolute positioning, and it's not likely to be fixable. If the entire sidebar were done that way it would work, but then you couldn't have more than one screen height worth of sidebar links without serious problems. Note that there is already an accesskey assigned to the search box, so you can hit alt-shift-f (on Firefox; other browsers may differ slightly) to set input focus on the search box from anywhere that displays it. — Gavia immer (talk) 03:56, 28 November 2010 (UTC)
Indeed, it's painfully easy to bring focus to the search box as it is; on my machine (Mac 10.6, Safari 5.03), all I have to do is hit tab to get to the search box. (which is to say nothing of how badly that would interact with a long list of interwiki links) EVula // talk // ☯ // 20:07, 30 November 2010 (UTC)
But for those who do not know what you are talking about and are too lazy to scroll up to the top and find out, like me, it would make it easier to us lazy people to have a search box scroll down with the page so we can just move our cursor to [Insert Searchbox Postition Here] and find out. Not to mention, it would be a cool/convenient addition to the Vector Skin regardless of how you already navigate to your searchbox. And how the hell would it interfere with interwiki links???A Word Of Advice From A Beast: Don't Be Silly, Wrap Your Willy! 23:53, 3 December 2010 (UTC)
And can someone tell me how to make it go behind article text, because right now it covers it up. I am asking this because I will be using this template on my User/Talk pages, and maybe my sub pages. Respond here, not on this page, please. A Word Of Advice From A Beast: Don't Be Silly, Wrap Your Willy! 00:25, 4 December 2010 (UTC)

Change to template:reflist fontsize wiki-wide?

It seems like {{reflist}} is used on most new articles. Historically, when the template was developed we left <references/> on the articles that already had it. Should we have a bot go through and convert the remaining uses of <references/> to use the reflist template instead? The advantage would be uniform styling, since the template gives a slightly different appearance (a smaller font) than the <references/> tag does. The disadvantage would be that we would be changing the established style on the pages that use <references/>. — Carl (CBM · talk) 20:28, 29 November 2010 (UTC)

Note: the proposal has changed during discussion to editing the CSS to make <references> format like {{reflist}}. — Carl (CBM · talk) 03:16, 30 November 2010 (UTC)
If we want to apply the styling of {{reflist}} in all articles, wouldn't it be easier to change the CSS than the articles? Algebraist 20:31, 29 November 2010 (UTC)
If that's possible then we should (a) do that and (b) declare that replacing references/ with reflist should be done only if an additional option available in reflist is used. It's not helpful to make that many bot edits for a minor formatting change, or (if the CSS is updated) no formatting change at all. Rd232 talk 20:42, 29 November 2010 (UTC)
Yes, should be possible to style all cite.php references by modifying the style for ol.references in Mediawiki:Common.css. This would affect articles that use either <references> or {{reflist}}. However, it has to be synchronized with the styling of div.references-small so that articles with {{reflist}} don't have the font size reduced twice. I agree with the minor edit issue if the styling was already the same; presumably it could be made a minor fix in AWB or something. But at the moment the style isn't the same, which is why I want to assess whether the consenus favors a uniform style or favors preserving the existing style for pages that use <references/> — Carl (CBM · talk) 20:46, 29 November 2010 (UTC)
Let's do the CSS change then, and make the style uniform (standardising on the reflist style). That way, as I said, a switch from references/ to reflist is only needed if a reflist option is actually used. Reflist, after all, is just a wrapper for references/, so there's no need to use it unnecessarily, is there? Rd232 talk 22:13, 29 November 2010 (UTC)
The only option for which reflist remains are columns, which is used a lot. Synchronizing is easy enough simply by editing common.css. I would support moving the CSS font-size to ol.references. The only problem I foresee is people who have custom declarations in their skin CSS; they would see a cumulative decrease in their font size, unless we removed .references-small from the template, as that classname has no meaning anymore. — Edokter • Talk • 22:24, 29 November 2010 (UTC)
The risk in removing it is that if people have a cached version of the css file, and we remove the div from the template, they may not get any font reduction until they get a fresh version of the css file. So it may be safer to leave the references-small for a little while (longer than the default cache delay). — Carl (CBM · talk) 22:49, 29 November 2010 (UTC)
Sounds like a good idea all around, I support it. However, I do note that some people prefer notes to be bigger than references. This is a very minority use, and could easily be handled on a case-by-case basis by something like {{reflist|text-size=regular}}, or similar. Headbomb {talk / contribs / physics / books} 23:09, 29 November 2010 (UTC)
Ugh, no. If we want to be consistent, this is not a good idea. — Edokter • Talk • 23:20, 29 November 2010 (UTC)
Yeah, I agree. I don't really feel like leaving a visual design issue like that to article-local consensus is beneficial. —chaos5023 (talk) 23:24, 29 November 2010 (UTC)
Then we remove the div classname 30 days after we change common.css. — Edokter • Talk • 23:18, 29 November 2010 (UTC)
That seems like the best way to do it. — Carl (CBM · talk) 23:27, 29 November 2010 (UTC)
This is not about the font size of the references. Its about replaced <references /> with {{Reflist}} because of the additional features Reflist provides, such as "colwidth". Personally, I do not want to see <references /> banned from Wikipedia, but general recommendation to use Reflist would be nice. —bender235 (talk) 23:19, 29 November 2010 (UTC)
Actually, it is about removing one feature, the fonsize, from the template to CSS. I don't think we should en- or discourage the use of either <references/> or {{reflist}}. In fact, this change would make them more consistent with eachother. — Edokter • Talk • 23:24, 29 November 2010 (UTC)

I support a general establishment of preference for {{Reflist}} over <references/>, with or without bot conversion. —chaos5023 (talk) 23:20, 29 November 2010 (UTC)

Comment on AWB: AWB doesn't change {{Reflist}} over <references/> unless the editor who introduced it requested small font size. -- Magioladitis (talk) 23:23, 29 November 2010 (UTC)

Yes. However, if the styles were the same, the change could in principle be added as a minor general fix to AWB. — Carl (CBM · talk) 23:26, 29 November 2010 (UTC)

I usually use <references/> when the references are really few (maximum 3 or 4) and reflist for 5 or more references. For over 30 or something I use refelist with 2 columns. -- Magioladitis (talk) 23:24, 29 November 2010 (UTC)

I vastly prefer in-reflist cite details via the |refs= argument to {{Reflist}}, so never use <references/>. —chaos5023 (talk) 23:27, 29 November 2010 (UTC)

The Wikipedia window is alreay cluttered with so much stuff that smaller and smaller font sizes are resorted to inorder to present enough content on one screen to make comprehension easy. I oppose any use of fonts smaller than the size used for running text on the grounds it is too hard to read. Jc3s5h (talk) 00:31, 30 November 2010 (UTC)

  • We've discussed this issue many times before, iirc. I support using {{reflist}} always, but seriously, it's not a big deal for a page with a few references that doesn't use it. Now, if a page has like 50 refs, we should probably condense the font size a little with {{reflist}}, but writing the articles themselves is more important, no? :) /ƒETCHCOMMS/ 01:57, 30 November 2010 (UTC)
    • We're talking about standardising that marginally smaller size (90% AFAIR) via a sitewide CSS change. If we can avoid distracting ourselves with issues of replacing references/ with {{reflist}} or vice versa, it's really quite a small and simple change which ensures that it doesn't matter which is used (unless an editor wants to use the advanced options of reflist). Rd232 talk 02:16, 30 November 2010 (UTC)
      • Yeah, well, the problem there is that CBM wrote a section header that's about font size and an opening paragraph that's about replacing <references /> with {{Reflist}}, so it's a coin toss what any given participant thinks the discussion is actually about. This doesn't make me real happy when I was already looking askance at CBM engaging in questionable behavior and justifying it with barely tangentially related discussion. —chaos5023 (talk) 02:20, 30 November 2010 (UTC)
        • ? The substantive effect of replacing <references /> with {{Reflist}} is a change in fontsize, enabling standardisation of fontsize in reference lists. A better alternative for standardising this was mooted, and clarified by CBM. It's really not that mysterious. Rd232 talk 02:32, 30 November 2010 (UTC)
          • Mmmkay. I suppose it doesn't parse that way to me because when I use {{Reflist}}, it's not because I care about the font size, it's because I want |colwidth= and |refs=. I think we could've left bot enforcement out of it, in any event, but that's fine. Askance gaze withdrawn. —chaos5023 (talk) 02:44, 30 November 2010 (UTC)
            • The questionable behavior has been editors changing the references tag to the reflist template without getting a consensus first that a widespread change has consensus. The historical consensus was that a widespread change was not desired, but that might have changed. I think this thread has already been gathering useful feedback about the font size issue, and will likely gather more. It's more productive to phrase a thread as an actually plausible proposal, that might change, than to make it completely open ended. It gets better feedback. — Carl (CBM · talk) 03:13, 30 November 2010 (UTC)
              • You don't need {{reflist}} for refs=. You just have to remember that <references/> does not have to be written as a an empty entity. You can write 
                <references><ref …><ref …><ref …></references>
                too. Uncle G (talk) 11:53, 1 December 2010 (UTC)
  • No, we shouldn't be forcing a smaller font on references. It's contentious. Enough editors object to smaller font references that, were the smaller font moved into CSS, one could reasonably expect a template would be created to reverse the CSS. Gimmetoo (talk) 02:49, 30 November 2010 (UTC)
    • Do you object to the smaller font references? I'd assign more weight to a real, live objector than a vague idea of "enough" objectors out there somewhere. —chaos5023 (talk) 02:51, 30 November 2010 (UTC)
    • Can you give examples of articles that use <references> instead of {{reflist}} explicitly to avoid the font change? What you are describing is what I always thought was the consensus, but people have been telling me lately there is now a general consensus to use the smaller font. If that isn't true, this thread would be a good place to re-establish the consensus. — Carl (CBM · talk) 03:13, 30 November 2010 (UTC)
      • For my part, I'm saying what I would like to see happen, not what I think consensus is, and I kinda wish more people would do the same instead of invoking vast, nebulous bodies of silent editors and readers. That said, I always thought that the fact that {{Reflist}} did it a particular way represented, in itself, consensus that that's the best way to do it. I mean, the purpose of templates is standardization, right? So if the community wanted it done a particular way, I assumed the template would reflect that. This is the same argument that, when presented to me, led to me ceasing to put <small></small> around citation quotes, as was once common practice — reasoning that if it were supposed to generally be that way, the template would implement it that way. —chaos5023 (talk) 04:19, 30 November 2010 (UTC)
        • If there had been agreement to make a broad switch to the smaller font size when the template was created, they would have changed the global CSS then instead of making the template change the font size. That would have been standardization. The fact that the template has to change the font size reflects the original lack of agreement about the matter. Maybe that has changed now; I guess we'll see. — Carl (CBM · talk) 04:54, 30 November 2010 (UTC)
  • I, personally, use Reflist over references/. I support either a change to a consistent use of Reflist over references/ or a change to the CSS of references/ so it formats in the same way anyways. Either way would work. I understand the arguments for both sides, but since we should really be supporting the use of more references anyways, which looks much nicer and formats better with a column. So...whichever way is decided on, either method works. Changing the CSS would probably be easier though, I would expect. SilverserenC 03:17, 30 November 2010 (UTC)


Again, I am urging you not to be distracted from the original topic. What brought User:CBM here was this WP:ANI. It's about whether Wikipedia users should be allowed to replaced <references /> with {{Reflist}} (or vice versa) as part of the standard fixing minor errors process. I said yes, CBM opposed. —bender235 (talk) 12:04, 30 November 2010 (UTC)

What you're claiming is that there's a consensus to change articles that use <references/> to use {{reflist}} instead. That change is not a minor fix - it changes the style of the references. However, I think you might be right that there's a consensus to make that change broadly. If so, we can do it much easier by simply changing the CSS for the <references/> tag so that it provides the same style.
That's the point of the proposal here. We have had the two parallel systems for a long time, and maybe it's time to merge them. If there's consensus now that the change to a smaller font size is appropriate wiki-wide, we can change the font size in CSS and not have to edit articles pages to achieve it. — Carl (CBM · talk) 12:43, 30 November 2010 (UTC)
Please don't derail a constructive debate with your personal issues with the proposer: yes, those issues are highly relevant to the subject, but the proposal, if passed, would neatly make those issues go away. So I've re-proposed this more clearly, under my name. Rd232 talk 13:23, 30 November 2010 (UTC)

Proposal

Let's be absolutely clear: it is now being proposed to change Mediawiki:Common.css so that <references /> has the same styling as {{Reflist}}. This ensures standardisation. If this is done, it doesn't matter formatting-wise which of <references /> and {{Reflist}} is used, unless a page needs the advanced options of {{Reflist}}. All in favour say aye. Rd232 talk 13:23, 30 November 2010 (UTC)

  • Aye Consistency is good and very much desired. Plus, placing this at the CSS level means that people who like bigger refs can update their stylesheet to cover both {{reflist}} and <references/> (and we could now make reference size an option in the user preferences). Headbomb {talk / contribs / physics / books} 18:55, 30 November 2010 (UTC)
  • Aye. I hate the 90% font size and all that it stands for, and will immediately busy myself trying to get it deprecated - and yet, nonetheless, this standardization is the way forward for now. One hopes that column support can be built into the bare <references /> eventually so that there will be no need for any separate template. — Gavia immer (talk) 19:48, 30 November 2010 (UTC)
  • Aye Once it's standardized, those that feel it's too small can increase it and have it update correctly (perhaps just toss up a simple gadget for an easy, one-click solution). EVula // talk // ☯ // 20:15, 30 November 2010 (UTC)
  • Aye This should improve both organization and look of articles on Wikipedia, along with making them follow a standard for how the references look. SilverserenC 20:27, 30 November 2010 (UTC)
  • Aye much better. Goodvac (talk) 22:10, 30 November 2010 (UTC)
  • Support (what is this, Congress?) Standardization for the win. --Cybercobra (talk) 05:20, 1 December 2010 (UTC)
  • Comment: Since {{Reflist}} offers more features, why not have a guideline that says "the use of {{Reflist}} is recommended"? Or at least one that says "in case there are 10+ refs, multiple columns (e.g. {{Reflist|colwidth=30em}}) are recommended"? Because the columns are the major advantage of {{Reflist}} compared to <references />, not the smaller font size. —bender235 (talk) 14:00, 1 December 2010 (UTC)
    • That is outside the scope of this proposal. This is purely to make <references /> look the same as {{reflist}}. — Edokter • Talk • 14:06, 1 December 2010 (UTC)
      • So I might as well object, because this proposal is nonsense. —bender235 (talk) 19:39, 1 December 2010 (UTC)
        • Why is it nonsense? The original reasoning for preferring either reflist or references over the other was the consistency accross articles. Now that there is another way of ensuring consistency, there is no longer a need of prefering one over the other, and there is no need to deprecate either one. — Edokter • Talk • 20:47, 2 December 2010 (UTC)
          • Even with similar font size, there still is a reason to prefer {{Reflist}} over <references />, and that is the columns feature. —bender235 (talk) 00:11, 3 December 2010 (UTC)
            • Yes, but since columns are an optional feature, there is no need to favor the use of reflist if columns are not used, thus there would be no reason to mass-convert <references /> to {{reflist}}. — Edokter • Talk • 01:59, 3 December 2010 (UTC)
  • Oppose. Some people object to the smaller font size. Smaller text for refs is arguably a remnant of the practices and costs associated with paper media publishing, which don't directly apply to web media. Smaller text is harder to read and it de-emphasizes the references. If there are many who find that "the 90% font-size is hardly distinguishable from the regular font-size on Windows", and "consistency" is the goal, one could achieve consistency by having reflist produce 100% font size text. Gimmetoo (talk) 18:16, 1 December 2010 (UTC)
    • I'm pleased this point has come up, because I have a reply I wanted to make in relation to it. Basically; in an article the content is the thing of interest to a reader. References shouldn't worry the majority of them; the only reason we place references in articles is for convenience, and mostly for the convenience of editors. The references are there to verify content that could be challenged (or quotes, or contentious material etc.). So, to my mind, it is acceptable to have references at reduced size to avoid reader confusion --Errant [tmorton166] (chat!) 18:26, 1 December 2010 (UTC)
      • How might there be "reader confusion" from seeing references, typically in their own section, in the same font size as the rest of the text? Gimmetoo (talk) 18:32, 1 December 2010 (UTC)
      • @Errant: I take the opposite viewpoint: references are there for readers first, so that they can use them to dig deeper into the material if they want to use the encyclopedia as a starting point. Disputes between Wikipedians belong on the talk page. I agree with Gimmetoo that the change in font size is a relic from print, but it seems to have become endemic here. — Carl (CBM · talk) 18:39, 1 December 2010 (UTC)
        • I agree that references are for readers first. I suppose it's probably true that the font size thing is a print relic, but I'll admit that I like it stylistically. But standardizing the style and then making small refs an easily settable preference seems even better than inflicting my design sense on the entire Wikipedia readership. —chaos5023 (talk) 19:09, 1 December 2010 (UTC)
            • Ok, but this is entirely incorrect. References are to verify information (which, I agree may be a reader endeavour, but is much more commonly an editor task). There is no requirement for references on an article (apart from those to establish notability, which due to policy wording must appear) --Errant [tmorton166] (chat!) 19:15, 1 December 2010 (UTC)
              • Well, um. I would say that WP:Verifiability at the very least strongly encourages the presence of references, and it does outright require them on material "likely to be challenged". The entire model of Wikipedia as a tertiary source that summarizes other sources strongly points to what CBM is saying about the article and its references being a starting point, as well. —chaos5023 (talk) 19:39, 1 December 2010 (UTC)
                • I used to think like that. In actuality the policy vaguely supports not using refs indiscriminately - but demands them from material likely to be challenged. This was explained to me by a large number of people, so I think it is widely accepted. External links are, as I mentioned to Carl on his talk page, there for "down the rabbit hole" style outward links for this very reason --Errant [tmorton166] (chat!) 19:43, 1 December 2010 (UTC)
  • Aye - With respect to senior editors who do not like change, this (IMO) is a net positive. Also per Headbomb Mlpearc powwow 18:55, 1 December 2010 (UTC)
  • Aye Magioladitis (talk) 19:16, 1 December 2010 (UTC)
  • Aye SnottyWong confabulate 19:56, 1 December 2010 (UTC)
  • Support I like streamliningCasliber (talk · contribs) 20:38, 1 December 2010 (UTC)
  • Aye, Support - Let the streamlining continue. --Kumioko (talk) 21:31, 1 December 2010 (UTC)
  • Some of the comments above, and the gadget below, seem to be missing some of the key issues. This is not an issue of "senior editors who do not like change". (Some might take that as a personal attack, even.) I would hazard to guess that many of those arguing against small font or reflist everywhere think the bibliographic references on WP should be default 100% font size for everyone (though perhaps with exceptions for short notes, or very long lists of references). The most readable option for readers in general would be the refs and text the same. A "gadget" doesn't address that. Indeed, for perspective: why not make the WP default 100%, and if some people, for stylistic reasons, want some parts of the text different, make that option available through a gadget. Gimmetoo (talk) 03:25, 2 December 2010 (UTC)
    • When I see footnotes in a book, they are usually not the same size as the regular text. Also, if a lot more people like it one way, that's consensus, and so we'd have the gadget to make it bigger, not smaller. /ƒETCHCOMMS/ 04:01, 2 December 2010 (UTC)
    • Formation of consensus requires, at minimum, an understanding of the various views, otherwise it is really just a majority with a gut preference. On style issues, the long-standing consensus seems to be that majority - even large majority - does not make a consensus. For example, the majority of WP editors would presumably put ref marks after punctuation, but there is no consensus to mandate that. And directly on this issue, there used to be some other reflist alternatives that implemented other font sizes. This was a while ago, so my recollection is a foggy, but I recall one of them existed on about 800 articles, most of which were maintained by a couple editors who objected to font size 90% because it didn't look right to them. On any straight-up vote, it would be 10:1 to consolidate, but WP didn't just do it until the objections were handled and the objectors ceased objecting to consolidation. Gimmetoo (talk) 04:21, 2 December 2010 (UTC)
      • I find that too many of the MOS regulars project an attitude of "Anyone who disagrees with us doesn't really understand the issue, so we can ignore their comments". Anomie⚔ 15:53, 2 December 2010 (UTC)
        • Please explain your comment in more detail. I don't see how it applies here, or to my comment. Gimmetoo (talk) 16:19, 2 December 2010 (UTC)
          • You said "Formation of consensus requires, at minimum, an understanding of the various views", from which I infer a corollary "We should ignore some people's comments, because if they understood the views they would agree with me". I've found that to be an attitude common among those regularly involved in MOS issues, which seems to me to be one of the reasons MOS discussions are often decided through attrition (i.e. one side eventually gives up, or those involved get provoked into blockable behavior) rather than consensus.
            Also, BTW, you're apparently out of date regarding refs after punctuation, or else WP:REFPUNC doesn't represent consensus. Anomie⚔ 17:22, 2 December 2010 (UTC)
            • Hmmm. Perhaps those who used to object to the refs after punctuation stopped objecting? But your corollary does not follow, definitely not the second part anyway. Fetch stated that footnotes in a book are different size, but it had already been said that practices from paper media do not directly apply to web media. So simply repeating "this is how books do it" is not addressing the concern. To address the concern, one would have to argue that "this is the right way to do it in web media" for whatever reason. I can, at least, imagine there might be reasons, but some of the comments just state "footnoes should be smaller" without giving reasons. Likewise, "streamlining is good" is an argument, but WP precedent has been not to "streamline" until objections are addressed or the objections stop, and I gave two examples. Gimmetoo (talk) 17:45, 2 December 2010 (UTC)
              • "practices from paper media do not directly apply to web media". Likewise, we don't have to change practices from paper media just because they don't apply to web media. Near as I can tell, your chief objection to having the font size for references be smaller is because this isn't a printed page (and so the standard should be different), which doesn't carry much weight to me (personally). There are plenty of printed page style choices that we still maintain, chiefly because reading is still reading, regardless of the medium. EVula // talk // ☯ // 18:57, 3 December 2010 (UTC)

Question(s)

Some seem to prefer custom visual styles, see Talk:Julian Assange#Scroll-box visual style. Is there some guideline for this? Another issue is the mixing of WP:LDR-type citations with those in the article body—there's no visual difference here for the reader, but there is (an organizational) one for editors. Tijfo098 (talk) 10:23, 3 December 2010 (UTC)

I see that at least the scrolling issue is addressed at MOS:SCROLL. Tijfo098 (talk) 12:14, 3 December 2010 (UTC)

Proposal for an information bot

I propose a bot that monitors the RC feed and updates a page at a timely interval (I suggest hourly) with various statistics.

Some statistics I suggest are:

  • Number of edits in the previous hour
  • Number of new accounts in the previous hour
  • Number of new pages in the previous hour
  • Number of reverted edits in the previous hour ("vandalism")
  • Percentage of reverted edits
  • A standardised measure of vandalism information, ideally to supersede the template {{Vandalism information}}
  • Number of Huggle users at time of update
  • Average number of Huggle user in the previous hour

and many more such as moving averages, daily averages etc.

I believe that this will give us a wealth of information, which we can use as an example to make graphs showing server load time by hour over the week.

Is the community interested in such a bot, and what further improvements and statistics do you suggest? 930913 (Congratulate/Complaints) 09:53, 1 December 2010 (UTC)

Personally I think that would be useful and intersting but some may argue that its uneeded. --Kumioko (talk) 21:29, 1 December 2010 (UTC)
To pre-empt the inevitable cries from others, let's not arm the vandals. - Jarry1250 [Who? Discuss.] 22:11, 1 December 2010 (UTC)
Im not sure how simple numbers would unleash the beast. --Kumioko (talk) 22:19, 1 December 2010 (UTC)
  • Seems like a bunch of relatively meaningless edits to me. At best, we could have a bot update {{wdefcon}} every four/six hours or so with the current RPM. We don't need a bot listing statistics all the time for vandalism info ... /ƒETCHCOMMS/ 04:05, 2 December 2010 (UTC)
    • I just list the vandalism ones, because I'm primarily into vandal fighting. Loads of other statistics would be included, as wanted by the community. Secondly, RPM is a bad measure of vandalism, namely because it's inversely proportional to the number of AVs needed. 930913 (Congratulate/Complaints) 08:15, 2 December 2010 (UTC)
      • The number of Huggle users is better because sometimes I will be the only AV online and be reverting very rapidly even though the counter only says 7 RPM. Other times I will be online with people like Wayne Slam/Access Denied and be only reverting once in a while, and the counter says 16 RPM. However, we don't want vandals looking up the times that the Huggle users are away. Reaper Eternal (talk) 03:04, 4 December 2010 (UTC)

Request for some feedback

Let us be clear - how can we have some feedback on which proposals, say, over the past twelve months, have been succesful?It would be nice to think that this feature of Wikipedia serves a useful function. ACEOREVIVED (talk) 19:28, 2 December 2010 (UTC)

Start a RfC for making the proposal policy or whatever you want it to be? What is this proposal? /ƒETCHCOMMS/ 01:24, 3 December 2010 (UTC)
Proposal that someone goes through the VPR/Idea Lab archives and tries to summarise them in terms of outcomes? Would be interesting, but hard work. Rd232 talk 12:00, 3 December 2010 (UTC)

Status

Would you like a feature where you could update your status (Online, Offline, or even Custom) so that other editor may see? And how about doing that without clogging your contributions?

For general comments, you may respond here. For comments that would directly effect the feature's deployment, please join the discussion, or participate directly at Bugzilla:26246. Thanks! Rehman 00:54, 4 December 2010 (UTC)

Gadget Proposal: NoSmallFonts

Sparked by the discussion above and suggested by EVula, as well as by past discussions relating to element- and page design, where there is always the few that object change because "the font is too small!", I propose a gadget that provides a one-click solution to those that loathe small fonts. It basically resets the fontsize of those elements, such as navboxes, infoboxes and reference lists to 100%. The list can be extended as I am bound to have forgotten a few. This should help readability for those that have problems with small fonts.

The code is here: MediaWiki:Gadget-NoSmallFonts / MediaWiki:Gadget-NoSmallFonts.css. Those wanting to testdrive it can simply copy the CSS code to their vector.css file. — Edokter • Talk • 02:16, 1 December 2010 (UTC)

I'll just go ahead and enable the gadget, as I haven't see any response, including objections. The code is failsafe and I think it will be helpfull for the vision impaired. — Edokter • Talk • 21:38, 1 December 2010 (UTC)
Strongly support. I see this is now available under Gadgets → Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists. ---— Gadget850 (Ed) talk 15:51, 2 December 2010 (UTC)

There is also an opposite problem. Many try to create small caps with the code small, but this does not work. E.g. for chemical names.--Wickey-nl (talk) 17:35, 3 December 2010 (UTC)

Those should use the proper styling by using the {{smallcaps}} template. — Edokter • Talk • 18:09, 3 December 2010 (UTC)
What's that [i.e. small caps styling] needed for? And what else is <small> used for in articles? Maybe a bot could identify/fix this? Rd232 talk 18:13, 3 December 2010 (UTC)
That's partly explained in the template documentation. It is mainly used for author names in citations and is sometimes usefull for technical text. The use of <small> however should be, in my humble opinion, killed with fire. — Edokter • Talk • 18:25, 3 December 2010 (UTC)
I've never seen small caps citations on Wikipedia. Is it just a theory of the template's creators, or is it actually used in this way somewhere?—Emil J. 18:36, 3 December 2010 (UTC)
Quite a few articles use reference lists where the author name is styled in smallcaps.[3] See Brassicales for example. ---— Gadget850 (Ed) talk 18:47, 3 December 2010 (UTC)
I know how to use Special:WhatLinksHere. The thing is, the articles on top of the list that I tried do not use small caps for citations, in fact, they do not use small caps at all, they just transclude {{List of European capitals by region}} where it's used for a different, ad hoc, purpose.—Emil J. 18:54, 3 December 2010 (UTC)

Small caps are part of a chemistry nomenclature (see Chirality_(chemistry)#By_configuration:_D-_and_L-; especially see the try of an editor in the heading). It is hardly applied in WP yet, because hardly anyone knows the Smallcaps template. Is a smallcaps editbutton possible?--Wickey-nl (talk) 10:45, 4 December 2010 (UTC)

New Page History Statistics tool for addition to External Tools in page history

There is a great new tool from toolserver.org that allows seeing a DETAILED graphical and statistical view of a page's history statistics. It's one of those tools that just has to among the External Tools in the history page. Someone add the tool to the section or contact the technical team that has the ability to it.

Here you can see page history statistics for Wikipedia:Village_pump_(proposals): http://toolserver.org/~soxred93/articleinfo/index.php?article=Wikipedia%3AVillage_pump_%28proposals%29&lang=en&wiki=wikipedia&begin=&end=

Is it just me, or do the readings for this page appear to halt seven months ago? - Jarry1250 [Who? Discuss.] 11:03, 4 December 2010 (UTC)
It seems by default, the tool only shows the statistics for the first 50,000 edits, as the message says at the top, which this page reached on 20 April 2010, 14:02:46. The statistics for the subsequent edits can be viewed by entering 20 April 2010, 14:02:47 as the starting date:
http://toolserver.org/~soxred93/articleinfo/index.php?article=%09Wikipedia%3AVillage+pump+%28proposals%29&lang=en&wiki=wikipedia&begin=20+April+2010%2C+14%3A02%3A47&end=
I tried to enter the time of the most recent edit as the ending date without a starting date but the tool returned an error. - Logos111 (talk) 00:13, 6 December 2010 (UTC)

A-class template

I am proposing there be a template for A-class articles like Template:Good article and Template:Featured article. I don't see why there isn't one, since A-class articles have surpassed GA and deserve such uhh I can't think of a word for here. Respect? Okay. So I was thinking a page like this. CrowzRSA 19:59, 5 December 2010 (UTC)

This has been proposed many times before. The usual stumbling block is that A-Class is not used across the project (and in fact used very sparingly amongst the few projects that do actually make use of it), so therefore there is no real standard. Personally, I think it's high time we had another site-wide discussion about what to do with A-Class. I'm not inherently opposed to showing the icon, but it seems rather confusing to do it when so many articles will never actually have the possibility of being rated A-Class. --Dorsal Axe 20:03, 5 December 2010 (UTC)
In practice, the military project might be the only one that widely uses A-class. It is Wikipedia's equivalent of imperial measurements - it is mostly depricated with only a few holdouts still using it. Resolute 20:21, 5 December 2010 (UTC)
Aye. Would be better to deprecate A-class than to advertise it. Fences&Windows 23:28, 5 December 2010 (UTC)
That sounds like a great proposal, depreciation that is, except WPMIlHIST would be mildly hostile to that methinks, Sadads (talk) 02:28, 6 December 2010 (UTC)
Them and whose army? Fences&Windows 00:39, 8 December 2010 (UTC)

So I've noticed that when editors add or remove templates, they generally use the template code in the edit summary instead of saying "Template:Whatever". Often when I have gone on tagging sprees (populating a stub category or for a WikiProject) I will simply paste the template code into the article and then paste into the summary. Almost every editor will know that "{{Disney-videogame-stub}}" as an edit summary means that article was tagged with that template. For some reason I always assumed that this created a wikilink in the summary, as is possible with normal links, but I just realized this is not the case.

So, to be specific, I am proposing that template links in an edit summary be treated as a wikilink to that template. So "{{Disney-videogame-stub}}" would display as "{{Disney-videogame-stub}}". There is obviously no giant benefit to be gained, it would just make reading histories and watchlists more informative. It should be a minor software change, I just wanted to see if it would have community support. Thanks! ▫ JohnnyMrNinja 07:24, 7 December 2010 (UTC)

That would be great, as would autolinking shortcuts and abbreviations and keywords like "rv" and "revert". We want more newcomers! This has certainly been discussed before and I think there may even be a Bugzilla bug - can someone find previous discussion? Rd232 talk 09:01, 7 December 2010 (UTC)
Ask at WP:VPT. If I remember correctly, the edit summary box is parsed in a different way by MediaWiki, so this may or may not be technically challenging to do. Titoxd(?!? - cool stuff) 10:31, 7 December 2010 (UTC)

Proposal to allow curly quotation marks in articles

Please see WT:MOS#Quotation mark glyph straw poll. A. di M. (talk) 11:59, 7 December 2010 (UTC) Fixed link. --Stephan Schulz (talk) 12:16, 7 December 2010 (UTC)

Wikipedia Per-Article Volatility Index

The following is a suggestion for a new Wikipedia feature - specifically, a volatility index for each article, built into (or near) the header of each article:

As we’re all aware, the popular complaint/stigma surrounding Wikipedia has been its correctness/reliability. This stigma comes because in general, the older generation (anyone who grew up before Web 2.0) distrusts (because it fails to understand) the speed and effectiveness of self-policing in online communities, especially large ones, like that of Wikipedia’s readers and contributors. My hope for the feature I’m suggesting here is to present a mechanism for assuaging the fears of the older generation (unfounded as they may be) by harnessing the Wikipedia article’s living nature.

The approach I’m suggesting to this reliability/correctness issue requires that we first accept that we can never be 100% sure of the correctness of any article at any single moment (Wikipedia or otherwise), but with Wikipedia, what we can do is get a really good idea as to the risk involved in trusting a specific article at a specific moment, thus drastically reducing overall public anxiety about using Wikipedia in general.

The approach is this: Simply display, at, say, the top right of each Wikipedia article, a small graph of the number of changes (edits) to the article per hour (or minute or day) over a span of several days, or months or years – the user should be able to click whichever of these time frames interests him, just as an investor may want to see a 1-hour, 1-day, 1-week or 10-year graph of the price of a stock that interests him.

Here’s an example of how it might work: Imagine that a skeptical user wants to educate himself on a new subject, so he searches Wikipedia and finds an appropriate article. Imagine next that the subject our user is researching has become popular recently and so the article is currently high in both “read-only” and “edit” traffic. The user arrives on the article/webpage, and in the top right of the screen there’s a small graph showing the number of changes that have been made to this very article over the past month (or week or day or hour), i.e. x-axis is time, in days (or hours or minutes) and the y-axis is number of changes. The user sees he has the option to zoom the graph in or out (to a timeline of a few hours or a few years), much like he would, as mentioned above, with stock price info on his broker’s website.

With this graph, which is kept up to date in real time by Wikipedia (or perhaps by http://stats.grok.se/), the user sees at one glance both the current and historic volatility of the article he’s viewing, just as a stock trader sees the market’s volatility using an index such as the VIX (http://en.wikipedia.org/wiki/VIX). High volatility for a Wikipedia article (a current spike or plateau in changes per unit time) tells a reader that the article (to continue the stock market parallel) is currently volatile, or unstable, and that using the info that appears in the article (for, say, a school paper) at this moment carries more risk (of inaccuracy, in Wikipedia’s case). The high risk (high changes per hour) could be because the subject of the article is a developing situation, or because it’s controversial and opposing viewpoints are in the midst of an edit war. Point is, now the reader has a way to know at a glance that something is going on that makes the current content of the article likely to change rapidly. The user can then make a choice, such as deciding to check back later, i.e. to not use the article’s info until the changes per hour have settled to a level that represents higher agreement among all potential editors who have been monitoring the article (less risk of inaccuracy).

If one wanted to take this idea a step further, moving averages could be shown, and even manipulated by users (e.g. 30-day or 180-day), and teachers could advise students, for example, not to use an article unless its current changes per hour were at or below some moving average of their choosing, say 30 days for example. The actual numbers used could be adjusted by the user (or his teacher) depending on desired risk levels.

Yet another step further would be to determine better ways to illustrate reliability of an article – i.e. instead of edits per hour, or changes in edits per hour, maybe a formula like ((edits / views) / hour) would prove more reliable – I’ll leave that to interested statisticians and econometricians.

In summary, everyone knows the risks at Wikipedia. It would be a mistake to treat them as a PR issue. Quantifying the risks and giving the public a way to work with them easily should increase the general public’s confidence in Wikipedia.

--Aldobiella (talk) 02:10, 8 December 2010 (UTC)

Have you heard of WikiTrust? --Cybercobra (talk) 02:33, 8 December 2010 (UTC)
  • WikiTrust is a better solution. The specific problem with the measure you have proposed, Aldobiella, is that the most egregiously false pages on Wikipedia were created a long time ago and have gone undetected and edited for a long period, and thus would register as "very stable" without being in any way correct. A system (like WikiTrust) that assesses articles on the basis of the calibre of their editors is generally better - more likely to return pages as falsely inaccurate rather than falsely accurate, as well, which is also a plus. - DustFormsWords (talk) 02:40, 8 December 2010 (UTC)
I can't see much value in WT at first glance. It assesses material on the basis of the contributors, and it assesses the contributors on the basis of whether others tend to agree with them. That sounds likely to give much the same results as "consensus". Peter jackson (talk) 18:01, 9 December 2010 (UTC)

A Third Tab: A Statistics Page to help people judge reliability

While it may not be a good idea to add a volatility indicator at the top of articles, it is useful to have such tools available to editors and those who want to see them to for their judgment on the reliability of an article.

That's why I propose that a third tab besides the Article and Discussion should be added, which can be named Statistics, Article Statistics, Volatility or a similar term, which will allow the viewing of editing statistics of an article.

A tool is available which can help in creating such a statistics viewer:

Through the Article History Statistics tool, you can see the history statistics of the article "Wikipedia" on the English Wikipedia: http://toolserver.org/~soxred93/articleinfo/index.php?article=Wikipedia

A statistics page for a third tab, aimed to help the public judge the reliability of articles and information on Wikipedia seems like a natural step toward enhancing the usability, reliability, and the transparency of Wikipedia. It will allow it to serve its mission of providing reliable information in a free encyclopedia of user-generated content. And it seems the rudiments for its creation are already in place. And as a third tab, it is not likely to provide a distraction in casual reading of articles any more than dose the Discussion tab. I think it will be a worthwhile and fruitful step to take.

The Article History Statistics tool should also be added to the external tools on the article revisions page, this more geared toward editors, as opposed to the tab, which will help better inform readers and the public about article reliability and their exercise of caution. λόγος Idea → ✉ 19:10, 9 December 2010 (UTC)

  • Oppose - Even having read the earlier discussion on volatility, I'm not clear what benefit this would bring to any editor, or how it substantially improves upon a careful reading of an article's history page. What you're proposing is something that would not be seen or found by casual viewers, and provides information that experienced editors can already access through existing tools. In addition, it falls foul of many of the same reasons we don't show how many people are watching a page below a certain limit, in that it provides clues for vandals as to which pages vandalism is unlikely to be detected on. - DustFormsWords (talk) 05:22, 10 December 2010 (UTC)
  • In addition the best way to judge the accuracy of articles on Wikipedia is simply to be information literate, and have the skills necessary to make informed judgments on your own behalf as to whether sources are reliable. I'm philosophically skeptical of methods that use algorithms and metrics to lull people into avoiding developing these crucial skills for themselves. That is, at least until we have MUCH better algorithms and metrics. - DustFormsWords (talk) 05:25, 10 December 2010 (UTC)
  • How do the statistics on the linked tool correlate to reliability? You could probably make some argument that articles with more edits or more frequent edits are more reliable, but it would likely be a weak relation, especially since "reliability" isn't a quantitative property. Wikitrust is better because it takes who made the edit into account, but more importantly, it works on a sentence level. As articles get bigger, the amount of the article each edit affects becomes smaller, so the idea that each edit improves the reliability of the article as a whole becomes less accurate. Mr.Z-man 05:46, 10 December 2010 (UTC)

"From Wikipedia, the free encyclopedia" - reocurring text under article's title

Screenshot here. There's already the same message / text at topmost-left corner (under 'puzzle' baloon). So wouldn't be it nice if we get rid of unnecessary / repetitive stuff? A cleaner / simpler scope / interface is better anyway. Userpd (talk) 19:12, 26 November 2010 (UTC)

Oppose Mirror sites would not have the logo, only the "From Wikipedia" message at the top of the article it copies from. :| TelCoNaSpVe :| 19:33, 26 November 2010 (UTC)
Mirror site like what? I guess anybody who once been to wikipedia had read that it's free / knows, why is there need to push at throats, too many texts which are not related to article's content only make it too bureaucratically stuffed. Besides still majority will read from wikipedia itself and not from someones who decide to mirror contents of wikipedia. Anyway, those who want to copy content from wikipedia wouldn't anyway copy this message along with the content, so this repetitive mentioning in an article's page is uncalled for. Would be better to make as simple as possible since it's a populated project. Userpd (talk) 22:28, 26 November 2010 (UTC)
Read Wikipedia:Mirrors and forks, which tells you about such websites. They sometimes don't include either the logo or the wording, but retain the other. :| TelCoNaSpVe :| 23:14, 28 November 2010 (UTC)
What is the point having the wording there if they can remove it as well? All the mirror sites I come across has attributed WP, which is all they need to do to copy. -- d'oh! [talk] 00:06, 29 November 2010 (UTC)
Using the same CSS rules the wording can be hidden until the page is printed. If the CSS rule is not 'honored' the logo will be there instead, win-win. -- d'oh! [talk] 03:13, 29 November 2010 (UTC)
Then putting it at the end of printed versions of articles should do the trick. Userpd (talk) 03:51, 29 November 2010 (UTC)
I often browse Wikipedia with a text-only browser. The logo doesn't show up for me there. --Carnildo (talk) 02:14, 30 November 2010 (UTC)
I would think the big Wikipedia logo to the left will get the readers a clue on where they are. In terms of mirrors, all mirrors I know of has removed the wording, but still attributes Wikipedia at the bottom of the page. In addition, that CSS causes a misalignment of the top icons. -- d'oh! [talk] 23:44, 30 November 2010 (UTC)
And removing it in some other manner won't misalign the top icons in the same way? Never mind that the "removal" will probably wind up being "edit MediaWiki:Vector.css to stop setting display:inline on #siteSub", which is pretty much equivalent to using that bit of CSS in your skin.css? Anomie⚔ 00:57, 1 December 2010 (UTC)
Obviously we personally could do whatever we want with it (I could equally well argue that you could use Java to put the tagline back if you wanted it that much), but it's a question of how we present pages to our millions of readers who don't have any such options. What reason is there for making the same vapid statement twice, within a few centimetres of itself? --Kotniski (talk) 07:00, 1 December 2010 (UTC)
Ooh, that's much better. Can we make that a preference, or is there a help page that advises that? --Bsherr (talk) 17:29, 8 December 2010 (UTC)
Never mind, it doesn't work. It affects for the worse the position of icons to the right of the title. --Bsherr (talk) 18:04, 8 December 2010 (UTC)
  • Apathy I don't really have a problem with it one way or the other; it's a bit redundant, sure, but there's a difference (on a technical level) between text in an image and actual text on the page. I'd be fine with it being hidden in the screen-media CSS (and visible in the print-media CSS). EVula // talk // ☯ // 20:13, 30 November 2010 (UTC)
  • Support It's been there forever and I don't really see it anymore, but that's really a bit of space that's better dedicated to article content. Plenty of mirrors remove the tag as well, and of course the tag itself is not enough to ensure license compliance, so the mirror issue isn't a big factor for me. Dcoetzee 01:47, 1 December 2010 (UTC)
  • Oppose - Removing that would lessen our SEO, as not all pages would then have those key words directly written on them. Also, they aren't hurting anything. Ajraddatz (Talk) 19:17, 1 December 2010 (UTC)
With the wording hidden using CSS (not removed) the wording will appear for crawlers and another bots, so there is no SEO issue. -- d'oh! [talk] 00:52, 4 December 2010 (UTC)

Project misnamed :(

I regret to inform you that your encyclopedia is misnamed. The part before the suffix -pedia is suppose to be the topic of the encyclopedia, not the way in which it is created. For example, Medpedia is about medical information, Wowpedia is about WoW, Conservipedia is about Conservative ramblings, and babynamespedia is about baby names. You don't have to specifically say that your encyclopedia is a wiki, that is implied by the suffix in all cases except for the prefix encyclo-. —Preceding unsigned comment added by 142.244.236.20 (talk) 01:06, 5 December 2010 (UTC)

Wikipedia predates all of those. "-pedia" wouldn't imply a wiki if it weren't for Wikipedia. Mr.Z-man 02:09, 5 December 2010 (UTC)
What he said. Also, Wikipedia is obviously a simple modification of the word Encyclopedia to include Wiki. Ajraddatz (Talk) 23:37, 5 December 2010 (UTC)
We live in an imperfect world, 142.244. Try not to sweat the small stuff as you take the Wiki Wiki Shuttle to Hotel Wikipedia. –Whitehorse1 23:41, 5 December 2010 (UTC)


Since Wikipedia is a proper noun and not a noun, surely we can be reasonably liberal in thinking about what to call it. After all, as early as 1997, there was Nupedia I am sure that was not about Nus. In fact, some of the information in Wikipedia is about wikis - we have an article on wiki, for example. ACEOREVIVED (talk)

If Wikipedia is not an encyclopedia of wikis, then what would you call an encyclopedia of wikis? (Answer: WikiIndex). Dcoetzee 18:38, 11 December 2010 (UTC)

Main page disclaimer

How about for a limited period, we put, on the main page under "Welcome to Wikipedia...", a prominent disclaimer that Wikipedia is not connected with Wikileaks. The confusion about this seems widespread. 86.184.239.37 (talk) 20:55, 7 December 2010 (UTC)

"We're not associated with WikiLeaks, but we have an encyclopedia article about them."? It does seem a confusion that's quite widespread - see the current Signpost feature. In the circumstances, I'm not sure that a Main Page note is an over-reaction, but I can't see it happening. Rd232 talk 21:42, 7 December 2010 (UTC)
On Radio 2 (UK) the other day they have a talk show and one person emailed "well done Wikipedia". This is definitely a weird problem Facepalm Facepalm --Errant (chat!) 22:01, 7 December 2010 (UTC)
Its symptomatic of a larger problem, the idea that the common public hears "Wiki" and thinks "Wikipedia". The Wikileaks business is the most recent episode, but its not the first and won't be the last. I'd like to see the Foundation try and do more to educate and dispel that. That said, I'd personally agree that either a notice on the Main Page, or maybe a sitenotice, would make sense, but I honestly doubt anything like that would get consensus.--Fyre2387 (talk • contribs) 22:49, 7 December 2010 (UTC)
A Main Page notice is simply out of the question. It's never going to happen.
A sitewide notice is a possibility, but I just can't see it happening for a whole host of reasons. Still, it's a possibility worth investing. These are unique circumstances after all. Also note that there is a disclaimer on the actual Wikileaks article. --Dorsal Axe 23:05, 7 December 2010 (UTC)
And even that seems to be contentious. --Cybercobra (talk) 02:24, 8 December 2010 (UTC)
I would agree with a sitewide notice. Main Page is a feasible option but takes too long to get consensus for any alterations. Right now we need something fast and the message is seen across any pages. Let's correct the situation before more uninformed general public mistakenly believe Wikipedia = Wikileaks. OhanaUnitedTalk page 15:25, 9 December 2010 (UTC)
A message like the one for the founds (above all pages, removable with a click) should be both informative, unobstrusive (if compared with other options) and easy to create, as such messages already exist (we wouldn't be talking about new functionality, or something that may screw the main page appearence) MBelgrano (talk) 15:40, 9 December 2010 (UTC)
I will support a sitenotice. But how would we word such a message? I think MediaWiki:Anonnotice would be more appropriate than anything. But I'm not sure... --Dorsal Axe 11:53, 10 December 2010 (UTC)
Try proposing something on MediaWiki talk:Sitenotice; perhaps "Wikipedia and the Wikimedia Foundation are not associated with the whistleblowing site Wikileaks, despite a similarity in names" --Errant (chat!) 12:44, 10 December 2010 (UTC)
Proposed at: MediaWiki_talk:Sitenotice#Wikileaks. Rd232 talk 13:05, 10 December 2010 (UTC)
The suggestion is probably more appropriate at MediaWiki talk:Anonnotice, which I have noted there. Editors are probably already aware, but anons and readers are not. bahamut0013wordsdeeds 17:43, 10 December 2010 (UTC)
FWIW, I've seen disclaimers on other Wikimedia pages. (See here for one example.) This confusion is not the most important Wikipedia-related item for me, but if it makes other contributor's lives easier go ahead & add the disclaimer on the Front Page, WP:AN & WP:AN/I, as well as WP:VP. -- llywrch (talk) 21:10, 9 December 2010 (UTC)

Please oh no. We're now just feeding WikiLeaks. /ƒETCHCOMMS/ 02:34, 11 December 2010 (UTC)

Nature : Time to underpin Wikipedia wisdom

A recent article in Nature (08 December 2010) states : Scientists who receive public or charitable funding should therefore seize the opportunity to make sure that Wikipedia articles are understandable, scientifically accurate, well sourced and up-to-date. Many in the scientific community will admit to using Wikipedia occasionally, yet few have contributed content. For society's sake, scientists must overcome their reluctance to embrace this resource. Nature : Time to underpin Wikipedia wisdom. Interesting. JoJan (talk) 14:39, 10 December 2010 (UTC)

I have copied it to the signpost suggestions. Shyamal (talk) 14:50, 10 December 2010 (UTC)
Indeed interesting, however, this also produces some possibility for bias within the effected articles - something which will need to be watched for. Ajraddatz (Talk) 15:18, 10 December 2010 (UTC)
There are actually quite a few scientists and other experts working on Wikipedia. There are also quite a few who've given up in disgust at the way it "works", and at least 2 who've been blocked or banned. In some circles it doesn't have a reputation as expert-friendly. Peter jackson (talk) 16:00, 10 December 2010 (UTC)
Yeah, we have a lot of scientists that contribute well, some scientists promoting their own theories, and a few who end up blocked/banned for not working with consensus on things that they "know better" than everyone else. /ƒETCHCOMMS/ 02:38, 11 December 2010 (UTC)
Well, like every category of editors, it seems. As a scientist myself (warning: shameless self-promotion) I collaborated with the authors of the letter in writing this small guide to contribute to WP for scientists; it would be interesting to know if any scientist has read it and begun to contribute to WP afterwards. --Cyclopiatalk 10:51, 11 December 2010 (UTC)

Cap editing protection on pages in the mainspace at 1 year

Just throwing out a suggestion to place a "cap" of 1 year for any edit protection (normally semi-protection) on any mainspace article. My reason is what setting edit protection to "indefinite" is more like a "set it and forget it" feature, and I think, as seen with the Pending Changes trial, there were quite a few articles which clearly did not necessitate permanent (semi) protection, though it definitely needed to be protected at that time. This would be beneficial in continuing to allow new users or anonymous users to edit more articles. –MuZemike 01:01, 24 November 2010 (UTC)

There is a list of protected pages, which can show indefinite protections. It isn't that hard to go through that list every once and a while, but I see and agree with what you are saying. Realistically, no page should be indefinitely protected, save the main page and other very high use pages and templates. Ajraddatz (Talk) 02:12, 24 November 2010 (UTC)
Not convinced. For example, low-profile BLPs with a certain demonstrated vulnerability to vandalism shouldn't suddenly be exposed to that again after 1 year, nor be dependent on somebody remembering to extend or re-protect. Indefinite should be used sparingly, and the list of pages using it should be checked regularly, but there are uses for it. Rd232 talk 02:44, 24 November 2010 (UTC)
I strongly disagree; sometimes protection is turned on and "forgotten" for a reason. An excellent example of this would be Elephant, which has been protected effectively ever since July 31, 2006. Every time we take it down, vandalism ramps right back up immediately, and so it gets restored quickly. EVula // talk // ☯ // 20:19, 30 November 2010 (UTC)
I dunno, I think we can reasonably assume that eventually people will forget about Colbert's call to action on elephant. I mean, it was just one episode of a TV show. Maybe try unprotecting after 5 years or something. Dcoetzee 18:42, 11 December 2010 (UTC)
I take it you've never heard of a cult following? Hell, I still revert vandalism at Evil stemming from a certain web comic that made a joke in 2006. The Internet has some really, really dedicated folks. — The Hand That Feeds You:Bite 15:45, 13 December 2010 (UTC)
I think that a report showing articles protected or semi-protected on this day in previous years would be worthwhile. But we shouldn't assume that all such decisions were incorrect or that the various BLP problems have gone away. Our editors come and go and the notoriety of certain celebrities is often fleeting. But some real life stalking and bullying cases go on for many many years, and we should have an appropriate response. I'm happy that an admin makes a considered decision to reduce protection on an article, provided they are watching that aricle and ready to reinstate protection if necessary. I'm not happy with an automated process to lower our guard on articles, especially if the protecting admin is no longer around to watch the article. ϢereSpielChequers 13:29, 7 December 2010 (UTC)

Religion Field in BLP infobox

I propose that the Religion field in the BLP infobox be removed as one's religion, or lack thereof is of a personal nature, often of a fluid nature and can only be defined by the person him/her self. This issue has come up on the BLP Noticeboard under Ed Miliband, where there is a degree of controversy as to whether to list him as "Jewish" or "of jewish descent". The controversy wouldn't exist if there were no Religion field in the infobox. It may be that many people share this view.MarkDask 07:35, 6 December 2010 (UTC)

  • Oppose - The surest way of eliminating controversy on Wikipedia is to not have articles. Difficult arguments are not a reason to avoid providing content. Traditionally we resolve questions of what religion, nationality, or ethnicity someone is in the same way that we determine their name - by reference to how they self-identify, and how they're described in the majority of reliable sources. In cases where there is no consensus on a person's religion the field can be left blank. Removing the field would harm those BLP articles where religion is a notable part of the subject's identity. - DustFormsWords (talk) 08:23, 6 December 2010 (UTC)
  • Comment use of the field should be strongly discouraged under WP:BLPCAT. That is a BLP policy that is only minimally enforced, partly due to the difficulty in establishing whether someone's religion is relevant to their public life. In the Ed Miliband example, I think BLPCAT probably applies because it's not really possible to source any media (or other) interest in his religion from the perspective of him being leader of the opposition. But I am not sure it warrants removal entirely. --Errant (chat!) 09:49, 6 December 2010 (UTC)
  • Comment This is more a problem with editors. The field should be there for the very large number of people for whom religion is important in their lives. However if you need to search to fill the field it shouldn't be filled, it should be something the sources say. Unfortunately some editors have this must fill every field complex, it is like the story of the wife of some composer who when she wanted to annoy him played do re mi fa so la te on the piano so he had to stand up and play do. Dmcq (talk) 12:31, 6 December 2010 (UTC)
  • Oppose , mostly per DustFormsWords. If sources concord on a religious affiliation, then we can fill the field. If they don't, we can leave it empty. It's easy. Let's not propose solutions to problems that don't exist. --Cyclopiatalk 12:37, 6 December 2010 (UTC)
  • Oppose For all the reasons listed. Sometimes, it is a relevent and highly citable fact, and should be included. Other times it is sketchy or irrelevent or unverified, and should be left blank. Not every field in every infobox needs to be filled in, and all that is needed is dilligence on the part of editors that care. --Jayron32 13:17, 6 December 2010 (UTC)
  • Oppose. Just because something can be abused does not mean it should be banned. Conversely, it would be rather silly to have an article about a member of the clergy that makes no mention of the subject's religious affiliation. A little common sense and editorial judgment is a better solution than requiring all situations be shoehorned into a one-size fits all interpretation that fails for a variety of common cases. --Allen3 talk 14:20, 6 December 2010 (UTC)
  • Support If someone's religious beliefs (or lack of) are of significance regarding their notability (which is the only reason they should be given at all), this should be dealt with in the body of the BLP text, where it can be discussed properly. Having a field in an infobox is an open invitation to fill it in for no good reason, and encourages sweeping generalisations. It is all very well saying diligence and care is needed from editors, but the evidence seems to suggest it isn't always being given. The inclusion of his infobox field is symptomatic of the wider the tendency for overcategorisation which is endemic in BLPs, detracting from the proper encyclopaedic treatment of subjects. It is also worth noting that the concept that one must actually have in identifiable religion (or a well-defined rejection of the concept) is not a universal one, being deeply rooted in the Judeo/Christian/Islamic traditions, but hardly applicable in all contexts. Maybe the 'religion' field needs to be removed from the infobox not because it can be misused, but because its very existence implies a non-neutral POV? I doubt I'll get far with this argument here, but it needs to be said. AndyTheGrump (talk) 16:30, 6 December 2010 (UTC)
  • there is no {{BLP infobox}}... but for example {{Infobox person}} documentation says "religion .. if relevant". I don't think deletion of the field (from the many BLP infobox templates which exist) is really helpful, but it may be that some specific infobox templates could have it removed, on the basis that religion simply isn't relevant enough for a BLP using that infobox. Also, we could have a bot add an HTML comment into every article with an infobox using the religion field, something like "this field should only be filled if relevant to the person's notability and well-sourced" or whatever. Rd232 talk 17:40, 6 December 2010 (UTC)
  • Support As AndyThe Grump mentioned above, giving a one word explanation of what can be a quite complex situation is an insult to most of the people we write about. There is no way my views could be expressed in less than a few sentences. In my country, Australia, the religion of others is not important at all to most of us. However, there is a minority that ALWAYS wants to add it to articles. In recent times this has led to very extensive argument on several articles. In particular, our new Prime Minister, Julia Gillard has declared that she is not religious. This has led to frequent attempts to edit that article to say that her Religion is Atheist. Several problems with that. Firstly, she didn't say Atheist, so it's synthesis. Secondly, Atheism is not a religion. Thirdly, those wanting to list such a status can often be seen to be doing so for POV reasons. It's all very unhealthy. And time wasting for serious editors trying to build a decent encyclopaedia. HiLo48 (talk) 00:36, 7 December 2010 (UTC)
  • Support removal too. Unlike DOB or gender or whatever, religion is something that is "unstable" I would say. Religion is a person's own belief, and may change without even his/her family knowing it. It is nearly impossible to get the necessary sources to verify this. If we keep such fields, am sure the disputes will never end. Rehman
  • Oppose Biographies of living people are just a small fraction of the biographies included in this site. If you are concerned about possible misuse at BLP by people thinking that if the field exists it should be filled, then simply include a disclaimer at the template documentation. MBelgrano (talk) 21:28, 7 December 2010 (UTC)
Comment - That's a minor part of the problem that can be easily addressed, as you say. What about the other issues mentioned above? HiLo48 (talk) 21:53, 7 December 2010 (UTC)
The other issues you list all fall under the category of "people editing controversially, in ignorance, or in bad faith", which in short is the problem of Wikipedia. There is no simple solution to it, and removing a field in an infobox neither resolves the problem or mitigates its damage in any but the most trivial of ways. The best way of managing the problem is talk page discussion plus the attention of a experienced editor with rollback privileges, not widespread template changes. - DustFormsWords (talk) 01:26, 8 December 2010 (UTC)
If there's a "trivial" way of reducing in any way the frequency of silly additions to articles, let's use it. HiLo48 (talk) 03:44, 8 December 2010 (UTC)
  • Trivial in the Wikipedian sense of trivia; i.e., having no place in an encyclopedia. The possible gain from this change in no way offsets the damage it does to our ability to provide clear readable at-a-glance information to readers, and the problem it proposes to solve is already well-managed through existing processes and procedures. - DustFormsWords (talk) 03:54, 8 December 2010 (UTC)
  • Oppose. There are a great number of cases where an article subject's religion is both pertinent and uncontroversial, and it's reasonable to have it in the infobox in those cases. For other cases, we just need to provide guidance on when to use that field an when not to. For the small number of cases where there's a continuing disruptive dispute - like this Ed Miliband case that is now on almost every noticeboard - the problem is caused by editors, not by the infobox parameter, and should be solved by addressing the cause of the problem. — Gavia immer (talk) 01:40, 8 December 2010 (UTC)
  • Oppose The content debate would still happen if the concept were presented in the prose instead of the infobox. This proposal does nothing to address the underlying problem, and merely removes a widely used field for the sake of convenience. Does where the content appears within an article make any difference? I don't believe that there are mobs of editors who suddenly decide that a suject's religious views are important to include because they've read the template documentation and seen that such a field exists. In fact, I often wonder how many editors read template documentation at all. Jim Miller See me | Touch me 01:51, 8 December 2010 (UTC)
  • Oppose per DustFormsWords. KillerChihuahua?!?Advice 01:54, 8 December 2010 (UTC)
  • Oppose Many people think that the writers T. S. Eliot and C. S. Lewis were members of the Roman Catholic Church (they were both members of the Church of England, although Eliot called himself an Anglo-Catholic). This is significant information that should be readily retrievable although not necessarily placed in the introductory paragraphs. The warning about entering religion only when it's undisputed and the editor is sure (preferably with Reliable Sources), should be put in <!-- pointy brackets --> on the Religion line of the Infobox template, not in documentation somewhere else. —— Shakescene (talk) 02:13, 8 December 2010 (UTC)
Comment - I would argue that religion should also not be displayed if it's not notable, which should be the case if it has no relevance to the reason we have an article about that person. Having the field in the infobox tells less experienced editors that it's ALWAYS notable if it can be identified. Another issue, already mentioned, is that of editors determined to label as atheist or agnostic those subjects who declare themselves to be something like "not religious" or "have no religion". It is very common, but clearly synthesis, and raises the question of whether atheism or agnosticism are valid entries for a religion field. They are clearly not religions. In summary, there are many ways in which that field can be wrongly used. Not good for Wikipedia. HiLo48 (talk) 03:56, 8 December 2010 (UTC)
There are many ways in which the "edit" and "revert" functions can be wrongly used, and wrong uses of them create vastly more damage than a religion field in an infobox. The problem is not in the tool but in the user. Removing the tool does not repair the user, who will doubtless pick up other tools and go on using them wrongly, and in the mean time legitimate users are hampered in their constructive work. The proper way to address these matters is through education, discussion, and a responsible level of attention to your watchlist. Also, for the vast majority of people we have articles on - ie, everyone born in the Western world between about 300 AD and 1960 AD - religion IS a key factor of their life, often moreso than their nationality, and on numbers alone that advocates for the inclusion of the field by default. - DustFormsWords (talk) 04:02, 8 December 2010 (UTC)
And there, in the certainty of that obviously POV statement, lies perfect evidence of the problem I am trying to discuss. It is debates exactly like this that take up so much time for editors trying to remove irrelevant entries from that field. HiLo48 (talk) 05:09, 8 December 2010 (UTC)
Sorry, I'm not saying that the majority of our bio articles SHOULD be about Westerners born 300 to 1940 AD, I'm saying that as a matter of statistical fact they ARE, and however much we might try to address cultural bias, the English Wikipedia is unlikely to change in the near future. For what it's worth, I'm not sure that adding in births pre 300 AD or a larger number of non-Western births addresses the problem; downplaying the importance of a religion seems to be, factually speaking, largely a conceit of the modern, Western, developed world. I speak here as an atheist myself, but also someone who's spent quite some time editing articles about people from the last century, who has, much to my irritation, found that determining someone's religion (or lack of one) in these older cases is a pretty crucial step to obtaining a proper encyclopaedic understanding of their life. - DustFormsWords (talk) 05:35, 8 December 2010 (UTC)
  • Oppose we are here to inform people with the verifyable facts, and this is one of them. If there is no information leave it blank and do not make up "none" or "Agnostic" unless that can be cited. Perhaps we need a prefil with a citation needed tag in comments. Graeme Bartlett (talk) 21:06, 9 December 2010 (UTC)
  • Oppose - Why remove it? Some, dare I say many people notable enough to appear in a Wikipedia article identify as a member of some faith - be it Christianity or atheism. If there is no info, leave the field blank. If someone actually has founded their own minor religion, sure, but that in the box. Just make sure it is sourced, obviously. Ajraddatz (Talk) 17:03, 11 December 2010 (UTC)
  • Oppose. If indeed an individual's religion is not clearly defined or fluid, don't try to sum it up in one word - don't put it in the infobox, put it in the article body. That makes perfect sense. But this is not true of everyone - there are many people whose religion is quite clearly defined, unambiguous, and notable to their life. Dcoetzee 18:36, 11 December 2010 (UTC)
I guess thats a no then - just thought I'd ask. MarkDask 20:45, 13 December 2010 (UTC)
Not an absolute no, Mark, but obviously a lot of people think it matters and, although they generally ignored the points of those wanting it gone, there's no chance at this stage of getting rid of it. I still argue that a strong instruction to editors at that field of the infobox would help, because I've certainly had to clean up some rubbish from it. And no-one seemed to want to pick up on my point that agnostic is not a religion. HiLo48 (talk) 21:21, 13 December 2010 (UTC)

OpenID revisited

It's time to stir the pot again and get some fresh eyes on the issue of using OpenID on Wikipedia. See WP:OpenID Proposal. I don't see any technical details holding us back from at least being able to attach an external OpenID account to your Wikipedia account, and subsequently being able to log in via your OpenID provider of choice. It would be opt-in, so wouldn't hurt those that don't understand how OpenID works.

Can we reach a consensus here, and then perhaps put pressure on the techies at Bugzilla to get it done? Bug 9604 is already filed for the purpose of "Support[ing] OpenID extension on all wikimedia projects", and the featured proposal Strategy:Proposal:Support_OpenID has the same idea. Let's lead the way at en.wikipedia. ...comments? ~BFizz 23:44, 11 December 2010 (UTC)

Im a pretty big fan of technologies that sit on top of other systems (Google Voice is Jesus, just sayin') so I dont want you to be scared by this question. It's not a big hurdle. But can you just give me a couple advantages one would gain from using an OpenID-linked account? Im only vaguely familiar with it, and even that passing knowledge is some years out of date. Mainly I remember it showing up on livejournal back in the first half of the decade and want to know if this is a 'cause we can' thing, or if its a 'this will benefit people who want to do X' thing. -- ۩ Mask 16:25, 12 December 2010 (UTC)
I ask because from your proposal, it reads to me that its to store all your login information under one password, but that feature would seem to be a reimplementation of the accounts manager in firefox and chrome. -- ۩ Mask 16:28, 12 December 2010 (UTC)
Sure. Advantage 1: OpenID works regardless what computer you're using; browser-based accounts managers only work for the computers they're installed on. Advantage 2: With many OpenID providers, once you're logged in you stay logged in until you log out - so you wouldn't have to re-enter your password in order to log into Wikipedia, you would just hit a "sign in with OpenID" button and choose your OpenID provider, which is more secure (because A. your password isn't sent over the ether again and B. there's nothing for keylogging software to read). Hope that helps. waggers (talk) 15:40, 13 December 2010 (UTC)
The 'accounts manager' type things are okay. But for one thing: they don't work across computers, and they don't work across browsers. They are very clumsy implementations of a secure keyring type system. OpenID is much more preferable to how it is now. –Tom Morris (talk) 20:04, 13 December 2010 (UTC)
Those are more then sufficient to justify it for me, I can support this without reservation. -- ۩ Mask 02:07, 14 December 2010 (UTC)

Enable Sub Pages in article space

I've been thinking about this a long time so pleas don't blow me off too quickly. Enable sub pages in main article space, instead of only sub talk pages. (For better AND for worse, one must recognize that talk pages are voluminous and transient. Anything written will be unseen as soon as there are a few more entries, and then a needle in the haystack of the archives shortly after that.) These would have two purposes:

  • Enable organized, structured discussions on major topics and "projects" within an article. This would enable editable, summarizable work on the sub-article page, and regular discussion on the related sub-article talk page. An example of existence and showing reasons/benefits for existence is use of this structure for mediation cabal work.
  • A practice could be set up of designating a particular name subpage to record major decisions and other semi-permanent records regarding the article. For example, if the editors spent a month consensusing a lead paragraph, such would be recorded there. Right now the only record gets lost in the talk page archives. The everybody forgets that such a major effort arrived at that decision. This would help provide a little extra stability for unstable articles. North8000 18:48, 9 December 2010 (UTC)
It's perfectly reasonable to try and use subpages in the way you suggest - but I see no reason at all why the subpages need to be in articlespace. They just need to be organised properly and linked suitably from the top of the talk page. Rd232 talk 19:33, 9 December 2010 (UTC)
Where else would they be? I may be mistaken, but the only places I know where you can create the "project-talk" pair of pages is user space and essays. And I was thinking that it would be much better to associate them with the article that they are for. Sincerely, North8000 19:59, 9 December 2010 (UTC)
Where else? For example Talk:Interesting Topic/Intriguing Discussion and Talk:Interesting Topic/Much Ado About Nothing, Please Don't Bring It Up Again, with both prominently mentioned at the top of Talk:Interesting Topic. Rd232 talk 20:59, 9 December 2010 (UTC)
I believe this was disabled to allow for articles where a slash is used. Nip/Tuck, for example, would be named "Tuck" as a subpage of "Nip" if we allowed subpages in articlespace. Killiondude (talk) 20:02, 9 December 2010 (UTC)
I knew that such a change would require taking slashes out of article titles (which I think is rare) but never heard that that was the reason. Seems like the tail wagging the dog! North8000 20:06, 9 December 2010 (UTC)
But you can make subpages of talk pages, so making subpages of articles isn't necessary. Fences&Windows 21:43, 9 December 2010 (UTC)
Even now, Talk:Nip/Tuck is seen as a subpage of Talk:Nip as well as the talk-page of Nip/Tuck, which is...confusing. DMacks (talk) 21:51, 9 December 2010 (UTC)
Discussion of articles does not belong in article space, on subpages or not. Discussion belongs on the talk pages. Neither does record of editorial decisions belong in article space, except in exceptional cases a note may be included at the trouble-spot in <!-- a hidden comment --> in the wikitext. Anomie⚔ 22:02, 9 December 2010 (UTC)

To RD232: But those are talk pages, with their limitations which would not provide the discussed advantages.

To: Anomiex You are stating a rule that does not exist, (that article work should not be put on a non-existent type of page) as a reason to keep that type of a page from being brought into existence.

To:Jim Miller. Thanks for that info. Your one comment implies article content on non-article pages, which would continue to be prohibited. Sincerely North8000 22:17, 9 December 2010 (UTC)

"the discussed advantages"? You haven't given any advantages from article subpages which talkpage subpages wouldn't have. Rd232 talk 00:53, 10 December 2010 (UTC)
Maybe I am confused, but your original proposal seemed to be about placing talk page material into an article space subpage. I was counting on the responses above in pointing out that doing that is prohibited. Discussions about articles only belong on talk pages. The point about subpages still holds. When you edit or watch an article, the talk page is automatically added to your watchlist. This does not happen with subpages in either space. I just wanted to point out that creating new subpages results in unwatched pages, and the last thing needed in any namespace is more unwatched pages. Jim Miller See me | Touch me 23:59, 9 December 2010 (UTC)
Unwatched pages is a fair point. This sort of subpaging should be kept pretty much for historical records of discussions organised by topic, or the most highly active talk pages, where any other approach is impractical. It would be different if we had the ability to watch all subpages of a page with one click... Which shouldn't be too hard to do, certainly in software, but perhaps even with a gadget? Rd232 talk 00:53, 10 December 2010 (UTC)

Perhaps I would explain myself better by describing the intended results rather than the technicalities on how to get there. And, for simplicity / and in hindsight, I'd drop my "permanent record" goal from the discussion. So it is:

The ability to attach a 2 page workspace to an article for for larger projects, consensusing etc. done in the course of work on an article. 1/2 is the "project" page for the temporary project which, without WP talk page rules, is the condensed, editable "work product" of the discussion. For example, a developoing draft of a large new section which is being worked on or debated, or a list of references that being developed/debated. The other half is the talk page associated with that workspace. For example, this structure is already used for mediation cabal cases related to the articles, with good reason ....such a structure is needed and useful. But is not otherwise available. North8000 02:32, 10 December 2010 (UTC)

I have sort of informally set these up on talk pages when informally mediating / organizing larger scale discussion, (e.g. by defining and setting up an "editable workspace" in a talk page, or defining a talk subpage as an "editable workspace") , but it is very awkward to people because it is contrary to the normal talk page rules, and also it gets "lost" in older sections (while still active) if it is an active talk page. And, in the case where a talk subpage is set up as an "editable workspace" then it has no talk page linked to it, and then it's discussion gets scatted to the four winds in the main article talk page. North8000 02:39, 10 December 2010 (UTC)

A talk subpage still has its own article/talk page pairing. See eg Talk:Provisional Irish Republican Army/draft. Rd232 talk 08:57, 10 December 2010 (UTC)
If I am understanding you properly, you are referring to use of the main article talk page as the talk page for the sub-workspace. That was the "scattered to the four winds" situation that I was referring to. We have one of those going at [[4]] which one of the examples that led me to suggest this. Sincerely, North8000 10:22, 10 December 2010 (UTC)
OK, I understand your point better now. There are two existing options here: (i) have the draft in a user's userspace whilst it's active, where it has the usual project/talk pairing, and then archive to several talk subpages when done (ii) reproduce that pairing on a talkpage subpage, eg Talk:Provisional Irish Republican Army/draft and Talk:Provisional Irish Republican Army/draft-talk, with a note on the top of each page pointing to the other (see those examples). Rd232 talk 17:49, 10 December 2010 (UTC)
Thanks for idea, which I will use. I do think that it would be good to implement the intent of my idea for more general use. Even if not via. enabling sub-pages in article space. Possibly it could be just a guideline to pair two sub-talk pages, and to re-define one of them as an editable workspace. North8000 13:18, 11 December 2010 (UTC)
Good idea - it could be a Help page, or just a paragraph in an existing page. I do think these kinds of drafts can be very helpful and should be encouraged. Rd232 talk 13:43, 12 December 2010 (UTC)
I'm going to try it on a few articles. Eventually might write a suggested framework as an essay. Otherwise everyone who does this will need to make up stuff each time. North8000 15:29, 15 December 2010 (UTC)
Help:Talkspace draft. Rd232 talk 22:31, 17 December 2010 (UTC)

Enable edit notices in project namespace

I think there could be many benefits, and relatively few disadvantages in allowing registered users to add edit notices to the top of WikiProject pages. Can they be enabled for pages that begin with Wikipedia:WikiProject ? - ʄɭoʏɗiaɲ τ ¢ 21:07, 14 December 2010 (UTC)

Please don't - they're annoying enough everywhere else, I'd rather get rid of them from all namespaces. DuncanHill (talk) 21:10, 14 December 2010 (UTC)
Those are probably individual examples that you find annoying, and not the ability itself. I'm looking to just be able to add a note or two at the top of project pages to help direct users to the correct venue. The BLP ones are annoying though, I'll admit. - ʄɭoʏɗiaɲ τ ¢ 21:14, 14 December 2010 (UTC)
I've never seen one that I didn't find annoying. DuncanHill (talk) 01:14, 15 December 2010 (UTC)
Start a discussion on the project's talk page about your proposed note, and if it gets consensus it will be easy for an admin to create the editnotice. Anomie⚔ 21:19, 14 December 2010 (UTC)
You might be interested in WP:CSSHIDE. Each editnotice should have its own ID, so you can hide it using your CSS file. Rd232 talk 21:38, 14 December 2010 (UTC)
Why waste an admins time? I see it on some project pages (eg here), but not on others. Why would this wikipedia namespace page have a placeholder for one, but others not? - ʄɭoʏɗiaɲ τ ¢ 22:50, 14 December 2010 (UTC)
It's really not a big deal to make or handle a request on a case-by-case basis, or even (using templates) to request a standard template be added to pages X,Y,Z. The problem with allowing it generally is that a lot of these pages aren't much watched or edited, which makes it more likely abuse of various kinds would stick around unacceptably long. Rd232 talk 01:01, 15 December 2010 (UTC)
I like editnotices :3 - Beyond that, I don't see how some in the WikiProject space would hurt anything. Ajraddatz (Talk) 15:16, 15 December 2010 (UTC)

{{PD-self}} -> {{Self|Cc-zero}}

I propose changing {{PD-self}} to {{Self|Cc-zero}} on all upload forms. Why? We live in a world of open standards. We already use a lot of Creative Commons templates to indicate license status, but for indicating that something is released into the public domain by the author, we have our own custom template. By changing this we make it easier for authors and (re)users to determine the license status of a work. At Commons we already changed see this topic. multichill (talk) 20:09, 24 November 2010 (UTC)

It's strange to "brand" a public-domain dedication, but the CC dedication is worded better. "To the greatest extent permitted by law", etc. I say go for it. —Noisalt (talk) 20:33, 24 November 2010 (UTC)
There's nothing wrong with CC-0 (but see below), but I don't think we should use it as our default public domain dedication, which is how it will be perceived if we make this change. Creative Commons doesn't own the concept of the public domain, and we shouldn't imply that they do. Having said that, I don't personally like the {{Pd-self}} wording either. Like CC-0 and most other PD boilerplate texts, it is just not strong enough against the potential of judicially-invented "rights" that weren't given away in the original dedication because they didn't exist - and the history of "moral rights" in European jurisprudence implies that such double-secret rights will continue to be invented. I'd much rather see us use language in line with the PD portion of User:Gavia immer/Copyright, though I suspect most people don't share my exact views on the matter. — Gavia immer (talk) 21:46, 24 November 2010 (UTC)
  • Support, but I wonder why we still have an upload form for English WP. It is a free encyclopedia that needs free images. We should only use the upload form of Commons.--Wickey-nl (talk) 12:35, 29 November 2010 (UTC)
    • Because we still allow fair-use images even if we'd prefer free images, and because there are some images that are considered free here that are not at Commons. Anomie⚔ 16:38, 29 November 2010 (UTC)
      • I do believe it's actually the other way around in terms of somethings being free in one place but not another. In many Germanic countries the standard of originality is much, much higher then here. The canonical example is the Star Wars logo. Being just text on a black background it does not qualify for copyright in Germany or the Netherlands and is (was? Last time this came up was back in 06 i think) hosted at commons. I believe that was the entire point of us putting down some servers in Europe if I remember right, de.wiki was getting a little upset at American rules being used on commons. -- ۩ Mask 02:15, 12 December 2010 (UTC)
  • I agree with Gavia above. Nothing wrong with CC-0, but there's nothing wrong with our standard PD templates. Killiondude (talk) 17:15, 29 November 2010 (UTC)
  • Support - CC0 is certainly much better designed, legally, than anything we can come up with. CC's goals are very much in line with our own, so the "branding" thing is a non-issue IMO. Mr.Z-man 00:24, 1 December 2010 (UTC)
  • Support. Commons has already done this recently. However, note that we cannot redirect PD-self to CC0, or otherwise mass convert PD-self to CC0, because they are not legally equivalent (among other things, CC0 waives neighboring rights). Of course CC0 media should be uploaded at Commons, not here, but some newbie users are not comfortable travelling to another wiki to contribute. Dcoetzee 01:49, 1 December 2010 (UTC)
  • comment The main issue I see s that very few people know what CC-0 means, but they will probably have heard of public domain. However it does have the advantage that releasing something to public domain is not possible in many countries. And those moral rights that cannot be released apply whether it is either license anyway. Graeme Bartlett (talk) 09:39, 1 December 2010 (UTC)
  • Support but please keep in mind that we can't just redirect (or "retransclude" if you want to be technical) for reasons similar to those behind {{GFDL-with-disclaimers}} (i.e. for legal reasons) since PD-self is not precisely the same as cc-0. Also, the wording of cc-0 is such that any rights invented by anyone are also waived by it. --NYKevin @771, i.e. 17:29, 3 December 2010 (UTC)
  • Support concept, but shouldn't we be sending these uploads to Commons?!?!? ǝɥʇM0N0farewell 23:34, 9 December 2010 (UTC)

Open Plaques integration

I'm not sure if this is the best place to put this: it may be better as an RFC but I'll start here and see where it goes.

I'm a developer on the open source codebase behind Open Plaques, a public domain database of commemorative plaques that are attached to buildings in the UK (and increasingly elsewhere). Each person in the Open Plaques database tends to have a link to Wikipedia (en) and reuses the lede from Wikipedia. We are also using RDFa to link through to DBpedia.

At the London Wikimedia meetup yesterday, I discussed with Fæ how it might be possible to link together Open Plaques and Wikipedia more. One way I am looking into is how Open Plaques can reuse images from Commons: we use Creative Commons licensed images on Flickr, but we could also start using images from Commons, and we may also want to start allowing people to upload images straight to the site, in which case, we might look into storing those images on Commons rather than either having to host them ourselves or, say, get a Flickr account.

The other way we can integrate is through links. We are already linking to Wikipedia. And Thomas Turner (diarist) and Hawkhurst (and possibly others) link to Open Plaques. I'd like to suggest that the Open Plaques community may be able to contribute to Wikipedia by creating a bot: basically, this bot would add an Open Plaques link to Wikipedia articles every time a new person gets added to our database. This could be removed if it was felt inappropriate by the community of people who edit the article in question. We could have a template which would link by id specifically, which could be updated easily if our database changes.

I don't know if this is appropriate or how we go about seeking consensus from Wikipedians and Wikimedia in general, so I'd love to hear advice on whether this kind of thing is practical and desirable. Thanks in advance. —Tom Morris (talk) 20:23, 13 December 2010 (UTC)

The problem with using a bot is that you may need human intervention to confirm that the correct article is being linked to the plaque. For example, Open Plaques has an entry for James Watson and the English wikipedia has seventeen articles for people named James Watson, two for Jamie Watson and eight for Jim or Jimmy Watson. That's a lot of potential for making the wrong connection. Does the volume of material really justify creating and maintaining a bot? How many new people get added to your database every month? Perhaps using humans to make the link would provide a useful opportunity for cross-checking the quality of data. - Pointillist (talk) 22:14, 13 December 2010 (UTC)
Thanks for the response. We do use humans on our side to check that the person we link to is the right person! Internally, we store a Wikipedia URL for each person and use that for both the visible links, pulling the lede in and linking to DBpedia. Rather, I think the questions that we'd like to hear about from the Wikipedia community are:
1. Would it be considered spammy if we were to add links to articles to Open Plaques given that we are both producing 'open content' material?
2. If not, would it be acceptable to create a bot to add those links automatically?
If the answer to (1) is yes, that's fine, we won't do it. We don't want to be dicks! But if it is okay for us to add links, it would be easy for us to add a little callback to our software that would queue up a bot to go and edit the relevant Wikipedia article automatically, as it would then come from a bot account. It'd be easier for us to have a bot as we wouldn't then be reliant on having someone in the community remember to go and put a link back from the Wikipedia article. —Tom Morris (talk) 22:21, 13 December 2010 (UTC)
(2) would generally be decided via WP:BRFA. --Cybercobra (talk) 08:15, 14 December 2010 (UTC)
Note that the community can and should decide now whether they want these links and want them added by a bot, or BAG may well send the question back here for discussion. Anomie⚔ 13:28, 14 December 2010 (UTC)

There is also the problem of copyright on the texts of the plaques. Commons for instance is seriously considering dumping more images of plaques because of questionable copyright status. Something to keep in mind. —TheDJ (talk • contribs) 15:46, 18 December 2010 (UTC)

Interactive tables

I think it would be a major improvement for mediawiki software to implement an upgrade to make tables to be more interactive. When I say that I am thinking about the ability to show/hide some rows and columns, defined in some kind of profile. Take for example this list: List of countries by population. For example an interactive table would be capable to show the countries of a single continent, and hide those from other continents, when the user needs that. Also would help the user see the first 5 countries from each continent for example. When you have a conversation with someone, you might want to show just some of the data in the table, therefore you would like to be able to hide the columns 4,5 and 6, because they are not relevant in your discussion. Profiling tables would mean adding some filters (simple or sophisticated), or simply to manually define each profile. However implemented in the software, I don't think it would ask for extensive work from the programmers, also it won't load the browser with too much JavaScript, but it would be for sure a MASSIVE improvement for the way data can be presented and make use of. Thanks. —  Ark25  (talk) 03:17, 16 December 2010 (UTC)

Someone is currently working on integrating http://tablesorter.com into the new version of MediaWiki, to replace our older tablesort code. What you want to do is better suited for a database in my opinion, not for an article. Semantic MediaWiki may be the answer here, but SMW is a lot of unreviewed code and has the potential to have huge effects on our caching services and system load (at least last time I looked into it). —TheDJ (talk • contribs) 15:38, 18 December 2010 (UTC)

styling <references /> like Reflist

Main page: Template talk:Reflist
Further information: [[:User:CBM, a case of WP:WIKIHOUNDING?]]; [[:Blocked for following WP:BRD?]]; [[:Change to template:reflist fontsize wiki-wide?]]; and [[:Change to Common.css]]
See also: #Recommending columns in reference lists longer than 20 entries

It has been proposed to change Mediawiki:Common.css so that <references /> has the same styling as {{Reflist}}. This ensures standardisation. If this is done, it doesn't matter formatting-wise which of <references /> and {{Reflist}} is used, unless a page needs the advanced options of {{Reflist}}. A discussion on this was open for 2 weeks and had a strong consensus, and was then automatically archived for lack of activity: see Wikipedia:Village_pump_(proposals)/Archive_67#Change_to_template:reflist_fontsize_wiki-wide.3F. What does the styling change entail? Making references sections consistently displayed at 90% font size. It should be noted that we now have a new Gadget "Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists." (see MediaWiki:Gadget-NoSmallFonts.css). Rd232 talk 12:34, 13 December 2010 (UTC)

IIUIC, putting
ol.references { font-size: 100% !important }
to User:JohnFromPinckney/vector.css (assuming you use the vector skin) should do the job.—Emil J. 15:00, 13 December 2010 (UTC)
As stated above, there is a Gadget to do this. Look in your Preferences under Gadgets for ""Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists." Rd232 talk 15:32, 13 December 2010 (UTC)
Which may or may not be what the user wants, he didn't say anything about infoboxes or navboxes.—Emil J. 15:57, 13 December 2010 (UTC)
True, but the reason the gadget's that way is the assumption that if you don't like refs 10% smaller, you don't like the other stuff smaller either. If that's not generally the case, maybe the Gadget needs splitting (can gadgets have options)? Rd232 talk 19:20, 13 December 2010 (UTC)
The idea is that, references should be all of the same size by default, except when explicitly specified by editors. Consider
Examples
<references/>
A great number of hadrons are known (see list of baryons and list of mesons), most of them differentiated by their quark content and the properties these constituent quarks confer. The existence of "exotic" hadrons with more valence quarks, such as tetraquarks (
q

q

q

q
) and pentaquarks (
q

q

q

q

q
), has been conjectured[1] but not proven.[nb 1][1]
Notes
  1. ^ Several research groups claimed to have proven the existence of tetraquarks and pentaquarks in the early 2000s. While the status of tetraquarks is still under debate, all known pentaquark candidates have since been established as non-existent.
References
  1. ^ a b W.-M. Yao et al. (Particle Data Group) (2006). "Review of Particle Physics: Pentaquark Update" (PDF). Journal of Physics G. 33 (1): 1–1232. doi:10.1088/0954-3899/33/1/001.
Versus
{{reflist}}
A great number of hadrons are known (see list of baryons and list of mesons), most of them differentiated by their quark content and the properties these constituent quarks confer. The existence of "exotic" hadrons with more valence quarks, such as tetraquarks (
q

q

q

q
) and pentaquarks (
q

q

q

q

q
), has been conjectured[1] but not proven.[nb 1][1]
Notes
  1. ^ Several research groups claimed to have proven the existence of tetraquarks and pentaquarks in the early 2000s. While the status of tetraquarks is still under debate, all known pentaquark candidates have since been established as non-existent.
References
  1. ^ a b W.-M. Yao et al. (Particle Data Group) (2006). "Review of Particle Physics: Pentaquark Update" (PDF). Journal of Physics G. 33 (1): 1–1232. doi:10.1088/0954-3899/33/1/001.
Versus
Hybrid
A great number of hadrons are known (see list of baryons and list of mesons), most of them differentiated by their quark content and the properties these constituent quarks confer. The existence of "exotic" hadrons with more valence quarks, such as tetraquarks (
q

q

q

q
) and pentaquarks (
q

q

q

q

q
), has been conjectured[1] but not proven.[nb 1][1]
Notes
  1. ^ Several research groups claimed to have proven the existence of tetraquarks and pentaquarks in the early 2000s. While the status of tetraquarks is still under debate, all known pentaquark candidates have since been established as non-existent.
References
  1. ^ a b W.-M. Yao et al. (Particle Data Group) (2006). "Review of Particle Physics: Pentaquark Update" (PDF). Journal of Physics G. 33 (1): 1–1232. doi:10.1088/0954-3899/33/1/001.
The idea is that that <references> and {{reflist}} give exactly the same result (that is small sized references) because currently the articles are inconsistent between each other (some have normal references, others have small references). If your concern is that you want the possibility to have something like the hybrid case, i.e. the "explanations" in normal size, and references proper to be small sized, that could be achieved by something like {{reflist|group=nb|size=normal}} (it's not yet implemented, but it would be trivial to add). If your concern is that you don't want to read the small size references at all, then you could set this in your user preferences. Headbomb {talk / contribs / physics / books} 15:06, 13 December 2010 (UTC)
(Please note the the collapsed box reduces the font-size of the small refs to 88% instead of the proposed 90%) — Edokter • Talk • 17:18, 13 December 2010 (UTC)
The problem is that most Wikipedia users don't know how to edit css files. They will either stay or leave depending on whether the site is easy to use and easy to read. Racepacket (talk) 17:36, 13 December 2010 (UTC)
They don't need to edit CSS files - there's a Gadget for those as wants. Otherwise, if you really think 90% is that bad that we shouldn't use it at all (particularly with readers in mind who aren't logged in), then make an alternate proposal to standardise the other way: styling reflist like references/, at 100%. Rd232 talk 18:33, 13 December 2010 (UTC)
There will be no "size=normal" parameter built into {{reflist}}. The whole point of consistency is that there will be no deviations from the norm. — Edokter • Talk • 21:29, 13 December 2010 (UTC)
Consistency doesn't have to be either/or; we could still permit limited exceptions here, with a style-guide suggesting when it may be used (not just because someone prefers the old style, but a specific reason). Rd232 talk 21:33, 13 December 2010 (UTC)
Those exception must probably not use {{reflist}} in the first place then. — Edokter • Talk • 22:06, 13 December 2010 (UTC)
Thanks for the comprehensive examples. My concern wasn't to get to the hybrid case, as I don't see that as desirable (it's inconsistent within the page and it includes smaller-than-normal text). I was really trying to find out how I could add references to an article such that both or all three of them are in a full-size readable size, not so much for me, but for every reader of that Wikipedia page.
I understand and accept that articles with 50 or more refs benefit from somewhat smaller ref lists, and on those I use {{Reflist|colwidth=25em}} or similar. But articles with one or two refs don't need shrunken references, and the standard font size on Wikipedia is, AIUI, already less than 100% of users' default font size. I thought there was some statement at WP:ACCESS about aiming for full-size text, but I don't see it there now.
Apparently, though, the consensus is already that <references /> and {{Reflist}} must produce the same size results across WP, and the discussion here is just how to get that to happen without deprecating <references /> immediately and have a bot replace it with Reflist. The documentation at Template:Reflist#Font size appears to be badly out of date in any case and needs to be changed, at the very latest when this proposal is adopted. — JohnFromPinckney (talk) 22:27, 13 December 2010 (UTC)
  • Question Sorry for asking what may be a dumb question for which this may be the wrong forum, but if (as this proposal suggests) {{reflist}} is superior to <references> why is the latter still an option (beyond legacy reasons). As an editor it has always been (unnecessarily) confusing to me why there are two options for references.Ajbpearce (talk) 00:07, 14 December 2010 (UTC)
    • Answer: The <references/> tag is standard MediaWiki markup that the MediaWiki software translates into a list of references (just like the <ref>...</ref> tags are used to tell the software that the text between the two tags is a reference). <references/> does not support customizable options, as far as I know. {{Reflist}}, however, is a template, which does support customizable options, allowing flexibility in the formatting of the reference list. [|Retro00064|☎talk|✍contribs|] 00:44, 14 December 2010 (UTC)
    • Reply: Ok, I (think) I understand that, but is there a reason instances of <references/> are not simply hunted down by a bot and replaced by the more versatile {{Reflist}} template on enwiki?Ajbpearce (talk) 01:16, 14 December 2010 (UTC)
      • Answer: One part/argument of this issue at hand (making <references/> the same as {{Reflist}}), is the "established style in the individual article" argument. The fact that people both agreed and disagreed with replacing <references/> with {{Reflist}} meant that is would not be acceptable to go and replace all of the instances of the former with the latter without consensus. Depending on the end consensus resulting from this proposal, it may well be decided to replace all instances of <references/> with {{Reflist}}. [|Retro00064|☎talk|✍contribs|] 01:38, 14 December 2010 (UTC)
        • If the change proposed here was made, there would be no reason to replace "<references>" with "{{reflist}}", because they would give exactly the same appearance. The reason to make the change via CSS is to avoid having to edit all those pages. However, the underlying question of the proposal is to decide whether the appearance should be the same; it does come down, in some sense, to editors' opinions on standardization. — Carl (CBM · talk) 01:45, 14 December 2010 (UTC)
        • Ok, thanks for your helpful replies. too Support the change now, for what its worthAjbpearce (talk) 18:27, 14 December 2010 (UTC)
  • Comment. Has anyone noticed that on the default skin (Vector), {{reflist}} doesn't give smaller text and columns, but gives exactly the same as </references> gives? Fences&Windows 00:19, 14 December 2010 (UTC)
Yes, I noticed that, and in fact raised it as an issue when Vector was introduced. Someone pointed me to a fix that I added to one of my user configuration files, which restores the small type, but only, of course, when I'm logged in. If there is interest, I'll go back and find the thread, and the fix. --Tryptofish (talk) 00:35, 14 December 2010 (UTC)
Actually, the font is smaller, but may not be noticable. On Windows with default fonts, 90% results in tighter letter spacing and smaller capitals, while lowercase letters remain essentially the same size. — Edokter • Talk • 00:58, 14 December 2010 (UTC)
Oh, that's right. Drat, I really like it smaller. But no matter, consistency trumps my personal taste. --Tryptofish (talk) 01:54, 14 December 2010 (UTC)
I mentioned above that there is a way, if one wants, to change how the font size is displayed for oneself under Vector. Please note that this configuration only affects how you see it when you are logged in, no effect on how the rest of the world sees it. But if you have a personal preference for larger or smaller sized font displays, you can put this, with a percent of your choosing, into your own Vector.css file:
/* Set the font size for {{reflist}} */
 .references-small { font-size: 88%;}
--Tryptofish (talk) 21:17, 17 December 2010 (UTC)
  • Support. Coincidentally, F&W just asked a question about exactly the issue that interests me the most about this question. It seems that, with Vector, there is even greater inconsistency from one (computer? operating system? video driver? browser? phase of the moon?) to another. Yes, consistency is exactly what we should want, and this proposal may fix an inconsistency in Vector. Let's do it! --Tryptofish (talk) 00:35, 14 December 2010 (UTC)
  • Support again. As I mentioned in the previous discussion, I find the reduced-size references abhorrent, and I think everyone else should too. We won't ever get to proper reference formatting without eliminating all the variants that would be used to reimplement some editor's belief that reduced font sizes "look nice", so I support this necessary first step. — Gavia immer (talk) 01:05, 14 December 2010 (UTC)
  • I support the change. I generally agree with Gavia immer, but I think that over time it is becoming less sustainable to have a difference between the two ways of displaying footnotes, and I think that moving all the style to a single CSS class has advantages. — Carl (CBM · talk) 01:41, 14 December 2010 (UTC)
  • Support the change. As to the complaints about vector, I can't understand why anyone would use it. I've never seen a skin for anything that did more to get in your way then Vector does. It seems built to hinder your productivity and exploration. And that's in addition to being butt-ass ugly. -- ۩ Mask 03:19, 14 December 2010 (UTC)
  • Support these should give the same result as each other. -- Eraserhead1 <talk> 08:38, 14 December 2010 (UTC)
  • Support. There was clear consensus on previous discussion as well. The only genuine objection was on the grounds that Reflist makes the text too small. That does appear to be a sideways objection as the aim here is simply standardisation - if there is genuine concern that Reflist makes the text too small, then that is a discussion about how we approach the formatting of citations in general, as the text size problem will remain even if these Wiki-codes are not merged (as Reflist is widely used). And if the codes are not merged, that leaves open the possibility of edit warring, which is inappropriate. Let's merge, and someone may later open a separate discussion about accessability issues re text size on the formatting of citations if they wish. SilkTork *YES! 11:36, 14 December 2010 (UTC)
  • Support - make the look more uniform across all Wikipedia articles. עוד מישהו Od Mishehu 11:56, 14 December 2010 (UTC)
  • Support. Standardizing the display of the references is a good idea, IMO. Kaldari (talk) 02:50, 16 December 2010 (UTC)
  • Support per SilkTork's reasoning. Diderot's dreams (talk) 02:58, 16 December 2010 (UTC)
  • Oppose The last thing we need to be doing is making the already tiny font size smaller in even more places. We really should be doing the opposite right now: making {{References}} display at font size 100%. access_denied (talk) 03:12, 16 December 2010 (UTC)
  • That's why there's a gadget for people who need to see larger text. 90% is not extremely small; in many books and other publications, footnotes as smaller than the main text as well. /ƒETCHCOMMS/ 16:31, 16 December 2010 (UTC)

Since implementation

Is it just me or did the edit have the result that {{Reflist|colwidth=30em}} no-longer function with all 3 columns? Not sure how many people use browsers with this capability but think this should be addressed.Moxy (talk) 18:12, 21 December 2010 (UTC)

Purge your cache if anyone sees bigger font sizes. — Edokter • Talk — 22:39, 21 December 2010 (UTC)

Question

I was told elsewhere that the vector skin abhorred the smaller typeface. Is this so? And if so why do we not make Monobook work the same way? Rich Farmbrough, 01:27, 22 December 2010 (UTC).

Help:Talkspace draft

So, inspired by a recent thread, I've created Help:Talkspace draft, adapted from Help:Userspace draft. Can use some improvements, but I hope the basic idea is clear. What do people think? Rd232 talk 15:30, 13 December 2010 (UTC)

I don't like this part: "...to be implemented in the article itself, list the page at Wikipedia:Cut and paste move repair holding pen, so that an admin..." Inherently, multiple-user drafts would create a nonsensical history if merged. (It's unfortunate that MediaWiki does not support "rapid branching and merging" like version control systems such as git.) At the very least, I would avoid this type of draft if possible, and only if the draft is necessary, either a) add some "draft ID" to the edit summary to make it possible to easily reconstruct the history when needed; or b) list all involved users on the main talk page or in the edit summary and not merge histories. In the long term, we should make improvements to better track drafts, e.g. allowing an edit to be attributed to multiple users and seamlessly link to a draft page that is auto-protected after the draft is merged. PleaseStand (talk) 21:39, 13 December 2010 (UTC)
OK, I've changed that, so the instructions say to copypaste and provide a permanent link to the draft page in the edit summary. OK now? Rd232 talk 21:44, 14 December 2010 (UTC)

Note: there is related discussion about the nature/purpose of this thing at Template_talk:Talkspace_draft. Rd232 talk 22:58, 21 December 2010 (UTC)

Redlinked images and deletion logs

Is there any way we can get a deletion log to show when clicking on a redlinked image link? Powers T 14:03, 15 December 2010 (UTC)

Put importScript('User:Gary King/show upload deletion logs.js'); to User:LtPowers/vector.js (or whatever skin you are using).—Emil J. 14:22, 15 December 2010 (UTC)
That's a good workaround but I would prefer a more integrated solution. Powers T 14:44, 15 December 2010 (UTC)
Me too. If it could at least be turned for admins. But also for normal editors the deletion log seems to be more practical than immediately the upload screen. Garion96 (talk) 15:36, 15 December 2010 (UTC)
This was basically something that broke in 1.16, it should be fixed again in 1.17 —TheDJ (talk • contribs) 15:41, 18 December 2010 (UTC)
This should be in the server or toolserver; importing random user scripts while logged in as an admin isn't a bright idea. 67.117.130.143 (talk) 02:06, 20 December 2010 (UTC)

Merging accounts' contributions into a single list

For some purposes, not least understanding multiple-sock behaviour better, it would be helpful to able to merge multiple accounts' contributions into a single list. It would be great if the software could do this somehow (where it would also help transparency of legitimate alternate accounts), but in the mean time, it ought to be not that hard for a toolserver tool to do this: put multiple accounts' contribs together in the usual date order, with maybe different accounts in different columns. Or perhaps this already exists, and I missed it. Rd232 talk 22:51, 17 December 2010 (UTC)

That shouldn't be technically difficult to do (SELECT whatever WHERE account IN { list }), but if you want it for examining potential sock-puppetry patterns, you'll need to create your own list of the accounts to be selected. I can see how such reports would help identify IP-range vandalism and spamming patterns, but a feature like that would also make it easier for people to do more intrusive—and maybe less well-intentioned—investigations than were possible hitherto. - Pointillist (talk) 23:20, 17 December 2010 (UTC)
This should be pretty easy to implement with an API client, either on the toolserver or on your desktop. I'm not persuaded it's really worth putting into the server. How often do you actually want such a thing? 67.117.130.143 (talk) 00:35, 20 December 2010 (UTC)
Well it would be a useful part of many a sock investigation. Rd232 talk 01:25, 20 December 2010 (UTC)
I'm sure there are lots of tools like that already in use, given the number of fancy graphs and charts I keep seeing in sock discussions. Maybe it's simplest for you to just contact someone privately who makes those graphs and ask if you can get access to their tools. Per Pointillist, I can understand why they're not in general circulation. 67.117.130.143 (talk) 01:35, 20 December 2010 (UTC)
One of the more useful tools of this type is Wikistalk. It exists in many versions on the mediawiki tool server. See this one that I use. --Jayron32 21:45, 20 December 2010 (UTC)
I know, but it just lists overlapping pages. It doesn't provide time/date/diff details of all contributions like Special:Contributions does. Rd232 talk 10:26, 21 December 2010 (UTC)
Would also be useful for understanding group activity. Rich Farmbrough, 01:33, 22 December 2010 (UTC).

Recommending columns in reference lists longer than 20 entries

See also: Template talk:Reflist

As far as I know there is no clear recommendation whether or not to use columns on reference lists, and which (fixed set of columns, e.g. {{Reflist|2}}, or flexible set, e.g. {{Reflist|colwidth=30em}}). Flexible sets of course offer the advantage of displaying just the amount of columns that suits the visitor's monitor size (which means someone who's having a 20+ in monitor will see 4-5 columns, while someone with a 10 in netbook will see only 2. The ideal width for columns has been discussed at Wikipedia:WikiProject Usability). Therefore I would like to propose an additon to WP:CITE that generally recommends the use of {{Reflist|colwidth=30em}} on articles with more than 20 references, unless local consensus (of editors of a specific article) opposes it. —bender235 (talk) 02:33, 15 December 2010 (UTC)

  • That sounds sensible. I have two observations: it is easier for editors to add "2" to Reflist, than to remember the code "colwidth=30em" - can the code be simplified?; and not all editors are aware of the detailed function of the flexible set - the guidance at Template:Reflist#Columns could be clearer, more in line with the above proposal which foregrounds the flexibility rather than the technical babble of "a minimum width of 30em". The advice to "Choose a column width that is appropriate for the average width of the references on the page", will sweep over the heads of most editors as it doesn't explain how to chose the appropriate width. If the guidance were clearer, and the coding easier to apply then more editors might be using it. SilkTork *YES! 10:01, 15 December 2010 (UTC)
Where I'm going with my thinking is that we might have {{reflist|narrowcolumns}} and {{reflist|standardcolumns}} to define column widths in words people can understand, with the advantage that we're not hardcoding a specific width meaning, as we are with "30em". That would be easier to understand, better for standardisation, and helpful for any future changes. Rd232 talk 13:51, 15 December 2010 (UTC)
"it is easier for editors to add "2" to Reflist, than to remember the code "colwidth=30em" - can the code be simplified?;"
It already has been simplified. You can also enter {{Reflist|30em}}. —bender235 (talk) 10:29, 15 December 2010 (UTC)
As none of the browsers I normally use for Wikipedia support multiple columns, I cannot tell what's appropriate, or how it would work. However, rechecking using one of the other browsers I have available, many of the cases where this is used turn out very ugly. In some of the most distinctive examples of use, most of the references are more than one line even if the columns are disabled, making it clearly inappropriate to use. — Arthur Rubin (talk) 10:34, 15 December 2010 (UTC)
Which is more clearly inappropriate: multiple-line references or references stretching for 25 to 40 words across a modern wide-screen display? Being unable to read a reference I'm interested in is very ugly, IMHO. — JohnFromPinckney (talk) 11:09, 15 December 2010 (UTC)
The references stretch about the same as the body text, so if the user is happy with the body text, the references will be fine too; and if they're not, they'll shrink their window and fix both. Rd232 talk 11:29, 15 December 2010 (UTC)
I think narrow, multiple-line references are much better to read then wide references to cover the whole screen, especially since references are in smaller font size. One-column references on a 22 in screen are pretty much unreadable. —bender235 (talk) 12:55, 15 December 2010 (UTC)
It's more important to err on the side of not giving small screens refs wrapped across lots of lines - on a large screen you can always make the window smaller (and if you're OK with the body text not in columns, the refs aren't much different). Rd232 talk 13:05, 15 December 2010 (UTC)
... and that as well. —17:27, 16 December 2010 (UTC)bender235 (talk)

To answer the question, we probably need to take a step back and ask "what do I want to see on my screen for a given article". Then we can think about how to satisfy different wants/needs in different contexts. I think the parameters are (i) no columns if there are only a few references (20-30 at least for columns); (ii) most of the references shouldn't wrap, or at least not wrap more than 2 lines; (iii) most of the references should take up at least 75% (more?) of the column. In addition, some people just don't like columns at all, but that seems a small minority and without some kind of per-user preference setting we just can't accommodate that.

Do we agree on these parameters as a ballpark? If so, the next question is how to achieve that in different contexts. The contexts are basically (a) different screen sizes (small, typical, large) and (b) different reference styles, which is basically Type A (standard style, mostly fairly long references) and Type B (mostly very short, eg Author (Year:Page) style references). Now the status quo is basically to use {{Reflist|2}} for Type A references and {{Reflist|3}} for Type B. This works out fine for typical screen sizes, and OK for large ones. Where this approach falls down substantially is with small screens, where you're stuck with 2 columns even though the screen is small, and so parameter ii (references shouldn't wrap too much) gets all shot to hell. On large screens, you can also end up breaking parameter iii (too much whitespace), though that's not so serious. Using colwidth with an appropriate value may be able to fix these issues; I'd suggest colwidth=40em works equivalent to {{Reflist|2}} on typical screens, whilst allowing one column on small screens and three columns on large; and colwidth=30em works equivalent to {{Reflist|3}}. This probably needs more testing and discussion, but I lean to suggesting (if this is correct, it may not be!) recommending use of colwidth with these values over fixed column counts. Rd232 talk 11:29, 15 December 2010 (UTC)

I agree with you, but I'd say {{Reflist|2}} is actually equivalent to {{Reflist|30em}}, while {{Reflist|3}} should be replaced with {{Reflist|20em}}. For example, on Operation Tonga, there are short references and 20em is just fine. —bender235 (talk) 12:55, 15 December 2010 (UTC)
Well this is the tricky area... but FWIW I don't think you're quite right. On Operation Tonga, which uses 20em for the Footnotes, I have fully six columns on my 1680 screen! So hardly equivalent to Reflist|3. That said, the footnotes there are all Type B short, and it seems to work out fine at all sizes, in terms of respecting the parameters i-iii I outlined above. So for Type B 20em may be about right, but for Type A, I think 30em is too narrow. Rd232 talk 13:01, 15 December 2010 (UTC)
So we're probably talking about type A, B, and C here, because there are also a number of cases where 30em is appropriate. Actually I think the recommendation targeted with this proposal should not be specific about the exact width of the columns. That decision should be left to the authors. It should only be recommended to use columns if there are more than 20 refs. —bender235 (talk) 13:14, 15 December 2010 (UTC)
I don't really see a Type C existing, as a well-defined middle ground; it's basically either short-form references (B), standard long-form (A), or a mixture of longish, middling (especially if incomplete), and short, which you have to treat as A unless the mixture is very very strongly skewed to short-form. Rd232 talk 13:45, 15 December 2010 (UTC)
  • Yes. I think columns look better, both onscreen and when printed. --SmokeyJoe (talk) 11:53, 15 December 2010 (UTC)
  • Based on my system, a "small" screen would be anything with less than 1122px width and a "normal" screen must be at least 1123px (at 40em, that's the width I need to resize my browser to to get two columns). Seems a bit much to me. At 1024px width, I can use at most 35em to still see 2 columns. But even 40em reportedly give 3 columns on a 1680px-width setup, which some consider too many columns. I don't think you can find a value to satisfy everyone here. Anomie⚔ 12:15, 15 December 2010 (UTC)
    • Well in my discussion about parameters above (i-iii) I didn't say anything about preferred number of columns per se (once there's lots of references), aside from people who don't like columns at all. Is this an issue to discuss? Are some people opposed to ever having any more than 2 columns, whatever the effect on the other parameters I mentioned above? Rd232 talk 12:55, 15 December 2010 (UTC)
Just for me personally, it's the width rather than the number that's important. Lots of short refs look fine in narrow columns, long refs need wider columns or even no columns (if say the sources are mostly in a foreign language, and the creator is putting translations in the footnotes) Elen of the Roads (talk) 13:31, 15 December 2010 (UTC)
Well I assumed most people thought that, apart from a few who don't like columns at all, but Anomie raised other possibilities ("too many columns" as a separate issue from how the references look within a column). Rd232 talk 13:42, 15 December 2010 (UTC)
The problem may be that some people don't want columns smaller than 50em but they have large 1680px-screens that can fit two 50em columns, while others are fine with 35em on a more normal 1024px-sized screen for the same article and also want two columns. Anomie⚔ 15:36, 15 December 2010 (UTC)
Well, we can't please everyone, but that doesn't mean we should necessarily give up here. And it isn't helpful to talk about this purely in fixed em terms; please see my comments above about parameters (i-iii) looking at what users actually want (which surely isn't an em number). Rd232 talk 15:40, 15 December 2010 (UTC)
  • Recommending {{reflist|30em}} as a default is a bad idea. Not a few weeks ago, we experimented with that default behaviour, where {{reflist|2}} would assign a column width of 30em, and got a lot of compaints, and the experiment was a failure and was reverted. But Bender likes it so much apparently, that he kept changing articles using {{reflist|30em}}, and then he was adminioshed on WP:ANI and asked to stop, because people didn't like the change. And now he sets up an RFC in order confirm his opinion for something that has been rejected twice already by the community. If there is going to be a recommendation, it should follow common practice, which is standard 2 column references, unless they are very short (such as footnotes). But in the interest of WP:CREEP, I feel it is best left to the editors' individual judgements. — Edokter • Talk • 13:32, 15 December 2010 (UTC)
Well I think that's a little harsh on Bender, because he was urged (not least by me) to seek a global consensus. It's unfortunate he didn't follow my advice more precisely (raise a proposal, have some initial discussion, then launch an RFC), but now we're here, I think the discussion can be useful and some MOS guidance would be appropriate, if only on when to use columns at all (if we can't agree on exactly how). In particular, look at how a fixed width (if we can agree on appropriate widths for different situations) can better accommodate both large and especially small screens than fixed column count. I think the problem with previous experiment may have been Bender's preferred 30em width, rather than the principle per se (also with changing the behaviour of an existing setting, which was bound to cause confusion). Rd232 talk 13:39, 15 December 2010 (UTC)
Hmmm. As an example, in 9/11, most of the references extend to more than one line of flowing (to be distinguished from multi-line references which consistent of multiple short references) text on my 1280 px screen; {{reflist|3}} is absurd. Our guideline should leave that one as without columns. (I didn't check whether that one was Bender's; I'm just trying to find a guideline that makes sense, even though I dislike columns if there are more than 200 references, anyway.) — Arthur Rubin (talk) 14:59, 15 December 2010 (UTC)
I'm not quite sure what your point is... especially about the >200 references remark. Anyway, I agree the 9/11 article should have 2 columns, not 3. Rd232 talk 15:22, 15 December 2010 (UTC)
To be honest I think three columns on 9/11 looks fine and a single column is just silly - obscuring access to the external links and other useful content. I think that if we were to push for single columns only then we should also adopt refs at the very bottom of the page because there are editors content more than readers content. I see no issue with multi-line refs, references are there as a reference not for you to sit and read like the article prose. If you want to verify or back up content the cite links will jump to an highlight the right one. Otherwise it is an efficient use of space. --Errant (chat!) 15:29, 15 December 2010 (UTC)
Refs split over too many lines are harder to scan. I find myself not really skimming such reference lists (to get a feel for quality of references) and just looking at specific references that I need to check. Rd232 talk 15:32, 15 December 2010 (UTC)
Sensible point. Random thought; how about some javascript - either as a gadget/page tool or as part of the reflist template - which you can click to turn it into one column? At the end of the day I think this is about getting a balance between editors needs (i.e. readable refs) and readers (i.e. much less concerned about refs, to the point of mostly ignoring them). --Errant (chat!) 15:38, 15 December 2010 (UTC)
Anything workable that allows users some choice in these matters would be great. Rd232 talk 15:43, 15 December 2010 (UTC)
I think the experiment of having {{Reflist|2}} behave like {{Reflist|colwidth=30em}} failed because it stunned a lot of people. If you enter {{Reflist|2}}, you expect the template to produce two columns. But the template didn't after that experiment. I was never in favor of doing this.
Also, I wasn't asked to stop implementing {{Reflist|colwidth=30em}} because people didn't like it, but because there is no Wikipedia rule or guideline that recommends this style (or any other). So this proposal is actually meant to establish clarity on what the global consensus regarding reference lists is. —bender235 (talk) 14:54, 15 December 2010 (UTC)
I feel the problem was both that no recommendation for the colwidth style over any other one and that we know that some people don't like it. — Carl (CBM · talk) 16:56, 15 December 2010 (UTC)

Could someone clarify the proposal for me? Which of these is being proposed?

  1. Articles with more than 20 references that don't currently have multiple columns should be changed to colwidth=30.
  2. Articles with more than 20 references that don't currently have multiple columns should be changed to colwidth=30 or reflist|2.
  3. Articles with more than 20 references should be changed to use colcount=30 even if they already use reflist|2

Those would be quite different proposals. I think that #1 or #2 seems preferable to #3. — Carl (CBM · talk) 16:56, 15 December 2010 (UTC)

Articles with more than 20 references, no matter whether they use multiple columns already, should be changed to colwidth. The exact width of the columns, however, has to be determined on each single article. This is actually about recommending the use of flexible columns in general, not about stipulating a particular width. —bender235 (talk) 22:48, 15 December 2010 (UTC)

Just my two cents on this matter. In my opinion, we should use columns for long reference lists (and there are plenty around here). This way, people do not have to scroll over a long reference list for ages just to get to the External Links section, etc. and back. [|Retro00064|☎talk|✍contribs|] 00:33, 16 December 2010 (UTC)

So, do is their at least consensus that articles with long reference lists (20+ refs) should use columns, regardless of width and number? —bender235 (talk) 14:19, 17 December 2010 (UTC)

I think there is consensus to use columns, but I see no consensus on which method to use. Therefor I think we should recommend what has been common practice for a long time, which is to use {{reflist|2}}. I would add the recommendation to use width based columns for lists of short refernces and footnotes. — Edokter • Talk • 14:44, 17 December 2010 (UTC)
I don't think so. Using {{Reflist|2}} was more like a temporary solution when nothing else was available. Now, however, we have colwidth, and that is a much better option. So instead of cementing the status quo by recommending users to implement an inferior option, we should just recommend them to use columns, and maybe point at the options available. —bender235 (talk) 14:59, 17 December 2010 (UTC)
Both column-count and column-width are part of the same feature set of CSS3; they were both available at the same time. I wasn't aware that we regarded {{reflist|2}} as something 'temporary', and to my knowledge, we never did. I am at all not conviced for the need of dynamic columns... some people say the columns get to wide? Then what are they thinking about the article text itself? 2-column references were chosen because it balanced the available space between space-wasting short references and long reference lists. With more columns, things just start to clutter up. — Edokter • Talk — 21:35, 17 December 2010 (UTC)
Well, that's your point of view. I can't argue with that. But I think columns can also "clutter up" if there are only two of them, but the screen is only about 600 px wide. I guess there are a number of people agreeing with you on the aesthetics of multi-column lists, but certainly also a lot disagreeing as well. But the argument "we always had {{Reflist|2}}, and it has been used more often" does not count, because following that argument we should go all the way back to <references />.
Also, that argument about the article text is wrong. Continuous text can easily fill out the whole line, even on a 1920 px screen. But if you have a couple of dozen refs like "Miller (2000), p. 10." (like, for instance, here), why give each the entire 1920 px of width? Or half of it? That would just look awkward. —bender235 (talk) 22:20, 17 December 2010 (UTC)
To Retro; if all of the references extend more than half of a line, then going to columns will not decrease the real estate used. Because of the space between the columns, it would likely increase the amount of real estate used. I'm still opposed to columns as a default, but just pointing out the facts. — Arthur Rubin (talk) 14:48, 17 December 2010 (UTC)
True, although references that extend more than half of a line are rare. But in those cases, neither {{Reflist|2}} nor {{Reflist|colwidth=30em}} is useful. But {{Reflist|colwidth=60em}} might be. So this actually adds to my point that its the width of the columns that should be determined by the author(s), not the number. —bender235 (talk) 14:59, 17 December 2010 (UTC)

Alternate proposal

Expand {{reflist}} so that {{reflist|narrowcolumns}} and {{reflist|standardcolumns}} define column widths in words people can understand, with the advantage that we're not hardcoding a specific width meaning, as we are with eg "30em". That would be easier to understand, better for standardisation, and helpful for any future changes. I'd suggest that narrowcolumns be initially set at 20em (can be debated and/or changed later) and standardcolumns as 40em (ditto). With these new parameters in place, it then makes it easier to conceive of a MoS addition which states

For less than 20 references, columns are not recommended in reference lists. Above this, {{reflist|narrowcolumns}} may be used where narrow columns are required (particularly where Author (Year:Page) style references are predominantly or exclusively used in an article), otherwise {{reflist|standardcolumns}} is recommended. Use of columns is not, however, required, and alternative formatting of columns may be used where there is a local consensus that there is a specific reason to do so.

Rd232 talk 15:30, 15 December 2010 (UTC)

Addendum: explaining slightly more why we should use columnwidth at all (see section above as well): the status quo is basically to use {{Reflist|2}} for most reference lists and {{Reflist|3}} for reference lists dominated by short-form (eg author/year/page) references. This works out fine for typical screen sizes, and OK for large ones. Where this approach falls down substantially is with small screens, where you're stuck with 2 columns even though the screen is small. On large screens, you can also end up with too much whitespace, though that's not so serious. Using colwidth with an appropriate value may be able to fix these issues; I'd suggest colwidth=40em works equivalent to {{Reflist|2}} on typical screens, whilst allowing one column on small screens and three columns on large; and colwidth=30em works equivalent to {{Reflist|3}}. I've suggested 20em for narrowcolumns because for cases with enough references, that works out better. Rd232 talk 01:41, 16 December 2010 (UTC)
I don't like it. It wouldn't look hardcoded, bit still is hardcoded, and still gives unpredictable results for different people. {{Reflist}} uses CSS3 column capabilities and is fully configurable in that regard; it should not be bloated with semantic paramters that go beyond the template's core funcitonality. — Edokter • Talk • 16:40, 15 December 2010 (UTC)
I don't entirely understand. If you have these parameters in place, you can implement them in whatever way seems best. If/when CSS4 comes along or someone simply comes up with a better way, you can easily change it. For the time being, you could even treat standardcolumns as a request for reflist|2 and narrowcolumns as a request for reflist|3. Rd232 talk 16:47, 15 December 2010 (UTC)
I think that picking a somewhat arbitrary number (30em) one time, inside the template code, is better than picking an arbitrary number in thousands of articles, where it will be much harder to change later. — Carl (CBM · talk) 16:58, 15 December 2010 (UTC)
Exactly. And it allows for an easier path for improvements. Rd232 talk 17:54, 15 December 2010 (UTC)
No, you can't make this a one-size-fits-all decision again. 30em looks good on most articles, but certainly not all. Leave the decision on how wide the columns should be to the local consensus. —bender235 (talk) 00:42, 16 December 2010 (UTC)
But... "most" is good enough, if you explicitly allow (as my proposal does) for people who actively want to do something different. Rd232 talk 00:57, 16 December 2010 (UTC)
  • I am against all attempts to make standardized rules for citation formatting. Different articles are written in different traditions by authors with different tastes. This is a cosmetic issue and there are no valid arguments for forced standardization.·Maunus·ƛ· 17:02, 15 December 2010 (UTC)
    • Yes there are valid arguments: there are accessibility issues with the current reflist|2 approach on small screens. The suggested MoS addition explicitly permitted people to do something different if they want; I'm suggesting a recommendation, not a rule. Rd232 talk 17:54, 15 December 2010 (UTC)
    • I disagree with Maunus's argument "against all attempts to make standardized rules for citation formatting. Different articles are written in different traditions by authors with different tastes." As I see it authors' traditions and tastes are irrelevant and apart from the most generic markup (e.g. applying the portrait parameter to tall images) contributors shouldn't decide presentation formatting. - Pointillist (talk) 00:41, 16 December 2010 (UTC)
That is an interesting viewoint - then who should decide which reference style an article should follow? The Dear Leader?·Maunus·ƛ· 22:27, 17 December 2010 (UTC)
I like that proposal. —bender235 (talk) 18:04, 15 December 2010 (UTC)

I'm confused (alternate? proposal)

I'm confused as to what we are trying to do now, require |colwidth=30em and not just |2, for always, sometimes? etc. I know we tried using colwidths as default recently but it was annoying on widescreens because it made 4 or 5 columns, each with only a few refs per column, making it hard to read. Why not just,

For pages with more than 20 references or pages with long reference lists, it is better to use columns to accommodate readers using smaller screens.

I change pages with long reference lists/bibliographies to 2 columns sometimes simply because it's easier to navigate when I'm on, say, an iPod Touch or even an iPad, rather than having to scroll through extra long reflists. For the issue about whether to use colwidth specifications, I think that it doesn't really matter and should be up to whatever works best with the page in question. /ƒETCHCOMMS/ 23:06, 15 December 2010 (UTC)

I don't think you've really understood the issue. I know it's a bit confusing, but please have another look both at my big post in the first section, and my alternate proposal. Rd232 talk 01:05, 16 December 2010 (UTC)
I know we tried using colwidths as default recently but it was annoying on widescreens because it made 4 or 5 columns, each with only a few refs per column
Yes, therefore this proposal only targets articles with long reference lists. On article with less than 20 refs, it is usually better not to use columns at all. —bender235 (talk) 00:40, 16 December 2010 (UTC)
I believe the recent experiment failed because (a) it changed the behaviour of an existing setup in a non-obvious way; (b) the width chosen was too narrow for most articles; (c) on some articles with not that many references, 2 columns looks OK, but 4 columns (on a big screen) looks silly. Again, a wider column width would help with that, so it would normally not be more than 3 columns, except on super-size screens. But the main thing, really, is that any column formatting should always be applied manually, by an editor making a specific decision on what should be done for a specific context (which others may then agree with or not). A recommendation on how to make decisions is helpful, but the recent experiment wasn't a recommendation - it was an enforced change. Rd232 talk 01:05, 16 December 2010 (UTC)
The proposal here is for an enforced change, though: the point of it is that, if it was passed, people would go through and implement it on every article that has more than 20 footnotes. — Carl (CBM · talk) 01:33, 16 December 2010 (UTC)
That could be done by a bot, right? —bender235 (talk) 01:38, 16 December 2010 (UTC)
Assuming that there is consensus in favor, it could be done by a bot, by AWB, or by some combination. — Carl (CBM · talk) 01:41, 16 December 2010 (UTC)
If we don't want to allow that, we can just disallow it! But as long as it's merely a recommendation, that should be fine, since anyone would be allowed to undo it. Essentially, if we write a BRD approach to this into the policy, then it shouldn't be a problem. (That would preclude AWB, though a bot would be OK as long as it could avoid editing the same article twice.) Rd232 talk 01:48, 16 December 2010 (UTC)

FWIW, if the only thing we can agree on is a MoS recommendation to use some kind of column formatting on "long" reference lists, that's still better than nothing (which AFAIK is the status quo). Rd232 talk 01:34, 16 December 2010 (UTC)

Yes it is. —bender235 (talk) 01:38, 16 December 2010 (UTC)
Well, it would be a change to the MOS (or WP:CITE, which is the more likely home). Right now there is no language about columns AFAIK. The key question is: do we want people to go through and add columns to articles that have 20 references? If so, do we want them to add reflist|2, reflist|30em, or a random mixture? — Carl (CBM · talk) 01:39, 16 December 2010 (UTC)
Well I'd rather see them add reflist|narrowcolumns or reflist|standardcolumns as appropriate. And I think those settings should be defined in the template in terms of colwidth; just look at a reflist|2 article on a very small screen (remember the range of devices we have today!) and see how crappy it looks. Then do the same with a colwidth article (eg Ivo_Sanader) and see how it elegantly goes down to 1 column! Rd232 talk 02:00, 16 December 2010 (UTC)
OK, I'm still a little confused but I would definitely prefer a recommendation rather than a "must-have" change. There are times when one is best off choosing exactly how many columns or no columns to have. /ƒETCHCOMMS/ 03:04, 16 December 2010 (UTC)
That is right. Therefore my original proposal said: "use columns, unless local consensus (of editors of a specific article) opposes it." —bender235 (talk) 07:56, 16 December 2010 (UTC)

Display format should be determined by user/agent

I'd like to be able to render wikipedia pages using different rules depending on which screen I am using. Left-column navigation and footnote column widths should be part of this. The layout I need when using a smartphone is competely different from the layout when I'm using a modern business desktop. Hard-coding the layout was a temporary expedient, a quick-and-dirty approximation because 1993-era browsers couldn't handle SGML/XSL. Nowadays named accounts should be able to view wikpedia using multiple screen formats (e.g. 400x800 smartphone, 640x480 netbook, 1024x768 and 1280x800 tablet, 1600x1200 and 1200x1600 DVI, 1920x1080 and 1920x1200 HD). Contributors can't be expected to check all those combinations, so wiki-markup should generalize layout options as far as possible. Generalizing footnote layout and preventing custom left|right|width for images are good places to start. - Pointillist (talk) 01:12, 16 December 2010 (UTC)

Good idea. Sounds pretty good. Makes sense. ;-) [|Retro00064|☎talk|✍contribs|] 01:15, 16 December 2010 (UTC)
If I understand you correctly, you're making a much more general case to remove (as far as possible) all forms of hard-coding of layout? That's a tough pill to swallow! I agree with your headline sentiment, that as far as possible we should try to accommodate different screen sizes (if we could detect the screen size per user it would help a lot... but that's probably not going to happen). This thread is really about the much more limited issue of how to make good use of "fixed" column widths (which aren't actually fixed; what we're actually doing is specifying a maximum width, which is more likely to work out well across screen sizes than specifying an actually fixed number of columns). Rd232 talk 01:25, 16 December 2010 (UTC)
Well, yes I am saying that there's a pill to be swallowed. You can take that in three ways: (1) that we should try to find a single perfect hard-coded solution for all future devices; (2) that we should respect different screen resolutions when we make design decisions; (3) that we shouldn't make design decisions—we should just semantically mark up data so that it can be laid out effectively in future. I'm not the first person to say this, but IMO option 2 is better than 1, and 3 is better than 2. The closer you get to option 3, the more you want to optimize the user experience depending on the layout and technical capabilities of their currently-used browser. The first step is to allow a user to log in to the same account using "different" versions of wikipedia depending on his/her user agent features. If you agree that step, then hard-coding of display parameters needs to be examined carefully against all the probable browser scenarios. Layouts that fail should be deprecated, and those that succeed should be encouraged. - Pointillist (talk) 01:53, 16 December 2010 (UTC)
Actually colwidth is doing just what you're asking for. Instead of pre-determine the number of columns onf the reference list, colwidth leaves that to the user's web browser (i.e., screen width and font size). People with large monitors see 3-4 columns too max out all available screen real estate, while people with smartphones and netbooks only see 1-2 columns on the same article. —bender235 (talk) 01:46, 16 December 2010 (UTC)
AFAICS the left-hand navigation column takes up too much space on any smart-phone. We need a model where a named account can use different style sheets depending on which device layout(s) they require. - Pointillist (talk) 01:58, 16 December 2010 (UTC)
There is a mobile site that comes up by default (for me at least) on my iphone: http://en.m.wikipedia.org/ — Carl (CBM · talk) 02:38, 16 December 2010 (UTC)
Some people disable that skin on an iPhone so they can edit (like me). So that doesn't solve everything. access_denied (talk) 03:08, 16 December 2010 (UTC)
There are users who have their own iphone skin. If you search hard enough, you may be able to find them. There is also an example in MediaWiki:Common.css which shows you how to target iphone sized screen devices. (look for "@media only screen ..." ). —TheDJ (talk • contribs) 15:44, 18 December 2010 (UTC)

Final proposal

Okay, so after the discussion now seemingly has come to an end, I propose to add the following to WP:CITEFOOT:

For less than 20 references, columns are not recommended in reference lists. Above this, {{reflist|20em}} may be used where narrow columns are required (particularly where Author (Year:Page) style references are predominantly or exclusively used in an article), otherwise {{reflist|30em}} is recommended. If the article contains particularly long references, consider using {{reflist|30em}} alternatively. Use of columns is not, however, required, and alternative formatting of columns may be used where there is a local consensus that there is a specific reason to do so.

This is basically User:Rd232's proposal from above, except that those narrowcolumns and standardcolumns parameters do not yet exist. Obviously support from my side. —bender235 (talk) 23:01, 19 December 2010 (UTC)

  • I agree with everything except the colwidth specifications. It should be perfectly acceptable to use reflist|2 over reflist|30em or reflist|3 over reflist|20em, etc. Whether to use fixed-number or fixed-width will differ per article and if there is a dispute over that, local consensus is the determining factor. /ƒETCHCOMMS/ 23:19, 19 December 2010 (UTC)
Like I told User:Edokter above, I don't think suggesting {{reflist|3}} as a substitute for {{reflist|20em}} (etc.) is correct. For example, on this page, how many columns would you recommend? In fact, you could now say any number from 2 to 8, but either would be incorrect (or at least imperfect), because there are always screens for which the number of columns you determine are either too many or too few. On my 22 inch 1920 px screen, six columns look just right. But if I was having a 10 inch netbook, that would be way too much. On the other hand, two columns might look perfect on that netbook, but look just awkward on any larger screen.
The point is: determining the number of columns is not useful, because it leads to awkward results everywhere except on those screen sizes the were originally determined for. But determining the width of columns always leads to perfect results, regardless of the size of the screen (except when there are too many columns for too few refs, which is why this recommendation only applies to reference lists with 20+ refs). —bender235 (talk) 23:45, 19 December 2010 (UTC)
It is useful for some pages. For example, I don't want eight columns on a wide screen for a page with 21 refs. Two columns will suffice whether on my iPod or a 27 inch iMac. I don't think there should be any absolute in terms of which; we recently tried making colwidths default on {{reflist}} and it was changed back. /ƒETCHCOMMS/ 01:28, 20 December 2010 (UTC)
Generally I'm not that crazy about multi-column reflists at all, and I'm generally opposed to fixed-width anything, because the proper width of something depends on screen size, window size, and user preference, all of which can vary. Anyway I'd rather stay with the status quo, where stuff happens article-by-article and we don't worry about consistency too much. 67.117.130.143 (talk) 00:31, 20 December 2010 (UTC)
One of the confusing things here is that colwidth=xx isn't fixed width, it's a maximum width; whilst specifying the number of columns (reflist|2 etc) is actually fixed formatting (it's always exactly 2 or 3 or whatever columns, regardless of how appropriate it is). Rd232 talk 00:33, 20 December 2010 (UTC)
Actually, colwidth is the minimum width of a column. — Edokter • Talk — 01:32, 20 December 2010 (UTC)
"I'm generally opposed to fixed-width anything, because the proper width of something depends on screen size, window size, and user preference, all of which can vary."
Well, actually no. The proper width of those references here is no more than 20 characters (20em), regardless of the size of the screen. The screen size only determines how many characters can be displayed in one line, and therefore how many columns fit on the screen.
"Anyway I'd rather stay with the status quo, where stuff happens article-by-article and we don't worry about consistency too much."
I agree that style decissions should be decentralised as much as possible, and therefore the proposal says that in the end its the local consensus that gets to decide. But at least we should have some general recommendation on the matter. —bender235 (talk) 00:58, 20 December 2010 (UTC)
If the article (like the Beatles article linked above) is written in a style that keeps its references very short, then colwidth=20em or 30em can work fine. If the writing style is such that the reference entries tend to be longer, then limiting them to 30em can screw them up. Writing styles vary by article, so the formatting should also be able to vary. 67.117.130.143 (talk) 01:15, 20 December 2010 (UTC)
"If the writing style is such that the reference entries tend to be longer, then limiting them to 30em can screw them up."
That is absolutely correct. In some cases, reference width should be 45em or even 60em. There's no problem with that. This proposal was meant to encourage people to determine some width for the columns. Whether it's 20em, 30em, or larger, always depends on the specific article.
If you'd use {{reflist|2}}, that could also screw up the article, if the user's monitor is small and the refs are too long for just half of the screen. —bender235 (talk) 01:25, 20 December 2010 (UTC)
Actually, I now see that Reflist changes the number of columns depending on the window width, which I hadn't noticed before. At least in a full sized browser, 30em works ok because of the font shrinkage in the ref section. It's more like 50em in the reference size, which is not that restrictive. Hmm. I might play with it some more. Anyway, it's not healthy to be obsessed with this stuff. 67.117.130.143 (talk) 01:31, 20 December 2010 (UTC)

As I understand it, the point of this proposal is to allow editors to begin a mass change to add columns to articles that have more than 20 references, and to change the formatting from reflist|2 to reflist|20em or reflist|30em on articles that have reflist|2 right now. Is that right? — Carl (CBM · talk) 00:41, 20 December 2010 (UTC)

Essentially yes, because if the consensus is to use reflist|30em, then why not implement it where suitable? On the other hand, if the consensus is not to use "colwidth", then why have that feature at all? —bender235 (talk) 00:58, 20 December 2010 (UTC)
Because both have their uses. I disagree with any "must" on this issue; it should be on a page-by-page basis. /ƒETCHCOMMS/ 01:30, 20 December 2010 (UTC)
Yes, but {{reflist|2}} only has its use on articles with less than 20 refs. Therefore, this proposal only applies to those articles with more than 20. This is not a proposal to replace {{reflist|2}}, but merely to recommend not to use it on articles with more than 20 refs. —bender235 (talk) 01:36, 20 December 2010 (UTC)
That's actually a nice idea. —bender235 (talk) 03:07, 20 December 2010 (UTC)
I thought of that myself, but I rejected it because plain {{reflist}} is too widely used on articles with few references. It could have been a good approach originally, but I'm not sure about doing it now. Rd232 talk 08:42, 20 December 2010 (UTC)
(edit conflict) Besides, the column code doesn't work properly [5]. Tijfo098 (talk) 12:30, 20 December 2010 (UTC)
Actually I does. What you report there is not a bug. —bender235 (talk) 13:40, 20 December 2010 (UTC)
If producing grossly unequal columns is a feature of this template parameter, then it's surely not something I'd ever use, so I've add "strong" in front of my oppose. Tijfo098 (talk) 21:03, 24 December 2010 (UTC)
This proposal does not mandate how many columns you should use or how wide they should be. It only mandates you to use columns, if your article has more than 20 refs. The rest may be decided locally. 20em and 30em are only a suggestion, not a directive. —bender235 (talk) 12:24, 20 December 2010 (UTC)

The number of references is not a good parameter for determining how many columns you want. The amount of text in each column is. If the references are actually of the kind "Smith (2006), p. 42" then 3-column footnotes look better to me, but with a single column for the book list. The point is that the number of references has no bearing on the columns size or number. Tijfo098 (talk) 13:17, 20 December 2010 (UTC)

(1) This proposal does not apply to the book list.
(2) If you only have references of the kind "Smith (2006), p. 42" (like here), then three columns might look good – on a 1024p screen like yours. But on a 1920p screen like mine, they wouldn't. —bender235 (talk) 13:40, 20 December 2010 (UTC)

Also, I see some people are discussing above the scaling issue of columns with the scree size. That is an irrelevant topic because the main text of a Wikipedia article doesn't scale well with the window size. At default font size it becomes very difficult for me to read Wikipedia on 1920-wide windows/screens, and I have even wider ones available to me occasionally (2560px wide). Having umpteen columns for references is rather pointless if the main article has 200+ characters per line in Arial, because the average person cannot read that comfortably. Tijfo098 (talk) 13:17, 20 December 2010 (UTC)

Some people might have that problem you described. The solution for them would be to size down their browser window. But then again: shouldn't the number of columns reduze with the size of the window? —bender235 (talk) 13:40, 20 December 2010 (UTC)
You haven't explained how the number of references is the determining factor for the number of columns, which is what your proposal seem to be mainly about. I say "seems" because it appears to change every so often. Tijfo098 (talk) 15:09, 20 December 2010 (UTC)
I think I've explained it before, but nonetheless: 20 refs should be the minimum for columns, because if there are less refs, there are in some cases too many columns for the existing refs (one ref might get split up in two or columns, and that does not look good). So, columns are useful in general, but not if there are too few refs to work with. —bender235 (talk) 17:08, 20 December 2010 (UTC)
Oppose As WP:CREEP. I don't understand why this problem needs to be fixed. See my alternative proposal, below ---- CharlesGillingham (talk) 20:38, 20 December 2010 (UTC)
  • Oppose I can't see any good reason for mandating a particular format here.--Kmhkmh (talk) 19:40, 21 December 2010 (UTC)
  • Oppose as long as we use 30em and not 35em which is simply too narrow. I do support the concept, but the devil is in the details. Just because my screen is 1920 by 1080 does not mean I always have my browser set to full screen. I don't consider defaulting for 2 or 3 here to some em, to be instruction creep. However, it does have a significant visual impact and should not be implemented without consensus and positive feedback. Vegaswikian (talk) 20:15, 21 December 2010 (UTC)
"Oppose as long as we use 30em and not 35em which is simply too narrow"
The exact value (width) is not part of the proposal. This is merely a recommendation to use "colwidth", not a recommendation to use a specific width. Because you are correct, 30em is too narrow for some pages (but certainly not all; and in some cases, it's too wide). —bender235 (talk) 03:40, 22 December 2010 (UTC)

Alternate Proposal 2: Remove the feature

Remove the parameter that currently allows {{reflist}} to produce multiple columns.

The column width parameter of {{reflist}} and the functionality it provides is not an essential part of providing the reader with accurate, verifiable content. It is unnecessary. It harms the encyclopedia in the following ways:

  1. Describing this feature clutters the documentation and makes it more difficult for new editors to find the information they need.
  2. It lengthens the learning curve for new editors, because they will waste time studying this feature when they come across it in articles.
  3. Editors do not agree on the best way to use this feature, and their disagreements are an unnecessary disruption to other editors who could care less.
  4. If this feature has bugs, or develops bugs in the future, these will bugs will be disruptive. If the feature does not exist, it can not develop bugs.
  5. If (as proposed above) this feature requires a WP:MOS rule, then it requires editors to do more work: they must learn the rule, and they must fix articles to obey the rule.
  6. If (as proposed above) this feature requires a WP:MOS rule, then Wikpedia's 3 million + articles will require constant maintenance to see that this rule is enforced. This maintenance will be unnecessary if the feature does not exist.

For these reasons, I don't believe the "column" feature of {{reflist}} is in the encyclopedia's best interest.

Caveat: if, however, the "column" feature is built into {{reflist}}, or better yet, Cite itself, then none of my arguments apply. My arguments only apply to the existence of a user-controlled parameter. Not the columns themselves. ---- CharlesGillingham (talk) 20:38, 20 December 2010 (UTC)

Support. (As proposed) ---- CharlesGillingham (talk) 20:38, 20 December 2010 (UTC)
Oppose Nothing therin written applies any more to this particular feature than any other template. That you do not find it useful to readers does not mean that nobody will. --Jayron32 21:08, 20 December 2010 (UTC)
Oppose, not the way to solve the "problem". --SarekOfVulcan (talk) 21:22, 20 December 2010 (UTC)
Oppose None of the listed "problems" are actually a problem, except in the most pedantic sense. Anomie⚔ 21:59, 20 December 2010 (UTC)
Oppose. On (1), (2), (5): no one expects new editors to learn all the nuances of MediaWiki. There will always be veteran editors to fix. On (6): a MOS recommendation does not have to be "enforced" on all 3m+ articles of Wikipedia over night. Even if some articles don't implement this ever, the world won't end. On (4): Columns (both fixed and flexible) are not supported by older browsers (because it's a CSS3 feature). But I don't see that as a problem. Just because old browser don't view columns doesn't mean they shouldn't at least be viewed on some. On (3): This is what this discussion is for. P.S.: "columns" should never be implemented directly into cite.php, because they're simply not suitable for every article. —bender235 (talk) 23:17, 20 December 2010 (UTC)
Oppose. Just because we can't agree on how to use something, doesn't mean we have to take it out. — Edokter • Talk — 23:34, 20 December 2010 (UTC)
Strong Oppose; no need to remove a useful styling option, would leave pages with lots and lots of references messy and confusing for readers. --Errant (chat!) 09:51, 21 December 2010 (UTC)
Oppose. I see no good reason for removing the feature (=mandating nonuse) as I see no good reason for mandating it. There's no one shoe that fits all and moreover no need for such a shoe. The only thing that really matters is that the sources are easily readable and that often can be achieved either way.--Kmhkmh (talk) 19:45, 21 December 2010 (UTC)
Oppose. No reason to stop using a very useful feature. This is one feature that has a graceful fail feature. If it is not supported by a browser, the formatting is what it would be without this. Vegaswikian (talk) 20:19, 21 December 2010 (UTC)
Moderate support apart from the "Author year" lists this would work well. Rich Farmbrough, 01:31, 22 December 2010 (UTC).
Oppose. There are many valid uses, especially for long (100+) lists of references of some 50 or so characters where even 4 columns can fit nicely for most users. The actual arguments are kind of applicable to most parameters. Most template parameter descriptions clutter documentation; editors constantly disagree; any feature can have bugs in future; there are already so any MoS rules this one wouldn't change anything; and all articles already require dozens of MoS rules applied. —  HELLKNOWZ  ▎TALK 13:14, 23 December 2010 (UTC)
Oppose — Even if there are no formal rules or guidelines on using columns, I think it generally improves the presentation of Wikipedia articles (my opinion, anyway). I would rather we keep the feature and work on improving it to address any need. If there are enough interested users to warrant it, perhaps there could be a user preference to keep reference lists as one column. CF84 (talk) 21:02, 25 December 2010 (UTC)

Proposal for this proposal

Sorry for starting a new section; I'm lost on where to put this.

I'm not an expert on all of the inner workings of Wikipedia, but I think the appearance and behaviour of reference lists in its current form warrants some discussion on how it can be improved. Perhaps there should be some further discussion on what exactly to propose here, because I see there being many possible solutions other than what you are proposing. If we could get consensus that, yes, we should try to improve how reference lists appear, we could then work on suggestions for how that could be achieved before coming up with a formal proposal. For example, I think the user agent should be taken into consideration (client-side script?). Medium, resolution, browser support, etc. should be considered, and there should be some upper limit on number of columns. Then this behaviour can be overridden with template parameters for exceptional cases. But that's just one idea, and maybe it could be built upon (or torn apart) ahead of proposing it and getting a bunch of !votes. Perhaps someone with more knowledge on WP procedural mumbo-jumbo could chime in and tell you how to start. I can say that I'm certainly interested in improving the look of reflists. :-) I hope that didn't seem condescending. You never know on the interwebs. Also, maybe I'm wrong in which case I invite someone to slap me with a fish. :-) Merry Christmas! CF84 (talk) 21:48, 25 December 2010 (UTC)

Uploader/creator in deletion discussions

Per this, would it be a good idea to mention the uploader/creator as part of the template in the relevant deletion discussions (AFD, TFD, RFD, etc)? Rehman 10:56, 22 December 2010 (UTC)

I would strongly oppose such an idea. File content and copyright status often need the uploader's input for justification of fair use, etc. Listing the creator on any other process is far too likely to shift the dicussion from the content to the author. Jim Miller See me | Touch me 19:55, 22 December 2010 (UTC)
The reason for this is because it would be easier to spot if the creator is posting a comment. I am quite sure this change is not that of a big deal; just a matter of adding a few chars into a template... Rehman 01:33, 23 December 2010 (UTC)
I still question why we would want this information. We expect the creator to comment on a proposed deletion, and we count their opinion as much as any other editor when it is offered. What would be gained by identifying the creator of a template in a deletion discussion? It just seems to be adding information that has no real bearing on the deletion discussion and could only serve to prejudice other commenters one way or the other. Jim Miller See me | Touch me 14:27, 23 December 2010 (UTC)
For instance, if the creator comments on an unused template at TFD, we could easily understand the intention of the template's existence (if commented by the creator), or if it is just an opinion/suggestion/comment (if commented by another user). I find this very useful. It's a small improvement, and so is the related edit. Rehman 02:45, 24 December 2010 (UTC)

Display of Biographical Names: Include Dates and/or living status

I often see lists of, for example, cast members of films and wonder if (for old movies) any are still surviving.

Perhaps a general policy of displaying birth and death dates (or to make them displayable if one mouses over them) or to simply display a name one way if the person is still alive and another if they are deceased would be useful?

Related might a surviving cast members feature for all movies which is different in that all cast members are typically not listed in a Wikipedia movie article.--Jrm2007 (talk) 03:53, 23 December 2010 (UTC)

Since most notable actors have their own articles, then provided that the listed names are wiki-linked, you could use the "navigation popups" gadget. Most biographic articles have the DOB (and DOD if applicable) parenthesized beside the person's name in the very first sentence, so you could just hover over the linked names to get the date(s). My own opinion is that something like an alive-or-dead status list would not typically be relevant to a movie article. Though maybe it's possible to code a custom script to display certain information from an article's infobox when you hover over a link, and the link could have a custom style to denote that there is additional info. That'd be neat. CF84 (talk) 20:38, 25 December 2010 (UTC)
The gadget you describe I think would be useful. But I would assert that the fact that birth and death dates are listed immediately after a person's name in a bio indicates that indeed someone being alive or dead is probably of interest so that this information being encoded in the display of the biographical name is not unreasonable -- perhaps simply a symbol after the name of someone not still living (but I guess a cross would be controversial). If I understand this gadget, it is something that must be downloaded? If so, this probably makes it unavailable to many; my mom and maybe yours, for example. My dad for sure would not have been able to download such a script or even understood the need to.Jrm2007 (talk) 22:21, 25 December 2010 (UTC)
In the vast majority of cases I think this information would simply be high maintenance clutter. High maintenance because almost everyone seems to die eventually, and this change would mean that when they die we would not just be updating the article on them but all the articles that mention them. Clutter because in the vast majority of occasions the birth and death dates of each of the individuals is almost irrelevant to an article on a film or sports event. But each of those dates would need to be referenced so the references section of say an Olympiad would become a forest of refs to the subsequent obits of the contestants. ϢereSpielChequers 00:30, 26 December 2010 (UTC)
I envision it of course being automated; any name with an associated article would look up DOD to determine how to display name. I would never suggest that every mention of a human would have to be accompanied by DOB/DOD and thus have to be updated everywhere.Jrm2007 (talk) 02:22, 26 December 2010 (UTC)
The only way I could think to do that would be to have a template for actor names to use in cast lists, then a simple change to the template for that actor would update all cast lists that include them. Might be cumbersome to implement though. -- ۩ Mask 05:51, 27 December 2010 (UTC)
Which is the need for all this? Unlike other sites, Wikipedia can have entries on both movies and their respective actors. This proposal does not help in keeping articles focused on their topic, which is the movie and not the personal life or career of its cast when they ended working in it. If an actor dies during the filming, or during the months the movie is in the cinemas as a new movie, it may be worth talking about it, but which use is there in mentioning at the article of a movie that X actor died 30 years after filming it, having made countless other movies aftr the mentioned one? What does have to do with the movie itself? MBelgrano (talk) 11:48, 27 December 2010 (UTC)

Just to clarify: This is not about movies/actors -- it is about biographical names. I am suggesting that the way a name is displayed automatically encode whether the person is living or dead -- maybe by color or typeface or a symbol after the name. I am not suggesting that in each place a name is mentioned someone go in and add this information and of course maintain it.

I have simply noticed that whenever I see a person's name in an article, for example one that lists cast members of a movie, I wonder if the person is still alive. Maybe it's only me that does this, in which case, never mind.--Jrm2007 (talk) 19:02, 27 December 2010 (UTC)

Personally, I could see some potential benefit to it, but I think that is outweighed by the costs (ie. maintenance effort).
In the meantime, if wikipedia already has biographical information on somebody, then their name should be a blue link; so further information on their status is only a click away.
bobrayner (talk) 03:34, 28 December 2010 (UTC)
What maintenance effort??? It is, as proposed, an automatic feature that accesses existing biographical information.Jrm2007 (talk) 07:05, 28 December 2010 (UTC)

Auto-revert unexplained deletions

I propose that edits that delete a significant amount of content and which do not have any edit summary -- such as this one -- are automatically reverted. 86.184.232.12 (talk) 14:48, 27 December 2010 (UTC).

  • Oppose. What happens if such content needs to be removed (added earlier as vandalism, needs to be split to other pages, etc)? If it is vandalism, it will anyway be reverted by RecentChanges patrollers or page watchers. And if the vandal is an IP, they would be warned or blocked, if an ordinary user, same as IP, and if an Autoreviewer, the right would be revoked. Rehman 15:07, 27 December 2010 (UTC)
The flaw here is the statement "If it is vandalism, it will anyway be reverted". This is very definitely not always the case (my link being just one of numerous examples). Requiring people who legitimately remove content to provide a brief explanation is not very onerous, and in any case is usually already done. 86.184.232.12 (talk) 18:30, 27 December 2010 (UTC).
  • Comment - I am on the fence with this one. On one hand they should be using an edit summery so if they aren't thats suspicious but on the other hand if it is vandalism then we shouldn't let it stay either. My gut tells me that most vandalism reverts would havea summery but Im not sure. It seems like there should be a way to find a compromise in here somehow. --Kumioko (talk) 18:37, 27 December 2010 (UTC)
I forgot to mention, as an alternative, that this auto-revert might be applied to anonymous editors only. Perhaps "undo" actions could also be excluded.86.135.25.173 (talk) 18:43, 27 December 2010 (UTC).
  • Oppose It's a good idea to stop extremely casual vandalism (even slightly determined vandals would quickly figure out they needed to put in an edit summary, so it would be ineffective there), until it bites a newbie who is trying to remove 30KiB of "poop" some vandal pasted into an article. Anomie⚔ 20:36, 27 December 2010 (UTC)
There is a bot that reverts large amounts of deletion by anons. Corvus cornixtalk 22:46, 27 December 2010 (UTC)
There's supposed to be, but the evidence is that it does not work reliably (for example, why did it not revert this?). I think at one time I tried to pursue that but could not generate any interest so I gave up... I guess this is the same proposal really: Make the bot work reliably. 86.135.25.173 (talk) 02:27, 28 December 2010 (UTC).
It probably wasn't a large enough removal. There are enough valid reasons to remove content that it shouldn't be blindly reverted except in the most extreme or blatant circumstances, like blanking the entire page. Mr.Z-man 03:52, 28 December 2010 (UTC)
Back in the days before auto-filled edit summaries and overview deletion, I would often revert what are now-called BLP violations with no edit summary to avoid calling further attention to the issue. I can imagine people doing the same today in good faith. Rmhermen (talk) 15:36, 28 December 2010 (UTC)
  • Have to oppose this, although I can understand the rationale behind it. I've seen too many examples of IPs improving the encyclopedia by removing vandalism, BLP violations and unsourced unencyclopedic material to support a blanket ban. Alzarian16 (talk) 16:22, 28 December 2010 (UTC)

Update cite.php messages for British English

MediaWiki interface pages for the Cite footnote system have been heavily customized on the English Wikipedia. Currently, if the language set in your preferences is en-GB (British English) or any other than en, then most interface pages are set to the default. This means that the citation in a reference shows a ↑ instead of the en custom ^ and a number of other changes. This also means that the error messages do not have a link to a help page as do the custom messages.

I propose to update en-GB interface pages to the en interface pages so those who set en-GB have the same viewing and editing experience.

One question for those who may know: is it possible to simply create a redirect so that en-GB does not need to be updated when the en interface page is changed?

---— Gadget850 (Ed) talk 04:57, 28 December 2010 (UTC)


Usefulness of language selection

(split from above discussion for cohesion)

Just a passer-by note: There are numerous areas where en has not been updated with en.gb and many other languages, not just on this wiki, but most other wikis too. For example, if you login xx.wiki in en, the interface shows in English, but if in en.gb, it mostly doesn't have that language saved, even though the en.gb interface is nearly 100% same as en interface. Since wiki content (articles) has policies on which English variant to use, and since selecting the lang variant doesn't really change the content, sometimes I wonder if it would actually be better to delete all specific English variants (en.us, en.gb, or maybe even one day for India as en.in, etc) and use only one English interface... It really wouldn't be that bad... Rehman 05:11, 28 December 2010 (UTC)
I don't understand why people can't just use en. In the core MediaWiki software, there are only 23 messages that are different from en, out of 2833 total. 15 of them are EXIF tag descriptions and one is for a special page that's disabled here. There are only 6 that have been defined locally. Mr.Z-man 07:10, 28 December 2010 (UTC)
This may sound stupid, but what are the consequences/issues with completely removing en.gb? It doesn't seem to be of any use... Rehman 11:53, 28 December 2010 (UTC)
We had this discussion ages ago— there was some objection, but I can't remember it now. ---— Gadget850 (Ed) talk 13:30, 28 December 2010 (UTC)
Adding or removing a language to MediaWiki is not within the remit of the enwiki community. I agree that this particular regional dialect is of limited use here on this particular project, but it is fundamentally no different to any other language variant, some of which are of great political and cultural importance (and the source of much community tension: T25217 etc). We don't make any effort to keep, say, the French messages in sync with the English ones, and this is not really any different. Enwiki is written in "English (world)", not "English (UK)" or "English (US)" or "English (uʍop ǝpısdn)"; if you want the full enwiki experience, use the appropriate interface language, as you say. But which languages should be available for the interface is a MediaWiki development issue, not an enwiki community issue. Happy‑melon 15:25, 28 December 2010 (UTC)
I split this part of the discussion to maintain cohesion of the original discussion. There are 371 languages available on the preferences page— as best I see, these select the MediaWiki interface pages used for upload dialogs. warnings, the cite.php footnote system and a myriad of other uses. Even if these were maintained with translated versions of the interface pages, the article would still be in English. I suppose the language selection would be useful if machine translation of text ever worked, but that is a very long way down the road and has been discussed elsewhere.
I doubt that the language selection will be removed, especially as the WMF is committed to internationalization. One solution would be to check the interface pages when rendering— if a custom English interface page exists but a custom interface page for the the selected language does not, then use the English page. Another would be to add a note on the preferences page to explain what the language selection does and does not do. ---— Gadget850 (Ed) talk 16:31, 28 December 2010 (UTC)

Proposal relating to page moves

Hello. I'm here to post a link to a discussion over at Requested Moves. Those of us discussing there have, I believe, said everything we've got to say, and we haven't reached consensus (i.e., I'm not convinced). I'd love to see more input from a wider cross-section of Wikipedians. Thanks in advance for any comments. -GTBacchus(talk) 20:53, 28 December 2010 (UTC)

Nocache

Proposal: install Extension:MagicNoCache (or implement equivalent functionality another way), and then use NOCACHE on sensitive pages. We already have {{NOINDEX}}, this seems a sensible complement. On a related note, this remains visible in Google some time after requesting noindexing... perhaps NOINDEX should be added to some of the related templates so it's always kept out of search engines. Rd232 talk 13:01, 28 December 2010 (UTC)

  • Are there problems with this?
    • the French Wikipedia who autocache links in articles (using called Wikiwix I think) might be affected depending on how they'd use it locally if implemented
    • whether it should be done or it shouldn't, it's a fact that many make use of cached versions deleted though otherwise undistinguished pages (various namespaces); adding it to deletion templates, for example, might affect this
    • likewise, it's common to use links to cached versions for speed, including with the text-only versions those give
  • Those may not be big issues or might be based on confusion about how this would work in practice. Nonetheless, this should still be explored thoroughly to consider all aspects.
    The {{NOINDEX}} template is transcluded eighty-seven and a half thousand times. Hmm. –Whitehorse1 13:50, 28 December 2010 (UTC)
I don't think that extension does what you think it does. The extension prevents pages from being cached within MediaWiki. That won't affect things like Google's cache. Mr.Z-man 16:38, 28 December 2010 (UTC)
Meh, that's not what I meant. I meant the no-cache HTML header, equivalent to the no-index HTML header of NOINDEX. Rd232 talk 08:51, 29 December 2010 (UTC)
Thanks, Mr.Z-man. :)  –Whitehorse1 14:40, 29 December 2010 (UTC)
This functionality is to disable MediaWiki's internal caching architecture, so that pages with the NOCACHE behaviour switch are always regenerated from the database every time they are accessed. I doubt that such behaviour would be allowed by the sysadmins, as the performance of the Wikimedia cluster is heavily dependent on caching. 90% of the cluster's servers use cached data; the last time a software edge-case prevented the caching infrastructure from functioning (the death of Michael Jackson), the load on the servers literally locked up virtually the entire cluster. This feature opens up the tempting attack vector of sneaking NOCACHE onto a large and complicated page and then slashdotting or otherwise virally-distributing it, resulting in very high load onto the database servers. Not desirable. Happy‑melon 16:41, 28 December 2010 (UTC)
My mistake, I was looking for an extension that did what I wanted and thought I'd found it. Clearly not! I'm concerned with external caching by Google etc. For example, it could be added to new pages (<24 hours, say), to prevent caching of potentially dubious submissions. Rd232 talk 10:08, 29 December 2010 (UTC)
I remembered another discussion village pump discussion about that, so had a search. I thought I'd taken part in that though apparently I only read them; you took part.
Links: WP:VP/T:#Deleted page caches can be removed from Google and WP:VP/PR#Mark pages less than 24 hours old for no-indexing. It doesn't look like it got much support--although for that matter the discussions didn't see much participation. Might be useful to see points people brought up. –Whitehorse1 14:40, 29 December 2010 (UTC)
Ha, there's also WP:NOCACHE, which I just found because I wanted to appropriate it as a shortcut for instructions seen here on requesting Google Cache removals. (It's easier if the page is NOINDEXed, there's a box to tick to say the page is excluded from robots.txt.) Rd232 talk 15:13, 29 December 2010 (UTC)
Hadn't seen that one! There's the alternative "You may create the page "Wikipedia:GOOGLECACHE", but consider checking the search results below to see whether it is already covered," have at it. ;) –Whitehorse1 15:22, 29 December 2010 (UTC)
OK, made Help:Google cache removal (and then redirected to the existing Wikipedia:Purging Google search results :( ). But that doesn't address the original issue of whether to prevent some things being cached by Google in the first place. Rd232 talk 18:37, 29 December 2010 (UTC)

Highlighting the text in articles

Hi people, First of all, pardon me, i know i might be repeating this proposal but I tried to search the archives, ~200 results, saw 40 - 50 of them :).

Demo (The controls are in sidebar)

So the point is: It is a common practice to highlight stuff when we read. It increases productivity and is very helpful for future references. I myself felt great need of it whenever I referenced wikipedia. So to help it out, I have made this extension (click here), which I believe will be helpful to a lot of wikipedia users. Also it give the solution to this problem. Please post your views, and if you think this functionality is worth providing on wikipedia, then support this proposal.

--Apeksharma (talk) 20:43, 29 December 2010 (UTC)

Article for Creation process

You know, this is kind of a major reconceptualization of the wikipedia status quo (and may be a case of closing the barn door after the horse is gone), but it occurred to me today that the encyclopedia would be a lot more encyclopedic (and there would be a lot less hassle for everyone on project) if article creation was restricted to sysops, and we had an AfC (Article for Creation) process in which people could propose new article ideas. In most cases it would be a rubber-stamp process - someone proposes an article, it sits for a couple of weeks and no one objects, then in it goes - but it would give the opportunity to stop a lot of irritating issues before they reached mainspace. It would let us discuss (and possibly squelch) POV-forks, BLP problems, article naming issues, joke articles, and notability problems, decide whether the article should be developed in userspace or the article incubator first, make meta-structuring (balancing different articles within a topic area) far easier, and obviate a lot of frustrating AfD debates with people trying to defend inappropriate content that they've put into the project. what do you all think? --Ludwigs2 23:49, 21 December 2010 (UTC)

Well there is the Wikipedia:Article Incubator, though it is open to anyone. We also have Pending AfC submissions, which is a subset of Wikipedia:WikiProject Articles for creation/Submissions. Are those why you had in mind? Soundvisions1 (talk) 03:48, 22 December 2010 (UTC)
The Incubator has been repurposed for material that has been deleted or is at risk of deletion only. Fences&Windows 03:59, 22 December 2010 (UTC)
Oh wow - I missed the entire discussion on that. I thought we were still discussing the time limits. Thanks for pointing that out. Soundvisions1 (talk) 04:09, 22 December 2010 (UTC)
Prior discussions along these lines: New page creation throttling for non-autoconfirmed users, autoconfirmed for unassisted article creation, RFC on new users: Article creation - autoconfirmed for unassisted article creation. Fences&Windows 03:59, 22 December 2010 (UTC)
hmmm... I wasn't actually suggesting that we restrict people's abilities to create new articles, but rather restrict their ability to get any-old idea plunked into wikipedia at a moment's notice. Think of it as pre-userfication - editors could create the article freely in userspace (which could be part of the process of AfC), but the community could still have time to vet the idea and NPOV it somewhat before the article became a mainspace reality. Think of it as AfD in reverse: controlling mainspace content by only letting decent seeds get planted in the first place, rather than by trying to weed out the ten thousand weeds that fly in randomly. --Ludwigs2 05:06, 22 December 2010 (UTC)
Yeah, that's what the prior proposal wanted too. Fences&Windows 19:21, 22 December 2010 (UTC)
Sorry, but this seems contrary to the very idea of a wiki — article creation would drop to a very low level if the average Wikipedian couldn't do it without help. I'm confident that the typical admin creates more often than the average registered user, since one needs to be active to be elected an admin in the first place, but most of our content is contributed by non-admins. We admins are busy enough as it is; if we had to approve all new articles, we'd be very overworked, even if creation plummeted as I expect. Nyttend (talk) 01:13, 28 December 2010 (UTC)

I would agree with Fences and windows & Nyttend. Also, I would emphasise the problem of workload. At the moment, NPP fulfils a similar niche in the wikipedia "ecology"; some third party is expected to review all¹ recently-created articles, and either weed out any deeply problematic ones, or perhaps make a start on fixing any that are fixable. However, Special:NewPages already has a huge backlog despite the number of potential patrollers being far larger than the number of admins. What would happen if that job was handed over to a much smaller set of people who are already busy with other work? Would we need some kind of screening process before a draft article even gets passed to an admin for approval?

¹Apart from those created by people with an adequate track-record of article creation who are likely to go on to create a large number of compliant articles. I can only assume that a similar exemption would apply to this proposal. If not, the workload would be even higher.
bobrayner (talk) 02:25, 28 December 2010 (UTC)

Not sure how you're agreeing with me! I didn't state an opinion, I just posted some links. In fact, I actually somewhat like the idea of funnelling new contributors through WP:AFC rather than allowing them to create new articles afresh, though I can see the potential downside of thousands of articles languishing in a massive backlog. Fences&Windows 00:06, 2 January 2011 (UTC)
This proposal's heart is in the right place, but we just don't have the amount of active editors needed to see this out. Even now the backlog at NPP is nearly a month long for some articles and this just involves hitting a button. We don't want to tell good-faith contributors to get at the back of a month-long line for article submission. This would discourage newbies from becoming longterm editors. ThemFromSpace 00:29, 2 January 2011 (UTC)
Most new users do not start by creating new articles. ~75% of new users start by editing an existing article. Of the users who do make their first edit an article creation, 80+% have their first article deleted. Mr.Z-man 00:53, 2 January 2011 (UTC)

Proposal to restore hoax pages for educational use

A while ago I moved Wikipedia:List of hoaxes on Wikipedia into mainspaceproject space, to help people like scholars who are interested in studying the history of hoaxes on Wikipedia. This was inspired by this quote from Jimbo Wales:

"To ask students to deliberately hoax Wkipedia is a very bad thing ... If you are in a class to train security guards for banks, you don't send the class out to rob a bank. It could be a learning experience, yes, but it's probably better to say, here's a list of 50 cases of bank robberies that went wrong, let's go through each one ..."

However, its utility as an educational resource is limited because the original hoax articles remain unavailable. I'm proposing restoring them and moving them to subpages of Wikipedia:List of hoaxes on Wikipedia, and clearly labelling them with templates marking them as hoaxes. I realise that this flies in the face of Wikipedia:Deny recognition, but if we never learn about our past we have little hope of improving the situation in the future. Dcoetzee 08:14, 29 December 2010 (UTC)

  • Do you mean your move [6] from user space into the current position in project space? I would oppose a move to mainspace. PrimeHunter (talk) 12:44, 29 December 2010 (UTC)
  • Dcoetzee, is the editor from whose userspace you moved that page somebody you know quite well? –Whitehorse1 14:02, 29 December 2010 (UTC)
    • No, I don't know them at all. In retrospect I should have asked them first, but for some reason I was under the impression it was userfied after a deletion discussion (this never occurred). Dcoetzee 14:57, 29 December 2010 (UTC)
  • I suppose there would have to be stringent inclusion criteria, if the list were to include subpages of that nature. I mean, there are a lot of hoaxes. For example, there's probably not a lot that can be learnt from studying this; likewise this is rather amusing but of little value for study. On venue, perhaps it's a meta: thing? –Whitehorse1 14:02, 29 December 2010 (UTC)
  • Sorry Derrick, but I oppose restoring the hoax pages on that list precisely because it provides more incentive to hoaxers. I want as little recognition for vandals as possible. I'm glad that you moved the list into project space -- it was difficult to find when I started whacking out hoaxes a couple of years ago. But I use it to check for previous titles, names, users, etc. -- not for educational purposes. As far as an educational page on hoaxes for scholars, you may wish to develop this Wikiversity page on Detecting_and_preventing_hoaxes_in_wikis-- and limit it to the very few cases with significant outside coverage, such as Edward Owens and [7]. (By the way, we should link the Wikiversity page into our own hoax page.) — CactusWriter (talk) 18:45, 29 December 2010 (UTC)
  • I would strongly oppose reviving deleted hoaxes, per WP:BEANS and WP:DENY. The List of hoaxes on Wikipedia is bad enough - here is a hoaxer, after an AFD full of pleas for more time, gloating that he has achieved equal ninth place. I'm not too happy even with the Wikiversity paper - I have considered writing a Guide to detecting hoaxes, but abandoned the idea for the same reason: why tell hoaxers how to avoid detection?
What would be useful is to encourage everyone to do a bit of checking if they have any doubts - when a long-term hoax is detected, its history often shows a lot of good-faith editors who have tidied it up, corrected spelling, even reverted as vandalism IP edits saying "This whole page is a fake", but never thought to check one or two of the references or do a little searching. If in doubt, add a "hoax" tag, which only says suspected, but will bring in more people to check, and maybe source properly and rehabilitate. JohnCD (talk) 14:46, 30 December 2010 (UTC)
I completely agree with JohnCD, and I also agree with CactusWriter that we should give vandals and hoaxers as little recognition as possible. [|Retro00064|☎talk|✍contribs|] 08:57, 1 January 2011 (UTC)
I do understand the concerns but I also find the position that denying recognition is the most important thing to be shortsighted. There is regular turnover in our population of contributors, and the first hand experience we gain with vandalism is not being passed on, which ultimately leads to more, longer-lasting damage from vandalism when future hoaxes evade detection. To give an analogy, when crime is published in the newspaper it sometimes inspires copycat crimes, but that is not a reason to keep such crimes out of the media. Perhaps some of these ideas can be conveyed using a general guide, but there is no substitute for the real thing. Dcoetzee 12:51, 1 January 2011 (UTC)
I've added a few deleted hoaxes to the list - most of them are extant in various mirrors, so if anyone wants to find them we don't need to host them. Fences&Windows 18:10, 2 January 2011 (UTC)

new idea

Take Wikipedia and turn it into videopedia, using teachers or instructors to turn Wikipedia subjects into lessons taught on a chalkboard, with visual aids to help get the message across using visual aids and audio explanations.

And/or create wikiuniversity and you could even give creaters the option to create multiple choice quizs of different levels of learning, easy, medium, hard after they watch the video. Users could log in and would be able to keep score of the tests they have taken. — Preceding unsigned comment added by 209.105.142.191 (talk • contribs) 19:31, 1 January 2011

Wikiversity] already exists. ~~ GB fan ~~ 19:43, 1 January 2011 (UTC)
And we even have an article on it: Wikiversity. ---— Gadget850 (Ed) talk 19:46, 1 January 2011 (UTC)
Wikimedia Commons accepts videos that are freely licensed. Fences&Windows 22:57, 1 January 2011 (UTC)
For clarity, Commons accepts videos that are freely licensed, in the one acceptable format (Ogg Theora), and under 100MB. — Gavia immer (talk) 23:05, 1 January 2011 (UTC)
See also Wikipedia:WikiProject Classroom coordination. -- Ϫ 15:36, 2 January 2011 (UTC)

Creating individual articles for specific ENSO seasons

Hi. This is to bring greater discussion to the topic of creating specific ENSO season articles. Thanks. ~AH1(TCU) 19:52, 2 January 2011 (UTC)

I started a discussion at MediaWiki talk:Watchlist-details/Archive 4#Change the link of "your watchlist"? about changing the page that the "Your watchlist" links to. I was asked to bring the discussion to a more visible location, so I brought it here. Comments? — Train2104 (talk • contribs • count) 21:49, 2 January 2011 (UTC)

WP:Requested merge

We currently have the neat procedure of WP:RM; where you place the template at the talkpage, and a bot updates to WP:RM to reach a much wider community.

Could we not create a WP:Requested merge which functions the same way? Current merge proposals stay open for ages and ages, sometimes up to years, with just a few heads around. Creating a merge discussions platform like WP:RM could awesomely speed up things, and also get in editors from outside the topic. Comments? Rehman 01:44, 2 December 2010 (UTC)

Wouldn't a thing like WP:RM be a little more, "active" or "cool" maybe? Rehman 05:54, 2 December 2010 (UTC)
I think xe meant "go try it, if people don't like it, they'll revert it and it'll be discussed." Also, it sounds like a good idea to me, not least because I've experienced the problem fairly recently. Rd232 talk 07:25, 2 December 2010 (UTC)
  • If there is no response, the template should be removed. Usually, it is a smaller page with too little watchers. Merging is not nessessarily the best sollution for small pages. No response usually means: not a good idea.--Wickey-nl (talk) 10:58, 4 December 2010 (UTC)
Okay, weird question, but: What makes "WP:Requested merge" fall under your response above, and not WP:RM, (considering both never existed, and both are being proposed)? Rehman 11:33, 4 December 2010 (UTC)
Quite the opposite: if there are too few watchers to deal with a merge suggestion (supporting or opposing), it's an excellent sign that a merger might be a good idea. Rd232 talk 11:46, 4 December 2010 (UTC)
I wanted to say: be carefully with promoting merge requests (do it, unless there is opposition). Not every page needs to be frequently watched to be usefull. But probably I was a little overreacting, I removed the opposed tag.--Wickey-nl (talk) 12:08, 4 December 2010 (UTC)
Well, it's fair to say that people shouldn't make a habit of merging obscure pages just because no-one comments on the idea. That's exactly why this proposal is helpful: ensuring that such proposals even on obscure pages get due attention. Rd232 talk 12:15, 4 December 2010 (UTC)
Right on the button! Rehman 12:28, 4 December 2010 (UTC)
Although I did not find the exact reason why that did not succeed (IMO, that's a good idea/proposal), I suspect that it didn't make it because it involves modifying existing procedures and contents, which is not the case for this proposal, as this involves creating a whole new area. I will contact the nominating editor to see what s/he thinks of this proposal. Rehman 09:45, 6 December 2010 (UTC)
My bot already handles WP:PM. It's not run in the same way as WP:RM; it's more of a backlog report. harej 19:39, 6 December 2010 (UTC)
Could it be made to update exactly like the way it is done at WP:RM? I think we need to modify the merger templates for that, do we? Rehman 00:06, 7 December 2010 (UTC)
  • In my opinion, the best course of action here would be to add a backlog section to the main WP:RM page (An additional 2nd level header section is what I mean here. Something like: "Mergers to be completed", maybe?). Then Harej's bot could keep that updated every 24 hours or so, if he's so inclined. "Articles for Discussion" just isnt' going to happen, for political reasons, so I wouldn't be waiting around for that. — V = IR (Talk • Contribs) 18:08, 8 December 2010 (UTC)
@OhmsLaw and Flatscan: Then how about renaming the current WP:RM to a "Wikipedia:Articles for Discussion", where only renames and merges are discussed, with only deletions at WP:Articles for deletion. That way, we could have two sections, merges and moves, on the same page, updated by the same bot. Rehman 05:37, 9 December 2010 (UTC)
No, bad idea, that would be too confusing. --SarekOfVulcan (talk) 15:44, 9 December 2010 (UTC)
Why? Two simple sections for each wouldn't be that confusing, would it? I actually don't think it would be confusing at all. In fact, outside WP:RM, the change would be less confusing, as these two are brought to one page. Rehman 16:16, 9 December 2010 (UTC)
I don't see any benefit to combining RM and PM: they cover separate issues and proceed at different speeds. Merger discussions have more in common with AfD (WP:Guide to deletion#Recommendations and outcomes). Flatscan (talk) 05:18, 10 December 2010 (UTC)
The benefit is that we wont have "essentially useless" or "stagnant" merge proposals anymore. Putting mergers and renames on one page would get more heads to look into the proposal. This would also allow us to perhaps enforce a two week (etc) period where the merge discussion would be closed with the appropriate action per consensus. This would make these procedures a bit more serious or formal, compared to the current "ignored" state, I would say. Rehman 07:58, 10 December 2010 (UTC)
I understand that the poor participation at merge discussions is a persistent issue. I don't see how combining them would make the RM regulars interested in the PM listings. Flatscan (talk) 05:25, 11 December 2010 (UTC)
WP:RM is currently well "advertised" and known, there are actually enough people watching it to not make things go stagnant. Having two sections on the same page could easily get the watcher's attention. And pointing all "discussions of articles (merges and moves)" (with only "deletions" on a separate page) on one page would most probably multiply the number of people contributing to that area. Rehman 05:38, 11 December 2010 (UTC)
  • I am prepared to implement the earlier decision to change the cname to Articles for Discussion; I can change it everywhere except in bots and scripts. how can we handle those? (I would make no change except for the words themselves--any modification of the instructions otherwise would be a second step, & I'd wait a bit to see if people accepted the wording change. I could implement it on a slow day , like the 25th. DGG ( talk ) 19:19, 16 December 2010 (UTC)
Okay, just for the record, I strongly support the folding in of merge and move pages into AfD and renaming as Articles for Discussion. We have too many venues - the merge/move pages are backlogged and underreviewed, the AfDs often end up as merges and moves, and it (hopefully) takes away the black/white confrontational focus of AfD. I'll keep my fingers crossed on this one. Casliber (talk · contribs) 20:22, 16 December 2010 (UTC)

My two cents: WP:Proposed mergers is a good platform to list proposed mergers in one place, but it has at least four problems: 1. I do not believe it is popular enough (compared to WP:RM, WP:AfD, etc.); 2. There is no requirement for users to list merger proposals they are making at WP:Proposed mergers; 3. Along with that, there are likely people who are proposing mergers who do not even know about WP:Proposed mergers; 4. There is no set time limit (that I know of) for a merge proposal to be open. Merge proposals can sit around for months on a talk page without much activity at all (especially on lower-traffic pages, where there are not that many users checking out the talk page and participating in the merge proposal. This relates to problem no. 1, where even if a proposal is listed at WP:PM, proposals can still sit inactive for long periods). Merge proposals can be just as important as deletion proposals and move proposals. Merge proposals could go through a lot better if more people were participating. [|Retro00064|☎talk|✍contribs|] 00:11, 17 December 2010 (UTC)

You misunderstand, I think. The page notes it's for listing controversial1 or complicated2 proposed merges. I agree with you on merge proposals importance, Retro'64. –Whitehorse1 12:09, 18 December 2010 (UTC)

1. think subject of Active Arbitration Remedies such as ARBPIA -- Israeli–Palestinian conflict, etc.
2. for example, four-way proposals on complex subjects like medicine or conceptual theories, requiring secondary research to even evaluate.


The whole idea of proposing a merge is to get community consensus to merge or not. This means that the merge is potentially controversial. At WP:Requested moves, we have a section for potentially controversial moves, and a section for uncontroversial moves that require the assistance of an adminitrator. Any action that requires consensus before the action is performed can be classified as potentially controversial, and thus should be listed at a central list (e.g. WP:Proposed mergers) to help gain outside input into the matter. Any action where consensus is not needed can be just done. For example, if it is a merge that would be required in order for the articles to follow Wikipedia's policies, then just be bold and do it. [|Retro00064|☎talk|✍contribs|] 01:17, 19 December 2010 (UTC)
You're comparing apples and oranges. WP:Requested moves is for renaming page titles.
You're also confusing terms. Two editors with different ideas about a thing that came up, vs. controversial, are completely different. Apples and oranges. Controversial is explained at Wikipedia:Controversial.
Merges involve editing content, copyedits to ensure flow, direct working with the subject matter, judgement over what content to remove. Moves don't.
Both, are important. But that doesn't mean treatment applied to one can fit the other: They're different animals fruits. –Whitehorse1 04:33, 19 December 2010 (UTC)
It would be nice if a WP:Requested splits also existed, since there is no central discussion listing for splits at all, unlike WP:PM for merges. 184.144.166.27 (talk) 18:59, 30 December 2010 (UTC)
Since splits and merges are closely related, they could perhaps be listed and dealt with on the same page... Rehman 02:01, 31 December 2010 (UTC)
I support this proposal. WT:Proposed mergers/Archive 2#Proposed mergers *and splits*? (September 2009) started toward this, but I think the bot task wasn't completed. Flatscan (talk) 04:58, 31 December 2010 (UTC)

Who will bell the cat?

Reviewing prior discussions would be very helpful here, I think. Unfortunately, they're spread around. This means they're harder to find, but a search of AfD-related pages led to several. There have been standalone proposals & well-advertised threads at AfD and elsewhere. It appears this has failed to gain consensus many times in the past.


Here's a few comments drawn from some of the debates:

…The problem is more that a "merge" can be anywhere from 100% to 1% of the content, and a limited time AfD is not usually the best place to discuss just what should be merged. This typically takes subject awareness and in practice, a good deal of alternate proposals and compromises… -- DGG 09:33, 23 November 2008 (UTC)
I agree completely that "merge and redirect" is much more like delete than keep. A merge/redirect results in the topic no longer having an independent article, just like deletion. -- Carl (CBM) 12:51, 23 November 2008 (UTC)
How effective is the merge decision? We have several hundred articles that got closed as "merge", and are still open. Some of these, such as Paul Blakely (edit | history) • Article talk (edit | history) • Watch , have not been edited for two months, and even have a stub message saying "You can help Wikipedia by expanding it." This seems to me to indicate that the merge decision is often ineffective. I assume that's because it's easy for people to say "merge" in an AfD, but it's harder to actually do the work. Is there a way to encourage people to actually help with the merge when they voted for it? Or do we need to rely on a technical solution, such as a bot that automatically changes such pages into a redirect after, say, a month? — Sebastian 17:52, 15 December 2009 (UTC)


Merge is seen as "Somebody Else's Problem". The admin doesn't care enough; they're just closing it. The nominator wanted it gone, so they don't want to do work to retain the material. The keepers resent the merge decision, so ignore it. I've closed some AfDs as merge, and sometimes I do it myself and other times I poke a WikiProject or !voter to see if they can follow through. Mergers are a very neglected part of the project.

—Fences&Windows 01:49, 16 December 2009 (UTC)


  • Proposal–discussions (far from complete)


The problem boils down to this: Saying “Yes, merge.” is easy. S/Merging as opposed opposed to pseudo‑merging – aka blank+redirect is time consuming and more difficult. The admins, if they close a merge discussion, don't want to perform the merge. Neither do the discussion participants very often, particularly if they disagreed or aren't active on either article. So it comes down to lots of mice saying putting a bell on the cat so it can be heard coming is a great idea; only the room falls silent when somebody asks, “Who will bell the cat?” –Whitehorse1 21:24, 16 December 2010 (UTC)

If I understand right, you simply meant "if the consensus is merge, who will will perform it if the nominator doesn't?", right? If so, we could instead put up a rule that the merge should be carried out by the nominator (or another volunteer) within another week or so (of discussion closing?) after consensus is gained. And if it hasn't been done by that time, to close it per something like "Merger supported but not performed"; possibly a linked template explaining it further. Rehman 11:29, 18 December 2010 (UTC)
Mm, no - that's not what I was saying. It's worth skimming the linked discussions also, for some background. Those're interesting ideas you mention - will reply on them later today. Thanks, Whitehorse1 12:15, 18 December 2010 (UTC)
Often the nominator can't (as in can't fly a plane) carry it out. Per WP:EARTH, with closer/participants who don't want to actually do the laborious work, a time limit has no effect. While deadlines can help motivate willing people, lighting a fire under somebody isn't a catalyst for achieving results. Templates for closing discussions and recording outcomes do exist; they just aren't necessary in most cases. In some cases, for longstanding merge tags, including 'driveby' or subjectively applied ones, as well as where it's clear cut whether anything needs doing, it's more sensible with less bureaucratic process-creep to simply remove them. –Whitehorse1 20:23, 18 December 2010 (UTC)
You have a good point, limiting time would in most cases, close with a no-merge. But listing both topics (moves and merges) at one page, without timers, would still be better, wouldn't it? Rehman 02:49, 19 December 2010 (UTC)
I'll come back to this (sleep). Your cats are gorgeous by the way! :) –Whitehorse1 04:33, 19 December 2010 (UTC)
Thank you :) I await your reply. Kind regards. Rehman 11:01, 19 December 2010 (UTC)
  • Having taken time to reflect, combining the process/pages wouldn't work. They're polar opposites.
    • The name of the moves page is “Requested Moves”, because some contributors cannot move all or specific pages (autoconfirmed account needed, or admin bits needed for moves over edited redirects), so they have to request them. By contrast, any editor including IPs and any editor who joined suddenly last Tuesday, can merge.
    • The word “controversial” seems to have a very distinct meaning at Requested Moves: Simple changes e.g. spelling fixes are “uncontroversial”, until someone says they prefer an alternative or the existing; at which point it becomes “contested”, or 'controversial first listed as uncontroversial'. Meanwhile, “controversial” comprises those where there's ever been chitchat on the best title or, there's more than one viewpoint aired--or it's conceivable there ever could be--on which is the 'primary topic' (disambig. principle) or 'common name'. By contrast, the Proposed Merges page uses the term in the ordinary and regular Wikipedia way.
    • The moves page houses a chronological ordered list, auto updated by bot based on tagged pages. Pages someone believes need a change of title make up the list. There's no way a move of page A to B or a page delete could ever take hours. By contrast, merges involve content directly. Some are extremely tricky to carry out well. Effective constructive participation or action typically takes subject awareness, as well as deciding how to--plus of course doing the sometimes laborious task.
  • Many aren't controversial or complicated of course, and duplication of categories and the various ways of monitoring them or listing all taggings would be an excess. Scarce participation is a difficulty faced by all wiki processes onsite I think. A single aggregated merge–move page would fuse these polar opposites, yet Flatscan's comment along with the above makes me believe it wouldn't genuinely enhance. –Whitehorse1 05:39, 20 December 2010 (UTC)
I either didn't understand what you're saying, or the points above doesn't make sense; these are not reasons for not having both content on the same page as proposed. Having both on one page only increases the chances of being noticed; more participation. I cannot think of the downs of having them on the same page... Rehman 11:09, 22 December 2010 (UTC)
Err... it's going to be confusing if you combine those threads. I restored the indentation. The whitespace-separated unindented comment below doesn't relate to combining the pages; the intention was to evaluate the merge processes and provide constructive feedback on ways to elicit and enhance participation. Since I'd expressed that I felt the suggestion wouldn't work, and being loathe to discourage enthusiasm, I was trying to provide some alternatives. –Whitehorse1 11:39, 22 December 2010 (UTC)
Rehman, they're ... totally different things? –Whitehorse1 12:04, 22 December 2010 (UTC)

This got me thinking about ways to improve this. I started wondering if the Article Alerts system included new merge notifications; found they didn't. I was unsure if it was still active, though figured maybe it could be revived or another bot could handle some things. It's been inactive some time.

The great news is a volunteer offered to create and be in charge of a replacement bot, and it started a trial last week. Snaps to User:H3llkn0wz for stepping up.

I had a great idea: suggest adding new merges to the notifications. I promptly learnt somebody else already had that idea. Incidentally, it turns out the wikiproject/workgroup-specific Cleanup listings include merge counts, but as that tables all cleanup statistics and is intermittent it impacts this less. WikiProjects that aren't moribund have begun receiving alerts. At present requests for new Alert features suggested previously don't need to be resubmitted. I think this could really help. Let's hope the trial goes well and the bot's parents can start to look at additions soon. –Whitehorse1 05:39, 20 December 2010 (UTC)

Re "they're ... totally different things?": Yes, they are different, but not too different; both relate to discussions about articles (merge/rename), with only deletion at a separate venue. As I said, this would greatly improve participation... Rehman 12:31, 22 December 2010 (UTC)
Rehman, they're unequivalent. You can Move a page without doing anything with the content, without touching a single character of its content in edit mode.
Analogies aren't my strong suit, but let's try one. It's like picture frames and paintings. Now you might have carpenters/joiners who make picture frames to wrap around a picture. They're good at what they do. The content of the picture, in contrast, is dealt with by painters or restorers. You can't jab a paintbrush & easel at the frame folks, skilled craftsmen though they are, and insist it needs touch-up restoration so why don't they just get on with it, nor thrust specialist cleaning chemicals at them and insist they remove the years of dirt-buildup because it's all to do with pictures. An editor might work on both areas, yet different skillsets and focus are applicable to each. A label attached to a page can help people see it better: Titles matter; it's still the same page underneath.
As well, there's the cant or dialect of Requested Moves: The nomenclature of RM includes existing terms used elsewhere on site or in general usage (like "controversial"), given an additional or new definition and a meaning (homonym?) peculiar to RM. It can only lead to confusion if two different things are mixed in together, with key terms/concepts used in vastly different ways depending on how far up or down the page you happen to be.
A reason merges can stay for longer periods is the controversial nature of the subjects involved means many prefer to distance themselves from any involvement. To reiterate Flatscan's comment there's no indication RM regulars would become interested in such merging if only the listing was moved to a page they already had watchlisted.
I can't see how combining the two makes sense, nor do I see that with the change poor participation would be addressed as an effect, and the consequence would be inevitable confusion. –Whitehorse1 17:18, 28 December 2010 (UTC)
So, consensus for such a venue? Rehman 14:43, 28 December 2010 (UTC)
I would say there is not. –Whitehorse1 17:18, 28 December 2010 (UTC)
archival timestamp 00:13, 4 January 2011 (UTC)

Summing up: A single page for Renames, Mergers, and Splits

To sum it up. My original proposal is to modify the popular WP:Requested moves pages to hold Mergers as well. This would immensely increase the participation in mergers, as compared to Moves. And since Splits are just mergers in the opposite direction, it has also been proposed that Splits and Merges be identified as one, with equal significance and attention. Thus, with a title like "Requested moves, mergers, and splits", or for short, "Articles for discussion", with only the deletion chapter on a separate venue at WP:Articles for deletion.

Currently, we have the following venues relating to mergers (with no main discussion area for Splits):

  1. WP:Proposed mergers, the current main venue to list mergers
  2. WP:Articles for merging, a failed proposal where mergers would be treated just as WP:Articles for deletion; time limits, etc.
  3. WP:Mergers for discussion, a failed proposal for a venue like WP:Proposed mergers, but with the requirement of discussions like WP:Articles for deletion
  4. WP:Articles for discussion, a failed proposal for a venue for all discussions relating to articles: Deletions, Moves, Mergers, Splits.

At present, Mergers (and Splits, for that matter) seems to be of least attention, compared to Moves, Deletions, and Merges&Splits.

Key modifications to merge Moves with Mergers&Splits would be:

  1. Rename the current WP:Requested moves to a more wider topic like WP:Articles for discussion
  2. Program RM bot to update Moves, along with Mergers and Splits. This would require:
  3. Modify the Merge and Split templates to functions like the Move template. (Merge and Split templates could also be merged; functioning with parameters)
  4. Point WP:Proposed mergers, and other key related links, to the new title.

Since this proposal imposes time limits to merge/split discussions (like WP:Articles for deletion), so that it wont drift on forever, the issue of "Who will perform the merge/split if consensus is reached to do so?" arises. So far, the closest to a solution is that:

  • After the 7-day discussion reaching consensus for merging/splitting, if the nominator doesn't perform the merge/split within another week, then the nomination will be closed per "Merge/Split supported but not performed". This means that the total event period will be two weeks.

But of course, a volunteer could always perform this merge/split. And since we have unified all chapters to one page, the chances of a volunteer stepping up is more. Future merge/splits proposals in the same topic could also be speedy closed.

Any further issues? Rehman 06:14, 31 December 2010 (UTC)

There seems to be a whole lot of "truth by assertion" here, repeating what's said before "This would immensely increase the participation in mergers / "the chances of a volunteer stepping up is more". Several of the points are unclear or inaccurate:
  1. since splits are just mergers in the opposite direction -- What? I don't think this is true.
  2. "Articles for discussion" -- This arguably has seen perennial rejection, even if not explicitly listed at wp:peren.
  3. "we have the following venues relating to mergers" -- How can failed proposals possibly be venues--only the first one is a venue for anything. It's not the current main/primary venue to list mergers either, just for particularly controversial or hard to carry out ones.
  4. Since this proposal imposes time limits to merge/split discussions (like WP:Articles for deletion), so that it wont drift on forever -- Generally they don't drift on forever, and peter out; they just aren't formally closed.
  5. A volunteer could always perform [a] merge/split -- Feel free?
Many of the points were talked about in the unfolded above discussion. --Whitehorse1 00:13, 4 January 2011 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_67&oldid=1180252851"