Wikipedia:Village pump (proposals)

 Policy Technical Proposals Idea lab WMF Miscellaneous 

• Table of contents
• First discussion
• End of page
• New post

New ideas and proposals are discussed here. Before submitting:

• Check to see whether your proposal is already described at Perennial proposals.
• Consider developing your proposal on Wikipedia:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Proposal to discourage "parent–child links" at WT:LINK

See Wikipedia talk:Manual of Style (linking)#Parent–child links.

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)

• BRD. Problem solved. /ƒETCHCOMMS/ 04:05, 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)

• We previously got consensus to rename AfD to "Articles for discussion", which would include merges, but the technicalities of doing that meant it never got implemented. See Wikipedia talk:Articles for discussion/Proposal 1 (originally at [1]). Fences&Windows 01:14, 6 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)

• Update: I just discovered Wikipedia:Proposed mergers, which I did not see before. Now that we already have a page for this proposal, I believe it's now just a matter of getting a bot to update the merge proposals on the page like WP:RM does. I will now contact the needed bot operators and see what we can do. Rehman 10:31, 6 December 2010 (UTC)

  I wonder if we could rename the page to WP:Requested mergers, to be consistent with WP:Requested moves. Could we? Would a RM request do to move, RM?? Rehman 10:59, 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)

• In addition to the problem of getting participants, mergers take more effort to implement than deletions, moves, or redirects. {{afd-merge from}} has a backlog of 364, and those have consensus to proceed. Flatscan (talk) 05:29, 9 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)
  • I'd disagree genuine consensus was achieved to do that. Per various commenters myself among them on that earlier discussion. –Whitehorse1 21:24, 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 controversial¹ or complicated² 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)

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)

• Wikipedia:Articles for merging
• Renaming this process Articles for Discussion
• Wikipedia:Mergers for discussion
• How effective is the merge decision?
• Mergers at AfD
• Mergers as a result of deletion discussions
• Deletion review:Updating Scope to handle AFDs closed as Merge
• Is AfD an inappropriate place to discuss mergers and/or redirects?
• Keep/Merge/Delete style
• Merging during live AfD
• Proposed change to the list of choices
• Consolidation
• Notifying talk pages when mergers are proposed
• Please, ... remember - redirect and merge are very different things

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)

Article Blame -- a simpler WikiBlame tool

There is a simpler version of the WikiBlame tool, linked as "Revision history search" from a history page; this is called Article Blame, from toolserver.org: http://toolserver.org/~soxred93/blame/ It should be considered whether the simpler tool should also be included in the External Tools section of a history page.

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)

• Support. I'd also support making {reflist} do that by default; {{reflist|1}} could then be used to override it in articles with few citations. A. di M. (talk) 02:14, 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)

• Strong oppose. Mandating how many ems and how many columns there should be for references over a precise ref count is an absurd amount of WP:CREEP. Tijfo098 (talk) 12:05, 20 December 2010 (UTC)

(edit conflict) Besides, the column code doesn't work properly [2]. 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)

Template:Namewarning

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

Personally, I think this is obvious. Pretty much everyone knows that an online screen name is in no way verified as being associated with a real person. I just don't see the need for such a template. Tiptoety ^talk 05:35, 20 December 2010 (UTC)

"pretty much everyone"? everyone knows WP usernames are unverified? I doubt that. And what about those who don't? Besides, even if everyone on planet earth knows, there's no obvious harm in acknowledging it, and there is some benefit: the labelling This Person is BANNED From Wikipedia does upset banned users, and such upsetness isn't helping them to let go of Wikipedia, is it? (And, spelling out why that matters: WP:SOCK.) Rd232 ^talk 08:40, 20 December 2010 (UTC)

Regardless of whether you think this will often be useful, there are surely some cases where it will help. This is the sort template that we should have had already. — Gavia immer (talk) 04:47, 22 December 2010 (UTC)

I can't imagine a good reason not to use this template. The more we can do to avoid offending individuals who haven't done anything, the better. Nyttend (talk) 01:15, 28 December 2010 (UTC)

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)

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 cornix_talk 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: Template:Bug 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)

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

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)

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 [3] 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)
  • I think that undeleting hoax material in project space for study purposes may be reasonable, but only if the true nature of the material is obvious. --SmokeyJoe (talk) 13:27, 29 December 2010 (UTC)
    • I've added above a proposal to add a template to them clearly labeling them as hoaxes. I think this will help address the concern that they may be mistaken for real articles. Dcoetzee 14:58, 29 December 2010 (UTC)
  • Sorry of course I meant project space. Dcoetzee 14:57, 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)
  • The idea has merit but it ought to be restricted to hoaxes which have been mentioned in reliable third-part sources. A. di M. (talk) 14:25, 29 December 2010 (UTC)
  • Currently the list is limited to hoaxes that "evaded capture for over a month or became mentioned in the media" which certainly narrows it down (most hoaxes are deleted quickly). Dcoetzee 14:57, 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 [4]. (By the way, we should link the Wikiversity page into our own hoax page.) — CactusWriter ^(talk) 18:45, 29 December 2010 (UTC)
  • If someone really does need the text of the hoax page for research, they can always ask a friendly admin for a copy. Anomie⚔ 19:07, 29 December 2010 (UTC)