Misplaced Pages

Revision as of 03:12, 16 December 2010

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

• WP:VPR
• WP:VP/PR
• WP:PROPS

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 Misplaced Pages:Village pump (idea lab).
• Proposed software changes that have gained consensus should be filed at Bugzilla.
• Proposed policy changes belong at Misplaced Pages:Village pump (policy).
• Proposed WikiProjects or task forces may be submitted at Misplaced Pages:WikiProject Council/Proposals.
• Proposed new wikis belong at meta:Proposals for new projects.

Centralized discussion Village pumps policy tech proposals idea lab WMF misc Refining the administrator elections process Blocks for promotional activity outside of mainspace For a listing of ongoing discussions, see the dashboard. view edit history watch archive talk purge

Cap editing protection on pages in the mainspace at 1 year

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

There is a list of protected pages, which can show indefinite protections. It isn't that hard to go through that list every once and a while, but I see and agree with what you are saying. Realistically, no page should be indefinitely protected, save the main page and other very high use pages and templates. Ajraddatz (Talk) 02:12, 24 November 2010 (UTC)

Not convinced. For example, low-profile BLPs with a certain demonstrated vulnerability to vandalism shouldn't suddenly be exposed to that again after 1 year, nor be dependent on somebody remembering to extend or re-protect. Indefinite should be used sparingly, and the list of pages using it should be checked regularly, but there are uses for it. Rd232 02:44, 24 November 2010 (UTC)

I strongly disagree; sometimes protection is turned on and "forgotten" for a reason. An excellent example of this would be Elephant, which has been protected effectively ever since July 31, 2006. Every time we take it down, vandalism ramps right back up immediately, and so it gets restored quickly. EVula // talk // ☯ // 20:19, 30 November 2010 (UTC)

I dunno, I think we can reasonably assume that eventually people will forget about Colbert's call to action on elephant. I mean, it was just one episode of a TV show. Maybe try unprotecting after 5 years or something. Dcoetzee 18:42, 11 December 2010 (UTC)

I take it you've never heard of a cult following? Hell, I still revert vandalism at Evil stemming from a certain web comic that made a joke in 2006. The Internet has some really, really dedicated folks. — The Hand That Feeds You: 15:45, 13 December 2010 (UTC)

• Modifying proposal to Cap editing protection on pages in the mainspace at 1 year, and one month before the protection ends, have a bot bring it up to a dedicated noticeboard or an offshoot of RfP. Would this be alright for editors? Wifione _....... 03:34, 7 December 2010 (UTC)

I think that a report showing articles protected or semi-protected on this day in previous years would be worthwhile. But we shouldn't assume that all such decisions were incorrect or that the various BLP problems have gone away. Our editors come and go and the notoriety of certain celebrities is often fleeting. But some real life stalking and bullying cases go on for many many years, and we should have an appropriate response. I'm happy that an admin makes a considered decision to reduce protection on an article, provided they are watching that aricle and ready to reinstate protection if necessary. I'm not happy with an automated process to lower our guard on articles, especially if the protecting admin is no longer around to watch the article. ϢereSpielChequers 13:29, 7 December 2010 (UTC)

{{PD-self}} -> {{Self|Cc-zero}}_{{Self|Cc-zero}}-2010-11-24T20:09:00.000Z">

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

It's strange to "brand" a public-domain dedication, but the CC dedication is worded better. "To the greatest extent permitted by law", etc. I say go for it. —Noisalt (talk) 20:33, 24 November 2010 (UTC)

There's nothing wrong with CC-0 (but see below), but I don't think we should use it as our default public domain dedication, which is how it will be perceived if we make this change. Creative Commons doesn't own the concept of the public domain, and we shouldn't imply that they do. Having said that, I don't personally like the {{Pd-self}} wording either. Like CC-0 and most other PD boilerplate texts, it is just not strong enough against the potential of judicially-invented "rights" that weren't given away in the original dedication because they didn't exist - and the history of "moral rights" in European jurisprudence implies that such double-secret rights will continue to be invented. I'd much rather see us use language in line with the PD portion of User:Gavia immer/Copyright, though I suspect most people don't share my exact views on the matter. — Gavia immer (talk) 21:46, 24 November 2010 (UTC)

• Support, also is there any reason why the width for copyright tags is different from Commons? Can the template width (Template:CC-Layout, etc) be changed to 100% to match Commons? -- d'oh! 01:04, 25 November 2010 (UTC)

• Support - CC-0 seems much more thorough than the alternatives. Going with a standard also means less work for us, and probably more expertise behind the design of the license. Discomfort over "branding" seems a small price to pay. --Avenue (talk) 14:13, 27 November 2010 (UTC)
• Support CC-0 has received more legal vetting and is likely to stand up better in court. --Cybercobra (talk) 03:04, 29 November 2010 (UTC)

• Support, but I wonder why we still have an upload form for English WP. It is a 💕 that needs free images. We should only use the upload form of Commons.--Wickey-nl (talk) 12:35, 29 November 2010 (UTC)
  • Because we still allow fair-use images even if we'd prefer free images, and because there are some images that are considered free here that are not at Commons. Anomie⚔ 16:38, 29 November 2010 (UTC)
    • I do believe it's actually the other way around in terms of somethings being free in one place but not another. In many Germanic countries the standard of originality is much, much higher then here. The canonical example is the Star Wars logo. Being just text on a black background it does not qualify for copyright in Germany or the Netherlands and is (was? Last time this came up was back in 06 i think) hosted at commons. I believe that was the entire point of us putting down some servers in Europe if I remember right, de.wiki was getting a little upset at American rules being used on commons. -- ۩ Mask 02:15, 12 December 2010 (UTC)
      • Last I heard Commons required copyright to be expired in both the US and the country of origin, while we here require just the US. Regarding de.wiki, maybe it's just coincidence but most of the really annoying deletionists I've encountered on Commons self-identified as Germans; I'm not so sure it's an improvement. Anomie⚔ 03:42, 12 December 2010 (UTC)
        • Annoying deletionists? Wow, thats a dick statement if I've ever heard one... It's still a wikimedia project, no need to talk shit about someone like that. Theres a rather distinct difference between commenting on something someones doing in a derogatory way and applying that same statement. It's the difference between 'you're being' or 'your're acting' and 'you are'. -- ۩ Mask 10:05, 12 December 2010 (UTC)
          • If they're deletionists and they're annoying about it... Anomie⚔ 13:27, 12 December 2010 (UTC)
• I agree with Gavia above. Nothing wrong with CC-0, but there's nothing wrong with our standard PD templates. Killiondude (talk) 17:15, 29 November 2010 (UTC)

• • How much vetting by actual lawyers have our PD templates had? --Cybercobra (talk) 18:16, 29 November 2010 (UTC)
    • Probably about as much as any other template we have relating to licensing. Killiondude (talk) 18:38, 29 November 2010 (UTC)
• Support - CC0 is certainly much better designed, legally, than anything we can come up with. CC's goals are very much in line with our own, so the "branding" thing is a non-issue IMO. Mr.Z-man 00:24, 1 December 2010 (UTC)
• Support. Commons has already done this recently. However, note that we cannot redirect PD-self to CC0, or otherwise mass convert PD-self to CC0, because they are not legally equivalent (among other things, CC0 waives neighboring rights). Of course CC0 media should be uploaded at Commons, not here, but some newbie users are not comfortable travelling to another wiki to contribute. Dcoetzee 01:49, 1 December 2010 (UTC)
• comment The main issue I see s that very few people know what CC-0 means, but they will probably have heard of public domain. However it does have the advantage that releasing something to public domain is not possible in many countries. And those moral rights that cannot be released apply whether it is either license anyway. Graeme Bartlett (talk) 09:39, 1 December 2010 (UTC)
• Support but please keep in mind that we can't just redirect (or "retransclude" if you want to be technical) for reasons similar to those behind {{GFDL-with-disclaimers}} (i.e. for legal reasons) since PD-self is not precisely the same as cc-0. Also, the wording of cc-0 is such that any rights invented by anyone are also waived by it. --NYKevin @771, i.e. 17:29, 3 December 2010 (UTC)
• Support concept, but shouldn't we be sending these uploads to Commons?!?!? ǝɥʇM0N0 23:34, 9 December 2010 (UTC)

"" - reocurring text under article's title

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

Oppose Mirror sites would not have the logo, only the "From Misplaced Pages" message at the top of the article it copies from. :| TelCoNaSpVe :| 19:33, 26 November 2010 (UTC)

Mirror site like what? I guess anybody who once been to wikipedia had read that it's free / knows, why is there need to push at throats, too many texts which are not related to article's content only make it too bureaucratically stuffed. Besides still majority will read from wikipedia itself and not from someones who decide to mirror contents of wikipedia. Anyway, those who want to copy content from wikipedia wouldn't anyway copy this message along with the content, so this repetitive mentioning in an article's page is uncalled for. Would be better to make as simple as possible since it's a populated project. Userpd (talk) 22:28, 26 November 2010 (UTC)

Read Misplaced Pages:Mirrors and forks, which tells you about such websites. They sometimes don't include either the logo or the wording, but retain the other. :| TelCoNaSpVe :| 23:14, 28 November 2010 (UTC)

What is the point having the wording there if they can remove it as well? All the mirror sites I come across has attributed WP, which is all they need to do to copy. -- d'oh! 00:06, 29 November 2010 (UTC)

• Support -- d'oh! 00:06, 29 November 2010 (UTC)
• Oppose The logo is omitted from printed copies that honor the CSS; the byline provides attribution in such cases. Also, call me nostalgic :) --Cybercobra (talk) 02:46, 29 November 2010 (UTC)

Using the same CSS rules the wording can be hidden until the page is printed. If the CSS rule is not 'honored' the logo will be there instead, win-win. -- d'oh! 03:13, 29 November 2010 (UTC)

Then putting it at the end of printed versions of articles should do the trick. Userpd (talk) 03:51, 29 November 2010 (UTC)

I often browse Misplaced Pages with a text-only browser. The logo doesn't show up for me there. --Carnildo (talk) 02:14, 30 November 2010 (UTC)

• Support No superfluous text.--Wickey-nl (talk) 15:03, 30 November 2010 (UTC)
• Support, there are any number of technical workarounds to solve the mirror site "problem". Meanwhile, we should be making our own interface as useful and uncluttered as possible.--Kotniski (talk) 16:49, 30 November 2010 (UTC)
• Oppose The tagline helps readers know where the article comes from. Use #siteSub { display:none; } in your skin.css if it bothers you that much. Anomie⚔ 18:40, 30 November 2010 (UTC)

I would think the big Misplaced Pages logo to the left will get the readers a clue on where they are. In terms of mirrors, all mirrors I know of has removed the wording, but still attributes Misplaced Pages at the bottom of the page. In addition, that CSS causes a misalignment of the top icons. -- d'oh! 23:44, 30 November 2010 (UTC)

And removing it in some other manner won't misalign the top icons in the same way? Never mind that the "removal" will probably wind up being "edit MediaWiki:Vector.css to stop setting display:inline on #siteSub", which is pretty much equivalent to using that bit of CSS in your skin.css? Anomie⚔ 00:57, 1 December 2010 (UTC)

Obviously we personally could do whatever we want with it (I could equally well argue that you could use Java to put the tagline back if you wanted it that much), but it's a question of how we present pages to our millions of readers who don't have any such options. What reason is there for making the same vapid statement twice, within a few centimetres of itself? --Kotniski (talk) 07:00, 1 December 2010 (UTC)

Ooh, that's much better. Can we make that a preference, or is there a help page that advises that? --Bsherr (talk) 17:29, 8 December 2010 (UTC)

Never mind, it doesn't work. It affects for the worse the position of icons to the right of the title. --Bsherr (talk) 18:04, 8 December 2010 (UTC)

• Apathy I don't really have a problem with it one way or the other; it's a bit redundant, sure, but there's a difference (on a technical level) between text in an image and actual text on the page. I'd be fine with it being hidden in the screen-media CSS (and visible in the print-media CSS). EVula // talk // ☯ // 20:13, 30 November 2010 (UTC)
• Support It's been there forever and I don't really see it anymore, but that's really a bit of space that's better dedicated to article content. Plenty of mirrors remove the tag as well, and of course the tag itself is not enough to ensure license compliance, so the mirror issue isn't a big factor for me. Dcoetzee 01:47, 1 December 2010 (UTC)
• Oppose - Removing that would lessen our SEO, as not all pages would then have those key words directly written on them. Also, they aren't hurting anything. Ajraddatz (Talk) 19:17, 1 December 2010 (UTC)

With the wording hidden using CSS (not removed) the wording will appear for crawlers and another bots, so there is no SEO issue. -- d'oh! 00:52, 4 December 2010 (UTC)

• Weak Oppose or neutral - not hugely fussed either way and the arguments to keep are marginally stronger. The .css code given about is a useful opt out if needed. Casliber (talk · contribs) 20:43, 1 December 2010 (UTC)
• Oppose. Nothing wrong with us branding. The text isnt in the article and does not interfere with reuser's rights. -- ۩ Mask 02:16, 12 December 2010 (UTC)

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

See Misplaced Pages 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 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 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 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 Misplaced Pages talk:Articles for discussion/Proposal 1 (originally at ). 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 Misplaced Pages: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 "Misplaced Pages: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)

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.

Project misnamed :(

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

Misplaced Pages predates all of those. "-pedia" wouldn't imply a wiki if it weren't for Misplaced Pages. Mr.Z-man 02:09, 5 December 2010 (UTC)

What he said. Also, Misplaced Pages is obviously a simple modification of the word Encyclopedia to include Wiki. Ajraddatz (Talk) 23:37, 5 December 2010 (UTC)

We live in an imperfect world, 142.244. Try not to sweat the small stuff as you take the Wiki Wiki Shuttle to Hotel Misplaced Pages. –Whitehorse1 23:41, 5 December 2010 (UTC)

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

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

Religion Field in BLP infobox

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

• Oppose - The surest way of eliminating controversy on Misplaced Pages is to not have articles. Difficult arguments are not a reason to avoid providing content. Traditionally we resolve questions of what religion, nationality, or ethnicity someone is in the same way that we determine their name - by reference to how they self-identify, and how they're described in the majority of reliable sources. In cases where there is no consensus on a person's religion the field can be left blank. Removing the field would harm those BLP articles where religion is a notable part of the subject's identity. - DustFormsWords (talk) 08:23, 6 December 2010 (UTC)
• Comment use of the field should be strongly discouraged under WP:BLPCAT. That is a BLP policy that is only minimally enforced, partly due to the difficulty in establishing whether someone's religion is relevant to their public life. In the Ed Miliband example, I think BLPCAT probably applies because it's not really possible to source any media (or other) interest in his religion from the perspective of him being leader of the opposition. But I am not sure it warrants removal entirely. --Errant 09:49, 6 December 2010 (UTC)
• Comment This is more a problem with editors. The field should be there for the very large number of people for whom religion is important in their lives. However if you need to search to fill the field it shouldn't be filled, it should be something the sources say. Unfortunately some editors have this must fill every field complex, it is like the story of the wife of some composer who when she wanted to annoy him played do re mi fa so la te on the piano so he had to stand up and play do. Dmcq (talk) 12:31, 6 December 2010 (UTC)
• Oppose , mostly per DustFormsWords. If sources concord on a religious affiliation, then we can fill the field. If they don't, we can leave it empty. It's easy. Let's not propose solutions to problems that don't exist. --Cyclopia 12:37, 6 December 2010 (UTC)
• Oppose For all the reasons listed. Sometimes, it is a relevent and highly citable fact, and should be included. Other times it is sketchy or irrelevent or unverified, and should be left blank. Not every field in every infobox needs to be filled in, and all that is needed is dilligence on the part of editors that care. --Jayron32 13:17, 6 December 2010 (UTC)
• Oppose. Just because something can be abused does not mean it should be banned. Conversely, it would be rather silly to have an article about a member of the clergy that makes no mention of the subject's religious affiliation. A little common sense and editorial judgment is a better solution than requiring all situations be shoehorned into a one-size fits all interpretation that fails for a variety of common cases. --Allen3  14:20, 6 December 2010 (UTC)
• Support If someone's religious beliefs (or lack of) are of significance regarding their notability (which is the only reason they should be given at all), this should be dealt with in the body of the BLP text, where it can be discussed properly. Having a field in an infobox is an open invitation to fill it in for no good reason, and encourages sweeping generalisations. It is all very well saying diligence and care is needed from editors, but the evidence seems to suggest it isn't always being given. The inclusion of his infobox field is symptomatic of the wider the tendency for overcategorisation which is endemic in BLPs, detracting from the proper encyclopaedic treatment of subjects. It is also worth noting that the concept that one must actually have in identifiable religion (or a well-defined rejection of the concept) is not a universal one, being deeply rooted in the Judeo/Christian/Islamic traditions, but hardly applicable in all contexts. Maybe the 'religion' field needs to be removed from the infobox not because it can be misused, but because its very existence implies a non-neutral POV? I doubt I'll get far with this argument here, but it needs to be said. AndyTheGrump (talk) 16:30, 6 December 2010 (UTC)
• there is no {{BLP infobox}}... but for example {{Infobox person}} documentation says "religion .. if relevant". I don't think deletion of the field (from the many BLP infobox templates which exist) is really helpful, but it may be that some specific infobox templates could have it removed, on the basis that religion simply isn't relevant enough for a BLP using that infobox. Also, we could have a bot add an HTML comment into every article with an infobox using the religion field, something like "this field should only be filled if relevant to the person's notability and well-sourced" or whatever. Rd232 17:40, 6 December 2010 (UTC)
  • I added a note to {{infobox person}} about BLPCAT in the religion field. Hopefully that is non-controversial --Errant 00:15, 7 December 2010 (UTC)
  • What about making the Religion field non-displayed by default, unless another field, Show_Religion_As_It_Is_Relevant, is set to true? Rd232 08:58, 7 December 2010 (UTC)

• Support As AndyThe Grump mentioned above, giving a one word explanation of what can be a quite complex situation is an insult to most of the people we write about. There is no way my views could be expressed in less than a few sentences. In my country, Australia, the religion of others is not important at all to most of us. However, there is a minority that ALWAYS wants to add it to articles. In recent times this has led to very extensive argument on several articles. In particular, our new Prime Minister, Julia Gillard has declared that she is not religious. This has led to frequent attempts to edit that article to say that her Religion is Atheist. Several problems with that. Firstly, she didn't say Atheist, so it's synthesis. Secondly, Atheism is not a religion. Thirdly, those wanting to list such a status can often be seen to be doing so for POV reasons. It's all very unhealthy. And time wasting for serious editors trying to build a decent encyclopaedia. HiLo48 (talk) 00:36, 7 December 2010 (UTC)

• Support removal too. Unlike DOB or gender or whatever, religion is something that is "unstable" I would say. Religion is a person's own belief, and may change without even his/her family knowing it. It is nearly impossible to get the necessary sources to verify this. If we keep such fields, am sure the disputes will never end. Rehman

• Oppose Biographies of living people are just a small fraction of the biographies included in this site. If you are concerned about possible misuse at BLP by people thinking that if the field exists it should be filled, then simply include a disclaimer at the template documentation. MBelgrano (talk) 21:28, 7 December 2010 (UTC)

Comment - That's a minor part of the problem that can be easily addressed, as you say. What about the other issues mentioned above? HiLo48 (talk) 21:53, 7 December 2010 (UTC)

The other issues you list all fall under the category of "people editing controversially, in ignorance, or in bad faith", which in short is the problem of Misplaced Pages. There is no simple solution to it, and removing a field in an infobox neither resolves the problem or mitigates its damage in any but the most trivial of ways. The best way of managing the problem is talk page discussion plus the attention of a experienced editor with rollback privileges, not widespread template changes. - DustFormsWords (talk) 01:26, 8 December 2010 (UTC)

If there's a "trivial" way of reducing in any way the frequency of silly additions to articles, let's use it. HiLo48 (talk) 03:44, 8 December 2010 (UTC)

• Trivial in the Wikipedian sense of trivia; i.e., having no place in an encyclopedia. The possible gain from this change in no way offsets the damage it does to our ability to provide clear readable at-a-glance information to readers, and the problem it proposes to solve is already well-managed through existing processes and procedures. - DustFormsWords (talk) 03:54, 8 December 2010 (UTC)

• Oppose. There are a great number of cases where an article subject's religion is both pertinent and uncontroversial, and it's reasonable to have it in the infobox in those cases. For other cases, we just need to provide guidance on when to use that field an when not to. For the small number of cases where there's a continuing disruptive dispute - like this Ed Miliband case that is now on almost every noticeboard - the problem is caused by editors, not by the infobox parameter, and should be solved by addressing the cause of the problem. — Gavia immer (talk) 01:40, 8 December 2010 (UTC)

• Oppose The content debate would still happen if the concept were presented in the prose instead of the infobox. This proposal does nothing to address the underlying problem, and merely removes a widely used field for the sake of convenience. Does where the content appears within an article make any difference? I don't believe that there are mobs of editors who suddenly decide that a suject's religious views are important to include because they've read the template documentation and seen that such a field exists. In fact, I often wonder how many editors read template documentation at all. Jim Miller 01:51, 8 December 2010 (UTC)
• Oppose per DustFormsWords. KillerChihuahuaAdvice 01:54, 8 December 2010 (UTC)

• Oppose Many people think that the writers T. S. Eliot and C. S. Lewis were members of the Roman Catholic Church (they were both members of the Church of England, although Eliot called himself an Anglo-Catholic). This is significant information that should be readily retrievable although not necessarily placed in the introductory paragraphs. The warning about entering religion only when it's undisputed and the editor is sure (preferably with Reliable Sources), should be put in <!-- pointy brackets --> on the Religion line of the Infobox template, not in documentation somewhere else. —— Shakescene (talk) 02:13, 8 December 2010 (UTC)

Comment - I would argue that religion should also not be displayed if it's not notable, which should be the case if it has no relevance to the reason we have an article about that person. Having the field in the infobox tells less experienced editors that it's ALWAYS notable if it can be identified. Another issue, already mentioned, is that of editors determined to label as atheist or agnostic those subjects who declare themselves to be something like "not religious" or "have no religion". It is very common, but clearly synthesis, and raises the question of whether atheism or agnosticism are valid entries for a religion field. They are clearly not religions. In summary, there are many ways in which that field can be wrongly used. Not good for Misplaced Pages. HiLo48 (talk) 03:56, 8 December 2010 (UTC)

There are many ways in which the "edit" and "revert" functions can be wrongly used, and wrong uses of them create vastly more damage than a religion field in an infobox. The problem is not in the tool but in the user. Removing the tool does not repair the user, who will doubtless pick up other tools and go on using them wrongly, and in the mean time legitimate users are hampered in their constructive work. The proper way to address these matters is through education, discussion, and a responsible level of attention to your watchlist. Also, for the vast majority of people we have articles on - ie, everyone born in the Western world between about 300 AD and 1960 AD - religion IS a key factor of their life, often moreso than their nationality, and on numbers alone that advocates for the inclusion of the field by default. - DustFormsWords (talk) 04:02, 8 December 2010 (UTC)

And there, in the certainty of that obviously POV statement, lies perfect evidence of the problem I am trying to discuss. It is debates exactly like this that take up so much time for editors trying to remove irrelevant entries from that field. HiLo48 (talk) 05:09, 8 December 2010 (UTC)

Sorry, I'm not saying that the majority of our bio articles SHOULD be about Westerners born 300 to 1940 AD, I'm saying that as a matter of statistical fact they ARE, and however much we might try to address cultural bias, the English Misplaced Pages is unlikely to change in the near future. For what it's worth, I'm not sure that adding in births pre 300 AD or a larger number of non-Western births addresses the problem; downplaying the importance of a religion seems to be, factually speaking, largely a conceit of the modern, Western, developed world. I speak here as an atheist myself, but also someone who's spent quite some time editing articles about people from the last century, who has, much to my irritation, found that determining someone's religion (or lack of one) in these older cases is a pretty crucial step to obtaining a proper encyclopaedic understanding of their life. - DustFormsWords (talk) 05:35, 8 December 2010 (UTC)

• Oppose we are here to inform people with the verifyable facts, and this is one of them. If there is no information leave it blank and do not make up "none" or "Agnostic" unless that can be cited. Perhaps we need a prefil with a citation needed tag in comments. Graeme Bartlett (talk) 21:06, 9 December 2010 (UTC)

• Oppose - Why remove it? Some, dare I say many people notable enough to appear in a Misplaced Pages article identify as a member of some faith - be it Christianity or atheism. If there is no info, leave the field blank. If someone actually has founded their own minor religion, sure, but that in the box. Just make sure it is sourced, obviously. Ajraddatz (Talk) 17:03, 11 December 2010 (UTC)
• Oppose. If indeed an individual's religion is not clearly defined or fluid, don't try to sum it up in one word - don't put it in the infobox, put it in the article body. That makes perfect sense. But this is not true of everyone - there are many people whose religion is quite clearly defined, unambiguous, and notable to their life. Dcoetzee 18:36, 11 December 2010 (UTC)

I guess thats a no then - just thought I'd ask. Mark 20:45, 13 December 2010 (UTC)

Not an absolute no, Mark, but obviously a lot of people think it matters and, although they generally ignored the points of those wanting it gone, there's no chance at this stage of getting rid of it. I still argue that a strong instruction to editors at that field of the infobox would help, because I've certainly had to clean up some rubbish from it. And no-one seemed to want to pick up on my point that agnostic is not a religion. HiLo48 (talk) 21:21, 13 December 2010 (UTC)

Main page disclaimer

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

"We're not associated with WikiLeaks, but we have an encyclopedia article about them."? It does seem a confusion that's quite widespread - see the current Signpost feature. In the circumstances, I'm not sure that a Main Page note is an over-reaction, but I can't see it happening. Rd232 21:42, 7 December 2010 (UTC)

On Radio 2 (UK) the other day they have a talk show and one person emailed "well done Misplaced Pages". This is definitely a weird problem Facepalm --Errant 22:01, 7 December 2010 (UTC)

Its symptomatic of a larger problem, the idea that the common public hears "Wiki" and thinks "Misplaced Pages". The Wikileaks business is the most recent episode, but its not the first and won't be the last. I'd like to see the Foundation try and do more to educate and dispel that. That said, I'd personally agree that either a notice on the Main Page, or maybe a sitenotice, would make sense, but I honestly doubt anything like that would get consensus.--Fyre2387 22:49, 7 December 2010 (UTC)

A Main Page notice is simply out of the question. It's never going to happen.

A sitewide notice is a possibility, but I just can't see it happening for a whole host of reasons. Still, it's a possibility worth investing. These are unique circumstances after all. Also note that there is a disclaimer on the actual Wikileaks article. --Dorsal Axe 23:05, 7 December 2010 (UTC)

And even that seems to be contentious. --Cybercobra (talk) 02:24, 8 December 2010 (UTC)

I would agree with a sitewide notice. Main Page is a feasible option but takes too long to get consensus for any alterations. Right now we need something fast and the message is seen across any pages. Let's correct the situation before more uninformed general public mistakenly believe Misplaced Pages = Wikileaks. OhanaUnited 15:25, 9 December 2010 (UTC)

A message like the one for the founds (above all pages, removable with a click) should be both informative, unobstrusive (if compared with other options) and easy to create, as such messages already exist (we wouldn't be talking about new functionality, or something that may screw the main page appearence) MBelgrano (talk) 15:40, 9 December 2010 (UTC)

I will support a sitenotice. But how would we word such a message? I think MediaWiki:Anonnotice would be more appropriate than anything. But I'm not sure... --Dorsal Axe 11:53, 10 December 2010 (UTC)

Try proposing something on MediaWiki talk:Sitenotice; perhaps "Misplaced Pages and the Wikimedia Foundation are not associated with the whistleblowing site Wikileaks, despite a similarity in names" --Errant 12:44, 10 December 2010 (UTC)

Proposed at: MediaWiki_talk:Sitenotice#Wikileaks. Rd232 13:05, 10 December 2010 (UTC)

The suggestion is probably more appropriate at MediaWiki talk:Anonnotice, which I have noted there. Editors are probably already aware, but anons and readers are not. bahamut0013_deeds 17:43, 10 December 2010 (UTC)

FWIW, I've seen disclaimers on other Wikimedia pages. (See here for one example.) This confusion is not the most important Misplaced Pages-related item for me, but if it makes other contributor's lives easier go ahead & add the disclaimer on the Front Page, WP:AN & WP:AN/I, as well as WP:VP. -- llywrch (talk) 21:10, 9 December 2010 (UTC)

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

Misplaced Pages Per-Article Volatility Index

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

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

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

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

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

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

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

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

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

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

Have you heard of WikiTrust? --Cybercobra (talk) 02:33, 8 December 2010 (UTC)

• WikiTrust is a better solution. The specific problem with the measure you have proposed, Aldobiella, is that the most egregiously false pages on Misplaced Pages were created a long time ago and have gone undetected and edited for a long period, and thus would register as "very stable" without being in any way correct. A system (like WikiTrust) that assesses articles on the basis of the calibre of their editors is generally better - more likely to return pages as falsely inaccurate rather than falsely accurate, as well, which is also a plus. - DustFormsWords (talk) 02:40, 8 December 2010 (UTC)

I can't see much value in WT at first glance. It assesses material on the basis of the contributors, and it assesses the contributors on the basis of whether others tend to agree with them. That sounds likely to give much the same results as "consensus". Peter jackson (talk) 18:01, 9 December 2010 (UTC)

Enable Sub Pages in article space

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

• Enable organized, structured discussions on major topics and "projects" within an article. This would enable editable, summarizable work on the sub-article page, and regular discussion on the related sub-article talk page. An example of existence and showing reasons/benefits for existence is use of this structure for mediation cabal work.
• A practice could be set up of designating a particular name subpage to record major decisions and other semi-permanent records regarding the article. For example, if the editors spent a month consensusing a lead paragraph, such would be recorded there. Right now the only record gets lost in the talk page archives. The everybody forgets that such a major effort arrived at that decision. This would help provide a little extra stability for unstable articles. North8000 18:48, 9 December 2010 (UTC)

It's perfectly reasonable to try and use subpages in the way you suggest - but I see no reason at all why the subpages need to be in articlespace. They just need to be organised properly and linked suitably from the top of the talk page. Rd232 19:33, 9 December 2010 (UTC)

Where else would they be? I may be mistaken, but the only places I know where you can create the "project-talk" pair of pages is user space and essays. And I was thinking that it would be much better to associate them with the article that they are for. Sincerely, North8000 19:59, 9 December 2010 (UTC)

Where else? For example Talk:Interesting Topic/Intriguing Discussion and Talk:Interesting Topic/Much Ado About Nothing, Please Don't Bring It Up Again, with both prominently mentioned at the top of Talk:Interesting Topic. Rd232 20:59, 9 December 2010 (UTC)

I believe this was disabled to allow for articles where a slash is used. Nip/Tuck, for example, would be named "Tuck" as a subpage of "Nip" if we allowed subpages in articlespace. Killiondude (talk) 20:02, 9 December 2010 (UTC)

I knew that such a change would require taking slashes out of article titles (which I think is rare) but never heard that that was the reason. Seems like the tail wagging the dog! North8000 20:06, 9 December 2010 (UTC)

But you can make subpages of talk pages, so making subpages of articles isn't necessary. Fences&Windows 21:43, 9 December 2010 (UTC)

Even now, Talk:Nip/Tuck is seen as a subpage of Talk:Nip as well as the talk-page of Nip/Tuck, which is...confusing. DMacks (talk) 21:51, 9 December 2010 (UTC)

Discussion of articles does not belong in article space, on subpages or not. Discussion belongs on the talk pages. Neither does record of editorial decisions belong in article space, except in exceptional cases a note may be included at the trouble-spot in <!-- a hidden comment --> in the wikitext. Anomie⚔ 22:02, 9 December 2010 (UTC)

• There are tools available already to index talk archives, or they can be setup with a search box using {{archivebox|auto=yes|search=yes}}. The problem with subpages is that there are so few people who would end up with them on watchlists. It is too easy to miss changes. See this page and this underlying discussion from when Comments subpages were deprecated last year for some background on why subpages are "bad". Jim Miller 22:04, 9 December 2010 (UTC)

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

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

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

"the discussed advantages"? You haven't given any advantages from article subpages which talkpage subpages wouldn't have. Rd232 00:53, 10 December 2010 (UTC)

Maybe I am confused, but your original proposal seemed to be about placing talk page material into an article space subpage. I was counting on the responses above in pointing out that doing that is prohibited. Discussions about articles only belong on talk pages. The point about subpages still holds. When you edit or watch an article, the talk page is automatically added to your watchlist. This does not happen with subpages in either space. I just wanted to point out that creating new subpages results in unwatched pages, and the last thing needed in any namespace is more unwatched pages. Jim Miller 23:59, 9 December 2010 (UTC)

Unwatched pages is a fair point. This sort of subpaging should be kept pretty much for historical records of discussions organised by topic, or the most highly active talk pages, where any other approach is impractical. It would be different if we had the ability to watch all subpages of a page with one click... Which shouldn't be too hard to do, certainly in software, but perhaps even with a gadget? Rd232 00:53, 10 December 2010 (UTC)

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

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

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

A talk subpage still has its own article/talk page pairing. See eg Talk:Provisional Irish Republican Army/draft. Rd232 08:57, 10 December 2010 (UTC)

If I am understanding you properly, you are referring to use of the main article talk page as the talk page for the sub-workspace. That was the "scattered to the four winds" situation that I was referring to. We have one of those going at ] which one of the examples that led me to suggest this. Sincerely, North8000 10:22, 10 December 2010 (UTC)

OK, I understand your point better now. There are two existing options here: (i) have the draft in a user's userspace whilst it's active, where it has the usual project/talk pairing, and then archive to several talk subpages when done (ii) reproduce that pairing on a talkpage subpage, eg Talk:Provisional Irish Republican Army/draft and Talk:Provisional Irish Republican Army/draft-talk, with a note on the top of each page pointing to the other (see those examples). Rd232 17:49, 10 December 2010 (UTC)

Thanks for idea, which I will use. I do think that it would be good to implement the intent of my idea for more general use. Even if not via. enabling sub-pages in article space. Possibly it could be just a guideline to pair two sub-talk pages, and to re-define one of them as an editable workspace. North8000 13:18, 11 December 2010 (UTC)

Good idea - it could be a Help page, or just a paragraph in an existing page. I do think these kinds of drafts can be very helpful and should be encouraged. Rd232 13:43, 12 December 2010 (UTC)

I'm going to try it on a few articles. Eventually might write a suggested framework as an essay. Otherwise everyone who does this will need to make up stuff each time. North8000 15:29, 15 December 2010 (UTC)

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

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

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

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

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

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

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

• Oppose - Even having read the earlier discussion on volatility, I'm not clear what benefit this would bring to any editor, or how it substantially improves upon a careful reading of an article's history page. What you're proposing is something that would not be seen or found by casual viewers, and provides information that experienced editors can already access through existing tools. In addition, it falls foul of many of the same reasons we don't show how many people are watching a page below a certain limit, in that it provides clues for vandals as to which pages vandalism is unlikely to be detected on. - DustFormsWords (talk) 05:22, 10 December 2010 (UTC)

• In addition the best way to judge the accuracy of articles on Misplaced Pages is simply to be information literate, and have the skills necessary to make informed judgments on your own behalf as to whether sources are reliable. I'm philosophically skeptical of methods that use algorithms and metrics to lull people into avoiding developing these crucial skills for themselves. That is, at least until we have MUCH better algorithms and metrics. - DustFormsWords (talk) 05:25, 10 December 2010 (UTC)

• How do the statistics on the linked tool correlate to reliability? You could probably make some argument that articles with more edits or more frequent edits are more reliable, but it would likely be a weak relation, especially since "reliability" isn't a quantitative property. Wikitrust is better because it takes who made the edit into account, but more importantly, it works on a sentence level. As articles get bigger, the amount of the article each edit affects becomes smaller, so the idea that each edit improves the reliability of the article as a whole becomes less accurate. Mr.Z-man 05:46, 10 December 2010 (UTC)

Nature : Time to underpin Misplaced Pages wisdom

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

I have copied it to the signpost suggestions. Shyamal (talk) 14:50, 10 December 2010 (UTC)

Indeed interesting, however, this also produces some possibility for bias within the effected articles - something which will need to be watched for. Ajraddatz (Talk) 15:18, 10 December 2010 (UTC)

There are actually quite a few scientists and other experts working on Misplaced Pages. There are also quite a few who've given up in disgust at the way it "works", and at least 2 who've been blocked or banned. In some circles it doesn't have a reputation as expert-friendly. Peter jackson (talk) 16:00, 10 December 2010 (UTC)

Yeah, we have a lot of scientists that contribute well, some scientists promoting their own theories, and a few who end up blocked/banned for not working with consensus on things that they "know better" than everyone else. /ƒETCHCOMMS/ 02:38, 11 December 2010 (UTC)

Well, like every category of editors, it seems. As a scientist myself (warning: shameless self-promotion) I collaborated with the authors of the letter in writing this small guide to contribute to WP for scientists; it would be interesting to know if any scientist has read it and begun to contribute to WP afterwards. --Cyclopia 10:51, 11 December 2010 (UTC)

OpenID revisited

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

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

Im a pretty big fan of technologies that sit on top of other systems (Google Voice is Jesus, just sayin') so I dont want you to be scared by this question. It's not a big hurdle. But can you just give me a couple advantages one would gain from using an OpenID-linked account? Im only vaguely familiar with it, and even that passing knowledge is some years out of date. Mainly I remember it showing up on livejournal back in the first half of the decade and want to know if this is a 'cause we can' thing, or if its a 'this will benefit people who want to do X' thing. -- ۩ Mask 16:25, 12 December 2010 (UTC)

I ask because from your proposal, it reads to me that its to store all your login information under one password, but that feature would seem to be a reimplementation of the accounts manager in firefox and chrome. -- ۩ Mask 16:28, 12 December 2010 (UTC)

Sure. Advantage 1: OpenID works regardless what computer you're using; browser-based accounts managers only work for the computers they're installed on. Advantage 2: With many OpenID providers, once you're logged in you stay logged in until you log out - so you wouldn't have to re-enter your password in order to log into Misplaced Pages, you would just hit a "sign in with OpenID" button and choose your OpenID provider, which is more secure (because A. your password isn't sent over the ether again and B. there's nothing for keylogging software to read). Hope that helps. waggers (talk) 15:40, 13 December 2010 (UTC)

The 'accounts manager' type things are okay. But for one thing: they don't work across computers, and they don't work across browsers. They are very clumsy implementations of a secure keyring type system. OpenID is much more preferable to how it is now. –Tom Morris (talk) 20:04, 13 December 2010 (UTC)

Those are more then sufficient to justify it for me, I can support this without reservation. -- ۩ Mask 02:07, 14 December 2010 (UTC)

styling <references /> like Reflist_like_Reflist-2010-12-13T12:34:00.000Z">

see also #Recommending columns in reference lists longer than 20 entries

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. Within 24 hours, this page will be added to the following list: Misplaced Pages style and naming When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

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

• Support. A most sound, logical, rational, and sensible idea. -- Cirt (talk) 12:57, 13 December 2010 (UTC)
• Support per my previous comments in the other thread --Errant 13:03, 13 December 2010 (UTC)
• Support for reasons given. Consistency is good. — Edokter • Talk • 13:42, 13 December 2010 (UTC)
• Question This already gain consensus... why is this new RfC needed? Headbomb {talk / contribs / physics / books} 14:05, 13 December 2010 (UTC)
  • Actually making the change was brought up on AN and it was suggested that more input was needed in the form of an RFC. (I disagree, but there you go) --Errant 14:10, 13 December 2010 (UTC)
  • Because it's a sitewide change, albeit a minor one, I wanted to be sure there wouldn't be too much post-change "why did nobody ask me?" blowback. Rd232 14:13, 13 December 2010 (UTC)
• Question If this styling change is made, how do I get <references /> to show the non-shrunken references? Or is the intention that I be no longer allowed to do that? — JohnFromPinckney (talk) 14:35, 13 December 2010 (UTC)

IIUIC, putting

ol.references { font-size: 100% !important }

to User:JohnFromPinckney/vector.css (assuming you use the vector skin) should do the job.—Emil J. 15:00, 13 December 2010 (UTC)

As stated above, there is a Gadget to do this. Look in your Preferences under Gadgets for ""Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists." Rd232 15:32, 13 December 2010 (UTC)

Which may or may not be what the user wants, he didn't say anything about infoboxes or navboxes.—Emil J. 15:57, 13 December 2010 (UTC)

True, but the reason the gadget's that way is the assumption that if you don't like refs 10% smaller, you don't like the other stuff smaller either. If that's not generally the case, maybe the Gadget needs splitting (can gadgets have options)? Rd232 19:20, 13 December 2010 (UTC)

The idea is that, references should be all of the same size by default, except when explicitly specified by editors. Consider

The idea is that that <references> and {{reflist}} give exactly the same result (that is small sized references) because currently the articles are inconsistent between each other (some have normal references, others have small references). If your concern is that you want the possibility to have something like the hybrid case, i.e. the "explanations" in normal size, and references proper to be small sized, that could be achieved by something like {{reflist|group=nb|size=normal}} (it's not yet implemented, but it would be trivial to add). If your concern is that you don't want to read the small size references at all, then you could set this in your user preferences. Headbomb {talk / contribs / physics / books} 15:06, 13 December 2010 (UTC)

(Please note the the collapsed box reduces the font-size of the small refs to 88% instead of the proposed 90%) — Edokter • Talk • 17:18, 13 December 2010 (UTC)

The problem is that most Misplaced Pages users don't know how to edit css files. They will either stay or leave depending on whether the site is easy to use and easy to read. Racepacket (talk) 17:36, 13 December 2010 (UTC)

They don't need to edit CSS files - there's a Gadget for those as wants. Otherwise, if you really think 90% is that bad that we shouldn't use it at all (particularly with readers in mind who aren't logged in), then make an alternate proposal to standardise the other way: styling reflist like references/, at 100%. Rd232 18:33, 13 December 2010 (UTC)

There will be no "size=normal" parameter built into {{reflist}}. The whole point of consistency is that there will be no deviations from the norm. — Edokter • Talk • 21:29, 13 December 2010 (UTC)

Consistency doesn't have to be either/or; we could still permit limited exceptions here, with a style-guide suggesting when it may be used (not just because someone prefers the old style, but a specific reason). Rd232 21:33, 13 December 2010 (UTC)

Those exception must probably not use {{reflist}} in the first place then. — Edokter • Talk • 22:06, 13 December 2010 (UTC)

Thanks for the comprehensive examples. My concern wasn't to get to the hybrid case, as I don't see that as desirable (it's inconsistent within the page and it includes smaller-than-normal text). I was really trying to find out how I could add references to an article such that both or all three of them are in a full-size readable size, not so much for me, but for every reader of that Misplaced Pages page.

I understand and accept that articles with 50 or more refs benefit from somewhat smaller ref lists, and on those I use {{Reflist|colwidth=25em}} or similar. But articles with one or two refs don't need shrunken references, and the standard font size on Misplaced Pages is, AIUI, already less than 100% of users' default font size. I thought there was some statement at WP:ACCESS about aiming for full-size text, but I don't see it there now.

Apparently, though, the consensus is already that <references /> and {{Reflist}} must produce the same size results across WP, and the discussion here is just how to get that to happen without deprecating <references /> immediately and have a bot replace it with Reflist. The documentation at Template:Reflist#Font size appears to be badly out of date in any case and needs to be changed, at the very latest when this proposal is adopted. — JohnFromPinckney (talk) 22:27, 13 December 2010 (UTC)

• Support, as I've already stated in the previous proposal.—Emil J. 15:00, 13 December 2010 (UTC)
• Support - Mmmm consistency. Ajraddatz (Talk) 15:01, 13 December 2010 (UTC)
• Support - Go standardization. shoy (reactions) 15:09, 13 December 2010 (UTC)
• Yay. About time, too.—Ëzhiki (Igels Hérissonovich Ïzhakoff-Amursky) • (yo?); December 13, 2010; 15:36 (UTC)
• Support Bring it on. waggers (talk) 15:44, 13 December 2010 (UTC)
• Oppose There is no reason to make short lists of references less readable with smaller font sizes. Misplaced Pages's san serif body type is already hard to read. Racepacket (talk) 16:35, 13 December 2010 (UTC)
  • It's only 10% smaller, and that can be turned off per user. And as per Headbomb's suggestion above, we should also change {{Reflist}} to give it a new optional parameter, so that 100% size can be used where specifically required. Rd232 18:30, 13 December 2010 (UTC)
• Support mmm, consistency indeed. Der Wohltemperierte Fuchs 19:11, 13 December 2010 (UTC)
• Support Consistency would be lovely, yes. —chaos5023 (talk) 19:40, 13 December 2010 (UTC)
• Support consistency is good. Airplaneman ✈ 19:53, 13 December 2010 (UTC)
• Support Same reason as last time: More consistency is better in this case. --Cybercobra (talk) 20:06, 13 December 2010 (UTC)
• Support for consistency. Guoguo12--Talk--  21:08, 13 December 2010 (UTC)
• Support - Pointillist (talk) 21:34, 13 December 2010 (UTC)
• Support Not before time.  Ronhjones  22:56, 13 December 2010 (UTC)
• Support: There needs to be consistency in the reference list across all Misplaced Pages articles. It is just more professional. In my opinion, the individual user should be able to set his/her own preferred font size for the reference list (whether in {{reflist}} or <references/> format) in the my prefrences page. That would settle all of this sillyness over reference list font sizes and should also hopefully settle the "established style" issue in articles. 23:56, 13 December 2010 (UTC)
• Support I'm surprised this hasn't already been done, given the other discussion about it. Yeesh. EVula // talk // ☯ // 00:03, 14 December 2010 (UTC)
• Comment many reference sections also contain a bulleted list following the output by <references/>, if the font size is changed these will need wrapping with {{Refbegin}} & {{Refend}} to maintain the same size throughout the section. Keith D (talk) 00:06, 14 December 2010 (UTC)

• Question Sorry for asking what may be a dumb question for which this may be the wrong forum, but if (as this proposal suggests) {{reflist}} is superior to <references> why is the latter still an option (beyond legacy reasons). As an editor it has always been (unnecessarily) confusing to me why there are two options for references.Ajbpearce (talk) 00:07, 14 December 2010 (UTC)
  • Answer: The <references/> tag is standard MediaWiki markup that the MediaWiki software translates into a list of references (just like the <ref>...</ref> tags are used to tell the software that the text between the two tags is a reference). <references/> does not support customizable options, as far as I know. {{Reflist}}, however, is a template, which does support customizable options, allowing flexibility in the formatting of the reference list. 00:44, 14 December 2010 (UTC)
  • Reply: Ok, I (think) I understand that, but is there a reason instances of <references/> are not simply hunted down by a bot and replaced by the more versatile {{Reflist}} template on enwiki?Ajbpearce (talk) 01:16, 14 December 2010 (UTC)
    • Answer: One part/argument of this issue at hand (making <references/> the same as {{Reflist}}), is the "established style in the individual article" argument. The fact that people both agreed and disagreed with replacing <references/> with {{Reflist}} meant that is would not be acceptable to go and replace all of the instances of the former with the latter without consensus. Depending on the end consensus resulting from this proposal, it may well be decided to replace all instances of <references/> with {{Reflist}}. 01:38, 14 December 2010 (UTC)
      • If the change proposed here was made, there would be no reason to replace "<references>" with "{{reflist}}", because they would give exactly the same appearance. The reason to make the change via CSS is to avoid having to edit all those pages. However, the underlying question of the proposal is to decide whether the appearance should be the same; it does come down, in some sense, to editors' opinions on standardization. — Carl (CBM · talk) 01:45, 14 December 2010 (UTC)
      • Ok, thanks for your helpful replies. too Support the change now, for what its worthAjbpearce (talk) 18:27, 14 December 2010 (UTC)
• Comment. Has anyone noticed that on the default skin (Vector), {{reflist}} doesn't give smaller text and columns, but gives exactly the same as </references> gives? Fences&Windows 00:19, 14 December 2010 (UTC)

Yes, I noticed that, and in fact raised it as an issue when Vector was introduced. Someone pointed me to a fix that I added to one of my user configuration files, which restores the small type, but only, of course, when I'm logged in. If there is interest, I'll go back and find the thread, and the fix. --Tryptofish (talk) 00:35, 14 December 2010 (UTC)

Actually, the font is smaller, but may not be noticable. On Windows with default fonts, 90% results in tighter letter spacing and smaller capitals, while lowercase letters remain essentially the same size. — Edokter • Talk • 00:58, 14 December 2010 (UTC)

Oh, that's right. Drat, I really like it smaller. But no matter, consistency trumps my personal taste. --Tryptofish (talk) 01:54, 14 December 2010 (UTC)

• Support. Coincidentally, F&W just asked a question about exactly the issue that interests me the most about this question. It seems that, with Vector, there is even greater inconsistency from one (computer? operating system? video driver? browser? phase of the moon?) to another. Yes, consistency is exactly what we should want, and this proposal may fix an inconsistency in Vector. Let's do it! --Tryptofish (talk) 00:35, 14 December 2010 (UTC)
• Support again. As I mentioned in the previous discussion, I find the reduced-size references abhorrent, and I think everyone else should too. We won't ever get to proper reference formatting without eliminating all the variants that would be used to reimplement some editor's belief that reduced font sizes "look nice", so I support this necessary first step. — Gavia immer (talk) 01:05, 14 December 2010 (UTC)
• I support the change. I generally agree with Gavia immer, but I think that over time it is becoming less sustainable to have a difference between the two ways of displaying footnotes, and I think that moving all the style to a single CSS class has advantages. — Carl (CBM · talk) 01:41, 14 December 2010 (UTC)
• Support the change. As to the complaints about vector, I can't understand why anyone would use it. I've never seen a skin for anything that did more to get in your way then Vector does. It seems built to hinder your productivity and exploration. And that's in addition to being butt-ass ugly. -- ۩ Mask 03:19, 14 December 2010 (UTC)
• Support these should give the same result as each other. -- Eraserhead1 <talk> 08:38, 14 December 2010 (UTC)
• Support. There was clear consensus on previous discussion as well. The only genuine objection was on the grounds that Reflist makes the text too small. That does appear to be a sideways objection as the aim here is simply standardisation - if there is genuine concern that Reflist makes the text too small, then that is a discussion about how we approach the formatting of citations in general, as the text size problem will remain even if these Wiki-codes are not merged (as Reflist is widely used). And if the codes are not merged, that leaves open the possibility of edit warring, which is inappropriate. Let's merge, and someone may later open a separate discussion about accessability issues re text size on the formatting of citations if they wish. SilkTork * 11:36, 14 December 2010 (UTC)
• Support - make the look more uniform across all Misplaced Pages articles. עוד מישהו Od Mishehu 11:56, 14 December 2010 (UTC)
• Support. Standardizing the display of the references is a good idea, IMO. Kaldari (talk) 02:50, 16 December 2010 (UTC)
• Support per SilkTork's reasoning. Diderot's dreams (talk) 02:58, 16 December 2010 (UTC)
• Oppose The last thing we need to be doing is making the already tiny font size smaller in even more places. We really should be doing the opposite right now: making {{References}} display at font size 100%. access_denied (talk) 03:12, 16 December 2010 (UTC)

Help:Talkspace draft

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

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

OK, I've changed that, so the instructions say to copypaste and provide a permanent link to the draft page in the edit summary. OK now? Rd232 21:44, 14 December 2010 (UTC)

Open Plaques integration

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

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

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

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

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

The problem with using a bot is that you may need human intervention to confirm that the correct article is being linked to the plaque. For example, Open Plaques has an entry for James Watson and the English wikipedia has seventeen articles for people named James Watson, two for Jamie Watson and eight for Jim or Jimmy Watson. That's a lot of potential for making the wrong connection. Does the volume of material really justify creating and maintaining a bot? How many new people get added to your database every month? Perhaps using humans to make the link would provide a useful opportunity for cross-checking the quality of data. - Pointillist (talk) 22:14, 13 December 2010 (UTC)

Thanks for the response. We do use humans on our side to check that the person we link to is the right person! Internally, we store a Misplaced Pages URL for each person and use that for both the visible links, pulling the lede in and linking to DBpedia. Rather, I think the questions that we'd like to hear about from the Misplaced Pages community are:

1. Would it be considered spammy if we were to add links to articles to Open Plaques given that we are both producing 'open content' material?

2. If not, would it be acceptable to create a bot to add those links automatically?

If the answer to (1) is yes, that's fine, we won't do it. We don't want to be dicks! But if it is okay for us to add links, it would be easy for us to add a little callback to our software that would queue up a bot to go and edit the relevant Misplaced Pages article automatically, as it would then come from a bot account. It'd be easier for us to have a bot as we wouldn't then be reliant on having someone in the community remember to go and put a link back from the Misplaced Pages article. —Tom Morris (talk) 22:21, 13 December 2010 (UTC)

(2) would generally be decided via WP:BRFA. --Cybercobra (talk) 08:15, 14 December 2010 (UTC)

Note that the community can and should decide now whether they want these links and want them added by a bot, or BAG may well send the question back here for discussion. Anomie⚔ 13:28, 14 December 2010 (UTC)

Enable edit notices in project namespace

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

Please don't - they're annoying enough everywhere else, I'd rather get rid of them from all namespaces. DuncanHill (talk) 21:10, 14 December 2010 (UTC)

Those are probably individual examples that you find annoying, and not the ability itself. I'm looking to just be able to add a note or two at the top of project pages to help direct users to the correct venue. The BLP ones are annoying though, I'll admit. - ʄɭoʏɗiaɲ  _¢ 21:14, 14 December 2010 (UTC)

I've never seen one that I didn't find annoying. DuncanHill (talk) 01:14, 15 December 2010 (UTC)

Start a discussion on the project's talk page about your proposed note, and if it gets consensus it will be easy for an admin to create the editnotice. Anomie⚔ 21:19, 14 December 2010 (UTC)

You might be interested in WP:CSSHIDE. Each editnotice should have its own ID, so you can hide it using your CSS file. Rd232 21:38, 14 December 2010 (UTC)

Why waste an admins time? I see it on some project pages (eg here), but not on others. Why would this wikipedia namespace page have a placeholder for one, but others not? - ʄɭoʏɗiaɲ  _¢ 22:50, 14 December 2010 (UTC)

It's really not a big deal to make or handle a request on a case-by-case basis, or even (using templates) to request a standard template be added to pages X,Y,Z. The problem with allowing it generally is that a lot of these pages aren't much watched or edited, which makes it more likely abuse of various kinds would stick around unacceptably long. Rd232 01:01, 15 December 2010 (UTC)

I like editnotices :3 - Beyond that, I don't see how some in the WikiProject space would hurt anything. Ajraddatz (Talk) 15:16, 15 December 2010 (UTC)

Recommending columns in reference lists longer than 20 entries

Please consider joining the feedback request service. An editor has requested comments from other editors for this discussion. Within 24 hours, this page will be added to the following list: Misplaced Pages style and naming When discussion has ended, remove this tag and it will be removed from the list. If this page is on additional lists, they will be noted below.

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 Misplaced Pages: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 * 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 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 Misplaced Pages 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 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 13:05, 15 December 2010 (UTC)

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 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 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 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 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 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 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 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 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 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 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 15:38, 15 December 2010 (UTC)

Anything workable that allows users some choice in these matters would be great. Rd232 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 Misplaced Pages 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. 00:33, 16 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 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 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 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 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 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 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)

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

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

Redlinked images and deletion logs

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

Put importScript('User:Gary King/show upload deletion logs.js'); to User:LtPowers/vector.js (or whatever skin you are using).—Emil J. 14:22, 15 December 2010 (UTC)

That's a good workaround but I would prefer a more integrated solution. Powers 14:44, 15 December 2010 (UTC)

Me too. If it could at least be turned for admins. But also for normal editors the deletion log seems to be more practical than immediately the upload screen. Garion96 (talk) 15:36, 15 December 2010 (UTC)

• Misplaced Pages noticeboards
• Misplaced Pages proposals
• Pages automatically checked for accidental language links
• Misplaced Pages requests for comment