Jump to content

Wikipedia:Village pump (proposals): Difference between revisions

From Wikipedia, the free encyclopedia
Browse history interactively
← Previous editNext edit →
Content deleted Content added
VisualWikitext
Line 441: Line 441:
: There is a simple workaround: register, login, go to [[Special:Preferences]], check "Prompt me when entering a blank edit summary". Then simply edit the sandbox, but don't enter the edit summary. You will get a warning each time you accidentally click "Save page". --[[User:Martynas Patasius|Martynas Patasius]] ([[User talk:Martynas Patasius|talk]]) 19:06, 12 June 2012 (UTC)
: There is a simple workaround: register, login, go to [[Special:Preferences]], check "Prompt me when entering a blank edit summary". Then simply edit the sandbox, but don't enter the edit summary. You will get a warning each time you accidentally click "Save page". --[[User:Martynas Patasius|Martynas Patasius]] ([[User talk:Martynas Patasius|talk]]) 19:06, 12 June 2012 (UTC)
::Reasonable, however, there still may be reasons or conveniences to have an offline or semi-offline sandbox, which may run faster, be more user-friendly, and more flexible as well. [[Special:Contributions/69.155.141.125|69.155.141.125]] ([[User talk:69.155.141.125|talk]]) 19:15, 12 June 2012 (UTC)
::Reasonable, however, there still may be reasons or conveniences to have an offline or semi-offline sandbox, which may run faster, be more user-friendly, and more flexible as well. [[Special:Contributions/69.155.141.125|69.155.141.125]] ([[User talk:69.155.141.125|talk]]) 19:15, 12 June 2012 (UTC)
::We may also be interested in [[Special:Sandbox]], which could do this job very well. [[Special:Contributions/69.155.141.125|69.155.141.125]] ([[User talk:69.155.141.125|talk]]) 19:16, 12 June 2012 (UTC)


== A template that automatically alphabetizes lists ==
== A template that automatically alphabetizes lists ==

Revision as of 19:16, 12 June 2012

 Policy Technical Proposals Idea lab WMF Miscellaneous 
Shortcuts

New ideas and proposals are discussed here. Before submitting:


« Archives, 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

Reference Tooltips

Note. There is also discussion at User talk:Yair rand/ReferenceTooltips

I propose that the Reference Tooltips gadget be enabled by default on the English Wikipedia. The gadget allows users to roll over any inline citation to see reference information. The displayed information is clickable and selectable. If enabled by default, an option to disable it would be available in Special:Preferences. --Yair rand (talk) 21:40, 18 April 2012 (UTC)[reply]

  • Support Had it for quite a while now and I think it constitutes a significant step forward in Wikipedia's usability. I just hope enabling a gadget by default means unregistered users also get it. Equazcion (talk) 21:46, 18 Apr 2012 (UTC)
    Yes, gadgets enabled by default work for unregistered users. --Yair rand (talk) 21:56, 18 April 2012 (UTC)[reply]
  • Support Yes! This would be extremely useful, rather than having to hit back to go to the spot you were in the article before you clicked it. This way, yu can tell beforehand if it's a reference you will actually want to click into. Furthermore, it lets you know directly which reference that number is referring to, without having to go to the reference list. Helps you understand the narrative of the article and its references without a bunch of back and forth clicking. SilverserenC 22:43, 18 April 2012 (UTC)[reply]
  • Support, seems to have few problems about it. (I wonder if existing popups can be disabled by preference for refs - this one's nicer?) Grandiose (me, talk, contribs) 22:45, 18 April 2012 (UTC)[reply]
  • Support; I'm a fan. I don't know if there is any technical downside to this - will it work on all browsers, does it degrade gracefully? --Tagishsimon (talk) 22:47, 18 April 2012 (UTC)[reply]
  • Well, the point is to make the Reference tooltips a normal feature that even unregistered readers can use. But that's a good question on whether the tooltip and popups works together or if one of them breaks. You might need to uninstall Popups until it's upgraded to work with Reference tooltips. SilverserenC 23:39, 18 April 2012 (UTC)[reply]
  • I just tried using both and tooltips appears redundant to popups, which already does the job, so I disabled tooltips. Why would you want or need both? Viriditas (talk) 00:48, 19 April 2012 (UTC)[reply]
    You wouldn't. However, the overwhelming majority of our readers do not want to have a large box pop up whenever they hover over any kind of link, so having popups enabled by default is not feasible. --Yair rand (talk) 01:17, 19 April 2012 (UTC)[reply]
    The tooltips box was larger than the popups box, and popups can be enabled by default and easily disabled. I really don't see any benefit to tooltips other than a pretty interface. Viriditas (talk) 01:43, 19 April 2012 (UTC)[reply]
    Agreeing with Yair rand below that it's not "easily disabled". I mean, yeah, a mouse click is easy to do, but I don't think we can assume that most users know about preferences and such, particularly non-Wikipedians who just read the articles.I myself have been editing articles on Wikipedia for years but never noticed the reference tooltips (until I came across this discussion). Well-restedTalk 03:47, 2 May 2012 (UTC)[reply]
    Not really "easily" disabled; pretty much none of our readers have accounts, and they wouldn't care to create one, and they wouldn't be able to figure out how to modify their preferences even if they did have accounts. Do you want to go ahead and propose that popups be enabled by default? Do you think that proposal has a realistic chance of succeeding, and that the change would improve the experience of our readers? I suppose we could temporarily close this discussion, and then resume this after the popups proposal is closed if it fails... --Yair rand (talk) 02:40, 19 April 2012 (UTC)[reply]
Nonsense, popups is a vast array of tools, and a bit much for enabling by default for everyone. We generally want to keep things simple when we're talking across-the-board changes, and reference tooltips is a simple feature that makes things easier. It has nothing to do with being pretty, though that is something of a prerequisite for default features. Equazcion (talk) 02:44, 19 Apr 2012 (UTC)
Simple, as in duplicating an interface that is already in wide use? That's not simple, and doesn't make anything easier. Viriditas (talk) 02:57, 19 April 2012 (UTC)[reply]
Last statistic I heard on that was that it was enabled by 34,000 users, which is what, 00.01% of our readers? The popups users are not a substantial portion of the user base. The use of a tool by a minuscule amount of people is not really relevant here. Do you want to propose that popups, or perhaps just part of popups, be used instead? If not, I don't think continuing discussion of popups makes much sense here... --Yair rand (talk) 03:12, 19 April 2012 (UTC)[reply]
See the screenshot above your comment. You are going to duplicate an interface we already have in wide use by our most active registered users. We already have a tooltips-like interface and it is called popups. Viriditas (talk) 03:26, 19 April 2012 (UTC)[reply]
If it creates a conflict with popups, perhaps something can be worked out where it's automatically disabled for popups users; or maybe the script code itself could disable the tooltip if popups is detected; or it could be done in the popups code. Equazcion (talk) 03:35, 19 Apr 2012 (UTC)
Agreed. Thanks for recognizing my concern. Viriditas (talk) 07:44, 19 April 2012 (UTC)[reply]
Viriditas, I don't understand what is the point you're trying to make. Yes, we already have a tool that does something similar, and it's probably been a great deal of help, and it's used by a large portion (most?) of the active editors. How is this relevant? Sorry, I didn't understand that you were worrying about having multiple boxes showing up at once. --Yair rand (talk) 07:53, 19 April 2012 (UTC)[reply]
slightly off topic, but is it out of the question to enable the popups script by default? I think it (a)deals with footnotes with references better (b) more readable text. on a downside, it's (c)not as good looking and (D) heavier.— Preceding unsigned comment added by Staticd (talk • contribs) 10:41, 19 April 2012 (UTC)[reply]
  • Oppose. The vast majority of unregistered readers give a damn about references. They just want their information and they are done. Also, popups can easily become an annoyance, and they usually annoy me, too, even though I actually like this tool. That does not mean it should be activated by default. Leave it as an opt-in tool, as it is now, and anyone registered and really interested in this additional functionality can easily activate it. Nageh (talk) 11:23, 19 April 2012 (UTC)[reply]
    Sorry, but this is an utterly ridiculous comment. References are more useful than the content itself, in many cases (it depends on the subject area, but that's generally true everywhere).
    — V = IR (Talk • Contribs) 19:00, 19 April 2012 (UTC)[reply]
    Ohm's law, I have very rarely if ever criticised other Wikipedians' comments, but it is not right to call someone's comments ridiculous when he is simply stating his or her opinion on a topic for which opinion is being gathered. Give everyone a chance to air their views so the consensus can be properly observed. Well-restedTalk 03:40, 2 May 2012 (UTC)[reply]
    To you, maybe. I did not make this claim out of thin air, I have watched enough people browsing Wikipedia articles, they never look up references unless they are students doing homework, and they take everything literally. We, editors, and researchers are in a vast minority when it comes to the general public. So do not come up with "this is an utterly ridiculous comment". Nageh (talk) 21:30, 19 April 2012 (UTC)[reply]
    Critics will probably appreciate, then, that we're seeking to make the sources of Wikipedia's info more apparent to everyone, by showing it to them as they read; rather than keeping it easy to overlook and ignore. Perhaps people will grow to care a little bit more about sources if we make it easier to see. Equazcion (talk) 21:39, 19 Apr 2012 (UTC)
    This is actually a pretty good argument. Nageh (talk) 22:02, 19 April 2012 (UTC)[reply]
    → Weak oppose/neutral under the condition that registered and unregistered editors can easily turn it off. Nageh (talk) 10:47, 21 April 2012 (UTC)[reply]
  • Conditional Oppose – pop-ups have the annoying habit of getting in the way of what you actually want to read. I prefer them off by default. If that is not acceptable, then it should be made trivially easy to disable them. Regards, RJH (talk) 16:51, 19 April 2012 (UTC)[reply]
  • Unsure: Based upon both arguments, on both sides, it seems like a reasonable tool to enhance verifiability, however, popups can indeed be annoying. If anything, I would say that there should be a substantial delay, say, 1½ seconds, to where they do not pop up accidentally and slow peoples' computers down or interfere with navigation. I do not usually use Google anymore due to my frustrating experience with Google Instant, where they refused to save my preferences to disable the feature, and every time I had exited and returned later, it was reverted back to its original state of being enabled. That's why I now use Yahoo! Search and Ixquick. 75.53.218.81 (talk) 01:13, 20 April 2012 (UTC)[reply]
    Quick note on Google Instant: It was sufficiently annoying to me, too. I have long set the browser's start page to www.google.com/webhp?complete=0 since. Nageh (talk) 09:13, 20 April 2012 (UTC)[reply]
  • Support. Unlike popups that are new windows, you can get rid of these by simply moving your mouse away. It's a great idea to simplify access to the citations for our text. Nyttend (talk) 01:01, 20 April 2012 (UTC)[reply]
    • Just to clarify, popups in this discussion were referring to WP:POPUPS, a gadget that offers a similar tooltip feature along with many others. It didn't mean new windows. Just mentioning that in case there was some confusion. Equazcion (talk) 01:35, 20 Apr 2012 (UTC)
  • Support. I think that this emphasizes that citing sources is important to Wikipedia, and will hopefully encourage others to cite the things that they post, when they might not have before. The only condition is that it should definitely be able to be easily disabled if one should so desire. Falconusp t c 17:24, 20 April 2012 (UTC)[reply]
  • Oppose. Have something similar. Mugginsx (talk) 19:59, 20 April 2012 (UTC)[reply]
    I don't quite see how this is relevant... --Yair rand (talk) 22:02, 22 April 2012 (UTC)[reply]
  • Support per comments by Silver Seren, Equazcion (particularly those in response to Nageh, above) and Falconus. Agree that it would emphasize the importance of citing sources. Also agree with others who have posited that users should have the option to easily disable if they so desire.--JayJasper (talk) 20:11, 20 April 2012 (UTC)[reply]
  • Oppose. As User:Yair rand has pointed out, many users are unaware that Special:Preference exist. Important for the text select-reading style people that this may interfere with who'll want it off. Like popups this cover up the read text, better to stick the reference on top or bottom. It lacks caret browsing support. Finally, Backport improvement to popups. — Dispenser 04:32, 21 April 2012 (UTC)[reply]
  1. Support, excellent idea. Ironholds (talk) 20:48, 22 April 2012 (UTC)[reply]
  • Oppose. Reference tooltips is a great feature for editors and researchers, but would probably be irrelevant at best, and downright annoying at worst, for many general readers. I don't think we should be imposing a feature on readers which they may not want and cannot turn off. SpinningSpark 21:39, 22 April 2012 (UTC)[reply]
The only readers that will notice the feature are those that are interested in references, since the tooltip appears only when pointing to a reference link. Diego (talk) 09:44, 23 April 2012 (UTC)[reply]
I counter. Users that are not interested in references may still leave their mouse over the reference. If the tooltip only showed up on click then it would be a different matter. Tideflat (talk) 17:52, 1 June 2012 (UTC)[reply]
  • Strong Support I have been editing articles for a few years now and spend quite a lot of time dealing with references, and only on reading this discusion found out that it was possible to enable the reference tooltip in preferences, which I then did. It has been very useful over the last few days, and to me a it is a great feature. It is not obtrusive, as you have to hold the cursor over the reference for anything to happen, and as it is a small target this does not usually happen unless you are actually trying to put it there, and it goes away effortlessly. I think the annoyance factor for the indiscriminate consumer will be small, and the usefullness to the rest of the world quite significant. Anyone who is sufficiently put out can switch it off, once they find out that it is possible. I would not support a proposal to make pop-ups a default setting. Peter (Southwood) (talk): 08:57, 23 April 2012 (UTC)[reply]
  • Strong Support - this feature greatly improves usability for references in an unobstrusive way. It should be made default because currently it's too difficult to discover. Also per Equazcion argument, enhancing the visibility and accesibility of references is a net benefit to the project itself.
However the tooltip should have a link to the configuration page so that it's also easy to deactivate it for readers that don't want it. Implementing this change and enabling it by default, it would be easy to set up both for users that want it and for those who don't; the reverse is not true. Diego (talk) 09:44, 23 April 2012 (UTC)[reply]
Like many of the other supporters, you are missing the point that a user needs to be registered before they are able to disable the feature. Things that popup on mouseover can be irritating for those who have no use for them. Registered users are nearly always also editors and will find the tooltip useful, and if not they can turn it off. A large section of our readership, however, possibly the majority, will not find it helpful. SpinningSpark 12:06, 23 April 2012 (UTC)[reply]
This is a technical detail with a technical solution; you can set up a cookie so that unregistered users can disable the tooltip on their machine with just one click (or maybe two, the second one for requiring confirmation) - not different to the current interface for disabling the mobile view in tablets and smartphones. "Like many of the other opposers", you are missing the point that the current interface already has tooltips for most links and images; the reference links are almost the only ones missing them. The target link for references has a quite small area and so it's unlikely to be targetted by accident, and for most references the size of the tooltip would be similar to the ones for wikilinks or images. And I doubt that the majority of readers won't find them helpful; but those who don't will likely not have problems because of them, and the percentage of readership that is interested in references is likely to find them invaluable. For those who don't, an easy way to disable the feature (providing a disable link in the tooltip itself) would be enough to avoid all possible remaining irritation. Diego (talk) 12:37, 23 April 2012 (UTC)[reply]

Oppose I don't see why that is necessary at all and anything popping up inside article text is an unnecessary distraction. Too easy to trigger this by accident. Those who want it can already enable it manually on two different ways as explained at User:Yair rand/ReferenceTooltips. -- Toshio Yamaguchi (tlk−ctb) 14:12, 17 May 2012 (UTC)[reply]

Reference Tooltips. Part 2

  • Comment As this change would affect everybody who reads or edits wikipedia, I listed it on wp:CENT. Yoenit (talk) 13:01, 23 April 2012 (UTC)[reply]
  • Support As some comments above show, many people where not aware of this tool before and consider it a significant improvement once they start using (myself included). I expect the response from our readerbase will be much the same and the large majority will see it as improvement. No doubt some will not like the change for various reasons, so it is important there is an easy way to turn it off/on through a single button click, as Diego says in his comment directly above. Yoenit (talk) 13:01, 23 April 2012 (UTC)[reply]
  • Support Too much click-scroll for me recently. 50.22.206.179 (talk) 14:25, 23 April 2012 (UTC)[reply]
    Comment Anonymous proxy server. Hipocrite (talk) 14:49, 23 April 2012 (UTC)[reply]
I don't think the change should be decided with people using Anonymous proxy servers in mind, if that's what you mean with your cryptic comment. Those that know what an Anonymous proxy server is wouldn't have problem creating an account or installing GreaseMonkey to trim the tooltip from references. Diego (talk) 22:00, 23 April 2012 (UTC)[reply]
  • Support Useful to many readers, not a detriment to readers who don't care (some have mentioned text-selecting readers as a possible group to be annoyed, but I select text as I read and these don't interfere with my view), will help Wikipedia's reputation as a sourced encyclopedia and emphasize references for editors (particularly new editors). Calliopejen1 (talk) 14:57, 23 April 2012 (UTC)[reply]
  • Comment. This discussion is flawed. We are discussing about a change that primarily affects unregistered readers, yet all the persons that are commenting here are registered editors. Nageh (talk) 21:53, 23 April 2012 (UTC)[reply]
How come? All registered editors would be equally affected by the default setting. And there's nothing impeding IPs from joining the discussion if they wish, so where's the flaw? Diego (talk) 22:00, 23 April 2012 (UTC)[reply]
A practical problem is that IP's can't use the extension, so they wouldn't know what they are supporting/opposing. Yoenit (talk) 22:49, 23 April 2012 (UTC)[reply]
That could be said to be a problem with all proposed changes to Wikipedia. A site's serious user community is generally the group that makes decisions that affect everyone else (well usually it's not even those, but some designers in a back room). Unregistered users are fortunately welcome to comment, which is much more than can be said for other sites. It's still not perfect, but it's the best we can ever do. Equazcion (talk) 23:21, 23 Apr 2012 (UTC)
Why do people always (seem to) avoid responding to the essence of a statement? The problem is that we don't know whether readers will appreciate the change. It is true that this applies to virtually every platform, but if we claim that we are working for the readers then this is not quite true. Nageh (talk) 23:30, 23 April 2012 (UTC)[reply]
I think I responded to its essence. This isn't an argument that would apply only to this particular change, but to nearly any. We could post a survey (via banner?) after a month or two asking for feedback on what people think of reference tooltips, and consider changing it if most people don't like it... Equazcion (talk) 23:35, 23 Apr 2012 (UTC)
You did. My comment was more directed at Diego. A public survey is what I am hinting to, it would be the only way to assess whether readers will appreciate it. Whether the community considers that it is worth it is another thing. Nageh (talk) 23:41, 23 April 2012 (UTC)[reply]
  • Support I didn't even know about this until I saw the WP:CENT notice for this discussion. I wish that it were the default sooner—it would have save me a lot of scrolling. There are so many good reasons already mentioned for this, not the least of which is demonstrating to users that we care about references, and for the user's ability to easily access them without mindless scrolling or clicking back and forth. First Light (talk) 22:08, 23 April 2012 (UTC)[reply]
  • Support Incredibly practical. Right now any editor questioning a source while reading an article would have to click a link, check it, scroll up and try to find where they left reading. I can't see it being in the way either, so i have no issue with seeing this enabled by default. Excirial (Contact me,Contribs) 23:02, 23 April 2012 (UTC)[reply]
    • Actually there's no need to scroll up, just hitting the back button works fine. ♫ Melodia Chaconne ♫ (talk) 01:26, 24 April 2012 (UTC)[reply]
      • At least for me it never really occurred to me that I could use the back button - I always click the "back up"-type button associated with the reference, and if there are multiple lines linked to the same reference I often click the same one. I imagine that many other readers have had the same issue. Calliopejen1 (talk) 03:35, 24 April 2012 (UTC)[reply]
        • True, the link is just a relative link inside the page so the back button works. But i gamble that most editors are not aware that they can use the back button for this since it will (normally) take you to a previous page. And even so, you will end at the bottom of the document, which is still quite inconvenient most times. Excirial (Contact me,Contribs) 08:07, 24 April 2012 (UTC)[reply]
  • Support Very useful, as it brings attention to the fact that we do indeed rely on third-party sources, and makes it much easier for casual readers to identify whether a cited source is reliable or sketchy. /ƒETCHCOMMS/ 00:55, 24 April 2012 (UTC)[reply]
  • Support This is an incredibly useful gadget, and surprisingly unobtrusive. I think enabling this gadget by default would be beneficial for Wikipedia and everyone who reads the encyclopedia. Maybe our references would get a lot more attention if we improve their accessibility, as the current system is honestly quite clunky. --Dorsal Axe 09:06, 24 April 2012 (UTC)[reply]
  • Support, if it does not conflict with popups (i.e, enabling popups must disable this feature).  Sandstein  16:03, 24 April 2012 (UTC)[reply]
  • Support—this is one of those things that once you turn it in, you wonder why we didn't have this a long time ago. So long as the technical details are worked out, and I have confidence they will be, do it! Imzadi 1979 → 20:37, 24 April 2012 (UTC)[reply]
  • Strong Support Useful tool, and will increase confidence of general public in reliability of WP.--Gilderien Chat|List of good deeds 18:36, 25 April 2012 (UTC)[reply]
  • Conditional Oppose. Unless a slight delay is added to the trigger, as I've suggested previously. (200 or 300 milliseconds should be adequate.) Otherwise it gets accidentally triggered constantly. Kaldari (talk) 09:04, 26 April 2012 (UTC)[reply]
    • Strongly oppose any delay. That's my pet peeve in the Windows user interface right after Windows popping up taking away the input focus from another window. If supported, make it user-configurable. Nageh (talk) 11:32, 26 April 2012 (UTC)[reply]
      • What does that possibly have to do with adding a trigger delay to referenceTooltips? There's no focus event involved here. Kaldari (talk) 22:16, 27 April 2012 (UTC)[reply]
        • Huh? I did say nothing like that. Delayed pop-up bubbles and windows popping up unexpectedly are two separate annoyances in Windows. Nageh (talk) 19:08, 1 May 2012 (UTC)[reply]
          • Yes you did. You said "...Windows popping up taking away the input focus from another window". As there is no focus event involved in this script, I don't see how that specific comment is relevant. As to delays in general begin an annoyance in Windows, you should realize that 200 milliseconds is 1/5 of a second, i.e. a very insignificant delay. Kaldari (talk) 19:53, 5 May 2012 (UTC)[reply]
    • I admit I haven't checked out the gadget yet, but I'd expect there to be a delay, similar to Navigation popups. If not, I'm sure it could be added. --The Evil IP address (talk) 10:53, 29 May 2012 (UTC)[reply]
  • Oppose (unconditionally :) ). I'm pretty sure that this is one of those things that look like great ideas when you don't see it from the typical user's point of view. Those of us voting here are definitely going to be biased towards a tool like this because we're likely to be the ones most interested in references, i.e. selection bias. The average user or even editor is just going to find this downright annoying IMO, and it won't be immediately obvious to many people that it's a feature that can be turned off. I certainly wouldn't want references popping up depending on where my cursor goes, delay or no delay, and I'd consider myself very interested in the references. Well-restedTalk 22:54, 26 April 2012 (UTC)[reply]
  • Support I did not know that tools of this kind existed until I read this proposal. It looks immensely useful, and I would have loved for it to have been enabled throughout my time here, before and after I made an account. Shirudo talk 22:50, 29 April 2012 (UTC)[reply]
  • Oppose I don't think we should be imposing a feature on readers which they may not want and cannot turn off. Mugginsx (talk) 15:42, 30 April 2012 (UTC)[reply]
  • Support I love this tool, and have wondered why it isn't enabled by default myself. Zach Vega (talk to me) 16:43, 30 April 2012 (UTC)[reply]
  • Support People need to care more about references, this is a way to make references more visible without being too intrusive. Also, we need more people to check the actual validity of the references, so it should at least be by default for logged-in editors. Nicolas1981 (talk) 07:22, 1 May 2012 (UTC)[reply]
  • Oppose Highly annoying feature. I hate pop-ups, if its SPAM or references. Night of the Big Wind talk 07:29, 1 May 2012 (UTC)[reply]
  • Support if a few changes. Making refs more visible is good. May be getting feedback from our readership first (a pilot). Just turned it on to see how it works. The click to put up option would be nice.Doc James (talk · contribs · email) 11:47, 1 May 2012 (UTC)[reply]
  • Oppose Even I, who has lupin's popups activated (providing this functionality), will often find it annoying. I've always found unexpected, and always unwanted similar popups to be an unsufferable plague on every other sites I have encountered them. Besides, tehre are widespread corner cases (cf., anything using the {{sfn}} templates) where the popups are useless. Circéus (talk) 16:27, 1 May 2012 (UTC)[reply]
  • Support In paper media, one needs to flip to the last page to see a reference. This distracts from the flow of reading. This isn't paper media; there is no need to suffer through a major shortcoming of paper media. Blevintron (talk) 17:16, 1 May 2012 (UTC)[reply]
  • Support checking references may be useful but far more useful is the ability to see the first few lines of any wikilink. This nearly always includes a definition of what the term means so you can check what an obscure term (i.e. any term you don't understand) means without having to leave the page. This is useful to far more people than the references thing. filceolaire (talk) 19:32, 1 May 2012 (UTC)[reply]
  • Support provided there is a way for logged-in users to opt out. I don't see how this could really cause much disruption, as moving the mouse away from the bluelink makes the window disappear. So with minimal disruption and great increase in visibility of references, I see this as a no-brainer. -RunningOnBrains(talk) 06:42, 2 May 2012 (UTC)[reply]
  • Conditional support -- only if it works by clicking, not hovering, or if there is an easy way to tell it to behave that way. --Waldir talk 15:00, 2 May 2012 (UTC)[reply]
  • Support' make sense -- Taku (talk) 13:34, 3 May 2012 (UTC)[reply]
  • Support For me the main issue is that I'm a little concerned that this might give problems in certain browsers/for certain users (particularly with the spread of non-PC-based devices), as on some websites pop-ups don't work properly, refuse to go away. For this reason, making click-to-view an option is useful (how does it work on iPads, etc?) But if they work well across different devices and they're easy to disable, that's not a problem. It's a very useful tool in other respects. --Colapeninsula (talk) 15:42, 4 May 2012 (UTC)[reply]
  • Question This sounds like a very good idea. However, how does it improve the current behavior of clicking on a reference tag and then using the browser's 'back' button to land at the original place? EngineerFromVega★ 17:57, 6 May 2012 (UTC)[reply]
  • Strongly support. Anyone who finds the tooltips annoying (and I believe that will be a very small percentage) can simply make sure the pointer is not in the part of the window where the text is, and can navigate the page (scrollbar, slider on the right, etc.) without putting the pointer in the page. Right now, it's a real pain for readers to look at footnotes (click to go there, click to go back, then time to regain the focus on where one is within the article text); this change solves that problem. Any negatives are hugely outweighed by the advantages to readers. -- John Broughton (♫♫) 19:51, 6 May 2012 (UTC)[reply]
  • Oppose hovering, support clicking. I'll change it to support if the reference tool-tip is displayed upon clicking the reference number, and not upon hovering over it. Displaying pop-ups or large tool-tips is not a good web design practice and should be avoided whenever possible. EngineerFromVega★ 05:20, 7 May 2012 (UTC)[reply]
  • Oppose Popups is a much more powerful tool and already has thousands of users. It has not been made available as a default part of this interface, so it begs the question why TT ought to be favoured over Popups. --Ohconfucius ¡digame! 16:28, 12 May 2012 (UTC)[reply]
  • Oppose any Ui change that involves hovering. Rollover behaviour is utterly obnoxious, user unfriendly and doesn't work on touch-screen devices. The functionality should be onclick. -86.152.239.23 (talk) 17:02, 18 May 2012 (UTC)[reply]
  • Support, a similar feature in Navigation popups is already pretty hot. As a reader, it's really annoying having to click on a ref to read its contents, and then having to go back to the text either via the back button or the arrow in the ref. Any gadget that makes this process easier will be welcomed by our readers. --The Evil IP address (talk) 10:45, 29 May 2012 (UTC)[reply]
  • Strong Support Much nicer way of looking at references. David1217 03:16, 30 May 2012 (UTC)[reply]
  • Support, provided that registered users are informed about the change (maybe by a watchlist notice) before it happens, and given instructions on how to turn it off if they wish. I use Navigation Pop-ups, so I'll turn this off, but that's no reason not to have it available for unregistered users/readers. I see some people complaining that the tooltips will be distracting or annoying to some readers; maybe so, but it seems to me that the benefits of making it easier to find references significantly outweigh the costs, since it's very easy to move your cursor off the footnote and thereby get rid of the tooltip. --R'n'B (call me Russ) 18:05, 1 June 2012 (UTC)[reply]

Reference tooltips. 200 millisecond delay. Fixed

Note: This change to the testing version added a delay.
  • Support if 200 millisecond delay (see below). Also, there might be a button in the sidebar or in the tooltip to change it to right-clicking, and/or to turn it off. Similar to the on-off button for watching a page. Cookies will remember the setting even for non-registered users in most cases. The 200 millisecond delay prevents the spam popup effect (see below). --Timeshifter (talk) 16:17, 6 May 2012 (UTC)[reply]
  • Comment. I created a version with a 200 millisecond delay on the pop-up, if anyone wants to try it out. Just add "importScript('User:Kaldari/ReferenceTooltips.js'); importStylesheet('User:Yair rand/ReferenceTooltips.css');" to your vector.js file (and make sure you have the regular gadget turned off). It's still virtually instantaneous, but prevents the pop-ups from being activated by just moving your cursor across the page. Kaldari (talk) 19:53, 5 May 2012 (UTC)[reply]
Definitely better. Would still like the click version though.Doc James (talk · contribs · email) 03:38, 6 May 2012 (UTC)[reply]
200 millisecond delay is much better. That is one-fifth of a second. There is no perceptible delay. But the references no longer pop up just by reading and scrolling through a page. One's cursor has to land on the reference link in order for it to popup. Just having one's mouse cursor pass over a reference link by scrolling does not cause it to popup. Perfect. I added the JS to common.js and it works fine there. Go to Special:MyPage/common.js - for me that ends up here: User:Timeshifter/common.js - and then add this:
importScript('User:Kaldari/ReferenceTooltips.js'); importStylesheet('User:Yair rand/ReferenceTooltips.css');
And of course, make sure you have the regular gadget turned off. For more info: User talk:Yair rand/ReferenceTooltips. --Timeshifter (talk) 16:45, 6 May 2012 (UTC)[reply]
A thought: to be tablet-friendly, it should be tap-activated.--Jorm (WMF) (talk) 05:42, 7 May 2012 (UTC)[reply]
This is a good point. Is there any way to detect whether a browser has an actual mouse that could hover or not (on tablets and such)? --Yair rand (talk) 23:25, 8 May 2012 (UTC)[reply]
How about making it click-only, even for computers with a mouse? EngineerFromVega★ 05:44, 9 May 2012 (UTC)[reply]
I'm really liking the idea of a click-only version of this (with an arrow in the box that when clicked will jump to its place in the footnotes as usual). Plus we could kill two birds with one stone (as touch users could simply tap the ref). It's certainly worth testing it out. --Dorsal Axe 15:44, 9 May 2012 (UTC)[reply]
That is an interesting idea. How does one close the tooltip though? I guess an X in the top-right corner of the tooltip would work. Though it might be irritating having to click in and out of tooltips to open and close them. And a different click in the tooltip to go to the reference below. In contrast, hovering is so convenient. And one can still click the number to go below. I would support an option to left click instead of hovering. Or an option to use the right-click menu to open the tooltip. This would also be instead of hovering. --Timeshifter (talk) 21:30, 9 May 2012 (UTC)[reply]
  • I have been using Reference Tooltips recently and it has been extremely helpful. The scrolling is the only problem that I have had with it, so this seems like an excellent compromise. However, I am concerned that since people won't be used to it, they won't be intentionally moving their mouse over references, and might not notice the feature. However, overall it does seem like a good plan, and the potential problem is very minor, so I support. Bzweebl (talk) 23:35, 10 May 2012 (UTC)[reply]
  • Strong support with 200 ms delay. Users will naturally discover this feature when going to click on references. It's obviously better to view a reference in-context without losing your place in the article when reading an article. Even more useful for explanatory footnotes, where it can juxtapose the explanation with the text it clarifies. Dcoetzee 17:19, 13 May 2012 (UTC)[reply]
  • I've modified User:Yair rand/ReferenceTooltips.js so that when a touchscreen device is detected, the tooltips appear on clicking/tapping rather than hovering. Clicking anywhere outside the tooltip will cause the tooltip to disappear. (This might still be buggy.) Non-touchscreen devices should still work by hovering.
    I'd like to have preferences options available for this, so that a user could change which events trigger the tooltip, whether there should be a delay and how long it should be if there is one, as well as disable the tooltip entirely. I'm thinking that maybe a small icon of a wrench or gear, or anything "settings-like", placed in the top-right or top-left corner of the tooltip itself, which brings up a menu, might be best. (Anyone know of a good icon on Commons?) There's still the issue of whether there should be a delay by default, and how long it should be if there is one. I personally think there should be no delay, but if there is one, I don't think it should be longer than 200ms. --Yair rand (talk) 23:12, 20 May 2012 (UTC)[reply]
    Hi Yair! We are trying to standardize on a "gear" for preferences.--Jorm (WMF) (talk) 23:38, 20 May 2012 (UTC)[reply]
I don't think Reference Tooltips will ever become a default part of Wikipedia without the delay. The feeling many people have (myself included) against uninvited popups is very strong. The 200ms delay is imperceptible. Have you tried it, Yair and Jorm? It completely stops the tooltip popup while scrolling. --Timeshifter (talk) 23:41, 20 May 2012 (UTC)[reply]
I've tried it, and while I can see it being an improvement for Wikipedians, I can't be sure what effect it would have on random users. Anyone want to do some user tests, and see if users who don't know about the feature would notice it within the course of reading an article, if there is a 200ms delay? (Though, getting someone to read through a random article without being able to give any explanation why might be a somewhat difficult test to run...) --Yair rand (talk) 03:10, 25 May 2012 (UTC)[reply]
Can you implement it now in your gadget? This will get more people to implement the gadget in their preferences. More people using the gadget will encourage its inclusion as a default setting in MediaWiki software, or at least as the default in Wikimedia's version of MediaWiki. I see from my watchlist that you have made some changes in the JS (Javascript) for your gadget. What do those changes do? I am currently using Kaldari's modification of your JS (see info higher up), and so I wouldn't know what the JS changes in your gadget do. Others may have the same problem. --Timeshifter (talk) 13:11, 28 May 2012 (UTC)[reply]
Yair rand. Your latest changes in the gadget have added a delay, and fixed this problem. I no longer need to use Kaldari's modification of the Javascript. --Timeshifter (talk) 13:43, 29 May 2012 (UTC)[reply]
Um, no, they haven't? (At least I don't think they have. I don't really know how they could have...) The newest changes were to allow the possibility of a delay, with the default set to a delay of zero for now. This was for the settings options that I intend to add (hopefully today if I have time). The recent changes have certainly not affected the gadget version, which is still only synchronized to the April 19 version. --Yair rand (talk) 18:00, 29 May 2012 (UTC)[reply]
Oops. I must have had a brain fart. I made the wrong JS change. I suggest making the default have a delay. You will have a much greater chance of this being accepted quickly in my opinion. Because unregistered users will not be able to add a delay. --Timeshifter (talk) 18:22, 29 May 2012 (UTC)[reply]

Reference tooltips. Touchscreen and hover/click options

Note: To implement the testing version of this see the notes at the top of User talk:Yair rand/ReferenceTooltips.
  • It looks like the gadget has more touchscreen capabilities now. See:
- User:Yair rand/ReferenceTooltips.js: Revision history.
- User:Yair rand/ReferenceTooltips.css: Revision history. --Timeshifter (talk) 13:38, 30 May 2012 (UTC)[reply]
OK. I see that the JS and CSS on your user subpages is for testing before applying changes to the actual gadget in Mediawiki namespace. For those who are interested see the discussion and notes at User talk:Yair rand/ReferenceTooltips.
I like the option to change from hover to click. That will satisfy people who are opposed to the tooltip appearing via hover (even with the delay). --Timeshifter (talk) 15:55, 31 May 2012 (UTC)[reply]

Wikipedia's motto

Call me a radical, but I'm not 100% sold on the "the encyclopedia anyone can edit" thing. That has a "the encyclopedia anyone can mess with" vibe to it. Wouldn't it be nicer to change it to something like "the encyclopedia anyone can contribute to" or something along those lines? The intention is to emphasize the collaborative and open nature of the encyclopedia without putting so much emphasis on the fact that whatever you read may have been tampered with. --uKER (talk) 13:50, 15 May 2012 (UTC)[reply]

I like the idea of changing from "edit" to something regarding contribution. Chris857 (talk) 17:20, 15 May 2012 (UTC)[reply]
Add a third voice, for exactly the reason uKER mentioned. --Khajidha (talk) 18:07, 15 May 2012 (UTC)[reply]
Oppose for ending the statement with an preposition I'm kidding actually, I just know some grammar-obsessed person is going to say that. I actually support it, but I highly doubt this change will get through. Angryapathy (talk) 18:16, 15 May 2012 (UTC)[reply]
Indeed, from a grammatical standpoint, it should be "...to which anyone can contribute" (the wording used by Commons).
But I find that less catchy and less informative in the context of describing Wikipedia. Getting a letter to the editor published in a newspaper or magazine constitutes "contributing" to the publication. When I discovered Wikipedia, the most exciting element was that I was able to edit it.
Yes, one might conclude that tampering occurs, which is true (but we manage to cope). After more than eleven years, do we suddenly seek to obscure this fact? —David Levy 18:59, 15 May 2012 (UTC)[reply]
I'm not sure what distinction you are making here about being excited that you could edit here, but finding the idea that you could contribute to be less informative. --Khajidha (talk) 19:08, 15 May 2012 (UTC)[reply]
"Contribute" is less specific and can mean various things. (I provided an example.)
When I became aware of Wikipedia (and by extension, wikis in general), I already had contributed to other websites (by writing material and having it accepted for publication), but the idea of directly editing one (apart from my own or something along the lines of a message board) was fascinating. —David Levy 19:32, 15 May 2012 (UTC)[reply]
I quite like the idea of such a warning, how about 'The encyclopaedia just about anyone might have edited' ;-) Dmcq (talk) 18:20, 15 May 2012 (UTC)[reply]
I think you lost a word? The tagline is "the free encyclopedia that anyone can edit." The "free" bit is fairly important. I also don't really understand the benefit of using "contribute" over "edit." Can you elaborate? --MZMcBride (talk) 18:32, 15 May 2012 (UTC)[reply]
"Contribute" connotes positive edits, whereas "edit" leaves it ambiguous. Equazcion (talk) 18:36, 15 May 2012 (UTC)[reply]
If you say so. I don't make that distinction and there are popular expressions (such as "contributed to his demise") that contradict what you claim. --MZMcBride (talk) 18:40, 15 May 2012 (UTC)[reply]
Well, even in your example, "contribute" means helping in the pursuit of demise. If you said "edited his demise" it could go either way (setting aside being the wrong word, but you get the idea). Equazcion (talk) 18:45, 15 May 2012 (UTC)[reply]

How about "the free encyclopedia where everyone can help" or something like that? And it's not a matter of obscuring Wikipedia's nature. It's a fact that its openness is the strongest argument against its credibility, so I thought it would be nice to make it so that the motto highlights its collaborative nature without directly implying its unreliability. --uKER (talk) 19:54, 15 May 2012 (UTC)[reply]

This suggestion is even vaguer, I'm afraid.
The current wording conveys exactly what's intended: everyone can edit. This has downsides, but they're far outweighed by the upsides. I realize that the intent isn't to obscure Wikipedia's nature, but that's an unavoidable consequence of failing to provide this essential information.
I see no reason not to be straightforward and forthcoming. We aren't a PR agency seeking to downplay Wikipedia's flaws and convince the public that it's more reliable than it actually is. —David Levy 20:20, 15 May 2012 (UTC)[reply]
I think agree w/ David Levy--edit's fine just they way it is. It has a solid meaning (not as wishy-washy as help) and contribute has, at least to my ear, a ring of solitiation or request for donation. If it isn't broke don't fix it. Rhodesisland (talk) 21:34, 15 May 2012 (UTC)[reply]
I agree, "edit" is just fine. Telling the truth does not put a negative effect to it. It is correct that wikipedia may be edited by anyone and be tampered with, but the word edit is very exact in the terms David Levy explained. If I would have seen "contribute", I would also, while a newbie, have taken it as meaning submissions of content which are then published or declined. Edit is very specific... it shouts out go and edit it. Perhaps we can have a separate proposal which can, in some way, create awareness about the vandalism fighting efforts and that it is not really edited by a mob. --lTopGunl (talk) 21:57, 15 May 2012 (UTC)[reply]
I think this is one of those things where, regardless what the community wants, Jimbo and the WMF will retain the current motto. Nothing we say is going to change it, as it fits their vision of what Wikipedia should be (not necessarily what it is) — The Hand That Feeds You:Bite 12:47, 16 May 2012 (UTC)[reply]
If we wanted to be honest, we could keep that motto for the vast majority of the encyclopedia, but for places like Eastern Europe or I/P, we should change it to "Earth's version of Purgatory, the giant morass where anyone can suffer". The Blade of the Northern Lights (話して下さい) 16:01, 16 May 2012 (UTC)[reply]

"Edit" has the advantage of implying an "editor" which would be a position of privilege and authority in a traditional publication, but here, anyone can do that job. APL (talk) 01:02, 17 May 2012 (UTC)[reply]

In fact it is not true that "anyone can edit", as some are banned (and for very good reasons). And I think we are slowly getting to a realization that editing access (power) is properly conditioned on editing qaulity and editor trustworthiness, as reflected in the different levels of protection. But while the broad range of contribution to WP is one of its notable characteristics, I would say that even more so is how everyones' efforts fit together. (Well, mostly!). Therefore I think a better motto would be: Wikipedia — the collaborative encyclopedia. ~ J. Johnson (JJ) (talk) 22:14, 19 May 2012 (UTC)[reply]

Aren't they all? APL (talk) 22:38, 21 May 2012 (UTC)[reply]
"Wikipedia, the encyclopedia anyone can edit" is often read as "Wikipedia, the encyclopedia anyone can vandalize." I've seen and heard this interpretation numerous times in "real life". What about "Wikipedia, your free encyclopedia"? If that sounds too much like a TV commercial slogan, what about simply eliminating the "that anyone can edit" part from our little motto line? dci | TALK 22:39, 29 May 2012 (UTC)[reply]

Suggestion: "Wikipedia - where you get information on the Internet, and where you can share information on the Internet"

Covering the (horrid) fact that WP is where people look for information, while also including indirectly the "anyone can edit" antecedent. Collect (talk) 22:52, 29 May 2012 (UTC)[reply]

I would object to "Wikipedia - the free encyclopaedia" because that would not clarify how every one can help (except, of course, those who are blocked after vandalism).

"Free" has a very broad, very loose meaning, and various undesireable subtexts. Which is why I suggest "collaborative": it suggests both broad (though not absolutely universal) participation, and also that it is a cooperative effort. ~ J. Johnson (JJ) (talk) 00:53, 5 June 2012 (UTC)[reply]

"The free encyclopedia that anyone can edit" doesn't mean "anything goes". One of the key words here is ENCYCLOPEDIA. You are free to edit Wikipedia for the purpose of helping us build a neutral, verifiable encyclopedia. You are not free to vandalize, cause trouble, play games, or otherwise make a nuisance of yourself. The phrase "The free encyclopedia that anyone can edit" is an essential description of our identity and our purpose, and the phrase has served us well for most of the time we've been in existence. That said, I wouldn't object to some sort of asterisk/footnote specifying that the privilege of editing Wikipedia can and will be revoked, or is unavailable, in some circumstances. szyslak (t) 04:45, 5 June 2012 (UTC)[reply]

Proposal to stop placeholder stubs being created without a sourced fact

Over the years I've witnessed a great deal of heartache and unpleasantries over "factory drilled stubs" and continue to be blamed for them even when I do not create them. I find it distressing and I'm sick to the core of having to defend myself after all I've done for this website. Every so often a "sub stub scandal" crops up in which several editors will gang up and insist that there is a strict rule against creating them, despite the fact the editor (User:Jaguar) had been creating articles on Chinese townships without facts for 6 months and nobody but me seemed to batter an eyelid and it was solely me who identified his errors. He was editing purely in good faith to try to address China, a black hole of information on wikipedia, but the sheer number of articles without info makes the task expanding them massive. I've had enough of the whining about it and uncertainty and I think its time we set a formal rule against mass stubbing of empty articles and that if new articles are mass generated they must contain a sourced fact bare minimum. I think this would stop a repeat of the deeply unpleasant scenario unfolding at ANI now and a backlash occurring against editors at a later date. At the end of the day we are an encyclopedia and if the article is completely devoid of any information something is obviously wrong, even if it is a desperate attempt to try to address systematic bias and get notable content onto wikipedia. An empty stub is still indicative of systematic bias anyway. I've seen a strong consensus against them witnessed at various AFDs and ANI disputes, so here's your chance to voice whether or not you support this and put an end formally to further potential distress for involved editors in the future. Please note that this is not a proposal to ban unsourced articles from being created by newbies or rookies, who might start notable content which can be sourced but don't yet know how, but to prevent experienced or fairly experienced editors from sub stubbing placeholder articles without a single fact or linked source and for any such unsourced/empty stubs deletable by an admin upon day of creation unless they strictly adhere to the rule. I don't believe speed or quantity of stubs is really the problem, its errors and a complete lack of content which seem to cause the biggest issues.♦ Dr. Blofeld 06:23, 23 May 2012 (UTC)[reply]

  • Dr. B asked my comment. He knows that I support the goal of preventing this sort of less than ideally useful activity. But I think he also knows that I would not absolutely prohibit it. It is certainly less useful than it might be, but it is a good deal more useful than nothing, if it is done with some degree of responsibility and care. True, people have done this without due care, but that hasn't always been because of the lack of a sourced fact of some sort.It has sometimes been the use of obsolete sources, or the improper programming of the data entry, or a carelessness about standard transliteration. W can't prohibit everything somebody would do wrong. Would I would support instead, is a requirement that anyone contemplating the mass creation of article,s whether by manual or automatic means, should say so in advance, so the work can be monitored, and accept the responsibility to stop it if there are valid objections and to fix their errors. I was thinking of saying, "should ask for approval", but on reflection I think that would be a dangerous principle--we should never to reach the point where people need prior approval to edit. If they do it wrong, though, we need quicker ways of getting them to stop and proceed more carefully. I think a referendum is premature at this point--what is needed is not a vote, but discussion. DGG ( talk ) 06:47, 23 May 2012 (UTC)[reply]
I said though, Please note that this is not a proposal to ban unsourced articles from being created by newbies or rookies, who might start notable content which can be sourced but don't yet know how, but to prevent experienced or fairly experienced editors from mass sub stubbing placeholder articles without a single fact or linked source and for any such unsourced/empty stubs deletable by an admin upon day of creation unless they strictly adhere to the rule... So any newbies or newish editors unaware of how to source mass creating would not be eligible but experienced editors mass creating without content and sources would be. Hope this answers Joe Decker's comment too.. ♦ Dr. Blofeld 06:49, 23 May 2012 (UTC)[reply]
Yeah DGG that's a good idea, but its difficult to know where the lines can be drawn. It would be a pain to have to ask permission to create 10 articles or something in one go. And a lot of editors regular produce a huge amount of stubs which are perfectly fine and I know they'd also hate to have to ask permission. There should be freedom to create, so long as it contains a source and fact bare minimum I think.♦ Dr. Blofeld 07:00, 23 May 2012 (UTC)[reply]
(edit conflict) *nod* Yup, that's answered, thanks. CSD is a blunt instrument, and it might be the best of the choices, but I'd at least like to scope out some others, too. If we were gong to do CSD, I'd want tight guidelines for usage, and DGG, who does a lot more CSD work than I do, I'm sure will tell us that there's a metric load of bad CSD tagging out there. That's a real practical concern. The workload of processing a few thousand CSDs is also at issue.
I would like to toss out the rate-limiting article creation idea again. Imagine that the software enforced a 25/day creation limit unless you had some magic bit, parallel to accountcreator. Intervention on expectations could be accomplished *before* the bit was granted, and the process of "oh, I can't create article number 26" is surely friendlier than *any* of our deletion processes. And give that we already *have* a policy that requires actually quite a bit more in the way of process than such a bit before such creation, so to me, this really seems like a straightforward enforcement mechanism, one that I would hope (am I a dreamer?) would be a ton less drama than what we have now.
Also, i wonder if we could get a little more info added to the new NPP tool so that people creating a lot of articles would be more visible to NPPers. This is absolutely a case of "the sooner you know, the less damage gets done.", and independently --joe deckertalk to me 07:19, 23 May 2012 (UTC)[reply]
First, I agree that there is a problem with unsourced mass stub creation, it's common enough and painful enough that it's worth talking about and figuring out what to do about it. I'm not sure simply outlawing it by policy is sufficient, though. The biggest problems were all violations of WP:MASSCREATION#Mass_article_creation, which is already policy. Will a second rule deter an excited editor? I'm skeptical. So while I support the idea of doing something, I'm entirely sure I know *what*. New CSDs? Rate limiting article creation on all users without a flag? Detect-and-intervene processes? I honestly don't know. --joe deckertalk to me 06:49, 23 May 2012 (UTC)[reply]
This is already covered by existing policies such as WP:MASSCREATION, WP:V and WP:N. They just need to be followed. Kanguole 06:53, 23 May 2012 (UTC)[reply]

Not really, as there is no clear guideline which specifically mentions placeholder stubs.. MASSCREATION at present is solely for automated and semi-automated articles and makes no mention of manual mass creation or that stubs must contain a fact and source bare minimum. Perhaps it needs amendment to include this? I don't believe speed or quantity is an issue. Ruigoland and Nielsen create tons of stubs daily which contains a sources and content. Its a quality/error issue which causes the problem. But its the purely empty xxx is a village no source or no information which appears to cause the biggest issues. User Carlos Suarez for instance is creating lots of Iranian stubs which are perfectly formatted and reliably sourced with one fact, and I think it would be silly to restrict what he can produce daily...♦ Dr. Blofeld 06:54, 23 May 2012 (UTC)[reply]

It does cover manual mass creation in the exact same page at MEATBOT. For convenience and clarity an amendment like a wikilink might help though. Thanks, I'll suggest adding one. --92.6.202.54 (talk) 20:58, 4 June 2012 (UTC)[reply]
Probably needs to be on a different page, or a new policy needs to be created. MASSCREATION directs to a section of bot policy. Equazcion (talk) 07:08, 23 May 2012 (UTC)[reply]
Wikipedia:Mass article creation would be a good idea.. I could draw something up on that..♦ Dr. Blofeld 07:18, 23 May 2012 (UTC)[reply]
Well Dr, I think stubs need a lot of law and order to survive, I think. The Article Class system of Wikipedia now, has become a way of deleting a lot of stubs. Once, stubs were articles of score:22 quality. Now they are treated as score:1Mir Almaat Ali Almaat ☏ From Trivandrum, Kerala, India(UTC+5:30) 07:20, 23 May 2012 (UTC)[reply]
  • In principle, we just have to start enforcing our existing rules. Most of these problems occur when editors see an opportunity to churn out large numbers of articles and WP:V, WP:N &c fall by the wayside. However, in practice, that's clearly not enough; because the reality is that editors succeed in creating thousands of articles based on flawed or fictional sources, with no evidence of notability, and they're not caught for months or years (or in some cases they're rewarded with barnstars instead of being told what standards en.wikipedia expects). So, I think we need to put out a clearer message somehow. bobrayner (talk) 08:27, 23 May 2012 (UTC)[reply]
  • What do you mean by "automatically notable"? If they are notable then we have sufficient sources to build an adequate article. If all we've got to go on is an entry in a list, they do not satisfy our notability rules. If somebody in the future discovers more sources, we could build an adequate article at that point in the future. The "automatically notable" notion is what enabled the copypasting of thousands of crappy microstubs based only on some assertion that "Settlement X exists". bobrayner (talk) 08:36, 23 May 2012 (UTC)[reply]

Well I think I'm fairly well addressed on notability and populated places and species are almost certainly notable based on past experience. It is possible to write full articles on tiny hamlets in the UK. Obviously sourcing is poor for a lot of Asian and African countries but its improving. The problem as Rayner says is that the "inherent notability" laebl is used as an excuse to generate stubs with no content and the sheer amount of articles makes the expansion task overbearing.♦ Dr. Blofeld 08:40, 23 May 2012 (UTC)[reply]

It's possible to write full articles on tiny hamlets in the UK if they pass the GNG. If all we have is a dot on an OS map, then no, we can't. Perhaps many of these Asian/African settlements are notable; at some point in the future an editor who has access to better sources (and who speaks the language) could take the time to write some decent content on them. The wide gap between that happy ideal and the actual state of the articles is filled by the unthinking botlike creation of articles from a list - any list. That's what "automatic notability" has given us. bobrayner (talk) 09:12, 23 May 2012 (UTC)[reply]

I managed to write start class articles on small towns in Burma and Thailand but many villages in Burma and Bangladesh etc still have nothing, maybe one mention or something in scraps. but its gradually improving. Its generally reflective of the way the Internet is distributed around the world which tampers with the common view of notability. I say its best to go where the info is and wait until the situation improves.. I remember being frustrated back in 2006-2009 the lack of any mention other than computer database, and since I've revisited some countries and seen a massive improvement and it now possible to generate start class articles. In a few years time it is likely that there will be an english language website actually covering the townships, I know of a site already which lists the village development committees of each township. You have a point that an empty stub is also not really addressing systematic bias but a well sourced meaty stub/start class article makes a massive difference. And I agree, completely. But can we please wipe the slate clean and progress... ♦ Dr. Blofeld 09:16, 23 May 2012 (UTC)[reply]

I have created bu liao qing (song), whose speedy deletion tag was contested by another administrator, who found asserted notability in the last sentence. Moreover, I've created Connie Mak and dan dan you qing. I barely understand Chinese, but my understanding of it has improve a little bit. --George Ho (talk) 09:19, 23 May 2012 (UTC)[reply]

Support I support this proposal. Stubs like "Xingzing is a village in Uzbekistan" are useless. If no source is given, we have no idea whether even the minimal information provided is accurate. They may be more than useless. A reader sees a link to Xingzing in an article or in the search results, clicks on it, and finds no reliable information. They have to click back to keep reading. We have wasted our reader's time, mildly irritated them and slightly reduced their opinion of the value of Wikipedia. I see no benefit from placeholder stubs that could possibly outweigh the negative effect on our readers. Aymatth2 (talk) 12:56, 23 May 2012 (UTC)[reply]

I disagree. Articles that say things like "Xingzing is a village in Uzbekistan" have been hugely helpful to me recently, when I've been doing some categorization work at Commons. The substub is enough to tell me that an image of a map whose page name is ""Xingzing" could be reasonably catted to "Maps of Uzbekistan". Also, these substubs help us WP:Build the web out to non-English Wikipedia articles (the one advantage that the substub has over a List of villages in Uzbekistan). WhatamIdoing (talk) 22:17, 29 May 2012 (UTC)[reply]

The lack of comment here, especially when I left a notice on Jimbo Wales's talk page is that its only a very small minority who really have a problem with it, not to mention the same editor produced over 8000 stubs in 6 months and nobody complained, in fact praised him with barnstars.. .♦ Dr. Blofeld 09:09, 24 May 2012 (UTC)[reply]

Wikipedia is a large place, and many things that are problematic can stay unnoticed for a long time. —Kusma (t·c) 09:43, 24 May 2012 (UTC)[reply]
  • I would support the slightly different rule that new stubs should only exist if they add information to Wikipedia. So assume there is a list of places in China, listing three hundred villages. Adding three hundred stubs that say "so and so is a village in China" is no new information. Substubs can be fine if they add some reasonably useful extra information that does not fit the list form (for example, their interwikilinks). But they shouldn't be created from red links in lists giving just the info that was in the list article anyway. In such cases, the red link is much more useful, as it cries out "hello! there is an article that needs to be written here!". Pretending that an article exists by having a bluelinked substub makes it harder to identify areas where we need to write articles and takes away the joy of "I have written a new article" from the person who actually does the work to write meaningful content. Starting new articles is fun, fixing contentless substubs much less so. —Kusma (t·c) 09:43, 24 May 2012 (UTC)[reply]
  • My view on sub-stubs is something along the lines of WP:HOLE. For want of a better term, I would view it as there being a need to pass two levels of notability. First is the notability of the topic. Most agree that pretty much any listed community is notable. The second is notability of the article. As Kusma notes, adding sub-stubs that offer nothing more than "place X is a village in Country Y" or "athlete A is a player for team B in league C" adds nothing to Wikipedia. You haven't taught me anything. You've only wasted my time. So give me something to show why I care. For athletes, the easy solution is their statistical table. At a glance, it would tell me who they played for, when, what league, how well they did. It gives me something to go by, and perhaps an odd statistical anomaly encourages me to research and expand the article. For towns and locations, give me some basic stats. Population at the most recent census. Location relative to another community that people may recognize. When the community was founded. Harder to do, yes, especially for the locales you tend to focus on, Dr., but but at least I would leave that two-sentence article having learned something, as opposed to the one-sentence article telling me nothing. So yes, I would definitely support a requirement to provide a sourced fact on such articles. Resolute 15:09, 24 May 2012 (UTC)[reply]
  • My position on stubs, especially geographic stubs, was largely shaped by User talk:TigreTiger#Tuma River - blocked for creating a stub. I thought PMDrive1061 was spot on in that exchange, and I thoroughly agree that a stub article should at least say something besides "Tuma River is a river in Nicaragua"; when PMDrive1061 and I actually put a little effort into it, we were able to build a nice short article; see Tuma River. That's what we should be shooting for, not thousands of one-line, uninformative stubs. The Blade of the Northern Lights (話して下さい) 20:08, 24 May 2012 (UTC)[reply]
    • Not even such stub as Tuma river is in Nicaragua" is meaningless. If someone refers to the river, the first thing I want to know is approximately where it is, and for a relatively minor location, even the country is a good deal more information than I started with, and perhaps even all the information I might need. If it were 20 questions, it would take 6 to narrow it down that far. It also helps anyone who might want to add for it by indicating what sort of sources they would look for more detailed information. DGG ( talk ) 00:19, 30 May 2012 (UTC)[reply]


Dr. Blofeld, Okay, I'm convinced. I hadn't looked through the case that probably triggered this until now, MASSCREATION is a policy in name but is, as near as I can tell, unenforced. At this point, I'm willing to support a four-prong approach:
  1. Creation of a separate policy page, *and*
  2. make sure the policy includes non-automated edits (so we don't have to argue about how the edits were made), *and*
  3. make sure the policy includes the requirement of a reliable source, *and*
  4. implement a 25/day article creation limit without some sort of flag
I don't believe the first three are very useful without the fourth.
Mass creation of stubs can be, in my view, a good thing, I'm in agreement with DGG above that stubs such as the one he discusses can be useful, but sourceless stubs, mass-created, are an invitation to hard-to-detect copyright issues (as we've already seen) and large numbers of errors (as we've already seen.) On the other hand, moderately regulated mass stub creations can generate a good bit of factual content in many cases, when we details like copyright, categories, basic sourcing, spelling and grammar as correct as we can make them before any errors are multiplied by four orders of magnitude. That's why we have a MASSCREATION policy, it's just a pity it's not, apparently, sufficient to the task. --joe deckertalk to me 02:40, 31 May 2012 (UTC)[reply]

Red Link Notice

Would there be Consensus to create a single issue notice, similar to {{uw-lang}}, which will be given to users who create red links (link to articles that don't exist and fail to remove them after realising they are red links)? Oddbodz (talk) 15:35, 30 May 2012 (UTC)[reply]

I wouldn't support that. Redlinks can be beneficial to the encyclopedia. Not all of them are, of course, but a blanket warning to nag any editor who creates one would be extremely over-inclusive and annoying. --R'n'B (call me Russ) 15:41, 30 May 2012 (UTC)[reply]
It would be better to send warnings to people who remove red links when they are to valid encyclopedic topics that don't yet happen to have articles. Please, Oddbodz, accept this as an official non-templated warning to desist from such disruption. Phil Bridger (talk) 16:04, 30 May 2012 (UTC)[reply]
Having redlinks is not always bad. For example, I've found that a bunch of mineral articles don't exist, and redlinks show that there is still work to do. They are only a problem when an article is unlikely to be created. Chris857 (talk) 16:14, 30 May 2012 (UTC)[reply]
Redlinks to plausible articles are a Good Thing. WhatamIdoing (talk) 16:24, 30 May 2012 (UTC)[reply]
...and if you look at Oddbodz's contributions of today you can see plenty of those Good Things that were turned into Bad Things. There seems to be a worrying recent trend towards valuing tidiness over the content of the encyclopedia and its development. Phil Bridger (talk) 16:38, 30 May 2012 (UTC)[reply]
Ah, well, that's a mistake I made when I was a new-ish user, too; WP:AGF, and with a little mature guidance I hope that Oddbodz will reflect and come to appreciate the value of redlinks. --R'n'B (call me Russ) 18:53, 30 May 2012 (UTC)[reply]
I certainly didn't mean to imply that Oddbodz was not acting in good faith, but I thought that a blunt response was appropriate when an editor has asked for a blunt method of telling people that they are doing something wrong when, in fact, they are not. Phil Bridger (talk) 21:12, 30 May 2012 (UTC)[reply]
see also one editor here Penyulap ☏ 00:07, 31 May 2012 (UTC)[reply]

Oppose This proposal seems to be based on the false assumption that a redlink only functions as a warning to the user creating the redlink. Redlinks serve a useful purpose, namely indicating topics which are relevant to the article where the redlink appears, but which do not have an own article (or redirect) yet (see also Wikipedia:Red link#When to create red links). -- Toshio Yamaguchi (tlk−ctb) 23:34, 9 June 2012 (UTC)[reply]

Linker

I was thinking of having a sort of linker where while editing if you click on an word it automatically get linked with [[]]. This is to save time for those who regulerly link articles. It can be enabled or disabled.

Do you mean a tool in the editor? Leonxlin (talk) 21:46, 1 June 2012 (UTC)[reply]

Either that or a Javascript program.--Deathlaser :  Chat  13:27, 2 June 2012 (UTC)[reply]
Well, in the editor, there is a link button. You can select any word and have it put brackets around it. Perhaps it's too many clicks for your taste? Leonxlin (talk) 17:40, 2 June 2012 (UTC)[reply]
Precisely, 1 long select and *3* clicks!--Deathlaser :  Chat  19:10, 2 June 2012 (UTC)[reply]
I don't see anything bad about it, since it can be turned on and off. I Support. One pier (Logbook) 17:00, 2 June 2012 (UTC)[reply]
Please put this in centralized discussions.--Deathlaser :  Chat  19:13, 2 June 2012 (UTC)[reply]
I'm not quite sure how you'd like this to work. Do you mean that when the linker feature is turned on, every word you click is linked? Nyttend (talk) 03:14, 4 June 2012 (UTC)[reply]
Yes, that's what I mean.--Deathlaser (talk) 16:31, 6 June 2012 (UTC)[reply]
Why don't you find someone technically inclined and ask them nicely to write some js for you? Why does this have to be listed on VPP? I've seen kind of a lot of... time-wasting threads where you've been the OP. Killiondude (talk) 16:48, 6 June 2012 (UTC)[reply]

Section tags

Most tags relating to content have a "section" version that changes their wording for placement within a section, instead of the top of a page (ie. "This article" becomes "This section", etc). There is some disagreement regarding what format these section versions should take. Currently, some section versions (eg. {{unreferenced}}) default to a "small" format for sections, while most use their standard large format. See User:Equazcion/sandbox2 for examples.

Since the aim of the ambox initiative was originally to standardize such templates, I think a standard "sectionized" version should be chosen for use across all such tags.

Options

I've listed a few options below. Click "[Show]" on the right to display them. Note that all small-format amboxes currently exclude the date stamp by default, but that can be changed, so please specify a preference in your comment ("Option 5 with date" or something). Feel free to add more options here. If you do add options, use {{h2notoc}} instead of == == so that these examples don't show up in this page's TOC. Equazcion (talk) 01:22, 2 Jun 2012 (UTC)

Discussion (section tags)

  • I like option 7, small, slim and with a date. (sorry, I wasn't paying attention to the writing, I was just admiring the pretty pictures) Penyulap ☏ 01:53, 2 Jun 2012 (UTC)
    • There actually is no option 7, but I guess you mean option 6. Equazcion (talk) 02:07, 2 Jun 2012 (UTC)
      • Oh I meant like option 5 and 4, but with the date showing, I think it helps to have the date showing, for lazy readers like me. :) Penyulap ☏ 06:46, 2 Jun 2012 (UTC)
Probably good to show the date in the small examples Equazcion, readers are missing the fact that it is an option....Penyulap ☏ 20:41, 2 Jun 2012 (UTC)
I agree with Penyulap.--Bbb23 (talk) 21:01, 2 June 2012 (UTC)[reply]
I considered displaying all the options with both date included and excluded, but that seems like overkill (there would be 12 options instead of 6). I think people can use their imaginations...? I'll amend the proposal to say that people should specify whether they want the date shown. Equazcion (talk) 21:09, 2 Jun 2012 (UTC)
  • Option 1. That's my first choice (March should be capitalized). It's consistent with the others. I like the fact that it stands out. One immediately knows how long it's been tagged. I like the warning about removal. Second choice is Option 6. If we are going to have something smaller, one line vertically is good even if it covers the whole space horizontally. I note that although the current smaller format box is only in the corner, it also takes up 4 lines vertically. No matter what we decide, it should be consistent across all of the similar maintenance templates.--Bbb23 (talk) 18:12, 2 June 2012 (UTC)[reply]
  • Option 4 or 5 - I prefer the slimmer look. I never liked the massive ugly tags. Kumioko (talk) 19:07, 2 June 2012 (UTC)[reply]
  • Massive? Surely that's bit of an exaggeration, and they're not ugly - they're colorful. :-) Seriously, if the option were listed, would you pick the slim format but with a date?--Bbb23 (talk) 21:04, 2 June 2012 (UTC)[reply]
  • Slim message boxes seem to work well when there is a short message, and less well when there is a lot of text inside (as Equazcion notes above). As an issue with a section is likely to be less important than an issue with the whole article, I would suggest that a short message (with a link to a help page with more details) would suffice for most of these section tags. Therefore I would personally support a careful migration over to the slim boxes. If the text cannot be fitted onto two rows then there is probably no benefit to it though, and for this reason I would be wary of including the date, as in many cases this may push the text onto the third row. What about displaying the date via a tooltip? (Hover over image below.) — Martin (MSGJ · talk) 07:28, 4 June 2012 (UTC)[reply]
Brilliant ! with Martin's brains and Equazcion's good looks, I could make a fortune. Penyulap ☏ 08:25, 4 Jun 2012 (UTC)
Bbb23: your opinion please? And anybody else? — Martin (MSGJ · talk) 19:37, 7 June 2012 (UTC)[reply]
It's a clever idea but I don't think it's apparent enough to most people. Even those who know about the feature will likely tend to miss it. I don't really think it's necessary either because the date doesn't take up enough space to make a difference in the box size:
Equazcion (talk) 19:56, 7 Jun 2012 (UTC)

maybe the irrelevant parts to disappear over time. Penyulap ☏ 22:23, 7 Jun 2012 (UTC)

Discussion needed

This RFC has been open for a few days and nobody's talking. I would really like some feedback regarding this template. Ten Pound Hammer • (What did I screw up now?) 12:52, 4 June 2012 (UTC)[reply]

Seems like a rather trivial thing to hold an RfC over ... — Martin (MSGJ · talk) 13:31, 4 June 2012 (UTC)[reply]
How else am I going to get comments? Ten Pound Hammer • (What did I screw up now?) 20:16, 4 June 2012 (UTC)[reply]
Just for the record, I think you meant to link here instead. — The Hand That Feeds You:Bite 20:32, 4 June 2012 (UTC)[reply]

Assistance

Hello, dear participants of the English Wikipedia. How can I help to develop articles on Ukrainian themes? Yours respectfully --Dfy191 (talk) 21:26, 9 June 2012 (UTC)[reply]

Hello Dfy191. You might start by visiting the Wikipedia:WikiProject Ukraine and chatting with the participants. Regards, RJH (talk) 00:35, 10 June 2012 (UTC)[reply]

Popup notifications

Can we have popup notifications in talk pages, discussion pages, etc. Take the case here itself : in order to see if anybody has commented on my thread here, I have to keep refreshing the page(which I must add, does cause some amount of irritation). Instead, having popup notifications(ideally, like the ones you get in facebook) will be a major help and would improve the usability a lot. Roshan220195 (talk) 08:01, 10 June 2012 (UTC)[reply]

It isn't a bad idea, providing it was sent up as a strictly opt-in feature. That said, I imagine that, technically speaking, implementing such a feature would be very complicated.--Fyre2387 (talk • contribs) 21:06, 11 June 2012 (UTC)[reply]
You may be interested in reading about this project: mw:Echo (Notifications). Helder 22:30, 11 June 2012 (UTC)[reply]
Good point Fyre2387. Hadn't thought about it technically.
Gee thanks Helder. That was really helpful. Happy to see something like this is already being done.

Roshan220195 (talk) 11:58, 12 June 2012 (UTC)[reply]

Reveal part of the oversight log?

When an oversighter removes a revision or revisions from a page, the action is logged, but only oversighters can see the log. This is good, partially because some oversightable pages are oversightable because of their names. However, in cases of error, the complete absence of the log can cause minor problems — there's no way to know who made the mistake and thus no way to notify him/her. For example, I just had to email the oversight mailing list because I found a page with an apparent oversight error — four edits in a string of five had been oversighted, and the text that was presumably the problem was present in the edit that was still publicly visible (the still-visible edit only added text to the previous revision, which had been oversighted), but because I couldn't see who performed the oversight, I couldn't contact just that person. Therefore, I suggest that the username of someone performing an oversight action be made publicly visible, as so doing would improve communication. Of course, this is subject to software capabilities; I have no clue if this be possible. Nyttend (talk) 05:00, 11 June 2012 (UTC)[reply]

I've run into a similar case where not enough revisions had been oversighted, and it was fixed very quickly after an email to the usual oversight address. A message to the original oversighter might lead to a slower response if that person happened to go offline at the wrong moment. -- John of Reading (talk) 19:18, 11 June 2012 (UTC)[reply]

Offline sandboxing software

Hello.

Is there any possibility that I could request the development of a software program which we can download for either Microsoft Windows, Mac OSX, or Debian Linux which will allow us to experiment with wikicode *offline*, which will only connect to Wikipedia if it needs to call up information such as templates or pages, without actually using the sandbox where we may accidentally submit our tests when we may not necessarily want to? Could we also consider the possibility of an "unsubmittable" sandbox, with preview only? Thanks. 70.248.176.149 (talk) 21:18, 11 June 2012 (UTC)[reply]

In other words, an offline program that would be able to show you what the code would look like if saved? As for your second suggestion, a better idea (if workable; I have no clue how much work this would take) would be to make it so that you could edit the text of a protected page and simply not be able to save it. Right now, you can view the code of a protected page, but you can't reword it to see what would happen; if you were able to reword text and preview the rewording on a protected page, we could simply create Wikipedia:Protected sandbox, protect it, and you'd have what you want. Nyttend (talk) 01:41, 12 June 2012 (UTC)[reply]
(edit conflict) That's my wet dream -- my own local Wikipedia to test, that renders using local software and only connects to grab transcluded content (maybe even caching it locally, and only connecting again to check if the transcluded content changed... mouth watering...). You could install a local web server and mediawiki, but that wouldn't solve the transclusion issue. Equazcion (talk) 01:47, 12 Jun 2012 (UTC)
Perhaps we could include in the software program the ability to select which server or site we wish to connect to (if any, or, it could be your local [virtual] server, on your computer, as was mentioned), whether it be Wikipedia's server, Wikia's server, or sites on Wikia such as Wikia's test wiki, Wikia's Classic Cars Wiki, etc. (IP address changed) 69.155.141.125 (talk) 18:55, 12 June 2012 (UTC)[reply]
There is a simple workaround: register, login, go to Special:Preferences, check "Prompt me when entering a blank edit summary". Then simply edit the sandbox, but don't enter the edit summary. You will get a warning each time you accidentally click "Save page". --Martynas Patasius (talk) 19:06, 12 June 2012 (UTC)[reply]
Reasonable, however, there still may be reasons or conveniences to have an offline or semi-offline sandbox, which may run faster, be more user-friendly, and more flexible as well. 69.155.141.125 (talk) 19:15, 12 June 2012 (UTC)[reply]
We may also be interested in Special:Sandbox, which could do this job very well. 69.155.141.125 (talk) 19:16, 12 June 2012 (UTC)[reply]

A template that automatically alphabetizes lists

There doesn't seem to be one in existence. It would seem to be quite useful and make editing of long lists, especially those that are currently out-of-order, easier. Leonxlin (talk) 03:26, 12 June 2012 (UTC)[reply]

👍 Theopolisme likes this. This is honestly a great idea... now, to find someone with the technical chops to make this a reality! Theopolisme TALK 06:01, 12 June 2012 (UTC)[reply]
I would question the usability of editing (as opposed to blindly adding to) a list using such a template, were such a thing even possible at this time. You'd do a better service for future editors to just correctly sort the list's wikitext instead. Anomie⚔ 14:43, 12 June 2012 (UTC)[reply]
What about some sort of list editor or something like that for the editor? Sort of like a table.... but for one column things only? Then it is sorted on save, assuming someone checks a box (i.e. |/| Sort list?) ....? But I don't know if this is actually possible. Theopolisme TALK 16:39, 12 June 2012 (UTC)[reply]
Copy the list source code, paste it in a spreadsheet, use the sort function (the actual process depends on the software you use), copy the sorted cells, paste it back. That's just one of possible workarounds. --Martynas Patasius (talk) 19:11, 12 June 2012 (UTC)[reply]
You can use useful third-party tools such as http://alphabetizer.flap.tv/, which do a great job at this. 69.155.141.125 (talk) 19:14, 12 June 2012 (UTC)[reply]

Prevent articles destined for speedy deletion from being created

"An ounce of prevention is worth a pound of cure."' — Benjamin Franklin

Wikipedia should take a few lessons from Franklin's wise words. Currently, we have an enormous amount of articles which are ultimately destined for speedy deletion due to their unsuitability for Wikipedia. From the way many of them seem to be written, they are not written by individuals who think out their words and write carefully, but rather by individuals who haven't a clue of what is suitable for Wikipedia (after all, it is the "encyclopedia that anyone can edit") and what is not. Therefore, I think that, through the same mechanisms through which an editor may already get a message above the editing box during the process of editing (e.g. the notices about BLPs), we should add a message for new editors like this one:

After this, we can put the current message which comes when creating a new article. Perhaps the userspace draft notice can be moved to the top somehow.

This should stop a lot of the confused new editors from writing articles, or make them write better ones. It'll certainly help with editor retention, as editors (who may not even know that talk pages exist!) are not lost, confused, and then dismayed because their article was (apparently capriciously) speedily deleted. Wer900 • talk • coordinationconsensus defined 04:32, 12 June 2012 (UTC)[reply]

Do you think anyone would actually sit through and read it? Maybe a more concise version, with links to the related pages in detail? Just an idea. Theopolisme TALK 06:04, 12 June 2012 (UTC)[reply]
I strongly suspect that anybody looking to create an article that reads "fhogrew09r3q09t235tytegf" will not be deterred by any template, no matter how concise. If this template were better targeted at constructive (but possibly misguided or uninformed) editors, it might prove useful but this shotgun blast of a template lacks focus or readability. - Dravecky (talk) 08:24, 12 June 2012 (UTC)[reply]
For what its worth it has been proven that short concise messages on Wikipedia tend to get the most bang so its unlikely that this very long one would change much. Most wouldn't bother reading it I'm afraid. Kumioko (talk) 12:10, 12 June 2012 (UTC)[reply]
Oppose Agree with above comment by Kumioko. 13:23, 12 June 2012 (UTC)

Such a message would only serve to frighten good-faith new editors away from editing Wikipedia by making them think that they have to jump through so many hoops before creating an article, leaving the field open to the bad-faith ones who wouldn't care about any instructions presented to them. Phil Bridger (talk) 16:22, 12 June 2012 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)&oldid=497268954"