This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212
Since this wiki is relevant only to the English Wikipedia project, I have decided to place the proposal here instead of meta, where they would normally decide whether to close down Wikimedia wikis. This is not a real encyclopedia even though it is registered under the .wikipedia.org domain name. It is an entire wiki dedicated to a single issue on the English Wikipedia. I do not believe that we should have wikis opened for every incident on any Wikimedia wikis; we would not have to open some new domain called http://wg.ur.wikipedia.org for example. And anyway, according to this wikiproject and its associated report from 2008 this wiki should have been closed as the disputes for the wikiproject have been resolved. :| TelCo NaSp Ve :| 05:29, 22 November 2010 (UTC)
Hi, the template {{ Infobox musician awards}} is extremely long and very difficult to navigate as it constricts all the tables present beside it. Hence I was proposing to have the awards portion of the template as collapsible, so that it would not constrict the tables. Also it looks more professional. An example of such a manually coded collapsible template can be found at List of accolades received by Precious. I am not very good with coding in HTML hence don't know how to change the template to reflect the collapsible thing. The linked article uses this code.
{{!}} colspan=3 {{!}}<br> {{{!}} class="collapsible collapsed" width=100%<br> ! colspan=3 style="background-color: #D9E8FF; text-align: center;" {{!}} Awards and nominations<br> {{!}}-<br> What say everyone? — Legolas (talk2me) 09:56, 22 November 2010 (UTC)
Simple suggestion: link alternate accounts ( WP:SOCK#LEGIT) from a user's Contributions page. This would require a simple software change (unless somebody has a clever way to do it without that), with an additional entry in Preferences for alternate accounts, and then a link to the other account(s) being given at the top of the page. We already have templates for the user page, but this would be clearer and harder to miss, and more convenient. Rd232 talk 13:36, 25 November 2010 (UTC)
Right spot for this? Is there a way we can make auto-confirmed or some other criteria of user, to allow said user to link to black listed links? It is a ridiculous when I can't show a link in a GAC to a website, because other users, use it for spam. CTJF83 chat 02:32, 23 November 2010 (UTC)
Problem: We have a system of editnotices which is currently basically only maintainable by admins. We can expand this in a way that remains safe (the core problem is that editnotice vandalism would be particularly hard to detect and fix for most editors.) Proposal: create a bot which maintains editnotices on the basis of templates added to the article talk page. Category:Editnotice templates would be expanded, and a standard editnotice template added by the bot into the editnotice if it finds an appropriate template request on the talk page. For example, if it finds {{ British English}} on the talk page it adds {{ British-English-editnotice}} to the page's editnotice. It would operate from a fully protected list of templates, translating the talkpage request templates into editnotice templates (which would themselves be fully protected).
As a slight variation, it would also be possible to do the same thing based on categories within the article, rather than templates on the talk page; this would work in exactly the same way, with a protected list of categories to be translated to editnotices. I'm not quite sure if this is better, it's perhaps marginally more intuitive(?) and perhaps likely to be implemented more widely (perhaps over-used?), but the template method would ensure a note on the talk page as well if appropriate, which may be useful.
Why? Because it'll make it much easier to use editnotices much more widely, eg to advertise Arbcom restrictions at the edit stage exactly where it's needed, to pick one example. In terms of possible overuse, because it's controlled by a bot and a central list, it should be relatively manageable to keep track of and ensure it's only used where necessary (eg, the bot could only apply the editnotice template if the request applies to a page within a certain category). Comments? Rd232 talk 02:15, 26 November 2010 (UTC)
I think that an additional special page to complement Special:PrefixIndex would greatly help users in searching for certain pages with certain suffixes; see this discussion for more information. (Sorry if there was a discussion before about it that I did not see; if anybody finds one, please link it here so that I know better the next time. Thanks.) :| TelCo NaSp Ve :| 01:45, 21 November 2010 (UTC)
Proposal: every January, for the whole month, organise a prominent Wikipedia:WikiProject Countering systemic bias Improvement Drive. By "prominent", I mean prominent, with a watchlist notice, WP:SIGNPOST coverage, and coordinated outreach to non-English Wikipedias. A key part of the Drive would be a landing page where editors can find out more about the issues, and investigate what aspect of CSB improvement they might be interested in. I imagine that a part of this might be a sort of Wizard or Guide, as a way for example to suggest to people interested in Baseball what aspects of Baseball are systemically neglected, i.e. with a listing of underserved baseball topics outside the US. Besides which, it would be part of the Drive itself, especially in the first year, to construct such a Wizard/Guide; I'd expect individual WikiProjects to play a particular role here in kicking things off. Basically, the core points of the proposal are (i) try to harness people's existing interests in a way they might like but haven't thought of; (ii) improve understanding of the nature of the CSB coverage issues (iii) generally raise the profile of CSB issues. Rd232 talk 11:42, 24 November 2010 (UTC)
I'd like to propose that we link Wikipedia:New contributors' help page a lot more from places that might rather increase the number of newcomers finding somewhere helpful and friendly to go. I'm looking at MediaWiki:Anoneditwarning, perhaps also MediaWiki:Semiprotectedpagewarning and MediaWiki:Protectedpagewarning. I'd also like it to be linked from an editnotice seen by new accounts who are not yet auto-confirmed, but I'm not sure there's any way of targeting them. The proposal is associated with my proposed redesign of that page ( Wikipedia_talk:New_contributors'_help_page#Redesign), which will make it a friendlier landing page and better able to cope with an increase in traffic. Pre-emptive counter to one inevitable objection: if it generates too much traffic and overwhelms the page and we can't figure out a way to handle it, we can get rid of the links again. I feel the more we have issues with declining editorship, and the larger and more complex Wikipedia gets, the more effort we need to put into easing newcomers into becoming Wikipedians, rather than remaining readers or just dipping a toe in and finding it too hard. Linking this help page more prominently would help a little, but I'd love to hear any other ideas. Rd232 talk 22:15, 24 November 2010 (UTC)
Hello you all the English speaking wikipedians in the world. Please excuse my approximative English, I'm a froggy. Some months ago, I asked a question on the Reference Desk (languages) about the gender of non humans things in English. I was thinking particularly about ships and boats etc.. I got many interesting answers such : a ship is "she", a boat is "it" with the joke "How to recognise one from the other? Answer: You can put a boat on board a ship".
I learnt that most means of transportation are "she" except trains (without knowing why, he said). But what about motobikes? About bicycles?
Please notice that it would help EVERYBODY whishing to improve his/her English and that even my wife, an English teacher (fairly good at English) doesn't know everything about that. Her grammar books, for example are not comprehensive on this subject.
For example this page: http://en.wikipedia.org/wiki/Gender_in_English#Modern_English doesn't speak about trains, bicycles, mountain-bikes, etc...
One of the answers, consideriging that these kinds of questions are frequent on that Desk proposed that it would be a good thing to write an article on that subject.
All that introduction to ask you if you could creat an article on this subject or, more simple, enhance the one I quote above.
Thank you very much for everything you do. Jojodesbatignoles-Rheims-France--- 90.18.67.249 ( talk) 13:33, 27 November 2010 (UTC)
For example:
War is now/current continue. is available in a Wikipedia text
Please not use the now and current words. you must warning the all members on this issue. Now and current words is remove.
Becuase;
For example:
War is now/current continue text with now or current word is write at 1 September 2009 I am see the this text at 1 June 2010.
maybe the war ended on 1 June 2010. I am think war is still continue.
Please warning the robot and members which correcting errors. They/We are remove this words. They/We are change with a more appropriate sentence and the words
88.235.131.60 ( talk) 14:45, 27 November 2010 (UTC)
Hey Guys, its been a while
Would it be appropriate yet to write an article on the new internet meme revolving around Wikipedia founder Jimmy Wales? Several notable media sources have covered the rise of this meme and I am not sure if it fufills general notability guidelines for inclusion. Thanks. Marlith (Talk) 17:57, 27 November 2010 (UTC)
Here's an idea: There should be a mode select for articles with cussing, sex references, gore, e.t.c., that censores and uncensores all these things. 82.13.79.52 ( talk) 07:57, 24 November 2010 (UTC)
82.13.79.52 ( talk) 08:47, 1 December 2010 (UTC)
Currently, DeleteRevision merely marks the contents of deleted revisions as unavailable, and admins may noticed such that revisions do not show up under Special:Undelete. In order to delete a revision the "normal" way, an admin still has to delete the entire page and then restore the revisions that they want to keep. It would be nice if DeleteRevision had an actual "delete" function. -- Ixfd64 ( talk) 23:05, 28 November 2010 (UTC)
Please check out this page, look in the bottom left of the screen, and scroll down to see my proposal in full effect. I made this myself and I think a modified version of it would be a usefull, cool and maybe even necassary tool, especially for those with slow scrolling like me. It would help with long articles if you randomly or purposely decide to search another article. A Word Of Advice From A Beast: Don't Be Silly, Wrap Your Willy! 03:37, 28 November 2010 (UTC)
It seems like {{
reflist}} is used on most new articles. Historically, when the template was developed we left <references/> on the articles that already had it. Should we have a bot go through and convert the remaining uses of <references/> to use the reflist template instead? The advantage would be uniform styling, since the template gives a slightly different appearance (a smaller font) than the <references/> tag does. The disadvantage would be that we would be changing the established style on the pages that use <references/>. — Carl (
CBM ·
talk)
20:28, 29 November 2010 (UTC)
{{
reflist|text-size=regular}}
, or similar.
Headbomb {
talk /
contribs /
physics /
books}
23:09, 29 November 2010 (UTC)
<references />
with {{
Reflist}}
because of the additional features Reflist provides, such as "colwidth". Personally, I do not want to see <references />
banned from Wikipedia, but general recommendation to use Reflist would be nice. —
bender235 (
talk)
23:19, 29 November 2010 (UTC)
I support a general establishment of preference for {{ Reflist}} over <references/>, with or without bot conversion. — chaos5023 ( talk) 23:20, 29 November 2010 (UTC)
Comment on AWB: AWB doesn't change {{ Reflist}} over <references/> unless the editor who introduced it requested small font size. -- Magioladitis ( talk) 23:23, 29 November 2010 (UTC)
I usually use <references/> when the references are really few (maximum 3 or 4) and reflist for 5 or more references. For over 30 or something I use refelist with 2 columns. -- Magioladitis ( talk) 23:24, 29 November 2010 (UTC)
|refs=
argument to {{
Reflist}}, so never use <references/>. —
chaos5023 (
talk)
23:27, 29 November 2010 (UTC)The Wikipedia window is alreay cluttered with so much stuff that smaller and smaller font sizes are resorted to inorder to present enough content on one screen to make comprehension easy. I oppose any use of fonts smaller than the size used for running text on the grounds it is too hard to read. Jc3s5h ( talk) 00:31, 30 November 2010 (UTC)
|colwidth=
and |refs=
. I think we could've left bot enforcement out of it, in any event, but that's fine. Askance gaze withdrawn. —
chaos5023 (
talk)
02:44, 30 November 2010 (UTC)
refs=
. You just have to remember that <references/>
does not have to be written as a an empty entity. You can write <references><ref …><ref …><ref …></references>
Again, I am urging you not to be distracted from the original topic. What brought
User:CBM here was this
WP:ANI. It's about whether Wikipedia users should be allowed to replaced <references />
with {{Reflist}}
(or vice versa) as part of the standard
fixing minor errors process. I said yes, CBM opposed. —
bender235 (
talk)
12:04, 30 November 2010 (UTC)
Let's be absolutely clear: it is now being proposed to change Mediawiki:Common.css so that <references /> has the same styling as {{ Reflist}}. This ensures standardisation. If this is done, it doesn't matter formatting-wise which of <references /> and {{ Reflist}} is used, unless a page needs the advanced options of {{ Reflist}}. All in favour say aye. Rd232 talk 13:23, 30 November 2010 (UTC)
{{Reflist}}
offers more features, why not have a guideline that says "the use of {{Reflist}}
is recommended"? Or at least one that says "in case there are 10+ refs, multiple columns (e.g. {{Reflist|
colwidth=30em}}
) are recommended"? Because the columns are the major advantage of {{Reflist}}
compared to <references />
, not the smaller font size. —
bender235 (
talk)
14:00, 1 December 2010 (UTC)
{{Reflist}}
over <references />
, and that is the columns feature. —
bender235 (
talk)
00:11, 3 December 2010 (UTC)
Some seem to prefer custom visual styles, see Talk:Julian Assange#Scroll-box visual style. Is there some guideline for this? Another issue is the mixing of WP:LDR-type citations with those in the article body—there's no visual difference here for the reader, but there is (an organizational) one for editors. Tijfo098 ( talk) 10:23, 3 December 2010 (UTC)
I propose a bot that monitors the RC feed and updates a page at a timely interval (I suggest hourly) with various statistics.
Some statistics I suggest are:
{{
Vandalism information}}
and many more such as moving averages, daily averages etc.
I believe that this will give us a wealth of information, which we can use as an example to make graphs showing server load time by hour over the week.
Is the community interested in such a bot, and what further improvements and statistics do you suggest? 930913 ( Congratulate/ Complaints) 09:53, 1 December 2010 (UTC)
Let us be clear - how can we have some feedback on which proposals, say, over the past twelve months, have been succesful?It would be nice to think that this feature of Wikipedia serves a useful function. ACEOREVIVED ( talk) 19:28, 2 December 2010 (UTC)
Would you like a feature where you could update your status (Online
, Offline
, or even Custom
) so that other editor may see? And how about doing that without clogging your
contributions?
For general comments, you may respond here. For comments that would directly effect the feature's deployment, please join the discussion, or participate directly at Bugzilla:26246. Thanks! Reh man 00:54, 4 December 2010 (UTC)
Sparked by the discussion above and suggested by EVula, as well as by past discussions relating to element- and page design, where there is always the few that object change because "the font is too small!", I propose a gadget that provides a one-click solution to those that loathe small fonts. It basically resets the fontsize of those elements, such as navboxes, infoboxes and reference lists to 100%. The list can be extended as I am bound to have forgotten a few. This should help readability for those that have problems with small fonts.
The code is here: MediaWiki:Gadget-NoSmallFonts / MediaWiki:Gadget-NoSmallFonts.css. Those wanting to testdrive it can simply copy the CSS code to their vector.css file. — Edokter • Talk • 02:16, 1 December 2010 (UTC)
There is also an opposite problem. Many try to create small caps with the code small, but this does not work. E.g. for chemical names.-- Wickey-nl ( talk) 17:35, 3 December 2010 (UTC)
Small caps are part of a chemistry nomenclature (see Chirality_(chemistry)#By_configuration:_D-_and_L-; especially see the try of an editor in the heading). It is hardly applied in WP yet, because hardly anyone knows the Smallcaps template. Is a smallcaps editbutton possible?-- Wickey-nl ( talk) 10:45, 4 December 2010 (UTC)
There is a great new tool from toolserver.org that allows seeing a DETAILED graphical and statistical view of a page's history statistics. It's one of those tools that just has to among the External Tools in the history page. Someone add the tool to the section or contact the technical team that has the ability to it.
Here you can see page history statistics for Wikipedia:Village_pump_(proposals): http://toolserver.org/~soxred93/articleinfo/index.php?article=Wikipedia%3AVillage_pump_%28proposals%29&lang=en&wiki=wikipedia&begin=&end=
I am proposing there be a template for A-class articles like Template:Good article and Template:Featured article. I don't see why there isn't one, since A-class articles have surpassed GA and deserve such uhh I can't think of a word for here. Respect? Okay. So I was thinking a page like this. Crowz RSA 19:59, 5 December 2010 (UTC)
So I've noticed that when editors add or remove templates, they generally use the template code in the edit summary instead of saying "Template:Whatever". Often when I have gone on tagging sprees (populating a stub category or for a WikiProject) I will simply paste the template code into the article and then paste into the summary. Almost every editor will know that "{{Disney-videogame-stub}}" as an edit summary means that article was tagged with that template. For some reason I always assumed that this created a wikilink in the summary, as is possible with normal links, but I just realized this is not the case.
So, to be specific, I am proposing that template links in an edit summary be treated as a wikilink to that template. So "{{Disney-videogame-stub}}" would display as "{{ Disney-videogame-stub}}". There is obviously no giant benefit to be gained, it would just make reading histories and watchlists more informative. It should be a minor software change, I just wanted to see if it would have community support. Thanks! ▫ JohnnyMrNinja 07:24, 7 December 2010 (UTC)
Please see WT:MOS#Quotation mark glyph straw poll. A. di M. ( talk) 11:59, 7 December 2010 (UTC) Fixed link. -- Stephan Schulz ( talk) 12:16, 7 December 2010 (UTC)
The following is a suggestion for a new Wikipedia feature - specifically, a volatility index for each article, built into (or near) the header of each article:
As we’re all aware, the popular complaint/stigma surrounding Wikipedia has been its correctness/reliability. This stigma comes because in general, the older generation (anyone who grew up before Web 2.0) distrusts (because it fails to understand) the speed and effectiveness of self-policing in online communities, especially large ones, like that of Wikipedia’s readers and contributors. My hope for the feature I’m suggesting here is to present a mechanism for assuaging the fears of the older generation (unfounded as they may be) by harnessing the Wikipedia article’s living nature.
The approach I’m suggesting to this reliability/correctness issue requires that we first accept that we can never be 100% sure of the correctness of any article at any single moment (Wikipedia or otherwise), but with Wikipedia, what we can do is get a really good idea as to the risk involved in trusting a specific article at a specific moment, thus drastically reducing overall public anxiety about using Wikipedia in general.
The approach is this: Simply display, at, say, the top right of each Wikipedia article, a small graph of the number of changes (edits) to the article per hour (or minute or day) over a span of several days, or months or years – the user should be able to click whichever of these time frames interests him, just as an investor may want to see a 1-hour, 1-day, 1-week or 10-year graph of the price of a stock that interests him.
Here’s an example of how it might work: Imagine that a skeptical user wants to educate himself on a new subject, so he searches Wikipedia and finds an appropriate article. Imagine next that the subject our user is researching has become popular recently and so the article is currently high in both “read-only” and “edit” traffic. The user arrives on the article/webpage, and in the top right of the screen there’s a small graph showing the number of changes that have been made to this very article over the past month (or week or day or hour), i.e. x-axis is time, in days (or hours or minutes) and the y-axis is number of changes. The user sees he has the option to zoom the graph in or out (to a timeline of a few hours or a few years), much like he would, as mentioned above, with stock price info on his broker’s website.
With this graph, which is kept up to date in real time by Wikipedia (or perhaps by http://stats.grok.se/), the user sees at one glance both the current and historic volatility of the article he’s viewing, just as a stock trader sees the market’s volatility using an index such as the VIX ( http://en.wikipedia.org/wiki/VIX). High volatility for a Wikipedia article (a current spike or plateau in changes per unit time) tells a reader that the article (to continue the stock market parallel) is currently volatile, or unstable, and that using the info that appears in the article (for, say, a school paper) at this moment carries more risk (of inaccuracy, in Wikipedia’s case). The high risk (high changes per hour) could be because the subject of the article is a developing situation, or because it’s controversial and opposing viewpoints are in the midst of an edit war. Point is, now the reader has a way to know at a glance that something is going on that makes the current content of the article likely to change rapidly. The user can then make a choice, such as deciding to check back later, i.e. to not use the article’s info until the changes per hour have settled to a level that represents higher agreement among all potential editors who have been monitoring the article (less risk of inaccuracy).
If one wanted to take this idea a step further, moving averages could be shown, and even manipulated by users (e.g. 30-day or 180-day), and teachers could advise students, for example, not to use an article unless its current changes per hour were at or below some moving average of their choosing, say 30 days for example. The actual numbers used could be adjusted by the user (or his teacher) depending on desired risk levels.
Yet another step further would be to determine better ways to illustrate reliability of an article – i.e. instead of edits per hour, or changes in edits per hour, maybe a formula like ((edits / views) / hour) would prove more reliable – I’ll leave that to interested statisticians and econometricians.
In summary, everyone knows the risks at Wikipedia. It would be a mistake to treat them as a PR issue. Quantifying the risks and giving the public a way to work with them easily should increase the general public’s confidence in Wikipedia.
-- Aldobiella ( talk) 02:10, 8 December 2010 (UTC)
While it may not be a good idea to add a volatility indicator at the top of articles, it is useful to have such tools available to editors and those who want to see them to for their judgment on the reliability of an article.
That's why I propose that a third tab besides the Article and Discussion should be added, which can be named Statistics, Article Statistics, Volatility or a similar term, which will allow the viewing of editing statistics of an article.
A tool is available which can help in creating such a statistics viewer:
Through the Article History Statistics tool, you can see the history statistics of the article "Wikipedia" on the English Wikipedia: http://toolserver.org/~soxred93/articleinfo/index.php?article=Wikipedia
A statistics page for a third tab, aimed to help the public judge the reliability of articles and information on Wikipedia seems like a natural step toward enhancing the usability, reliability, and the transparency of Wikipedia. It will allow it to serve its mission of providing reliable information in a free encyclopedia of user-generated content. And it seems the rudiments for its creation are already in place. And as a third tab, it is not likely to provide a distraction in casual reading of articles any more than dose the Discussion tab. I think it will be a worthwhile and fruitful step to take.
The Article History Statistics tool should also be added to the external tools on the article revisions page, this more geared toward editors, as opposed to the tab, which will help better inform readers and the public about article reliability and their exercise of caution. λόγος Idea → ✉ 19:10, 9 December 2010 (UTC)
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)
#siteSub { display:none; }
in your
skin.css if it bothers you that much.
Anomie
⚔
18:40, 30 November 2010 (UTC)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)
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)
Since Wikipedia is a proper noun and not a noun, surely we can be reasonably liberal in thinking about what to call it. After all, as early as 1997, there was
Nupedia I am sure that was not about Nus. In fact, some of the information in Wikipedia is about wikis - we have an article on
wiki, for example.
ACEOREVIVED (
talk)
How about for a limited period, we put, on the main page under "Welcome to Wikipedia...", a prominent disclaimer that Wikipedia is not connected with Wikileaks. The confusion about this seems widespread. 86.184.239.37 ( talk) 20:55, 7 December 2010 (UTC)
Please oh no. We're now just feeding WikiLeaks. / ƒETCH COMMS / 02:34, 11 December 2010 (UTC)
A recent article in Nature (08 December 2010) states : Scientists who receive public or charitable funding should therefore seize the opportunity to make sure that Wikipedia articles are understandable, scientifically accurate, well sourced and up-to-date. Many in the scientific community will admit to using Wikipedia occasionally, yet few have contributed content. For society's sake, scientists must overcome their reluctance to embrace this resource. Nature : Time to underpin Wikipedia wisdom. Interesting. JoJan ( talk) 14:39, 10 December 2010 (UTC)
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)
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 Dask 07:35, 6 December 2010 (UTC)
It's time to stir the pot again and get some fresh eyes on the issue of using OpenID on Wikipedia. See WP:OpenID Proposal. I don't see any technical details holding us back from at least being able to attach an external OpenID account to your Wikipedia account, and subsequently being able to log in via your OpenID provider of choice. It would be opt-in, so wouldn't hurt those that don't understand how OpenID works.
Can we reach a consensus here, and then perhaps put pressure on the techies at Bugzilla to get it done? Bug 9604 is already filed for the purpose of "Support[ing] OpenID extension on all wikimedia projects", and the featured proposal Strategy:Proposal:Support_OpenID has the same idea. Let's lead the way at en.wikipedia. ...comments? ~ B F izz 23:44, 11 December 2010 (UTC)
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:
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)
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:
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)
I think there could be many benefits, and relatively few disadvantages in allowing registered users to add edit notices to the top of WikiProject pages. Can they be enabled for pages that begin with Wikipedia:WikiProject ? - ʄɭoʏɗiaɲ τ ¢ 21:07, 14 December 2010 (UTC)
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)
{{
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. --
N
Y
Kevin @771, i.e.
17:29, 3 December 2010 (UTC)I'm not sure if this is the best place to put this: it may be better as an RFC but I'll start here and see where it goes.
I'm a developer on the open source codebase behind Open Plaques, a public domain database of commemorative plaques that are attached to buildings in the UK (and increasingly elsewhere). Each person in the Open Plaques database tends to have a link to Wikipedia (en) and reuses the lede from Wikipedia. We are also using RDFa to link through to DBpedia.
At the London Wikimedia meetup yesterday, I discussed with Fæ how it might be possible to link together Open Plaques and Wikipedia more. One way I am looking into is how Open Plaques can reuse images from Commons: we use Creative Commons licensed images on Flickr, but we could also start using images from Commons, and we may also want to start allowing people to upload images straight to the site, in which case, we might look into storing those images on Commons rather than either having to host them ourselves or, say, get a Flickr account.
The other way we can integrate is through links. We are already linking to Wikipedia. And Thomas Turner (diarist) and Hawkhurst (and possibly others) link to Open Plaques. I'd like to suggest that the Open Plaques community may be able to contribute to Wikipedia by creating a bot: basically, this bot would add an Open Plaques link to Wikipedia articles every time a new person gets added to our database. This could be removed if it was felt inappropriate by the community of people who edit the article in question. We could have a template which would link by id specifically, which could be updated easily if our database changes.
I don't know if this is appropriate or how we go about seeking consensus from Wikipedians and Wikimedia in general, so I'd love to hear advice on whether this kind of thing is practical and desirable. Thanks in advance. — Tom Morris ( talk) 20:23, 13 December 2010 (UTC)
There is also the problem of copyright on the texts of the plaques. Commons for instance is seriously considering dumping more images of plaques because of questionable copyright status. Something to keep in mind. — TheDJ ( talk • contribs) 15:46, 18 December 2010 (UTC)
I think it would be a major improvement for mediawiki software to implement an upgrade to make tables to be more interactive. When I say that I am thinking about the ability to show/hide some rows and columns, defined in some kind of profile. Take for example this list: List of countries by population. For example an interactive table would be capable to show the countries of a single continent, and hide those from other continents, when the user needs that. Also would help the user see the first 5 countries from each continent for example. When you have a conversation with someone, you might want to show just some of the data in the table, therefore you would like to be able to hide the columns 4,5 and 6, because they are not relevant in your discussion. Profiling tables would mean adding some filters (simple or sophisticated), or simply to manually define each profile. However implemented in the software, I don't think it would ask for extensive work from the programmers, also it won't load the browser with too much JavaScript, but it would be for sure a MASSIVE improvement for the way data can be presented and make use of. Thanks. — Ark25 ( talk) 03:17, 16 December 2010 (UTC)
It has been proposed to change Mediawiki:Common.css so that <references /> has the same styling as {{ Reflist}}. This ensures standardisation. If this is done, it doesn't matter formatting-wise which of <references /> and {{ Reflist}} is used, unless a page needs the advanced options of {{ Reflist}}. A discussion on this was open for 2 weeks and had a strong consensus, and was then automatically archived for lack of activity: see Wikipedia:Village_pump_(proposals)/Archive_67#Change_to_template:reflist_fontsize_wiki-wide.3F. What does the styling change entail? Making references sections consistently displayed at 90% font size. It should be noted that we now have a new Gadget "Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists." (see MediaWiki:Gadget-NoSmallFonts.css). Rd232 talk 12:34, 13 December 2010 (UTC)
<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)ol.references { font-size: 100% !important }
Examples
| |||
---|---|---|---|
|
{{Reflist|colwidth=25em}}
or similar. But articles with one or two refs don't need shrunken references, and the standard font size on Wikipedia is, AIUI, already less than 100% of users' default font size. I thought there was some statement at
WP:ACCESS about aiming for full-size text, but I don't see it there now.<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)/* Set the font size for {{reflist}} */ .references-small { font-size: 88%;}
Is it just me or did the edit have the result that {{Reflist|colwidth=30em}} no-longer function with all 3 columns? Not sure how many people use browsers with this capability but think this should be addressed. Moxy ( talk) 18:12, 21 December 2010 (UTC)
I was told elsewhere that the vector skin abhorred the smaller typeface. Is this so? And if so why do we not make Monobook work the same way?
Rich
Farmbrough,
01:27, 22 December 2010 (UTC).
So, inspired by a recent thread, I've created Help:Talkspace draft, adapted from Help:Userspace draft. Can use some improvements, but I hope the basic idea is clear. What do people think? Rd232 talk 15:30, 13 December 2010 (UTC)
Note: there is related discussion about the nature/purpose of this thing at Template_talk:Talkspace_draft. Rd232 talk 22:58, 21 December 2010 (UTC)
Is there any way we can get a deletion log to show when clicking on a redlinked image link? Powers T 14:03, 15 December 2010 (UTC)
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)
For some purposes, not least understanding multiple-sock behaviour better, it would be helpful to able to merge multiple accounts' contributions into a single list. It would be great if the software could do this somehow (where it would also help transparency of legitimate alternate accounts), but in the mean time, it ought to be not that hard for a toolserver tool to do this: put multiple accounts' contribs together in the usual date order, with maybe different accounts in different columns. Or perhaps this already exists, and I missed it. Rd232 talk 22:51, 17 December 2010 (UTC)
As far as I know there is no clear recommendation whether or not to use columns on reference lists, and which (fixed set of columns, e.g. {{Reflist|2}}
, or flexible set, e.g. {{Reflist|colwidth=30em}}
). Flexible sets of course offer the advantage of displaying just the amount of columns that suits the visitor's monitor size (which means someone who's having a 20+ in monitor will see 4-5 columns, while someone with a 10 in netbook will see only 2. The
ideal width for columns has been discussed at
Wikipedia:WikiProject Usability). Therefore I would like to propose an additon to
WP:CITE that generally recommends the use of {{Reflist|colwidth=30em}}
on articles with more than 20 references, unless local consensus (of editors of a specific article) opposes it. —
bender235 (
talk)
02:33, 15 December 2010 (UTC)
{{Reflist|30em}}
. —
bender235 (
talk)
10:29, 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 talk 11:29, 15 December 2010 (UTC)
{{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)
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)
{{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){{
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)
{{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.{{Reflist|colwidth=30em}}
because people didn't like it, but because there is no Wikipedia rule or guideline that recommends this style (or any other). So this proposal is actually meant to establish clarity on what the global consensus regarding reference lists is. —
bender235 (
talk)
14:54, 15 December 2010 (UTC)
Could someone clarify the proposal for me? Which of these is being proposed?
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)
colwidth
. The exact width of the columns, however, has to be determined on each single article. This is actually about recommending the use of flexible columns in general, not about stipulating a particular width. —
bender235 (
talk)
22:48, 15 December 2010 (UTC)Just my two cents on this matter. In my opinion, we should use columns for long reference lists (and there are plenty around here). This way, people do not have to scroll over a long reference list for ages just to get to the External Links section, etc. and back. [| Retro00064| ☎talk| ✍contribs|] 00:33, 16 December 2010 (UTC)
So, do is their at least consensus that articles with long reference lists (20+ refs) should use columns, regardless of width and number? — bender235 ( talk) 14:19, 17 December 2010 (UTC)
{{Reflist|2}}
was more like a temporary solution when nothing else was available. Now, however, we have colwidth
, and that is a much better option. So instead of cementing the status quo by recommending users to implement an inferior option, we should just recommend them to use columns, and maybe point at the options available. —
bender235 (
talk)
14:59, 17 December 2010 (UTC)
{{Reflist|2}}
, and it has been used more often" does not count, because following that argument we should go all the way back to <references />
.{{Reflist|2}}
nor {{Reflist|colwidth=30em}}
is useful. But {{Reflist|colwidth=60em}}
might be. So this actually adds to my point that its the width of the columns that should be determined by the author(s), not the number. —
bender235 (
talk)
14:59, 17 December 2010 (UTC)Expand {{ reflist}} so that {{reflist|narrowcolumns}} and {{reflist|standardcolumns}} define column widths in words people can understand, with the advantage that we're not hardcoding a specific width meaning, as we are with eg "30em". That would be easier to understand, better for standardisation, and helpful for any future changes. I'd suggest that narrowcolumns be initially set at 20em (can be debated and/or changed later) and standardcolumns as 40em (ditto). With these new parameters in place, it then makes it easier to conceive of a MoS addition which states
For less than 20 references, columns are not recommended in reference lists. Above this, {{reflist|narrowcolumns}} may be used where narrow columns are required (particularly where Author (Year:Page) style references are predominantly or exclusively used in an article), otherwise {{reflist|standardcolumns}} is recommended. Use of columns is not, however, required, and alternative formatting of columns may be used where there is a local consensus that there is a specific reason to do so.
Rd232 talk 15:30, 15 December 2010 (UTC)
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)
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. / ƒETCH COMMS / 23:06, 15 December 2010 (UTC)
FWIW, if the only thing we can agree on is a MoS recommendation to use some kind of column formatting on "long" reference lists, that's still better than nothing (which AFAIK is the status quo). Rd232 talk 01:34, 16 December 2010 (UTC)
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)
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)
Okay, so after the discussion now seemingly has come to an end, I propose to add the following to WP:CITEFOOT:
For less than 20 references, columns are not recommended in reference lists. Above this,
{{reflist|20em}}
may be used where narrow columns are required (particularly where Author (Year:Page) style references are predominantly or exclusively used in an article), otherwise{{reflist|30em}}
is recommended. If the article contains particularly long references, consider using{{reflist|30em}}
alternatively. Use of columns is not, however, required, and alternative formatting of columns may be used where there is a local consensus that there is a specific reason to do so.
This is basically User:Rd232's proposal from above, except that those narrowcolumns and standardcolumns parameters do not yet exist. Obviously support from my side. — bender235 ( talk) 23:01, 19 December 2010 (UTC)
{{reflist|3}}
as a substitute for {{reflist|20em}}
(etc.) is correct. For example, on
this page, how many columns would you recommend? In fact, you could now say any number from 2 to 8, but either would be incorrect (or at least imperfect), because there are always screens for which the number of columns you determine are either too many or too few. On my 22 inch 1920 px screen, six columns look just right. But if I was having a 10 inch netbook, that would be way too much. On the other hand, two columns might look perfect on that netbook, but look just awkward on any larger screen.20em
), regardless of the size of the screen. The screen size only determines how many characters can be displayed in one line, and therefore how many columns fit on the screen.{{reflist|2}}
, that could also screw up the article, if the user's monitor is small and the refs are too long for just half of the screen. —
bender235 (
talk)
01:25, 20 December 2010 (UTC)
As I understand it, the point of this proposal is to allow editors to begin a mass change to add columns to articles that have more than 20 references, and to change the formatting from reflist|2 to reflist|20em or reflist|30em on articles that have reflist|2 right now. Is that right? — Carl ( CBM · talk) 00:41, 20 December 2010 (UTC)
{{reflist|2}}
only has its use on articles with less than 20 refs. Therefore, this proposal only applies to those articles with more than 20. This is not a proposal to replace {{reflist|2}}
, but merely to recommend not to use it on articles with more than 20 refs. —
bender235 (
talk)
01:36, 20 December 2010 (UTC){{
reflist|1}}
could then be used to override it in articles with few citations.
A. di M. (
talk)
02:14, 20 December 2010 (UTC)20em
and 30em
are only a suggestion, not a directive. —
bender235 (
talk)
12:24, 20 December 2010 (UTC)The number of references is not a good parameter for determining how many columns you want. The amount of text in each column is. If the references are actually of the kind "Smith (2006), p. 42" then 3-column footnotes look better to me, but with a single column for the book list. The point is that the number of references has no bearing on the columns size or number. Tijfo098 ( talk) 13:17, 20 December 2010 (UTC)
Also, I see some people are discussing above the scaling issue of columns with the scree size. That is an irrelevant topic because the main text of a Wikipedia article doesn't scale well with the window size. At default font size it becomes very difficult for me to read Wikipedia on 1920-wide windows/screens, and I have even wider ones available to me occasionally (2560px wide). Having umpteen columns for references is rather pointless if the main article has 200+ characters per line in Arial, because the average person cannot read that comfortably. Tijfo098 ( talk) 13:17, 20 December 2010 (UTC)
Remove the parameter that currently allows {{ reflist}} to produce multiple columns.
The column width parameter of {{ reflist}} and the functionality it provides is not an essential part of providing the reader with accurate, verifiable content. It is unnecessary. It harms the encyclopedia in the following ways:
For these reasons, I don't believe the "column" feature of {{ reflist}} is in the encyclopedia's best interest.
Caveat: if, however, the "column" feature is built into {{ reflist}}, or better yet, Cite itself, then none of my arguments apply. My arguments only apply to the existence of a user-controlled parameter. Not the columns themselves. ---- CharlesGillingham ( talk) 20:38, 20 December 2010 (UTC)
Sorry for starting a new section; I'm lost on where to put this.
I'm not an expert on all of the inner workings of Wikipedia, but I think the appearance and behaviour of reference lists in its current form warrants some discussion on how it can be improved. Perhaps there should be some further discussion on what exactly to propose here, because I see there being many possible solutions other than what you are proposing. If we could get consensus that, yes, we should try to improve how reference lists appear, we could then work on suggestions for how that could be achieved before coming up with a formal proposal. For example, I think the user agent should be taken into consideration (client-side script?). Medium, resolution, browser support, etc. should be considered, and there should be some upper limit on number of columns. Then this behaviour can be overridden with template parameters for exceptional cases. But that's just one idea, and maybe it could be built upon (or torn apart) ahead of proposing it and getting a bunch of !votes. Perhaps someone with more knowledge on WP procedural mumbo-jumbo could chime in and tell you how to start. I can say that I'm certainly interested in improving the look of reflists. :-) I hope that didn't seem condescending. You never know on the interwebs. Also, maybe I'm wrong in which case I invite someone to slap me with a fish. :-) Merry Christmas! CF84 ( talk) 21:48, 25 December 2010 (UTC)
Per this, would it be a good idea to mention the uploader/creator as part of the template in the relevant deletion discussions (AFD, TFD, RFD, etc)? Reh man 10:56, 22 December 2010 (UTC)
I often see lists of, for example, cast members of films and wonder if (for old movies) any are still surviving.
Perhaps a general policy of displaying birth and death dates (or to make them displayable if one mouses over them) or to simply display a name one way if the person is still alive and another if they are deceased would be useful?
Related might a surviving cast members feature for all movies which is different in that all cast members are typically not listed in a Wikipedia movie article.-- Jrm2007 ( talk) 03:53, 23 December 2010 (UTC)
Just to clarify: This is not about movies/actors -- it is about biographical names. I am suggesting that the way a name is displayed automatically encode whether the person is living or dead -- maybe by color or typeface or a symbol after the name. I am not suggesting that in each place a name is mentioned someone go in and add this information and of course maintain it.
I have simply noticed that whenever I see a person's name in an article, for example one that lists cast members of a movie, I wonder if the person is still alive. Maybe it's only me that does this, in which case, never mind.-- Jrm2007 ( talk) 19:02, 27 December 2010 (UTC)
I propose that edits that delete a significant amount of content and which do not have any edit summary -- such as this one -- are automatically reverted. 86.184.232.12 ( talk) 14:48, 27 December 2010 (UTC).
MediaWiki interface pages for the
Cite footnote system have been heavily customized on the English Wikipedia. Currently, if the language set in your preferences is en-GB (British English) or any other than en, then most interface pages are set to the default. This means that the citation in a reference shows a ↑ instead of the en custom ^ and a number of other changes. This also means that the error messages do not have a link to a help page as do the custom messages.
I propose to update en-GB interface pages to the en interface pages so those who set en-GB have the same viewing and editing experience.
One question for those who may know: is it possible to simply create a redirect so that en-GB does not need to be updated when the en interface page is changed?
---— Gadget850 (Ed) talk 04:57, 28 December 2010 (UTC)
(split from above discussion for cohesion)
en
has not been updated with en.gb
and many other languages, not just on this wiki, but most other wikis too. For example, if you login xx.wiki
in en
, the interface shows in English, but if in en.gb
, it mostly doesn't have that language saved, even though the en.gb
interface is nearly 100% same as en
interface. Since wiki content (articles) has policies on which English variant to use, and since selecting the lang variant doesn't really change the content, sometimes I wonder if it would actually be better to delete all specific English variants (en.us
, en.gb
, or maybe even one day for India as en.in
, etc) and use only one English interface... It really wouldn't be that bad...
Reh
man
05:11, 28 December 2010 (UTC)Hello. I'm here to post a link to a discussion over at Requested Moves. Those of us discussing there have, I believe, said everything we've got to say, and we haven't reached consensus (i.e., I'm not convinced). I'd love to see more input from a wider cross-section of Wikipedians. Thanks in advance for any comments. - GTBacchus( talk) 20:53, 28 December 2010 (UTC)
Proposal: install Extension:MagicNoCache (or implement equivalent functionality another way), and then use NOCACHE on sensitive pages. We already have {{ NOINDEX}}, this seems a sensible complement. On a related note, this remains visible in Google some time after requesting noindexing... perhaps NOINDEX should be added to some of the related templates so it's always kept out of search engines. Rd232 talk 13:01, 28 December 2010 (UTC)
Hi people, First of all, pardon me, i know i might be repeating this proposal but I tried to search the archives, ~200 results, saw 40 - 50 of them :).
Demo (The controls are in sidebar)
So the point is: It is a common practice to highlight stuff when we read. It increases productivity and is very helpful for future references. I myself felt great need of it whenever I referenced wikipedia. So to help it out, I have made this extension (click here), which I believe will be helpful to a lot of wikipedia users. Also it give the solution to this problem. Please post your views, and if you think this functionality is worth providing on wikipedia, then support this proposal.
-- Apeksharma ( talk) 20:43, 29 December 2010 (UTC)
You know, this is kind of a major reconceptualization of the wikipedia status quo (and may be a case of closing the barn door after the horse is gone), but it occurred to me today that the encyclopedia would be a lot more encyclopedic (and there would be a lot less hassle for everyone on project) if article creation was restricted to sysops, and we had an AfC (Article for Creation) process in which people could propose new article ideas. In most cases it would be a rubber-stamp process - someone proposes an article, it sits for a couple of weeks and no one objects, then in it goes - but it would give the opportunity to stop a lot of irritating issues before they reached mainspace. It would let us discuss (and possibly squelch) POV-forks, BLP problems, article naming issues, joke articles, and notability problems, decide whether the article should be developed in userspace or the article incubator first, make meta-structuring (balancing different articles within a topic area) far easier, and obviate a lot of frustrating AfD debates with people trying to defend inappropriate content that they've put into the project. what do you all think? -- Ludwigs2 23:49, 21 December 2010 (UTC)
I would agree with Fences and windows & Nyttend. Also, I would emphasise the problem of workload. At the moment, NPP fulfils a similar niche in the wikipedia "ecology"; some third party is expected to review all¹ recently-created articles, and either weed out any deeply problematic ones, or perhaps make a start on fixing any that are fixable. However,
Special:NewPages already has a huge backlog despite the number of potential patrollers being far larger than the number of admins. What would happen if that job was handed over to a much smaller set of people who are already busy with other work? Would we need some kind of screening process before a draft article even gets passed to an admin for approval?
¹Apart from those created by people with an adequate track-record of article creation who are likely to go on to create a large number of compliant articles. I can only assume that a similar exemption would apply to this proposal. If not, the workload would be even higher.
bobrayner (
talk)
02:25, 28 December 2010 (UTC)
A while ago I moved
Wikipedia:List of hoaxes on Wikipedia into mainspaceproject space, to help people like scholars who are interested in studying the history of hoaxes on Wikipedia. This was inspired by
this quote from Jimbo Wales:
However, its utility as an educational resource is limited because the original hoax articles remain unavailable. I'm proposing restoring them and moving them to subpages of Wikipedia:List of hoaxes on Wikipedia, and clearly labelling them with templates marking them as hoaxes. I realise that this flies in the face of Wikipedia:Deny recognition, but if we never learn about our past we have little hope of improving the situation in the future. Dcoetzee 08:14, 29 December 2010 (UTC)
Take Wikipedia and turn it into videopedia, using teachers or instructors to turn Wikipedia subjects into lessons taught on a chalkboard, with visual aids to help get the message across using visual aids and audio explanations.
And/or create wikiuniversity and you could even give creaters the option to create multiple choice quizs of different levels of learning, easy, medium, hard after they watch the video. Users could log in and would be able to keep score of the tests they have taken. — Preceding unsigned comment added by 209.105.142.191 ( talk • contribs) 19:31, 1 January 2011
Hi. This is to bring greater discussion to the topic of creating specific ENSO season articles. Thanks. ~ A H 1( T C U) 19:52, 2 January 2011 (UTC)
I started a discussion at MediaWiki talk:Watchlist-details/Archive 4#Change the link of "your watchlist"? about changing the page that the "Your watchlist" links to. I was asked to bring the discussion to a more visible location, so I brought it here. Comments? — Train2104 ( talk • contribs • count) 21:49, 2 January 2011 (UTC)
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? Reh man 01:44, 2 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?? Reh man 10:59, 6 December 2010 (UTC)
My two cents: WP:Proposed mergers is a good platform to list proposed mergers in one place, but it has at least four problems: 1. I do not believe it is popular enough (compared to WP:RM, WP:AfD, etc.); 2. There is no requirement for users to list merger proposals they are making at WP:Proposed mergers; 3. Along with that, there are likely people who are proposing mergers who do not even know about WP:Proposed mergers; 4. There is no set time limit (that I know of) for a merge proposal to be open. Merge proposals can sit around for months on a talk page without much activity at all (especially on lower-traffic pages, where there are not that many users checking out the talk page and participating in the merge proposal. This relates to problem no. 1, where even if a proposal is listed at WP:PM, proposals can still sit inactive for long periods). Merge proposals can be just as important as deletion proposals and move proposals. Merge proposals could go through a lot better if more people were participating. [| Retro00064| ☎talk| ✍contribs|] 00:11, 17 December 2010 (UTC)
1. think subject of Active Arbitration Remedies such as
ARBPIA --
Israeli–Palestinian conflict, etc.
2. for example, four-way proposals on complex subjects like medicine or conceptual theories, requiring secondary research to even evaluate.
Reviewing prior discussions would be very helpful here, I think. Unfortunately, they're spread around. This means they're harder to find, but a search of AfD-related pages led to several. There have been standalone proposals & well-advertised threads at AfD and elsewhere. It appears this has failed to gain consensus many times in the past.
Here's a few comments drawn from some of the debates:
Merge is seen as " Somebody Else's Problem". The admin doesn't care enough; they're just closing it. The nominator wanted it gone, so they don't want to do work to retain the material. The keepers resent the merge decision, so ignore it. I've closed some AfDs as merge, and sometimes I do it myself and other times I poke a WikiProject or !voter to see if they can follow through. Mergers are a very neglected part of the project.
The problem boils down to this: Saying “Yes, merge.” is easy.
S/Merging as opposed opposed to pseudo‑merging – aka blank+redirect is time consuming and more difficult. The admins, if they close a merge discussion,
don't want to perform the merge. Neither do the discussion participants very often, particularly if they disagreed or aren't active on either article. So it comes down to lots of mice saying putting a bell on the cat so it can be heard coming is a great idea; only the room falls silent when somebody asks, “Who will bell the cat?” –
Whitehorse1
21:24, 16 December 2010 (UTC)
This got me thinking about ways to improve this. I started wondering if the Article Alerts system included new merge notifications; found they didn't. I was unsure if it was still active, though figured maybe it could be revived or another bot could handle some things. It's been inactive some time.
The great news is a volunteer offered to create and be in charge of a replacement bot, and it started a trial last week. Snaps to User:H3llkn0wz for stepping up.
I had a great idea: suggest adding new merges to the notifications. I promptly learnt somebody else already had that idea. Incidentally, it turns out the wikiproject/workgroup-specific Cleanup listings include merge counts, but as that tables all cleanup statistics and is intermittent it impacts this less. WikiProjects that aren't moribund have begun receiving alerts. At present requests for new Alert features suggested previously don't need to be resubmitted. I think this could really help. Let's hope the trial goes well and the bot's parents can start to look at additions soon. – Whitehorse1 05:39, 20 December 2010 (UTC)
To sum it up. My original proposal is to modify the popular WP:Requested moves pages to hold Mergers as well. This would immensely increase the participation in mergers, as compared to Moves. And since Splits are just mergers in the opposite direction, it has also been proposed that Splits and Merges be identified as one, with equal significance and attention. Thus, with a title like "Requested moves, mergers, and splits", or for short, "Articles for discussion", with only the deletion chapter on a separate venue at WP:Articles for deletion.
Currently, we have the following venues relating to mergers (with no main discussion area for Splits):
At present, Mergers (and Splits, for that matter) seems to be of least attention, compared to Moves, Deletions, and Merges&Splits.
Key modifications to merge Moves with Mergers&Splits would be:
Since this proposal imposes time limits to merge/split discussions (like WP:Articles for deletion), so that it wont drift on forever, the issue of "Who will perform the merge/split if consensus is reached to do so?" arises. So far, the closest to a solution is that:
But of course, a volunteer could always perform this merge/split. And since we have unified all chapters to one page, the chances of a volunteer stepping up is more. Future merge/splits proposals in the same topic could also be speedy closed.
Any further issues? Reh man 06:14, 31 December 2010 (UTC)
This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.
< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212
Since this wiki is relevant only to the English Wikipedia project, I have decided to place the proposal here instead of meta, where they would normally decide whether to close down Wikimedia wikis. This is not a real encyclopedia even though it is registered under the .wikipedia.org domain name. It is an entire wiki dedicated to a single issue on the English Wikipedia. I do not believe that we should have wikis opened for every incident on any Wikimedia wikis; we would not have to open some new domain called http://wg.ur.wikipedia.org for example. And anyway, according to this wikiproject and its associated report from 2008 this wiki should have been closed as the disputes for the wikiproject have been resolved. :| TelCo NaSp Ve :| 05:29, 22 November 2010 (UTC)
Hi, the template {{ Infobox musician awards}} is extremely long and very difficult to navigate as it constricts all the tables present beside it. Hence I was proposing to have the awards portion of the template as collapsible, so that it would not constrict the tables. Also it looks more professional. An example of such a manually coded collapsible template can be found at List of accolades received by Precious. I am not very good with coding in HTML hence don't know how to change the template to reflect the collapsible thing. The linked article uses this code.
{{!}} colspan=3 {{!}}<br> {{{!}} class="collapsible collapsed" width=100%<br> ! colspan=3 style="background-color: #D9E8FF; text-align: center;" {{!}} Awards and nominations<br> {{!}}-<br> What say everyone? — Legolas (talk2me) 09:56, 22 November 2010 (UTC)
Simple suggestion: link alternate accounts ( WP:SOCK#LEGIT) from a user's Contributions page. This would require a simple software change (unless somebody has a clever way to do it without that), with an additional entry in Preferences for alternate accounts, and then a link to the other account(s) being given at the top of the page. We already have templates for the user page, but this would be clearer and harder to miss, and more convenient. Rd232 talk 13:36, 25 November 2010 (UTC)
Right spot for this? Is there a way we can make auto-confirmed or some other criteria of user, to allow said user to link to black listed links? It is a ridiculous when I can't show a link in a GAC to a website, because other users, use it for spam. CTJF83 chat 02:32, 23 November 2010 (UTC)
Problem: We have a system of editnotices which is currently basically only maintainable by admins. We can expand this in a way that remains safe (the core problem is that editnotice vandalism would be particularly hard to detect and fix for most editors.) Proposal: create a bot which maintains editnotices on the basis of templates added to the article talk page. Category:Editnotice templates would be expanded, and a standard editnotice template added by the bot into the editnotice if it finds an appropriate template request on the talk page. For example, if it finds {{ British English}} on the talk page it adds {{ British-English-editnotice}} to the page's editnotice. It would operate from a fully protected list of templates, translating the talkpage request templates into editnotice templates (which would themselves be fully protected).
As a slight variation, it would also be possible to do the same thing based on categories within the article, rather than templates on the talk page; this would work in exactly the same way, with a protected list of categories to be translated to editnotices. I'm not quite sure if this is better, it's perhaps marginally more intuitive(?) and perhaps likely to be implemented more widely (perhaps over-used?), but the template method would ensure a note on the talk page as well if appropriate, which may be useful.
Why? Because it'll make it much easier to use editnotices much more widely, eg to advertise Arbcom restrictions at the edit stage exactly where it's needed, to pick one example. In terms of possible overuse, because it's controlled by a bot and a central list, it should be relatively manageable to keep track of and ensure it's only used where necessary (eg, the bot could only apply the editnotice template if the request applies to a page within a certain category). Comments? Rd232 talk 02:15, 26 November 2010 (UTC)
I think that an additional special page to complement Special:PrefixIndex would greatly help users in searching for certain pages with certain suffixes; see this discussion for more information. (Sorry if there was a discussion before about it that I did not see; if anybody finds one, please link it here so that I know better the next time. Thanks.) :| TelCo NaSp Ve :| 01:45, 21 November 2010 (UTC)
Proposal: every January, for the whole month, organise a prominent Wikipedia:WikiProject Countering systemic bias Improvement Drive. By "prominent", I mean prominent, with a watchlist notice, WP:SIGNPOST coverage, and coordinated outreach to non-English Wikipedias. A key part of the Drive would be a landing page where editors can find out more about the issues, and investigate what aspect of CSB improvement they might be interested in. I imagine that a part of this might be a sort of Wizard or Guide, as a way for example to suggest to people interested in Baseball what aspects of Baseball are systemically neglected, i.e. with a listing of underserved baseball topics outside the US. Besides which, it would be part of the Drive itself, especially in the first year, to construct such a Wizard/Guide; I'd expect individual WikiProjects to play a particular role here in kicking things off. Basically, the core points of the proposal are (i) try to harness people's existing interests in a way they might like but haven't thought of; (ii) improve understanding of the nature of the CSB coverage issues (iii) generally raise the profile of CSB issues. Rd232 talk 11:42, 24 November 2010 (UTC)
I'd like to propose that we link Wikipedia:New contributors' help page a lot more from places that might rather increase the number of newcomers finding somewhere helpful and friendly to go. I'm looking at MediaWiki:Anoneditwarning, perhaps also MediaWiki:Semiprotectedpagewarning and MediaWiki:Protectedpagewarning. I'd also like it to be linked from an editnotice seen by new accounts who are not yet auto-confirmed, but I'm not sure there's any way of targeting them. The proposal is associated with my proposed redesign of that page ( Wikipedia_talk:New_contributors'_help_page#Redesign), which will make it a friendlier landing page and better able to cope with an increase in traffic. Pre-emptive counter to one inevitable objection: if it generates too much traffic and overwhelms the page and we can't figure out a way to handle it, we can get rid of the links again. I feel the more we have issues with declining editorship, and the larger and more complex Wikipedia gets, the more effort we need to put into easing newcomers into becoming Wikipedians, rather than remaining readers or just dipping a toe in and finding it too hard. Linking this help page more prominently would help a little, but I'd love to hear any other ideas. Rd232 talk 22:15, 24 November 2010 (UTC)
Hello you all the English speaking wikipedians in the world. Please excuse my approximative English, I'm a froggy. Some months ago, I asked a question on the Reference Desk (languages) about the gender of non humans things in English. I was thinking particularly about ships and boats etc.. I got many interesting answers such : a ship is "she", a boat is "it" with the joke "How to recognise one from the other? Answer: You can put a boat on board a ship".
I learnt that most means of transportation are "she" except trains (without knowing why, he said). But what about motobikes? About bicycles?
Please notice that it would help EVERYBODY whishing to improve his/her English and that even my wife, an English teacher (fairly good at English) doesn't know everything about that. Her grammar books, for example are not comprehensive on this subject.
For example this page: http://en.wikipedia.org/wiki/Gender_in_English#Modern_English doesn't speak about trains, bicycles, mountain-bikes, etc...
One of the answers, consideriging that these kinds of questions are frequent on that Desk proposed that it would be a good thing to write an article on that subject.
All that introduction to ask you if you could creat an article on this subject or, more simple, enhance the one I quote above.
Thank you very much for everything you do. Jojodesbatignoles-Rheims-France--- 90.18.67.249 ( talk) 13:33, 27 November 2010 (UTC)
For example:
War is now/current continue. is available in a Wikipedia text
Please not use the now and current words. you must warning the all members on this issue. Now and current words is remove.
Becuase;
For example:
War is now/current continue text with now or current word is write at 1 September 2009 I am see the this text at 1 June 2010.
maybe the war ended on 1 June 2010. I am think war is still continue.
Please warning the robot and members which correcting errors. They/We are remove this words. They/We are change with a more appropriate sentence and the words
88.235.131.60 ( talk) 14:45, 27 November 2010 (UTC)
Hey Guys, its been a while
Would it be appropriate yet to write an article on the new internet meme revolving around Wikipedia founder Jimmy Wales? Several notable media sources have covered the rise of this meme and I am not sure if it fufills general notability guidelines for inclusion. Thanks. Marlith (Talk) 17:57, 27 November 2010 (UTC)
Here's an idea: There should be a mode select for articles with cussing, sex references, gore, e.t.c., that censores and uncensores all these things. 82.13.79.52 ( talk) 07:57, 24 November 2010 (UTC)
82.13.79.52 ( talk) 08:47, 1 December 2010 (UTC)
Currently, DeleteRevision merely marks the contents of deleted revisions as unavailable, and admins may noticed such that revisions do not show up under Special:Undelete. In order to delete a revision the "normal" way, an admin still has to delete the entire page and then restore the revisions that they want to keep. It would be nice if DeleteRevision had an actual "delete" function. -- Ixfd64 ( talk) 23:05, 28 November 2010 (UTC)
Please check out this page, look in the bottom left of the screen, and scroll down to see my proposal in full effect. I made this myself and I think a modified version of it would be a usefull, cool and maybe even necassary tool, especially for those with slow scrolling like me. It would help with long articles if you randomly or purposely decide to search another article. A Word Of Advice From A Beast: Don't Be Silly, Wrap Your Willy! 03:37, 28 November 2010 (UTC)
It seems like {{
reflist}} is used on most new articles. Historically, when the template was developed we left <references/> on the articles that already had it. Should we have a bot go through and convert the remaining uses of <references/> to use the reflist template instead? The advantage would be uniform styling, since the template gives a slightly different appearance (a smaller font) than the <references/> tag does. The disadvantage would be that we would be changing the established style on the pages that use <references/>. — Carl (
CBM ·
talk)
20:28, 29 November 2010 (UTC)
{{
reflist|text-size=regular}}
, or similar.
Headbomb {
talk /
contribs /
physics /
books}
23:09, 29 November 2010 (UTC)
<references />
with {{
Reflist}}
because of the additional features Reflist provides, such as "colwidth". Personally, I do not want to see <references />
banned from Wikipedia, but general recommendation to use Reflist would be nice. —
bender235 (
talk)
23:19, 29 November 2010 (UTC)
I support a general establishment of preference for {{ Reflist}} over <references/>, with or without bot conversion. — chaos5023 ( talk) 23:20, 29 November 2010 (UTC)
Comment on AWB: AWB doesn't change {{ Reflist}} over <references/> unless the editor who introduced it requested small font size. -- Magioladitis ( talk) 23:23, 29 November 2010 (UTC)
I usually use <references/> when the references are really few (maximum 3 or 4) and reflist for 5 or more references. For over 30 or something I use refelist with 2 columns. -- Magioladitis ( talk) 23:24, 29 November 2010 (UTC)
|refs=
argument to {{
Reflist}}, so never use <references/>. —
chaos5023 (
talk)
23:27, 29 November 2010 (UTC)The Wikipedia window is alreay cluttered with so much stuff that smaller and smaller font sizes are resorted to inorder to present enough content on one screen to make comprehension easy. I oppose any use of fonts smaller than the size used for running text on the grounds it is too hard to read. Jc3s5h ( talk) 00:31, 30 November 2010 (UTC)
|colwidth=
and |refs=
. I think we could've left bot enforcement out of it, in any event, but that's fine. Askance gaze withdrawn. —
chaos5023 (
talk)
02:44, 30 November 2010 (UTC)
refs=
. You just have to remember that <references/>
does not have to be written as a an empty entity. You can write <references><ref …><ref …><ref …></references>
Again, I am urging you not to be distracted from the original topic. What brought
User:CBM here was this
WP:ANI. It's about whether Wikipedia users should be allowed to replaced <references />
with {{Reflist}}
(or vice versa) as part of the standard
fixing minor errors process. I said yes, CBM opposed. —
bender235 (
talk)
12:04, 30 November 2010 (UTC)
Let's be absolutely clear: it is now being proposed to change Mediawiki:Common.css so that <references /> has the same styling as {{ Reflist}}. This ensures standardisation. If this is done, it doesn't matter formatting-wise which of <references /> and {{ Reflist}} is used, unless a page needs the advanced options of {{ Reflist}}. All in favour say aye. Rd232 talk 13:23, 30 November 2010 (UTC)
{{Reflist}}
offers more features, why not have a guideline that says "the use of {{Reflist}}
is recommended"? Or at least one that says "in case there are 10+ refs, multiple columns (e.g. {{Reflist|
colwidth=30em}}
) are recommended"? Because the columns are the major advantage of {{Reflist}}
compared to <references />
, not the smaller font size. —
bender235 (
talk)
14:00, 1 December 2010 (UTC)
{{Reflist}}
over <references />
, and that is the columns feature. —
bender235 (
talk)
00:11, 3 December 2010 (UTC)
Some seem to prefer custom visual styles, see Talk:Julian Assange#Scroll-box visual style. Is there some guideline for this? Another issue is the mixing of WP:LDR-type citations with those in the article body—there's no visual difference here for the reader, but there is (an organizational) one for editors. Tijfo098 ( talk) 10:23, 3 December 2010 (UTC)
I propose a bot that monitors the RC feed and updates a page at a timely interval (I suggest hourly) with various statistics.
Some statistics I suggest are:
{{
Vandalism information}}
and many more such as moving averages, daily averages etc.
I believe that this will give us a wealth of information, which we can use as an example to make graphs showing server load time by hour over the week.
Is the community interested in such a bot, and what further improvements and statistics do you suggest? 930913 ( Congratulate/ Complaints) 09:53, 1 December 2010 (UTC)
Let us be clear - how can we have some feedback on which proposals, say, over the past twelve months, have been succesful?It would be nice to think that this feature of Wikipedia serves a useful function. ACEOREVIVED ( talk) 19:28, 2 December 2010 (UTC)
Would you like a feature where you could update your status (Online
, Offline
, or even Custom
) so that other editor may see? And how about doing that without clogging your
contributions?
For general comments, you may respond here. For comments that would directly effect the feature's deployment, please join the discussion, or participate directly at Bugzilla:26246. Thanks! Reh man 00:54, 4 December 2010 (UTC)
Sparked by the discussion above and suggested by EVula, as well as by past discussions relating to element- and page design, where there is always the few that object change because "the font is too small!", I propose a gadget that provides a one-click solution to those that loathe small fonts. It basically resets the fontsize of those elements, such as navboxes, infoboxes and reference lists to 100%. The list can be extended as I am bound to have forgotten a few. This should help readability for those that have problems with small fonts.
The code is here: MediaWiki:Gadget-NoSmallFonts / MediaWiki:Gadget-NoSmallFonts.css. Those wanting to testdrive it can simply copy the CSS code to their vector.css file. — Edokter • Talk • 02:16, 1 December 2010 (UTC)
There is also an opposite problem. Many try to create small caps with the code small, but this does not work. E.g. for chemical names.-- Wickey-nl ( talk) 17:35, 3 December 2010 (UTC)
Small caps are part of a chemistry nomenclature (see Chirality_(chemistry)#By_configuration:_D-_and_L-; especially see the try of an editor in the heading). It is hardly applied in WP yet, because hardly anyone knows the Smallcaps template. Is a smallcaps editbutton possible?-- Wickey-nl ( talk) 10:45, 4 December 2010 (UTC)
There is a great new tool from toolserver.org that allows seeing a DETAILED graphical and statistical view of a page's history statistics. It's one of those tools that just has to among the External Tools in the history page. Someone add the tool to the section or contact the technical team that has the ability to it.
Here you can see page history statistics for Wikipedia:Village_pump_(proposals): http://toolserver.org/~soxred93/articleinfo/index.php?article=Wikipedia%3AVillage_pump_%28proposals%29&lang=en&wiki=wikipedia&begin=&end=
I am proposing there be a template for A-class articles like Template:Good article and Template:Featured article. I don't see why there isn't one, since A-class articles have surpassed GA and deserve such uhh I can't think of a word for here. Respect? Okay. So I was thinking a page like this. Crowz RSA 19:59, 5 December 2010 (UTC)
So I've noticed that when editors add or remove templates, they generally use the template code in the edit summary instead of saying "Template:Whatever". Often when I have gone on tagging sprees (populating a stub category or for a WikiProject) I will simply paste the template code into the article and then paste into the summary. Almost every editor will know that "{{Disney-videogame-stub}}" as an edit summary means that article was tagged with that template. For some reason I always assumed that this created a wikilink in the summary, as is possible with normal links, but I just realized this is not the case.
So, to be specific, I am proposing that template links in an edit summary be treated as a wikilink to that template. So "{{Disney-videogame-stub}}" would display as "{{ Disney-videogame-stub}}". There is obviously no giant benefit to be gained, it would just make reading histories and watchlists more informative. It should be a minor software change, I just wanted to see if it would have community support. Thanks! ▫ JohnnyMrNinja 07:24, 7 December 2010 (UTC)
Please see WT:MOS#Quotation mark glyph straw poll. A. di M. ( talk) 11:59, 7 December 2010 (UTC) Fixed link. -- Stephan Schulz ( talk) 12:16, 7 December 2010 (UTC)
The following is a suggestion for a new Wikipedia feature - specifically, a volatility index for each article, built into (or near) the header of each article:
As we’re all aware, the popular complaint/stigma surrounding Wikipedia has been its correctness/reliability. This stigma comes because in general, the older generation (anyone who grew up before Web 2.0) distrusts (because it fails to understand) the speed and effectiveness of self-policing in online communities, especially large ones, like that of Wikipedia’s readers and contributors. My hope for the feature I’m suggesting here is to present a mechanism for assuaging the fears of the older generation (unfounded as they may be) by harnessing the Wikipedia article’s living nature.
The approach I’m suggesting to this reliability/correctness issue requires that we first accept that we can never be 100% sure of the correctness of any article at any single moment (Wikipedia or otherwise), but with Wikipedia, what we can do is get a really good idea as to the risk involved in trusting a specific article at a specific moment, thus drastically reducing overall public anxiety about using Wikipedia in general.
The approach is this: Simply display, at, say, the top right of each Wikipedia article, a small graph of the number of changes (edits) to the article per hour (or minute or day) over a span of several days, or months or years – the user should be able to click whichever of these time frames interests him, just as an investor may want to see a 1-hour, 1-day, 1-week or 10-year graph of the price of a stock that interests him.
Here’s an example of how it might work: Imagine that a skeptical user wants to educate himself on a new subject, so he searches Wikipedia and finds an appropriate article. Imagine next that the subject our user is researching has become popular recently and so the article is currently high in both “read-only” and “edit” traffic. The user arrives on the article/webpage, and in the top right of the screen there’s a small graph showing the number of changes that have been made to this very article over the past month (or week or day or hour), i.e. x-axis is time, in days (or hours or minutes) and the y-axis is number of changes. The user sees he has the option to zoom the graph in or out (to a timeline of a few hours or a few years), much like he would, as mentioned above, with stock price info on his broker’s website.
With this graph, which is kept up to date in real time by Wikipedia (or perhaps by http://stats.grok.se/), the user sees at one glance both the current and historic volatility of the article he’s viewing, just as a stock trader sees the market’s volatility using an index such as the VIX ( http://en.wikipedia.org/wiki/VIX). High volatility for a Wikipedia article (a current spike or plateau in changes per unit time) tells a reader that the article (to continue the stock market parallel) is currently volatile, or unstable, and that using the info that appears in the article (for, say, a school paper) at this moment carries more risk (of inaccuracy, in Wikipedia’s case). The high risk (high changes per hour) could be because the subject of the article is a developing situation, or because it’s controversial and opposing viewpoints are in the midst of an edit war. Point is, now the reader has a way to know at a glance that something is going on that makes the current content of the article likely to change rapidly. The user can then make a choice, such as deciding to check back later, i.e. to not use the article’s info until the changes per hour have settled to a level that represents higher agreement among all potential editors who have been monitoring the article (less risk of inaccuracy).
If one wanted to take this idea a step further, moving averages could be shown, and even manipulated by users (e.g. 30-day or 180-day), and teachers could advise students, for example, not to use an article unless its current changes per hour were at or below some moving average of their choosing, say 30 days for example. The actual numbers used could be adjusted by the user (or his teacher) depending on desired risk levels.
Yet another step further would be to determine better ways to illustrate reliability of an article – i.e. instead of edits per hour, or changes in edits per hour, maybe a formula like ((edits / views) / hour) would prove more reliable – I’ll leave that to interested statisticians and econometricians.
In summary, everyone knows the risks at Wikipedia. It would be a mistake to treat them as a PR issue. Quantifying the risks and giving the public a way to work with them easily should increase the general public’s confidence in Wikipedia.
-- Aldobiella ( talk) 02:10, 8 December 2010 (UTC)
While it may not be a good idea to add a volatility indicator at the top of articles, it is useful to have such tools available to editors and those who want to see them to for their judgment on the reliability of an article.
That's why I propose that a third tab besides the Article and Discussion should be added, which can be named Statistics, Article Statistics, Volatility or a similar term, which will allow the viewing of editing statistics of an article.
A tool is available which can help in creating such a statistics viewer:
Through the Article History Statistics tool, you can see the history statistics of the article "Wikipedia" on the English Wikipedia: http://toolserver.org/~soxred93/articleinfo/index.php?article=Wikipedia
A statistics page for a third tab, aimed to help the public judge the reliability of articles and information on Wikipedia seems like a natural step toward enhancing the usability, reliability, and the transparency of Wikipedia. It will allow it to serve its mission of providing reliable information in a free encyclopedia of user-generated content. And it seems the rudiments for its creation are already in place. And as a third tab, it is not likely to provide a distraction in casual reading of articles any more than dose the Discussion tab. I think it will be a worthwhile and fruitful step to take.
The Article History Statistics tool should also be added to the external tools on the article revisions page, this more geared toward editors, as opposed to the tab, which will help better inform readers and the public about article reliability and their exercise of caution. λόγος Idea → ✉ 19:10, 9 December 2010 (UTC)
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)
#siteSub { display:none; }
in your
skin.css if it bothers you that much.
Anomie
⚔
18:40, 30 November 2010 (UTC)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)
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)
Since Wikipedia is a proper noun and not a noun, surely we can be reasonably liberal in thinking about what to call it. After all, as early as 1997, there was
Nupedia I am sure that was not about Nus. In fact, some of the information in Wikipedia is about wikis - we have an article on
wiki, for example.
ACEOREVIVED (
talk)
How about for a limited period, we put, on the main page under "Welcome to Wikipedia...", a prominent disclaimer that Wikipedia is not connected with Wikileaks. The confusion about this seems widespread. 86.184.239.37 ( talk) 20:55, 7 December 2010 (UTC)
Please oh no. We're now just feeding WikiLeaks. / ƒETCH COMMS / 02:34, 11 December 2010 (UTC)
A recent article in Nature (08 December 2010) states : Scientists who receive public or charitable funding should therefore seize the opportunity to make sure that Wikipedia articles are understandable, scientifically accurate, well sourced and up-to-date. Many in the scientific community will admit to using Wikipedia occasionally, yet few have contributed content. For society's sake, scientists must overcome their reluctance to embrace this resource. Nature : Time to underpin Wikipedia wisdom. Interesting. JoJan ( talk) 14:39, 10 December 2010 (UTC)
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)
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 Dask 07:35, 6 December 2010 (UTC)
It's time to stir the pot again and get some fresh eyes on the issue of using OpenID on Wikipedia. See WP:OpenID Proposal. I don't see any technical details holding us back from at least being able to attach an external OpenID account to your Wikipedia account, and subsequently being able to log in via your OpenID provider of choice. It would be opt-in, so wouldn't hurt those that don't understand how OpenID works.
Can we reach a consensus here, and then perhaps put pressure on the techies at Bugzilla to get it done? Bug 9604 is already filed for the purpose of "Support[ing] OpenID extension on all wikimedia projects", and the featured proposal Strategy:Proposal:Support_OpenID has the same idea. Let's lead the way at en.wikipedia. ...comments? ~ B F izz 23:44, 11 December 2010 (UTC)
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:
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)
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:
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)
I think there could be many benefits, and relatively few disadvantages in allowing registered users to add edit notices to the top of WikiProject pages. Can they be enabled for pages that begin with Wikipedia:WikiProject ? - ʄɭoʏɗiaɲ τ ¢ 21:07, 14 December 2010 (UTC)
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)
{{
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. --
N
Y
Kevin @771, i.e.
17:29, 3 December 2010 (UTC)I'm not sure if this is the best place to put this: it may be better as an RFC but I'll start here and see where it goes.
I'm a developer on the open source codebase behind Open Plaques, a public domain database of commemorative plaques that are attached to buildings in the UK (and increasingly elsewhere). Each person in the Open Plaques database tends to have a link to Wikipedia (en) and reuses the lede from Wikipedia. We are also using RDFa to link through to DBpedia.
At the London Wikimedia meetup yesterday, I discussed with Fæ how it might be possible to link together Open Plaques and Wikipedia more. One way I am looking into is how Open Plaques can reuse images from Commons: we use Creative Commons licensed images on Flickr, but we could also start using images from Commons, and we may also want to start allowing people to upload images straight to the site, in which case, we might look into storing those images on Commons rather than either having to host them ourselves or, say, get a Flickr account.
The other way we can integrate is through links. We are already linking to Wikipedia. And Thomas Turner (diarist) and Hawkhurst (and possibly others) link to Open Plaques. I'd like to suggest that the Open Plaques community may be able to contribute to Wikipedia by creating a bot: basically, this bot would add an Open Plaques link to Wikipedia articles every time a new person gets added to our database. This could be removed if it was felt inappropriate by the community of people who edit the article in question. We could have a template which would link by id specifically, which could be updated easily if our database changes.
I don't know if this is appropriate or how we go about seeking consensus from Wikipedians and Wikimedia in general, so I'd love to hear advice on whether this kind of thing is practical and desirable. Thanks in advance. — Tom Morris ( talk) 20:23, 13 December 2010 (UTC)
There is also the problem of copyright on the texts of the plaques. Commons for instance is seriously considering dumping more images of plaques because of questionable copyright status. Something to keep in mind. — TheDJ ( talk • contribs) 15:46, 18 December 2010 (UTC)
I think it would be a major improvement for mediawiki software to implement an upgrade to make tables to be more interactive. When I say that I am thinking about the ability to show/hide some rows and columns, defined in some kind of profile. Take for example this list: List of countries by population. For example an interactive table would be capable to show the countries of a single continent, and hide those from other continents, when the user needs that. Also would help the user see the first 5 countries from each continent for example. When you have a conversation with someone, you might want to show just some of the data in the table, therefore you would like to be able to hide the columns 4,5 and 6, because they are not relevant in your discussion. Profiling tables would mean adding some filters (simple or sophisticated), or simply to manually define each profile. However implemented in the software, I don't think it would ask for extensive work from the programmers, also it won't load the browser with too much JavaScript, but it would be for sure a MASSIVE improvement for the way data can be presented and make use of. Thanks. — Ark25 ( talk) 03:17, 16 December 2010 (UTC)
It has been proposed to change Mediawiki:Common.css so that <references /> has the same styling as {{ Reflist}}. This ensures standardisation. If this is done, it doesn't matter formatting-wise which of <references /> and {{ Reflist}} is used, unless a page needs the advanced options of {{ Reflist}}. A discussion on this was open for 2 weeks and had a strong consensus, and was then automatically archived for lack of activity: see Wikipedia:Village_pump_(proposals)/Archive_67#Change_to_template:reflist_fontsize_wiki-wide.3F. What does the styling change entail? Making references sections consistently displayed at 90% font size. It should be noted that we now have a new Gadget "Disable smaller font sizes of elements such as Infoboxes, Navboxes and References lists." (see MediaWiki:Gadget-NoSmallFonts.css). Rd232 talk 12:34, 13 December 2010 (UTC)
<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)ol.references { font-size: 100% !important }
Examples
| |||
---|---|---|---|
|
{{Reflist|colwidth=25em}}
or similar. But articles with one or two refs don't need shrunken references, and the standard font size on Wikipedia is, AIUI, already less than 100% of users' default font size. I thought there was some statement at
WP:ACCESS about aiming for full-size text, but I don't see it there now.<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)/* Set the font size for {{reflist}} */ .references-small { font-size: 88%;}
Is it just me or did the edit have the result that {{Reflist|colwidth=30em}} no-longer function with all 3 columns? Not sure how many people use browsers with this capability but think this should be addressed. Moxy ( talk) 18:12, 21 December 2010 (UTC)
I was told elsewhere that the vector skin abhorred the smaller typeface. Is this so? And if so why do we not make Monobook work the same way?
Rich
Farmbrough,
01:27, 22 December 2010 (UTC).
So, inspired by a recent thread, I've created Help:Talkspace draft, adapted from Help:Userspace draft. Can use some improvements, but I hope the basic idea is clear. What do people think? Rd232 talk 15:30, 13 December 2010 (UTC)
Note: there is related discussion about the nature/purpose of this thing at Template_talk:Talkspace_draft. Rd232 talk 22:58, 21 December 2010 (UTC)
Is there any way we can get a deletion log to show when clicking on a redlinked image link? Powers T 14:03, 15 December 2010 (UTC)
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)
For some purposes, not least understanding multiple-sock behaviour better, it would be helpful to able to merge multiple accounts' contributions into a single list. It would be great if the software could do this somehow (where it would also help transparency of legitimate alternate accounts), but in the mean time, it ought to be not that hard for a toolserver tool to do this: put multiple accounts' contribs together in the usual date order, with maybe different accounts in different columns. Or perhaps this already exists, and I missed it. Rd232 talk 22:51, 17 December 2010 (UTC)
As far as I know there is no clear recommendation whether or not to use columns on reference lists, and which (fixed set of columns, e.g. {{Reflist|2}}
, or flexible set, e.g. {{Reflist|colwidth=30em}}
). Flexible sets of course offer the advantage of displaying just the amount of columns that suits the visitor's monitor size (which means someone who's having a 20+ in monitor will see 4-5 columns, while someone with a 10 in netbook will see only 2. The
ideal width for columns has been discussed at
Wikipedia:WikiProject Usability). Therefore I would like to propose an additon to
WP:CITE that generally recommends the use of {{Reflist|colwidth=30em}}
on articles with more than 20 references, unless local consensus (of editors of a specific article) opposes it. —
bender235 (
talk)
02:33, 15 December 2010 (UTC)
{{Reflist|30em}}
. —
bender235 (
talk)
10:29, 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 talk 11:29, 15 December 2010 (UTC)
{{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)
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)
{{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){{
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)
{{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.{{Reflist|colwidth=30em}}
because people didn't like it, but because there is no Wikipedia rule or guideline that recommends this style (or any other). So this proposal is actually meant to establish clarity on what the global consensus regarding reference lists is. —
bender235 (
talk)
14:54, 15 December 2010 (UTC)
Could someone clarify the proposal for me? Which of these is being proposed?
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)
colwidth
. The exact width of the columns, however, has to be determined on each single article. This is actually about recommending the use of flexible columns in general, not about stipulating a particular width. —
bender235 (
talk)
22:48, 15 December 2010 (UTC)Just my two cents on this matter. In my opinion, we should use columns for long reference lists (and there are plenty around here). This way, people do not have to scroll over a long reference list for ages just to get to the External Links section, etc. and back. [| Retro00064| ☎talk| ✍contribs|] 00:33, 16 December 2010 (UTC)
So, do is their at least consensus that articles with long reference lists (20+ refs) should use columns, regardless of width and number? — bender235 ( talk) 14:19, 17 December 2010 (UTC)
{{Reflist|2}}
was more like a temporary solution when nothing else was available. Now, however, we have colwidth
, and that is a much better option. So instead of cementing the status quo by recommending users to implement an inferior option, we should just recommend them to use columns, and maybe point at the options available. —
bender235 (
talk)
14:59, 17 December 2010 (UTC)
{{Reflist|2}}
, and it has been used more often" does not count, because following that argument we should go all the way back to <references />
.{{Reflist|2}}
nor {{Reflist|colwidth=30em}}
is useful. But {{Reflist|colwidth=60em}}
might be. So this actually adds to my point that its the width of the columns that should be determined by the author(s), not the number. —
bender235 (
talk)
14:59, 17 December 2010 (UTC)Expand {{ reflist}} so that {{reflist|narrowcolumns}} and {{reflist|standardcolumns}} define column widths in words people can understand, with the advantage that we're not hardcoding a specific width meaning, as we are with eg "30em". That would be easier to understand, better for standardisation, and helpful for any future changes. I'd suggest that narrowcolumns be initially set at 20em (can be debated and/or changed later) and standardcolumns as 40em (ditto). With these new parameters in place, it then makes it easier to conceive of a MoS addition which states
For less than 20 references, columns are not recommended in reference lists. Above this, {{reflist|narrowcolumns}} may be used where narrow columns are required (particularly where Author (Year:Page) style references are predominantly or exclusively used in an article), otherwise {{reflist|standardcolumns}} is recommended. Use of columns is not, however, required, and alternative formatting of columns may be used where there is a local consensus that there is a specific reason to do so.
Rd232 talk 15:30, 15 December 2010 (UTC)
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)
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. / ƒETCH COMMS / 23:06, 15 December 2010 (UTC)
FWIW, if the only thing we can agree on is a MoS recommendation to use some kind of column formatting on "long" reference lists, that's still better than nothing (which AFAIK is the status quo). Rd232 talk 01:34, 16 December 2010 (UTC)
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)
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)
Okay, so after the discussion now seemingly has come to an end, I propose to add the following to WP:CITEFOOT:
For less than 20 references, columns are not recommended in reference lists. Above this,
{{reflist|20em}}
may be used where narrow columns are required (particularly where Author (Year:Page) style references are predominantly or exclusively used in an article), otherwise{{reflist|30em}}
is recommended. If the article contains particularly long references, consider using{{reflist|30em}}
alternatively. Use of columns is not, however, required, and alternative formatting of columns may be used where there is a local consensus that there is a specific reason to do so.
This is basically User:Rd232's proposal from above, except that those narrowcolumns and standardcolumns parameters do not yet exist. Obviously support from my side. — bender235 ( talk) 23:01, 19 December 2010 (UTC)
{{reflist|3}}
as a substitute for {{reflist|20em}}
(etc.) is correct. For example, on
this page, how many columns would you recommend? In fact, you could now say any number from 2 to 8, but either would be incorrect (or at least imperfect), because there are always screens for which the number of columns you determine are either too many or too few. On my 22 inch 1920 px screen, six columns look just right. But if I was having a 10 inch netbook, that would be way too much. On the other hand, two columns might look perfect on that netbook, but look just awkward on any larger screen.20em
), regardless of the size of the screen. The screen size only determines how many characters can be displayed in one line, and therefore how many columns fit on the screen.{{reflist|2}}
, that could also screw up the article, if the user's monitor is small and the refs are too long for just half of the screen. —
bender235 (
talk)
01:25, 20 December 2010 (UTC)
As I understand it, the point of this proposal is to allow editors to begin a mass change to add columns to articles that have more than 20 references, and to change the formatting from reflist|2 to reflist|20em or reflist|30em on articles that have reflist|2 right now. Is that right? — Carl ( CBM · talk) 00:41, 20 December 2010 (UTC)
{{reflist|2}}
only has its use on articles with less than 20 refs. Therefore, this proposal only applies to those articles with more than 20. This is not a proposal to replace {{reflist|2}}
, but merely to recommend not to use it on articles with more than 20 refs. —
bender235 (
talk)
01:36, 20 December 2010 (UTC){{
reflist|1}}
could then be used to override it in articles with few citations.
A. di M. (
talk)
02:14, 20 December 2010 (UTC)20em
and 30em
are only a suggestion, not a directive. —
bender235 (
talk)
12:24, 20 December 2010 (UTC)The number of references is not a good parameter for determining how many columns you want. The amount of text in each column is. If the references are actually of the kind "Smith (2006), p. 42" then 3-column footnotes look better to me, but with a single column for the book list. The point is that the number of references has no bearing on the columns size or number. Tijfo098 ( talk) 13:17, 20 December 2010 (UTC)
Also, I see some people are discussing above the scaling issue of columns with the scree size. That is an irrelevant topic because the main text of a Wikipedia article doesn't scale well with the window size. At default font size it becomes very difficult for me to read Wikipedia on 1920-wide windows/screens, and I have even wider ones available to me occasionally (2560px wide). Having umpteen columns for references is rather pointless if the main article has 200+ characters per line in Arial, because the average person cannot read that comfortably. Tijfo098 ( talk) 13:17, 20 December 2010 (UTC)
Remove the parameter that currently allows {{ reflist}} to produce multiple columns.
The column width parameter of {{ reflist}} and the functionality it provides is not an essential part of providing the reader with accurate, verifiable content. It is unnecessary. It harms the encyclopedia in the following ways:
For these reasons, I don't believe the "column" feature of {{ reflist}} is in the encyclopedia's best interest.
Caveat: if, however, the "column" feature is built into {{ reflist}}, or better yet, Cite itself, then none of my arguments apply. My arguments only apply to the existence of a user-controlled parameter. Not the columns themselves. ---- CharlesGillingham ( talk) 20:38, 20 December 2010 (UTC)
Sorry for starting a new section; I'm lost on where to put this.
I'm not an expert on all of the inner workings of Wikipedia, but I think the appearance and behaviour of reference lists in its current form warrants some discussion on how it can be improved. Perhaps there should be some further discussion on what exactly to propose here, because I see there being many possible solutions other than what you are proposing. If we could get consensus that, yes, we should try to improve how reference lists appear, we could then work on suggestions for how that could be achieved before coming up with a formal proposal. For example, I think the user agent should be taken into consideration (client-side script?). Medium, resolution, browser support, etc. should be considered, and there should be some upper limit on number of columns. Then this behaviour can be overridden with template parameters for exceptional cases. But that's just one idea, and maybe it could be built upon (or torn apart) ahead of proposing it and getting a bunch of !votes. Perhaps someone with more knowledge on WP procedural mumbo-jumbo could chime in and tell you how to start. I can say that I'm certainly interested in improving the look of reflists. :-) I hope that didn't seem condescending. You never know on the interwebs. Also, maybe I'm wrong in which case I invite someone to slap me with a fish. :-) Merry Christmas! CF84 ( talk) 21:48, 25 December 2010 (UTC)
Per this, would it be a good idea to mention the uploader/creator as part of the template in the relevant deletion discussions (AFD, TFD, RFD, etc)? Reh man 10:56, 22 December 2010 (UTC)
I often see lists of, for example, cast members of films and wonder if (for old movies) any are still surviving.
Perhaps a general policy of displaying birth and death dates (or to make them displayable if one mouses over them) or to simply display a name one way if the person is still alive and another if they are deceased would be useful?
Related might a surviving cast members feature for all movies which is different in that all cast members are typically not listed in a Wikipedia movie article.-- Jrm2007 ( talk) 03:53, 23 December 2010 (UTC)
Just to clarify: This is not about movies/actors -- it is about biographical names. I am suggesting that the way a name is displayed automatically encode whether the person is living or dead -- maybe by color or typeface or a symbol after the name. I am not suggesting that in each place a name is mentioned someone go in and add this information and of course maintain it.
I have simply noticed that whenever I see a person's name in an article, for example one that lists cast members of a movie, I wonder if the person is still alive. Maybe it's only me that does this, in which case, never mind.-- Jrm2007 ( talk) 19:02, 27 December 2010 (UTC)
I propose that edits that delete a significant amount of content and which do not have any edit summary -- such as this one -- are automatically reverted. 86.184.232.12 ( talk) 14:48, 27 December 2010 (UTC).
MediaWiki interface pages for the
Cite footnote system have been heavily customized on the English Wikipedia. Currently, if the language set in your preferences is en-GB (British English) or any other than en, then most interface pages are set to the default. This means that the citation in a reference shows a ↑ instead of the en custom ^ and a number of other changes. This also means that the error messages do not have a link to a help page as do the custom messages.
I propose to update en-GB interface pages to the en interface pages so those who set en-GB have the same viewing and editing experience.
One question for those who may know: is it possible to simply create a redirect so that en-GB does not need to be updated when the en interface page is changed?
---— Gadget850 (Ed) talk 04:57, 28 December 2010 (UTC)
(split from above discussion for cohesion)
en
has not been updated with en.gb
and many other languages, not just on this wiki, but most other wikis too. For example, if you login xx.wiki
in en
, the interface shows in English, but if in en.gb
, it mostly doesn't have that language saved, even though the en.gb
interface is nearly 100% same as en
interface. Since wiki content (articles) has policies on which English variant to use, and since selecting the lang variant doesn't really change the content, sometimes I wonder if it would actually be better to delete all specific English variants (en.us
, en.gb
, or maybe even one day for India as en.in
, etc) and use only one English interface... It really wouldn't be that bad...
Reh
man
05:11, 28 December 2010 (UTC)Hello. I'm here to post a link to a discussion over at Requested Moves. Those of us discussing there have, I believe, said everything we've got to say, and we haven't reached consensus (i.e., I'm not convinced). I'd love to see more input from a wider cross-section of Wikipedians. Thanks in advance for any comments. - GTBacchus( talk) 20:53, 28 December 2010 (UTC)
Proposal: install Extension:MagicNoCache (or implement equivalent functionality another way), and then use NOCACHE on sensitive pages. We already have {{ NOINDEX}}, this seems a sensible complement. On a related note, this remains visible in Google some time after requesting noindexing... perhaps NOINDEX should be added to some of the related templates so it's always kept out of search engines. Rd232 talk 13:01, 28 December 2010 (UTC)
Hi people, First of all, pardon me, i know i might be repeating this proposal but I tried to search the archives, ~200 results, saw 40 - 50 of them :).
Demo (The controls are in sidebar)
So the point is: It is a common practice to highlight stuff when we read. It increases productivity and is very helpful for future references. I myself felt great need of it whenever I referenced wikipedia. So to help it out, I have made this extension (click here), which I believe will be helpful to a lot of wikipedia users. Also it give the solution to this problem. Please post your views, and if you think this functionality is worth providing on wikipedia, then support this proposal.
-- Apeksharma ( talk) 20:43, 29 December 2010 (UTC)
You know, this is kind of a major reconceptualization of the wikipedia status quo (and may be a case of closing the barn door after the horse is gone), but it occurred to me today that the encyclopedia would be a lot more encyclopedic (and there would be a lot less hassle for everyone on project) if article creation was restricted to sysops, and we had an AfC (Article for Creation) process in which people could propose new article ideas. In most cases it would be a rubber-stamp process - someone proposes an article, it sits for a couple of weeks and no one objects, then in it goes - but it would give the opportunity to stop a lot of irritating issues before they reached mainspace. It would let us discuss (and possibly squelch) POV-forks, BLP problems, article naming issues, joke articles, and notability problems, decide whether the article should be developed in userspace or the article incubator first, make meta-structuring (balancing different articles within a topic area) far easier, and obviate a lot of frustrating AfD debates with people trying to defend inappropriate content that they've put into the project. what do you all think? -- Ludwigs2 23:49, 21 December 2010 (UTC)
I would agree with Fences and windows & Nyttend. Also, I would emphasise the problem of workload. At the moment, NPP fulfils a similar niche in the wikipedia "ecology"; some third party is expected to review all¹ recently-created articles, and either weed out any deeply problematic ones, or perhaps make a start on fixing any that are fixable. However,
Special:NewPages already has a huge backlog despite the number of potential patrollers being far larger than the number of admins. What would happen if that job was handed over to a much smaller set of people who are already busy with other work? Would we need some kind of screening process before a draft article even gets passed to an admin for approval?
¹Apart from those created by people with an adequate track-record of article creation who are likely to go on to create a large number of compliant articles. I can only assume that a similar exemption would apply to this proposal. If not, the workload would be even higher.
bobrayner (
talk)
02:25, 28 December 2010 (UTC)
A while ago I moved
Wikipedia:List of hoaxes on Wikipedia into mainspaceproject space, to help people like scholars who are interested in studying the history of hoaxes on Wikipedia. This was inspired by
this quote from Jimbo Wales:
However, its utility as an educational resource is limited because the original hoax articles remain unavailable. I'm proposing restoring them and moving them to subpages of Wikipedia:List of hoaxes on Wikipedia, and clearly labelling them with templates marking them as hoaxes. I realise that this flies in the face of Wikipedia:Deny recognition, but if we never learn about our past we have little hope of improving the situation in the future. Dcoetzee 08:14, 29 December 2010 (UTC)
Take Wikipedia and turn it into videopedia, using teachers or instructors to turn Wikipedia subjects into lessons taught on a chalkboard, with visual aids to help get the message across using visual aids and audio explanations.
And/or create wikiuniversity and you could even give creaters the option to create multiple choice quizs of different levels of learning, easy, medium, hard after they watch the video. Users could log in and would be able to keep score of the tests they have taken. — Preceding unsigned comment added by 209.105.142.191 ( talk • contribs) 19:31, 1 January 2011
Hi. This is to bring greater discussion to the topic of creating specific ENSO season articles. Thanks. ~ A H 1( T C U) 19:52, 2 January 2011 (UTC)
I started a discussion at MediaWiki talk:Watchlist-details/Archive 4#Change the link of "your watchlist"? about changing the page that the "Your watchlist" links to. I was asked to bring the discussion to a more visible location, so I brought it here. Comments? — Train2104 ( talk • contribs • count) 21:49, 2 January 2011 (UTC)
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? Reh man 01:44, 2 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?? Reh man 10:59, 6 December 2010 (UTC)
My two cents: WP:Proposed mergers is a good platform to list proposed mergers in one place, but it has at least four problems: 1. I do not believe it is popular enough (compared to WP:RM, WP:AfD, etc.); 2. There is no requirement for users to list merger proposals they are making at WP:Proposed mergers; 3. Along with that, there are likely people who are proposing mergers who do not even know about WP:Proposed mergers; 4. There is no set time limit (that I know of) for a merge proposal to be open. Merge proposals can sit around for months on a talk page without much activity at all (especially on lower-traffic pages, where there are not that many users checking out the talk page and participating in the merge proposal. This relates to problem no. 1, where even if a proposal is listed at WP:PM, proposals can still sit inactive for long periods). Merge proposals can be just as important as deletion proposals and move proposals. Merge proposals could go through a lot better if more people were participating. [| Retro00064| ☎talk| ✍contribs|] 00:11, 17 December 2010 (UTC)
1. think subject of Active Arbitration Remedies such as
ARBPIA --
Israeli–Palestinian conflict, etc.
2. for example, four-way proposals on complex subjects like medicine or conceptual theories, requiring secondary research to even evaluate.
Reviewing prior discussions would be very helpful here, I think. Unfortunately, they're spread around. This means they're harder to find, but a search of AfD-related pages led to several. There have been standalone proposals & well-advertised threads at AfD and elsewhere. It appears this has failed to gain consensus many times in the past.
Here's a few comments drawn from some of the debates:
Merge is seen as " Somebody Else's Problem". The admin doesn't care enough; they're just closing it. The nominator wanted it gone, so they don't want to do work to retain the material. The keepers resent the merge decision, so ignore it. I've closed some AfDs as merge, and sometimes I do it myself and other times I poke a WikiProject or !voter to see if they can follow through. Mergers are a very neglected part of the project.
The problem boils down to this: Saying “Yes, merge.” is easy.
S/Merging as opposed opposed to pseudo‑merging – aka blank+redirect is time consuming and more difficult. The admins, if they close a merge discussion,
don't want to perform the merge. Neither do the discussion participants very often, particularly if they disagreed or aren't active on either article. So it comes down to lots of mice saying putting a bell on the cat so it can be heard coming is a great idea; only the room falls silent when somebody asks, “Who will bell the cat?” –
Whitehorse1
21:24, 16 December 2010 (UTC)
This got me thinking about ways to improve this. I started wondering if the Article Alerts system included new merge notifications; found they didn't. I was unsure if it was still active, though figured maybe it could be revived or another bot could handle some things. It's been inactive some time.
The great news is a volunteer offered to create and be in charge of a replacement bot, and it started a trial last week. Snaps to User:H3llkn0wz for stepping up.
I had a great idea: suggest adding new merges to the notifications. I promptly learnt somebody else already had that idea. Incidentally, it turns out the wikiproject/workgroup-specific Cleanup listings include merge counts, but as that tables all cleanup statistics and is intermittent it impacts this less. WikiProjects that aren't moribund have begun receiving alerts. At present requests for new Alert features suggested previously don't need to be resubmitted. I think this could really help. Let's hope the trial goes well and the bot's parents can start to look at additions soon. – Whitehorse1 05:39, 20 December 2010 (UTC)
To sum it up. My original proposal is to modify the popular WP:Requested moves pages to hold Mergers as well. This would immensely increase the participation in mergers, as compared to Moves. And since Splits are just mergers in the opposite direction, it has also been proposed that Splits and Merges be identified as one, with equal significance and attention. Thus, with a title like "Requested moves, mergers, and splits", or for short, "Articles for discussion", with only the deletion chapter on a separate venue at WP:Articles for deletion.
Currently, we have the following venues relating to mergers (with no main discussion area for Splits):
At present, Mergers (and Splits, for that matter) seems to be of least attention, compared to Moves, Deletions, and Merges&Splits.
Key modifications to merge Moves with Mergers&Splits would be:
Since this proposal imposes time limits to merge/split discussions (like WP:Articles for deletion), so that it wont drift on forever, the issue of "Who will perform the merge/split if consensus is reached to do so?" arises. So far, the closest to a solution is that:
But of course, a volunteer could always perform this merge/split. And since we have unified all chapters to one page, the chances of a volunteer stepping up is more. Future merge/splits proposals in the same topic could also be speedy closed.
Any further issues? Reh man 06:14, 31 December 2010 (UTC)