Jump to content

Wikipedia:Village pump (proposals)/Archive 89

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

This page contains discussions that have been archived from Village pump (proposals). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214

Allow rollbackers to view abuse log

Currently, only admins (and possibly edit filter managers) can view all of the abuse log entries in full. Other users can view some of the entries (of particular filters) without the filter number, nor the details of the event, which makes things difficult when evaluating reports at Wikipedia:Edit filter/False positives/Reports. Because most users who patrol that page are rollbackers, it would be nice if they could be allowed to view these log entries in full.--Jasper Deng (talk) 22:21, 9 May 2012 (UTC)

So you can't see log entries generated by hidden filters. Working as intended. These filters are hidden for a reason. T. Canens (talk) 07:46, 10 May 2012 (UTC)
I think in enwiki everybody can view any abuse log entries in full unless they were hidden. Ruslik_Zero 15:55, 10 May 2012 (UTC)
No, these are events that are too numerous to just be plain revdeleted/oversighted.--Jasper Deng (talk) 16:56, 10 May 2012 (UTC)
Details of some filters are hidden to make it more difficult for them to be evaded. Only the filter maintainers need to know the details. A reviewer should assess whether or not an edit was a false positive entirely on the merits of the edit itself, not what the filter says. Otherwise we are into a Kafkaesque situation of edit filter tripped - user challenges - reviewer checks edit filter - yep, you broke the edit filter rule - not a false positive - you are a vandal. SpinningSpark 11:51, 11 May 2012 (UTC)
No, that's not what I'm talking about. I said abuse log, not abuse filter. If I cannot see what the user tried to do, how can I help?--Jasper Deng (talk) 17:19, 12 May 2012 (UTC)
In that case I'm not sure I understand your problem. Looking at the abuse log (which has the page title "edit filter log") while logged out I can see all the entries as far as I can tell. The only difference is that filters which are flagged to hide from public view are not named and there is no link to the edit filter manager. You can look in the user's contributions and find the edit which triggered the filter from the timestamp. Even while I am logged in I still have to do this manually because there is no diff to the edit in the abuse log. Since you can see what the user did you can judge whether or not it was really an abuse. If I am still not understanding your problem, post a link to an instance of the abuse log and explain what you have a problem with. Oh, PS, it does hide the log from you if you search by filter ID number when that ID is a hidden filter, but you would be searching by user if you were trying to help a user I presume. SpinningSpark 18:23, 12 May 2012 (UTC)
I cannot see the details of the event, only the fact that the user has triggered it. The entry "Example triggered an edit filter, performing the action "edit" on Lorem ipsum: Actions taken: Disallow Filter description: Long-term pattern abuse" is not helpful because I can't see the "details" link that's needed to see what the user did and whether it was a false positive or not.--Jasper Deng (talk) 18:27, 12 May 2012 (UTC)

According to Special:ListGroupRights, everyone has the userright abusefilter-log-detail. I'm not aware of there being log entries that doesn't apply to, unless they're entries made private by oversighters (via userright abusefilter-hide-log). If hidden filters generate private log entries that's certainly news to me. (Wikipedia:Edit filter doesn't even mention the existence of hidden filters, BTW.) Rd232 talk 18:30, 12 May 2012 (UTC)

There are too many such entries for oversighting to be the culprit. I guess it has something to do with the abusefilter-view-private permission that sysops have and ordinary users don't.--Jasper Deng (talk) 18:33, 12 May 2012 (UTC)
I would guess that too - it looks like hidden filters are applying abusefilter-hide-log, because there are certainly are entries at Special:Abuselog without a "details" link. Rd232 talk 18:36, 12 May 2012 (UTC)
That can't be the case, because admins who aren't oversighters can view all the entries, supporting my hypothesis that abusefilter-view-private is needed. Therefore, this proposal intends to give edit filter managers (who aren't necessarily admins) and rollbackers that permission.--Jasper Deng (talk) 18:38, 12 May 2012 (UTC)
I assumed abusefilter-hide-log was the counterpart to abusefilter-view-private, but that doesn't really make sense. So yes, abusefilter-view-private is probably to show the "details" link for private entries, and private entries generated by hidden filters. Rd232 talk 18:42, 12 May 2012 (UTC)

Now it's time for logistics. Should we make a new user right just for this? Or, as I want, should we attach it to the existing Rollbacker and Edit Filter Manager groups?--Jasper Deng (talk) 18:46, 12 May 2012 (UTC)

Ok, I logged out and looked at the log of the filter 9 (a private filter). I was able to see all entries with details links. Only 'adjust visibility' links disappeared. Ruslik_Zero 17:15, 14 May 2012 (UTC)
Hmm. When I try that, it ignores the specification of the filter and shows me entries for all filters instead. Anomie⚔ 18:18, 14 May 2012 (UTC)
That's unusual - this is what I was trying to address with this proposal.--Jasper Deng (talk) 19:43, 14 May 2012 (UTC)
In this example there are details links even when I am logged out. Ruslik_Zero 05:40, 15 May 2012 (UTC)
That's not what I get...--Jasper Deng (talk) 19:02, 17 May 2012 (UTC)
Special:AbuseLog/6899383 shows a message "You do not have permission to see details of this entry." The edit is probably one that was tagged and is still visible. The log for the filter that tagged that edit (354) shows entries for all filters. Peter E. James (talk) 10:34, 20 May 2012 (UTC)
Have any of the rollbackers involved tried running for admin? One of the common grounds for oppose is no need for the tools, so if there really are things at the abusefilter that can only be seen by admins, perhaps the solution is to appoint some of the regulars there as admins. OK I appreciate that RFA has a shitty reputation, but if you've been here > 12 months have >4,000 manual edits, can point to some reliably sourced content that you've added, have no made many recent mistakes, have a cleanbock log and a need for the tools, then it can still be passable. ϢereSpielChequers 15:36, 20 May 2012 (UTC)

Non-free image size, name, and categorization

Working with non-free images, I've had a few ideas that I think would improve their use and presence on Wikipedia.

Naming
  • Non-free image names should ideally be as clear as is reasonable, and preferably contain the name of both the article and the subject (i.e. File:Transformers Prime logo.jpg instead of File:Tfprime.jpg, File:Pokémon Ditto art.png instead of File:132Ditto.png, etc.). I'm not proposing this as an actionable policy, but merely as a suggestion to those uploading or doing file maintenance. Ideally uninvolved editors should not have to guess as to its use or contents.
Categorization
  • Non-free images should be tagged with WikiProject banners whenever possible. WikiProjects that cover articles with non-free images should maintain "File-Class articles" categories. This can easily be maintained by bot. Category:File-Class video game articles has helped people at the video games project maintain and police non-free images for a few years now, since they were Image Class.
Sizing
  • Non-free images should not be resized below 300px width unless the height exceeds at least 450px. The reason being that most non-free images on WP are set with the thumb, frameless or (occasionally) frame tags. Users are able to set their default thumbnail size from 120px up to 300px (for larger resolution screens). There is no reason to size the images below the width at which they will be used. Images could still be uploaded at less than 300px if the uploader feels that is appropriate for the subject; this is specifically suggesting that bots and other editors not unilaterally resizing these images.
  • Similarly, non-free images should not be wider than 300px unless the image is panoramic, or the image contains details or text that cannot be seen clearly in a standard thumbnail size. Those last conditions would need to be defensible (meaning a clear argument would be needed to agreed upon to keep an image at 500px), and we could make a template for these exception so that bots don't tag them. There is no reason to keep most images in a larger size than is used.
Utilitarian objects
  • Non-free images of utilitarian objects should not be allowed, unless the object has A) not been made commercially available and B) is unlikely to be made commercially available. Manufacturers could possibly be convinced to release promotional images for unreleased products to have them used on Wikipedia (as happened with the Pebble watch). If the Wikipedia article already contains their non-free promotional photos (as with I'm Watch), there is no reason for the manufacturer to release free images. By "utilitarian" I mean only objects that would not qualify as copyrightable (i.e. toasters, cars, watches, etc.).

Please let me know what you think. ▫ JohnnyMrNinja 21:57, 18 May 2012 (UTC)

With naming, it would be nice if we could normalize against Commons, but I don't believe there's any set system them and the amount of work... oy. But I do agree that naming of files should be clear.
The suggestion on utilitarian objects can be incorporated into NFCI/NFC#UU.
The size thing, however...there's two problems I see with it. First, many infoboxes that incorporate cover art are usually set to display the infobox at a specific size (like 252px) and thus the image is set to that size, no "thumb" tag. So to apply this to "every" image isn't a good idea. Secondly, right now, the thumbnail sizes are as you say. What happens in, say, 5 years when the default device size can support 600px without a sweat (including mobile units, etc.). NFCC#3 must be followed for minimal use, so if I know that you just inserted a movie screenshot at 1920x1020, that's not going to pass low-resolution muster, but there's no reason to not have a 320x240 screenshot which is thumb'ed to 180px in an article. --MASEM (t) 22:07, 18 May 2012 (UTC)
Non-free images are replaceable, and can generally be found with a simple image search. Also, if an image is uploaded at 1920px and resized, the original can always be undeleted and rescaled. If the thumnail sizes change, most of the non-free images would need to be replaced anyway, right? Images are already being rescaled below 300px, by bots, based on a perception of our policy. ▫ JohnnyMrNinja 22:32, 18 May 2012 (UTC)
Concerning naming, I do not think it is a good idea. First, it can not be automated, meaning somebody would have to rename files on a regular basis. Given that we lack resources to do more necessary work, I do not think this would be a good investment of time. Second, if we start going into details, there are lots of problems. What if a non-free image is used in several articles? What id an article gets renamed? What if the image becomes free, should we rename it? Ant those are only the ones which are on the surface, I am pretty sure there are more of these issues.--Ymblanter (talk) 22:12, 18 May 2012 (UTC)
I only mean this as guide, under ideal circumstances. Copyright holders deserve to be able to find any images that infringe on their copyright. I am not talking about bot runs, just when people see it and have time. Commons does not have naming policies, but Commons does not have non-free images (also image names could be in any language, which makes standardization impossible). I already do this when I see it, but it would be nice if images were uploaded with meaningful names. Also, keep in mind that non-free images are entirely dependent on the articles they are used in, and are deleted if not used, so their use should be as clear as possible to even the casual observer. ▫ JohnnyMrNinja 22:32, 18 May 2012 (UTC)
I dislike the naming suggestion as WP:CREEP. We have more important things to do.
I'm not really current on NFU stuff, but I thought that 300x300px was the maximum size (for typical uses), and you seem to propose it here as the minimum. WhatamIdoing (talk) 22:45, 18 May 2012 (UTC)
It is the maximum size for a thumbnail image. Unlike a free image, non-free images only exist to be used on the page, so they shouldn't be larger than necessary. They should also not be smaller than what is useful. An image at 300px can be scaled down to 120px if you are viewing on your phone. An image at 120px cannot be scaled up to 300px if you are viewing on a 1080 monitor. We currently have bots (and editors) that find overly-large images and reduce them below 300px. I'm suggesting that large images not be reduced in size to below 300px, though they can still be uploaded at a smaller size when appropriate. ▫ JohnnyMrNinja 23:06, 18 May 2012 (UTC)
IMO, all images—free and non-free—should be clearly named, although I don't think containing the name of the article is necessarily necessary. Anomie⚔ 01:50, 19 May 2012 (UTC)
Not practical, either, since they can be used on more than one article, article names change, etc... but yeah, clarity in general is nice. -— Isarra ༆ 18:51, 19 May 2012 (UTC)
Again, this is meant only as a suggestion. Most uploaders think that they are being clear with a title, but they are forgetting about context. File:AA ROAS.jpg may have been clear to the uploader, but File:America's Army Rise of a Soldier cover art.jpg is clearer to everyone else. The uploader may know what File:9th titlescreen.jpg is, but File:Beatmania IIDX 9th Style title screen.jpg has clearer context. Article names are chosen because of their context and clarity, so it makes sense to use those names as a guidepost when naming the dependent files. If it is used on multiple pages (which is maybe 5% or less of non-free files?), who cares? It's a suggestion. If it can be reasonably achieved, naming a file "File:Article Name subject.jpg" will almost always create a unique name with a clear context. ▫ JohnnyMrNinja 21:54, 19 May 2012 (UTC)
Non-free images are totally different to free images. They are 100% dependent on the pages in which they are used. Think of them like a proprietary cable. If you sell someone a universal cable, like coaxial, you might describe the length, or the variety of connector, or the color, or the brand. With a proprietary cable, like a Game Link Cable, none of these things matter a fraction as much as the name of the devices which which it can be used. This is the same with non-free files. File:ER Cast Season 1.jpg may have a cast, it may have an ambulance, it may have doctors and nurses, but it cannot be used for any of those things. It can only be used for things related to ER (TV series), so it is named with appropriate context. If it were named File:Season 1 cast Doctors and Nurses with an Ambulance.jpg or File:Assorted rich people with obscured hands and pale clothes.jpg, it would be plenty clear, but it would lack the context to make it usable. A free picture (especially of non-fictional objects) has no such restrictions, so the naming of that is really unrelated. ▫ JohnnyMrNinja 22:10, 19 May 2012 (UTC)
"File:Season 1 cast Doctors and Nurses with an Ambulance.jpg" doesn't mention season 1 of what. "File:Assorted rich people with obscured hands and pale clothes.jpg" is verbose, but doesn't really explain the interesting aspect of the image. I don't doubt that an appropriately-named image will probably wind up including the name of the (primary) article. Anomie⚔ 00:28, 20 May 2012 (UTC)
File:ER Season 1 cast Doctors and Nurses with an Ambulance.jpg may be acceptable, specificly if serveral images of ER are uploaded - although you coiuld make a case that it's too long a name. I would definitely expect that ER would show up somewhere in the name, but that has nothing to do with it being unfree - I would say the same thing if they were to decide that this specific screenshot is PD. עוד מישהו Od Mishehu 13:20, 22 May 2012 (UTC)

Proposal for a "Number of times an article has been edited" feature

If one clicks on an article's "History" one can go to an icon that says "Page view statistics" and that will tell you the number of times a Wikipedia article has been viewed in the past thirty days. Can I make a proposal for a similar feature that tells one the number of times a Wikipedia article has been edited in the past thirty days? Or do people think that one can work this out by looking at an article's history so that this will be superfluous? Either way, I shall be interested to hear responses. ACEOREVIVED (talk) 09:58, 22 May 2012 (UTC)

I'm not sure that such a link would be particularly useful. If you think it is, feel free to either create such a tool yourself, or find someone else willing to, and therte's a good chance that it would be added to the header of the history page. עוד מישהו Od Mishehu 13:11, 22 May 2012 (UTC)
It is there already, History -> Revision history statistics -> month by month breakdown. Interesting, nobody has edited this page since april 2010 ? what the ? Penyulap ☏ 13:27, 22 May 2012 (UTC)

I am not sure which aspect of "History" you are referring to there - do you mean the one marked "Public log" (the one that is on the top left of the history screen?)ACEOREVIVED (talk) 23:01, 22 May 2012 (UTC)

I think that I have just found where you can find this information now - it is in the top left hand corner of the "History", and it is called "Revision history statistics". This seems to be the thing I was pleaing for, and I have now found it is there already. ACEOREVIVED (talk) 23:12, 22 May 2012 (UTC)

Data is only shown for the first 50,000 edits using that tool. As to the original point, I think there's no use for it. In history, select to view the past 500 edits, look for the date from when you want to start counting, and copy and paste into Excel (or some other spreadsheet tool). Problem solved. —Strange Passerby (talk • cont) 13:34, 22 May 2012 (UTC)
A little clumsy. But so what? "Number of times ... edited" seems a meaningless, rather useless statistic. ~ J. Johnson (JJ) (talk) 22:02, 22 May 2012 (UTC)

A hidden heading for navboxes (especially for mobile)

This isn't a big deal, but navboxes are sorted under "External links" which is incorrect. On the mobile layout you expand "External links" to get to them. Maybe we should create a hidden heading for "Related pages" or something like that that just shows up on mobile, so they're filed correctly. —Designate (talk) 00:50, 23 May 2012 (UTC)

Some editors have been using WP:Related information for navboxes. There are some disadvantages (e.g., screwing up print versions of Wikipedia, which do not include navboxes), and it doesn't seem to have caught on, but it's one option.
Alternatively, they're always at the bottom of the page. Is there a "scroll to the end" feature in your mobile device? WhatamIdoing (talk) 01:06, 23 May 2012 (UTC)

Wikipedia.....

Wikipedia needs to a way to attain the historical references of deleted articles. It may be useful in the future. For example: Some times a deleted article can recreated by adding the things it lacked. An editor who formerly edited the article can help the new user who is recreating it.Mir Almaat Ali Almaat ☏ From Trivandrum, Kerala, India(UTC+5:30) 07:05, 23 May 2012 (UTC)

Editors can ask at WP:REFUND. If you have any specific deleted articles you want to ask about you can ask me or use that refund page to get a userfication happening. If the page cannot be restored to public view because of some other problem, an administrator may be able to snip out references for you, if they exist. Copies may exist on mirrors, and perhaps at Deletionpedia or Wayback Machine. Graeme Bartlett (talk) 09:08, 23 May 2012 (UTC)
Administrators can view and restore deleted pages. See Wikipedia:Perennial proposals#Deleted pages should be visible for past discussions about making them visible to non-administrators. PrimeHunter (talk) 13:05, 23 May 2012 (UTC)
In addition to WP:REFUND, asking Graeme, asking myself, ... there is also a list of administrators willing to consider requests for deleted articles at Category:Wikipedia_administrators_who_will_provide_copies_of_deleted_articles --joe deckertalk to me 15:58, 23 May 2012 (UTC)

Subpages at TfD

I propose to transform WP:TFD such that each template discussion is on a separate subpage and the discussion shown at TFD would be transcluded from that discussion. I hate having to watch the whole page, when I am only interested in one specific discussion. -- Toshio Yamaguchi (tlk−ctb) 06:23, 24 May 2012 (UTC)

I'm sure everyone will each have thir own personal preference, but for me, I very much prefer the daily log pages. In my opinion, separate pages (like MfD) just segment discussions and make it harder to comment in several discussions. Just a lot of reasons. - jc37 06:26, 24 May 2012 (UTC)
Yes, different people have different preferences. But I disagree with your statement that "separate pages (like MfD) just segment discussions and make it harder to comment in several discussions". The single TfD discussions are unrelated to each other, except for the cases, when several related templates are being nominated, in which case a group nomination should be made anyway, which would still be on a single subpage. -- Toshio Yamaguchi (tlk−ctb) 06:39, 24 May 2012 (UTC)
Not been my experience. It's nice to open/edit a single page and while it's open in editing mode, to have a second window/tab of the same page open not in editing mode. then I click the various links in a particular discussion, researching it, I comment, then all I need do is scroll to work on the next discussion.
That aside, I also think that it makes it a lot more user friendly for newbies. Especially for nominating. And having separate pages would, I believe, be a hindrance for those who edit as IPs. Since they cannot create pages. but in the log system, the daily pages are created, and anyone regardless of IP or account can nominate at their discretion.
I understand the watchlist issue, but i find it's not hard to click on the history link in my watchlist and look directly to see who has edited a page recently.
Like I said, I have a lot of reasons that I prefer the daily log version of XfD. - jc37 06:50, 24 May 2012 (UTC)
WT:TFD and WT:Deletion policy were notified of this discussion. עוד מישהו Od Mishehu 03:35, 29 May 2012 (UTC)
We also need to consider how the limits on template usage effect this - see, for example, Wikipedia talk:Templates for discussion#Transclusion not working. Transcluding a separate page for each discussion would make problems worse. עוד מישהו Od Mishehu 03:39, 29 May 2012 (UTC)

Two new requests for comment regarding the Arbitration Committee

I've started two new requests for comment regarding the Arbitration Committee:

The intent of these requests is to solicit community feedback regarding potential improvements to the arbitration process. Input from anyone with an interest in arbitration or the Committee's work would be very appreciated! Kirill [talk] 20:34, 27 May 2012 (UTC)

The problem is at a lower level in my opinion, until arbitrators are empowered to deal with content dispute resolution. If that happened then there would have to be a lot more arbitrators. It would be better to create a lower level of arbitrators and call them something else - such as content-dispute admins. Above all else, content-dispute admins should be separate from regular admins. Because regular admins are seen mainly as enforcers.
To sum things up there are more articles, less editors, and many low-quality articles. Many editors have left. If content dispute resolution became more efficient, then more editing could be done with less editors. The lack of simple content dispute resolution oftentimes leads to curt, rude, or otherwise offensive admin intervention. Admins frequently have to step in: WP:3RR, page protection, incivility warnings and blocks, and WP:Edit warring (a completely vague policy).
Due to its vagueness and arbitrariness WP:Edit warring is almost diabolically efficient in driving away active editors. It is inevitable that active editors will arrive at content disputes one after another especially as they edit more and more controversial topics. After a few arbitrary clueless rulings (it happens often) by admins wielding WP:Edit warring even the most thick-skinned active editors just throw in the towel. Why bother? Admin power corrupts, WP:Edit warring corrupts absolutely. It is currently substituting for content dispute resolution. --Timeshifter (talk) 13:17, 28 May 2012 (UTC)
+1 / ditto Penyulap ☏ 17:59, 28 May 2012 (UTC)
My preferred solution for content disputes would be binding RfCs which lasted something like 3 months. This wouldn't need arbitration and it would give people a breather to stop getting worked up about the matter. If a person kept on about the matter whilst the RfC was in place they could be pointed to the RfC and just told no that's how it is till that ends and persistence against that would be a civility or disruption problem. There's no great need for every problem to be fixed now instantly if that gets people worked up and causes trouble. Dmcq (talk) 07:39, 29 May 2012 (UTC)
In fact I see one can suggest ways of not needing arbitration in the first place, I guess that is a way of improving it, so I'll suggest there. Dmcq (talk) 07:46, 29 May 2012 (UTC)

If you want your comments to be considered, you need to comment over there, not here. This section will be archived in a week and ignored by whomever closes the RFCs. WhatamIdoing (talk) 22:25, 29 May 2012 (UTC)

Do we need another notice board?

Moved from Wikipedia:Administrators' noticeboard/Archive236 § Do we need another notice board?

There are ample opportunities to report incidents of negative consequence, to the exclusion of a place to report positive contributions. Is there any merit to an administrative notice board where exceptional contributions can be discussed to the possible result of a relatively high accolade? My76Strat (talk) 00:49, 27 May 2012 (UTC)

I think people could do without more drama. Any such board would easily be hijacked and turned into the standard AN dramafest. —Strange Passerby (talk • cont) 01:18, 27 May 2012 (UTC)
I am sure you are correct. I suppose it becomes a matter of where best to use the energy of our inner diva. My76Strat (talk) 01:47, 27 May 2012 (UTC)
It makes a good deal of sense. There are a lot of quiet drama-free editors who do a great deal of work, and a little thanks now and then makes a good deal of difference. I expect it can be created as a subpage of an existing project, but I am not certain which one myself. Penyulap ☏ 04:11, 27 May 2012 (UTC)
Not that I strongly oppose the idea, but at what point does it become "the barnstar board" : ) - jc37 04:52, 27 May 2012 (UTC)
The Teahouse is going well, and we at least need a Santa clause's list of nice boys and girls for people who want to thank someone to have a list they can add to, the editor can be assessed, and moved to a deserving list. It makes sense, the only question is which location is the most logical ? Where would you direct people like this to, so their energy would not be wasted ?
Further, ANI has a lot of process, I personally like to make certain that if I am going to give an award that I am giving it to an editor who deserves it. Like this award. It would be easier if there were people to assist just like at ANI, and process, such as NOT notifying the editor who is being discussed :) I think it would be a good balance to the Dramaz.
Awards are not a serious thing for most people, sure, fair enough, but for others, giving them out incorrectly is cause for banning someone, so for some editors, it is zerious business. Not everyone is into ANI, not everyone will be into this, but there will be interest. It can help give the award culture more vibrant order, a sense of definition that preserves the spirit of giving awards on wiki.
If anything, the additional process would add additional prestige to the award, we can tailor the awards to show that they have been awarded by the board, and as such are genuine and bona-fide. Occasionally there is doubt if someone really deserves an award, or if they gave it to themselves, or someone did it for no particular reason, so a board with it's own awards would be cool. Penyulap ☏ 06:03, 27 May 2012 (UTC)
No. Nobody Ent 00:21, 28 May 2012 (UTC)
Sounds like a fine idea. Edison (talk) 03:56, 28 May 2012 (UTC)
  • I don't think it makes sense to formalize a process for giving awards/recognition in a notice board, the current system where anyone who thinks a barnstar etc is warranted is able to just hand it out works great. That said, rather then a noticeboard, what about forming a project, or even a cabal, to coordinate the seeking out and barnstarring of under appreciated contributors? Monty845 04:07, 28 May 2012 (UTC)
  • I think it already exists, but I can't remember the name. It was basically a page for saying thanks to someone who helped you. It quickly fell into disuse. WhatamIdoing (talk) 22:23, 29 May 2012 (UTC)
    You're probably thinking about WP:TEA. Jafeluv (talk) 08:55, 30 May 2012 (UTC)
  • It's a nice idea. Problems, however, might derive from editors who view this as a way to heap praise upon ourselves and from those who are not awarded any of this recognition and tirelessly demand it. If you want to recognize someone's efforts, award them a barnstar - it won't be earth-shattering or even webpage-shattering, but I suppose it's some token that the community notices the recipient's good efforts and intentions. dci | TALK 23:19, 30 May 2012 (UTC)

I see request after request for more search options. Many of those options are already available at Special:Search. So why not put a link to search in the sidebar? That is something we can do on Wikipedia right now without having to modify the overall MediaWiki software.

Then people could click the search link in the sidebar to go to Special:Search. Then they could do all kinds of searches. And they could keep their current page open too. They can go to Special:Search in a new tab. --Timeshifter (talk) 13:15, 28 May 2012 (UTC)

We already have a search box at the top that takes you to a search page. Your suggested approach seems to add an extra step in most cases. Forking a separate tab would be useful in some cases, but it seems like that could be implemented using the search box. Regards, RJH (talk) 03:08, 29 May 2012 (UTC)
The provision is there already. If you leave the search box empty, and click on the magnifying glass icon (or click on Search in MonoBook skin), you go directly to Special:Search. The only thing lacking from Timeshifter's suggestion is that using this method, you cannot open Special:Search in a new tab - it always stays in the current tab. --Redrose64 (talk) 06:17, 29 May 2012 (UTC)
Yes, that is the problem. It does not open in a new tab. One can right-click a link to get to a new tab. --Timeshifter (talk) 12:36, 29 May 2012 (UTC)
RJH. There is a preference (on the gadgets tab) to "Open external links in a new tab/window". Maybe there could be a preference to "Open search results list and search suggestions in a new tab/window." Then clicking on the magnifying glass icon from the search box at the top of the page would take one to Special:Search in a new tab. The search form could be empty and it would work too. --Timeshifter (talk) 13:48, 30 May 2012 (UTC)

Banning divas

I am sick of people who retire with extremely long-winded messages about how Wikipedia's a "broken system" and how "its days are numbered". It really annoys me, because it's one thing to retire, but it's another to insult people who stay. A lot of these "missing persons" end up coming back anyways, often times with "fresh start" accounts. I think we should permaban (possibly even IP block) these self-righteous divas. Sorry for the rant, but I felt like just putting it out there.--yutsi Talk/ Contributions 18:19, 29 May 2012 (UTC)

I think you should be banned for this rant. :) --Timeshifter (talk) 18:26, 29 May 2012 (UTC)
Strong Oppose- not a very good policy.--Deathlaser :  Chat  18:34, 29 May 2012 (UTC)
Give me Examples.--Deathlaser :  Chat  18:51, 29 May 2012 (UTC)
Oh oh, me, me, me !!! actually I object that this new policy isn't named after me *)})8-P (someone, anyone, point out I haven't left yet? or did I several times, or in my head I'm already gone, anyone ? Gimme some loving here!) Penyulap ☏ 22:56, 29 May 2012 (UTC)
Weak Support. If someone says they don't want anything to do with Wikipedia, we should enforce that for them. Certainly, "fresh start" (WP:CLEANSTART) should be voided if they continue "editing patterns or behaviors that would allow other users to recognize and identify the account." — Arthur Rubin (talk) 19:00, 29 May 2012 (UTC)
  • People should be banned for expressing their opinions about the direction of Wikipedia? Fuck that nonsense. I presume you will give us a list of acceptable opinions to hold? Fuck that nonsense too. Groupthink is enough of a problem on Wikipedia already without enshrining it in policy. This is a completely stupid and bullshit proposal. → ROUX ₪ 19:05, 29 May 2012 (UTC)
  • I'm not sure this is one of those "proposals" meant for people to use bold words to vote on. I think this was just a venue for them to vent their frustrations and/or for people to talk about this issue (if indeed it is an issue). I mean, they themselves just called it a "rant". Killiondude (talk) 19:07, 29 May 2012 (UTC)
Yes, you're correct. :)—Yutsi Talk/ Contributions ( 偉特 ) 01:30, 30 May 2012 (UTC)
Ahh...so this isn't actually a proposal. This is just an off-topic diva rant for the forum. --Onorem♠Dil 03:29, 30 May 2012 (UTC)
  • It sounds like what you want to ban is flouncing, not so much divas themselves. —chaos5023 (talk) 19:09, 29 May 2012 (UTC)
  • This is why I left Wikipedia two years ago. Oh, what I'd give for the good old days...  :) Seriously, it is rather irritating when people harp about why they've left. Sure, there are lots of things wrong with this place, but it's only to be expected. Complaints don't write articles. dci | TALK 22:35, 29 May 2012 (UTC)

Updates on Social Media pilot

Greetings! This is an initiative by meta:India Program run by the Wikimedia Foundation. Here is a small update on the Social Media pilot supported by India Program. This pilot is running on two Facebook groups for Wikipedia activities: one in English (One is You can also write on Wikipedia) and one in Odia (Odia Wikipedia). Both of these are being piloted to see if we can explain the very basics of editing to new editors and to encourage them to make their first basic edits. This is done You can visit these groups to see the regular editing sessions that we are conducting there. So far, we have been able to get 30 first time editors in English and 10 in Odia - all of whom have completed a few basic tasks (like creating usernames, corrected mistakes, adding references, inter-wiki links!)

Facebook is a useful way of engaging with young users because they are more comfortable there. Here is a 19 point comprehensive guide that we've developed to illustrate the kind of language, nature of messages and way of interacting on Fb that you might find useful and can implement on your groups as well. Please note the mini-editing sessions we have devised with just 5 tasks to make the start of a new editor's Wiki journey really simple! If you need any help to try this pilot in your group please write to me (noopur@wikimedia.org). (Even if your community does not yet have a Facebook page, or if the page is inactive right now, I can support you.) Happy to help! Noopur28 (talk) 10:42, 30 May 2012 (UTC)

The Facebook groups are a great idea.
From your update: "Why we decided to go with Facebook at all is because potential new editors are more comfortable and familiar with the channel. To illustrate, after outreach sessions, we tried staying in touch with around 100 participants using a combination of email and talk page messages and got just 3 responses. When we sent an invite to a Facebook page where they could get help and inputs on how to edit, we got 300 signed up in less than 3 days."
Wikipedia:Teahouse might be interested in this. --Timeshifter (talk) 19:19, 31 May 2012 (UTC)

Disappearing cite button

The cite button disappeared, thus I cannot improve articles much more.--Deathlaser :  Chat  17:34, 30 May 2012 (UTC)

It reappeared, but now the ref tags are starting to Glitch, this is ******* ********.--Deathlaser :  Chat  17:41, 30 May 2012 (UTC)
And everything works again LOL.--Deathlaser :  Chat  17:50, 30 May 2012 (UTC)
Where is the cite button???!!! ='( I think I am going to die now. Leonxlin (talk) 21:44, 1 June 2012 (UTC)
I found it again YAY. Leonxlin (talk) 22:00, 1 June 2012 (UTC)

Just push the 'sight' button and it will reappear. ;P -- Ϫ 07:17, 4 June 2012 (UTC)

Would like to see the guideline Wikipedia:Don't feed the divas changed to gender neutral title

http://www.merriam-webster.com/dictionary/diva It's meaning is feminine in English, Italian and Latin

Any suggestions? Otherwise, please just vote. Perhaps Don't feed the malcontents? Don't feed the constant complainers?

  • Comment I just saying, I have seen males behave the same way. Mugginsx (talk) 20:14, 30 May 2012 (UTC)
    • Yes, but males can be divas, just like they can be drama queens or prima donnas. The PC language police may object to such terms, but I don't see why they have to be banned from Wikipedia essays, which have a tradition of using language that gets attention. Policies and guidelines are written more formally, and perhaps more politely. --Trovatore (talk) 20:58, 30 May 2012 (UTC)
  • I'm a bit confused as to why this was brought straight to a sitewide forum without any prior discussion on the essay's talk page. In addition, as of this post, there hasn't even been a notice left there, or any indication whatsoever to watchers of that page that there's talks about changing its name. elektrikSHOOS (talk) 23:55, 30 May 2012 (UTC)
  • Comment:

"the term "prima donna" has come into common usage in any field denoting someone who behaves in a demanding, often temperamental fashion, revealing an inflated view of themselves, their talent, and their importance"

A diva is a celebrated female singer [with] outstanding talent in the world of opera, and, by extension, in theatre, cinema and popular music

Hmmm... seems like prima donna's the one we're after.. technically anyways. I get the whole allitaration thing though, but... Wikipedia articles never lie, right? :D Plus it also allows us to use the male primo uomo.--Coin945 (talk) 23:56, 30 May 2012 (UTC)

Diva and prima donna seem to mean roughly the same thing in popular speech, and neither of the masculine versions divo or primo uomo conveys the same idea at all. Seriously, I don't care what anyone does with this essay; discuss it on the essay's talk page, or just move it boldly and see if anyone moves it back; whatever you like. But if you (or Mugginsx) bring it up on VP on some silly politically correct basis, I'm going to call it silly. What would you want to do with Wikipedia:Don't be a dick? Isn't that insulting to men, by the same logic? --Trovatore (talk) 01:06, 31 May 2012 (UTC)
Let it be known to the ladies and gentlemen of the jury, I don't actually agree with the proposal. I was just making a devil's-advocatey-type comment. Proposal sounds rather trivial and silly actually....--Coin945 (talk) 01:46, 31 May 2012 (UTC)
Coin945 Perhaps that is because you have the good fortune to have been born after women had fought for their right to be respected as a man is.Mugginsx (talk) 14:32, 31 May 2012 (UTC)
I'm not sure I understand what that has to do with this proposal. Are you fighting for a woman's right to be called a diva without having to share that title with a man? --Onorem♠Dil 15:11, 31 May 2012 (UTC)

My last remark was to Coin945 in response to his or her remark. I really started this half-heartedly and thought we could share the names to make it include both genders without a fight and even have a laugh or two while we were doing it. Naive to be sure. Mugginsx (talk) 15:58, 31 May 2012 (UTC)

May I suggest the alternative title Wikipedia:Don't feed the peafowl? Not only isn't sexist, it isn't even a human referent. It also avoids the wp:UE issue. LeadSongDog come howl! 16:09, 31 May 2012 (UTC)
Your geting warmer. Pretty good. I was thinking of Wikipedia:Don't feed the peafowl? Section: Non-judgmental descriptive titles. We don't want to offend the peafowls. Mugginsx (talk) 17:06, 31 May 2012 (UTC)
Vandals? Geez, that is kind of a giant leap of logic, isn't it? Mugginsx (talk) 17:22, 31 May 2012 (UTC)

Notability Noticeboard / Wikipedia:Proposed Articles

Occasionally I wonder if something without an article is notable; I generally take the viewpoint that if I'm wondering this it probably doesn't need an article, but how about a noticeboard, or place of discussion or whatever where an editor can take an article proposal (and it doesn't have to be much - I'm thinking the typical proposal would be merely a title) for feedback as to whether it has notability. This could potentially prevent quite a bit of time put into non-notable articles being wasted.

It would of course have to be very clear that this will never be a required step before creating an article, to avoid creep.

Two possible titles:

Thoughts?

Egg Centric 21:24, 30 May 2012 (UTC)

P.S. The particular article I am not sure whether I ought to create that inspired this is Care in Mann - I welcome your feedback on that too and propose below a possible format: Egg Centric 21:28, 30 May 2012 (UTC)

Support article creation

Deathlaser :  Chat  21:38, 30 May 2012 (UTC)

Oppose article creation

Neutral

Because, AIUI, AFC is for users who want articles creating by other users. This is for users who want to create the article, but would like some feedback as to whether it's a good idea. Egg Centric 22:21, 30 May 2012 (UTC)
Noted. Egg Centric 22:21, 30 May 2012 (UTC)

WP:AFC you have my permission to delete this remark Penyulap ☏ 23:56, 30 May 2012 (UTC)

And if you don't want NN, then you probably want WP:Requested articles. WhatamIdoing (talk) 04:32, 31 May 2012 (UTC)

Can I please say that there already is somewhere in Wikipedia where one can go for requeseted articles? A few years, I requested an article on Harvey A. Carr and it is now in Wikipedia. So, asking for a place where one can request Wikipedia articles is only asking for what Wikipedia already has. ACEOREVIVED (talk) 19:34, 31 May 2012 (UTC)

Spaced mdash and ndash vs unspaced (templated)

A discussion has been started about the usage of templated usage of ndash and mdash templates (spaced and unspaced). Please see Wikipedia talk:Manual of Style#Spaced mdash and ndash vs unspaced (templated) and comment there.  Hazard-SJ  ✈  01:49, 1 June 2012 (UTC)

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)

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

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)

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)
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)
Wikipedia:Mass article creation would be a good idea.. I could draw something up on that..♦ Dr. Blofeld 07:18, 23 May 2012 (UTC)
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)
  • 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)
  • 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)

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)

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)

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)

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)

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)

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)

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)

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


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)

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)

Either that or a Javascript program.--Deathlaser :  Chat  13:27, 2 June 2012 (UTC)
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)
Precisely, 1 long select and *3* clicks!--Deathlaser :  Chat  19:10, 2 June 2012 (UTC)
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)
Please put this in centralized discussions.--Deathlaser :  Chat  19:13, 2 June 2012 (UTC)
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)
Yes, that's what I mean.--Deathlaser (talk) 16:31, 6 June 2012 (UTC)
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)

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)

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

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)
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)
  • Option 4 or 5 - I prefer the slimmer look. I never liked the massive ugly tags. Kumioko (talk) 19:07, 2 June 2012 (UTC)
  • 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)
  • 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)
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)
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)

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)

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)

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)

I like the idea of changing from "edit" to something regarding contribution. Chris857 (talk) 17:20, 15 May 2012 (UTC)
Add a third voice, for exactly the reason uKER mentioned. --Khajidha (talk) 18:07, 15 May 2012 (UTC)
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)
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)
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)
"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)
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)
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)
"Contribute" connotes positive edits, whereas "edit" leaves it ambiguous. Equazcion (talk) 18:36, 15 May 2012 (UTC)
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)
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)

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)

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

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

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)

Aren't they all? APL (talk) 22:38, 21 May 2012 (UTC)
"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)

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)

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)

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

The IP Speaks: I got one: "Wikipedia - An online encyclopedia by the people, for the people". Excuse the Americanist bias. 68.173.113.106 (talk) 21:07, 12 June 2012 (UTC)

Better one. "Wikipedia, your free encyclopedia." Note the keyword your. 68.173.113.106 (talk) 21:09, 12 June 2012 (UTC)
"Your" has connotations of ownership, and, strictly speaking, it is not "your" encyclopedia (nor mine) at all. It belongs to the Wikipedia Foundation. All the rest of us have a more nuanced relation which "your" largely misses. ~ J. Johnson (JJ) (talk) 22:16, 12 June 2012 (UTC)
PAHH!! belongs to us ! belongs to us ! belongs to us ! Penyulap ☏ 03:31, 13 Jun 2012 (UTC)
First of all, there's no such thing as the Wikipedia Foundation. It's the Wikimedia Foundation (and it also deals with many non-Wikipedia projects). Second, none of the content is actually owned by the WMF. It's owned by the contributors, and licenced under the Creative Commons Attribution-ShareAlike License, meaning that anyone can use/copy/duplicate/modify/sell/share it, and "ownership" is practically meaningless. Anyone really "owning" it as in having control over it would entirely eliminate the "free"-ness (free as in freedom) of it, which would really ruin the whole point. --Yair rand (talk) 06:28, 13 June 2012 (UTC)

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)

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)
You may be interested in reading about this project: mw:Echo (Notifications). Helder 22:30, 11 June 2012 (UTC)
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)

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)

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)

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)

👍 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)
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)
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)
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)
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)
That's quite a useful site! :) Theopolisme TALK 05:58, 13 June 2012 (UTC)

Reference Tooltips

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.
I'm not sure that "closure" is strictly necessary here, but a request was made at WP:AN/RFC for an admin to close it.

I find that the consensus here is overwhelmingly in favour of the proposal. There is dissent, but very little compared to the level of support. It is worth noting that compatibility or conflict with popups was raised several times, and is something that should be explored. A suggestion of adding a delay to minimise inadvertent triggering of the tool was also made , and it appears that this suggestion was taken up. HJ Mitchell | Penny for your thoughts? 16:25, 21 August 2012 (UTC)

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)

  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
    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)
    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)
    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)
    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)
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)
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)
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)
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)
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)
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‎
  • 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)
    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)
    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)
    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)
    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)
    → Weak oppose/neutral under the condition that registered and unregistered editors can easily turn it off. Nageh (talk) 10:47, 21 April 2012 (UTC)
  • 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)
  • 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)
    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)
  • 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)
    • 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)
  • Oppose. Have something similar. Mugginsx (talk) 19:59, 20 April 2012 (UTC)
    I don't quite see how this is relevant... --Yair rand (talk) 22:02, 22 April 2012 (UTC)
  • 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)
  • 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)
  1. Support, excellent idea. Ironholds (talk) 20:48, 22 April 2012 (UTC)
  • 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)
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)
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)
  • 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)
  • 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)
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)
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)

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)
  • 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)
  • Support Too much click-scroll for me recently. 50.22.206.179 (talk) 14:25, 23 April 2012 (UTC)
    Comment Anonymous proxy server. Hipocrite (talk) 14:49, 23 April 2012 (UTC)
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)
  • 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)
  • 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)
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)
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)
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)
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)
  • 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)
  • 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)
    • Actually there's no need to scroll up, just hitting the back button works fine. ♫ Melodia Chaconne ♫ (talk) 01:26, 24 April 2012 (UTC)
      • 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)
        • 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)
  • 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)
  • 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)
  • Support, if it does not conflict with popups (i.e, enabling popups must disable this feature).  Sandstein  16:03, 24 April 2012 (UTC)
  • 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)
  • 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)
  • 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)
    • 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)
      • 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)
        • 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)
          • 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)
    • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • Support' make sense -- Taku (talk) 13:34, 3 May 2012 (UTC)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • 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)
  • Strong Support Much nicer way of looking at references. David1217 03:16, 30 May 2012 (UTC)
  • 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)

Reference tooltips. 200 millisecond delay. Fixed

Note: This change to the testing version added a delay. Later added to gadget itself.
  • 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)
  • 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)
Definitely better. Would still like the click version though.Doc James (talk · contribs · email) 03:38, 6 May 2012 (UTC)
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)
A thought: to be tablet-friendly, it should be tap-activated.--Jorm (WMF) (talk) 05:42, 7 May 2012 (UTC)
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)
How about making it click-only, even for computers with a mouse? EngineerFromVega★ 05:44, 9 May 2012 (UTC)
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)
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)
  • 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)
  • 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)
  • 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)
    Hi Yair! We are trying to standardize on a "gear" for preferences.--Jorm (WMF) (talk) 23:38, 20 May 2012 (UTC)
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)
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)
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)
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)
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)
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)

Reference tooltips. Touchscreen, hover/click. Fixed

Note: To implement the testing version of this see the notes at the top of User talk:Yair rand/ReferenceTooltips. A disable button, touchscreen support, adjustable delay, and a hover/click option were added to the actual gadget itself on June 11, 2012.
  • 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)
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)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Semantic tags in MOS

We should encourage (but not require) editors to use tags specifically designated by the W3C for emphasis (<em> and <strong>), rather than just italic. (Italics chould still be used for book titles, stuff in other languages, etc.) This would be part of MOS but optional. (Note that I used the semantic emphasis element to italicize the word optional - and that was appropriate use of italics.)

Alternative: Create a task force to "fix" this in good and featured articles.

Reasoning: While this change wouldn't affect the way a page is displayed in a web browser, it would change the way pages are read aloud using aural interpreters, and be processed more accurately using intelligent scripts. That's me planning for way in the future. 68.173.113.106 (talk) 01:12, 13 June 2012 (UTC)

I can't think of many cases in article text where we'd use <strong> or <em> that wouldn't already be covered by simple italics such as a book title. Can you provide an example? On a related note, though, we should probably also encourage the use of <del> and <ins> over <s> and <u> when adding or redacting text in discussions. It makes more sense semantically. elektrikSHOOS (talk) 20:44, 13 June 2012 (UTC)
I'm for it. You can't use <s> in a regular HTML document, though, so MediaWiki automatically changes it to <span style="text-decoration: line-through">. still semantically meaningless. But you're right. Per Wikipedia:Manual of Style#Italics, there's really no point in italicizing for emphasis unless you're quoting someone who used italics, or if there's a really, really important word. (Just be careful not to overdo it like how they put everything in all capital letters in some sections of legal contracts. It kills the joke.) 68.173.113.106 (talk) 21:18, 13 June 2012 (UTC)

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)

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

While I support the spirit in which this proposal was made, the sad truth is the individuals that most need the information are least likely to actually read any message. As explained by the Dunning–Kruger effect, "poor performers do not learn from feedback suggesting a need to improve.". Warnings that new articles need sources and that any new article not meeting Wikipedia's core content policies will be subject to deletion have existed for years and have shown no measurable difference in the volume of inappropriate submissions. --Allen3 talk 19:20, 12 June 2012 (UTC)
We already use salting to prevent recreation of some articles, and I can't create a new article without help. 68.173.113.106 (talk) 23:29, 12 June 2012 (UTC)


I'll make the message box more concise, per the recommendations of Wikipedians who have commented here:

I think it's focused and less discouraging to new but well-meaning editors, but I will leave the final determination of that up to the Wikipedia community. Wer900 • talk • coordinationconsensus defined 03:18, 13 June 2012 (UTC)

This idea goes against the prime principle of Wikipedia that "anyone can edit" and whom, may I ask, is going to make this determination about what new articles are good enough for creation? Opposes prime directive of Wikipedia. Mugginsx (talk) 11:59, 13 June 2012 (UTC)
Just wow! When I see these templates, all I see is a taunt, something like this: "So, you think you can edit Wikipedia? There's no way you can become a Wikipedia editor unless you've already been one for ears. These are just a fraction of all the rules you have to follow. Are you up for the challenge. You will slip up and make a mistake, and then we'll be there within minutes and revert or delete everything you did. And that's nothing less than what you deserve, f**n' newbie. We don't want you here!" — Preceding unsigned comment added by Coffeeshivers (talk • contribs) 15:58, June 13, 2012 (UTC)
"[...] whom, may I ask, is going to make this determination about what new articles are good enough for creation?"? Well, I guess that all of us, the community (or, to the different extent, the administrators, to whom this "authority" has been delegated), can (and do) during deletion discussions and the like...
But, while it doesn't seem right to say that this proposal "[o]pposes prime directive of Wikipedia.", it is not a good proposal. For example, what if the user is trying to create a redirect? Nothing that is listed applies.
It is also misleading to imply that speedy deletion is going to be used if the article is not written neutrally. It isn't (unless the article is an "attack page").
Furthermore, the users who are sufficiently careful will find the relevant policies anyway. And the users who are not careful are less likely to read the instructions, when they are already going to create an article. However, there was a similar proposal for instructions while creating the account: Wikipedia:Village pump (proposals)/Archive 87#Explain at account creation time what Wikipedia is NOT for. It might be worth reading. --Martynas Patasius (talk) 19:43, 13 June 2012 (UTC)
I disagree with this reasoning. Many first-time editors are unaware that Wikipedia even has policies or guidelines, and do not know about user talk pages. As a new editor, I definitely did not. By the way, I am not making the determination of suitability, it's all based on policy and precedent. You can't just flippantly say that they will "find the relevant policies and guidelines" if there's really nowhere they can find it until it's been told to them somehow. One cannot understand the law of a foreign country until he has access to it, and access implies that one knows such laws exist. Similarly, when new editors do not know that policies and guidelines exist, their pages are speedily deleted and they leave. Wer900 • talk • coordinationconsensus defined 20:22, 13 June 2012 (UTC)
That's why I said it is "users who are sufficiently careful" that "will find the relevant policies". Some users are "careful", some are "bold". If you didn't look for the policies or otherwise investigate how Wikipedia works, then, I guess, you can be safely described by word "bold". I know I did start by such investigation (that might have taken more than a week - perhaps significantly more) and did find the policies rather easily - I guess I could be considered "careful" (maybe too "careful").
Also, about users who "do not know that policies and guidelines exist". That might be solved by the proposal I mentioned: at the time of registration the user's attention is not distracted by the article he's writing. Thus it seems more likely that the messages will be read at that time, rather than at the time of writing... --Martynas Patasius (talk) 22:10, 13 June 2012 (UTC)
Well for a start, if you're going to go down this path you're going to have to speak the language of a newbie (Does this include: teenager? internet-age kid? short attention-span? Usage of short/sharp words?) Perhaps something like:

--Coin945 (talk) 23:38, 13 June 2012 (UTC)

👍 Cool -- Toshio Yamaguchi (tlk−ctb) 12:52, 15 June 2012 (UTC)
Still too long. The notice on Uncyclopedia just says, "Pages about yourself, your friends, your teachers, etc. will be deleted on sight." It works to enforce WP:Notability.
I got one:
68.173.113.106 (talk) 16:01, 16 June 2012 (UTC)
I like yours the best, as it is most accessible to newbies who just want to create an article. Also, this *could* be implemented in conjunction with displaying a similar message on account creation. However, I would like to modify your proposal to add more information:

Good? Wer900 • talk • coordinationconsensus defined 20:16, 16 June 2012 (UTC)

Change "Arbitrator" to "Arbiter"

"Arbiter" has been suggested to replace "arbitrator".
Not to be confused with the arrr biter.

Not sure if this has been proposed before. While both forms are correct, an arbitrator refers to a private contractor that parties hire to settle a dispute, while an arbiter is appointed by an organization or government to interpret and uphold its policies. In Wikipedia terms, the former sounds more like mediation, while the latter seems to fit better with our arbitration. Plus arbiter sounds cooler. Equazcion (talk) 19:28, 13 Jun 2012 (UTC)

I agree with this reasoning, but I would like to add something. "Arbiter" avoids many of the redundancies which come with arbitrator, redundancies similar to those found in transportation. It will be shorter, simpler, and cleaner to give them the title "Arbiter." — Preceding unsigned comment added by Wer900 (talk • contribs) 20:16, 13 June 2012‎
This makes sense. I'd support it. Reminds me of StarCraft, though. If we make this change, pretty soon we'll find out we can't make any more articles on Wikipedia because we must construct additional pylons. elektrikSHOOS (talk) 20:20, 13 June 2012 (UTC)
Support per Equazcion's reasoning, sums it up perfectly. Theopolisme TALK 23:48, 13 June 2012 (UTC)
Oppose The ArbCom is supposed to be arbitrators and not arbiters. That is, they are meant to be a last resort to establish binding solutions to long term disputes and disruptions. They are not supposed "interpret and uphold policies". The group charged at Wikipedia with doing that is called "the entire community". --Jayron32 03:14, 14 June 2012 (UTC)
Oppose, since the whole "arbitration" thing is a misnomer anyway, tweaking the details of the jargon like this brings no benefit. Let's just face it, "arbitration" is simply not what these guys are doing, be it as "-ter"s or "-trators". Fut.Perf. ☼ 06:18, 14 June 2012 (UTC)
"trators"... hah. Choyoołʼįįhí:Seb az86556 > haneʼ 07:56, 14 June 2012 (UTC)
Now that I think of it, we should make it a rule to refer to them alternately as "'biters" and "'traters". Purely in order to take the "arbitrary" back out of the arbitration. Fut.Perf. ☼ 08:15, 14 June 2012 (UTC)
Maybe "taters"? Next topic; what colour do we pain the bikeshed (I vote sky blue pink) --Errant (chat!) 09:00, 14 June 2012 (UTC)
..what's that, traitors, you say!? Jersey Royal Admins, surely? Martinevans123 (talk) 10:27, 14 June 2012 (UTC)
Support, plus, extra support if you can add a 'se' in there somewhere (I am living dangerously) Penyulap ☏ 12:56, 14 Jun 2012 (UTC)
I see what you did there. elektrikSHOOS (talk) 03:57, 15 June 2012 (UTC)
  • Oppose – This is Wikipedia, not Halo. --MuZemike 15:17, 14 June 2012 (UTC)
    • No, this is Sparta. It's funny how the word conjures different things for different people. So far we have Starcraft and Halo. Mine is Star Trek, when Picard was appointed "Arbiter of Succession" for the Klingon thing. All references seem to point to sci-fi though, which I think will likely appeal to Wikipedia's primary fan base. Just saying. Equazcion (talk) 17:23, 14 Jun 2012 (UTC)
  • Oppose. This proposal is based upon the incorrect premise that "an arbitrator refers to a private contractor that parties hire to settle a dispute". That's a specific type of arbitrator, sometimes referred to as an "independent arbitrator". The word "arbitrator" simply means "a person chosen to decide a dispute or settle differences, especially one formally empowered to examine the facts and decide the issue" (source: Random House Dictionary via Dictionary.com).
    While "arbiter" can be synonymous with "arbitrator", it also can mean "a person having complete control of something" (source: Collins English Dictionary via Dictionary.com). As noted above, an ArbCom case is a last resort when the community is unable to resolve a long-term problem. I see no reason to adopt terminology subject to the misinterpretation that the Arbitration Committee is intended to have "complete control of" the English Wikipedia. —David Levy 16:04, 14 June 2012 (UTC)
    Right, but when an "arbitrator" is appointed by an organization and settles disputes based on its policies, they're referred to as "arbiters" instead -- regardless of what else "arbiter" can mean. Equazcion (talk) 17:16, 14 Jun 2012 (UTC)
    Not in arbitrations of legal disputes. Disputes are arbitrated by arbitrators -- see http://www.adr.org/ for example.--ukexpat (talk) 17:28, 14 June 2012 (UTC)
    Yeah that's the point -- outside of court, if parties agree to hire someone to settle a dispute (the service that site is about), they're hiring an arbitrator. When you can't/won't settle and are forced into appealing to a body that determines what the organization's policies indicate must happen, you're dealing with arbiters. Equazcion (talk) 17:33, 14 Jun 2012 (UTC)
    The terms "arbitrator" and "arbiter" often are used interchangeably. The distinction that you describe exists in certain contexts, but it's an arbitrary convention with no bearing on the words' definitions and no relevance to Wikipedia. The site's editors don't share a common professional background whose jargon is familiar to them, so it's best that we use the clearest, least ambiguous terminology possible.
    The designation "arbitrator" is correct and causes no apparent confusion. You propose that we switch to a term that's equally correct but also carries an unintended connotation likely to mislead users. How would this be an improvement? What problem do you seek to solve? —David Levy 18:09, 14 June 2012 (UTC)
    Honestly the reason was that I don't like the word "arbitrator". It seems like it was formed fallaciously from "arbitration" and became accepted through use. As someone made reference to above, it sounds to me like "transportator", when one who engages in transportation should be a "transporter", just like one who engages in arbitration should be an "arbiter" (not an "arbitrator"... it just sounds wrong). But you're right, it's just a push for pedantic accuracy on my part, and would really make no difference in practice. Equazcion (talk) 00:01, 15 Jun 2012 (UTC)
  • Opppose, per David Levy. It's not been shown to be needed or useful. And it is confusingly similar to the German word for "worker". ~ J. Johnson (JJ) (talk) 18:02, 14 June 2012 (UTC)
  • Oppose at best, this is change for the sake of change. At worst, it's downright confusing/misleading. Due to its use in fiction, "arbiter" has unpleasant connotations of galactic despot types. "Arbitrator" sounds more contemporary and businesslike. Andrew Lenahan - Starblind 19:28, 14 June 2012 (UTC)
  • Oppose. "Arbitration" is not a perfect term for the process the Committee uses to decide cases, and quite a lot of the Committee's work is doing things other than deciding cases. Nonetheless, "arbitration" is as good a term as any other I can think of, and it also established by eight-plus years of usage on the project. And a person who resolves an arbitration is most commonly referred to an arbitrator. The Committee has made an effort in recent years to use less legalistic language in its policies and decisions, but I don't think the word "arbitrator" is avoidable. Newyorkbrad (talk) 20:59, 14 June 2012 (UTC)
  • Neutral Regarding "it's cooler": Arbitrator sound a bit like Terminator and that is cool as well, despite some of them might already feel like that :) Petrb (talk) 14:48, 15 June 2012 (UTC)
  • Oppose "Arbiter" sounds too much like "tirebiter." And they do not "arbit." Edison (talk) 21:23, 15 June 2012 (UTC)
  • Weak support. "Arbiter" is a perfectly good word, and I regard "arbitrator" as misguided polysyllabification, much like using "incentivize" for "incent". However, I recognize that it doesn't really matter because modern use has already thrown good vocabulary down the memory hole. ~ Ningauble (talk) 16:39, 16 June 2012 (UTC)
    • I have to note though that arbitratificationism rolls of the tongue more easily than arbiterificationism. So it goes. Regards, RJH (talk) 16:54, 16 June 2012 (UTC)
    • That's exactly why I suggested this, as I described above (minus your fancy terminology). The mutilated word friggin bugs me. But I think arbiterificationism is simply arbiterrific! Equazcion (talk) 16:59, 16 Jun 2012 (UTC)

Hello.

I feel that it is a good idea to have diff links automatically inserted to signatures which link to the diff of the post for easier verifiability of the post, without the tedious work of searching the page history manually.

For example, 69.155.128.40 (talk) 22:30, 15 June 2012 (UTC) will look like 69.155.128.40 (talk) 22:30, 15 June 2012 (UTC)

Please provide your feedback on this. Thank you. 69.155.128.40 (talk) 22:30, 15 June 2012 (UTC), modified 22:31, 15 June 2012 (UTC)

Why? If you've got the date, it only takes a few seconds to find the diff on those rare occasions when you want it. WhatamIdoing (talk) 22:33, 15 June 2012 (UTC)
Isn't it reasonable to make this easier? After all, we would like to make things as convenient as possible here. That's what improving the encyclopedia is all about. 69.155.128.40 (talk) 22:39, 15 June 2012 (UTC)
Isn't it reasonable for me to spend about five seconds looking it up manually about twice a week (and NB that I do far more of this than the average person), rather than taking the developers off of much more important projects to add this particular feature and thereby save me a whopping ten minutes a year?
The MediaWiki developer community is small. A couple hundred people, most of whom are volunteers with very limited time, do all the work. Why should their limited efforts be focused on this particular task rather than the hundreds of others? WhatamIdoing (talk) 22:54, 15 June 2012 (UTC)
Actually I think this is a very clever idea. The problem is, people go back for a second (or third or fourth) edit to revise their comments often, so the diff link as verification of the comment wouldn't be too reliable. Equazcion (talk) 00:15, 16 Jun 2012 (UTC)
Per my own customs, I re-sign my modified comments by placing a comma, then "last modified ~~~~~" (yes, with five tildes). Perhaps this can become a standard practice for all Wikipedians. 69.155.128.40 (talk) 00:36, 16 June 2012 (UTC), last modified 00:38, 16 June 2012 (UTC)
I don't see how you'll be able to convince 16,971,681 people to do that. 68.173.113.106 (talk) 16:14, 16 June 2012 (UTC)
We evidently convince that many people to sign their posts through guidelines, therefore, shouldn't we have an extra guideline to reduce confusion on modified posts? 69.155.128.40 (talk) 18:11, 16 June 2012 (UTC)
The signature is expanded before the revision exists, so there's no revision ID to link to. This feature would require a change in how MediaWiki saves revisions and I don't think it's really worth doing that. Reach Out to the Truth 02:04, 17 June 2012 (UTC)
Are the revision IDs predictable? They're kind of a mystery to me. But if they are, it could be done that way (grab the last one at expansion time and link to the one up next). I too have to doubt this will happen though, in any event. Equazcion (talk) 02:45, 17 Jun 2012 (UTC)
I'd say that that they are semi-predictable; it would be the lastest revision ID + 1, at least I believe. You could use this to calculate the revision that the signature should link to, and under the rare circumstance that a new revision happens to be created in that millisecond, or however much time it is, after the calculation and before the post, a bot could correct it. 69.155.128.40 (talk) 19:02, 18 June 2012 (UTC)

Delinking dates

I was asked to post this notice here and several other places. I have started a discussion at Wikipedia talk:Manual of Style/Dates and numbers#Delinking dates on delinking dates using an AWB bot. Input is always appreciated. Hmains (talk) 19:36, 17 June 2012 (UTC)

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)

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)
(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)
Well, you can make a private wiki that can transclude templates and images and such from another wiki. That might be a way to pull off some of that, though it's not exactly useful for folks who don't know what they're doing... -— Isarra ༆ 23:36, 21 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". --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. 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. 69.155.141.125 (talk) 19:16, 12 June 2012 (UTC)

This should be possible using mw:API:Parsing wikitext. Fut.Perf. ☼ 13:56, 13 June 2012 (UTC)

Is it possible to make some type of user-friendly interface to use this feature for those who do not have the technical skills? It would be nice to simply have a box such as the one we use on Wikipedia, with a Preview button. 69.155.128.40 (talk) 22:28, 15 June 2012 (UTC)

F9 CSD criterion

Hello.

A while back, when my IP address was different, I posted here to propose a merger of F9 and G12. It appears to be moving slowly, but is rather unopposed/supported. I would like to request additional input. Thanks. 70.248.178.6 (talk) 20:14, 20 June 2012 (UTC)

Both of these are codes for "Unambiguous copyright infringement". WhatamIdoing (talk) 19:18, 22 June 2012 (UTC)

An enhancement for the "Random article" feature

Well, I'd use it. Some thing on the order of a cycling random page (user selects time) selection, a new page every <n> minutes. But only if the computer (or just Firefox) has been idle <m> minutes. A screen-saver for the absurdly curious.

BG — Preceding unsigned comment added by AlStonyBridger (talk • contribs)

  • That's an idea for a third-party application, not for the Wikipedia website. - Mike Rosoft (talk) 23:06, 16 June 2012 (UTC)
  • I don't really see the point. If someone lets their PC idle for a long time, they're probably not going to read whatever's on screen. On the other hand, a screensaver that pulls random featured pictures and cycles through them would be cool. Andrew Lenahan - Starblind 02:09, 17 June 2012 (UTC)
Windows Vista and Windows 7 come with a screensaver option that cycles through pictures in a folder; if you have this sort of screensaver, you could download a bunch of FPs and put them all in the same folder. I've been using it for quite a while for this purpose. Nyttend backup (talk) 21:23, 18 June 2012 (UTC)
XP also can do this. - Purplewowies (talk) (How's my driving?) 18:46, 23 June 2012 (UTC)
  • Whoever would do it ... I wouldn't spend a lot of time watching it change (unless I'm "thinking about something"), but there'd be something different when I glance at the screen. That's indeed what I do with pix on W7. -- BG

Creating a new user-right group

New proposal. - jc37 17:07, 23 June 2012 (UTC)

Category:Births by year and Category:Deaths by year

Does anyone have a reason to significantly oppose the birth and death by year categories divided into month? Category:2012 deaths has over 2,200 deaths half way through the year and past recent years contain about 5,000+. We have articles like Deaths in January 2012, so why don't we have Category:January 2012 deaths as a sub-category of Category:2012 deaths? I'm not suggesting categories with a couple entries like year 1 deaths (Category:1 deaths) be split into 12 sub-categories, but rather ones with at least 100 entries to be split into months for navigational purposes. Splitting 5,000 death or birth entries to about around 400 per category would be useful, right? — Moe ε 20:42, 23 June 2012 (UTC)

The months aren't that important to users and aren't known in a large number of cases. WhatamIdoing (talk) 23:23, 23 June 2012 (UTC)
Are these really used as navigational categories? I've always viewed them more as metadata categories, akin to Category:Living people, and the benefits of grouping them together are thus a bit stronger in this case. I'm open to being persuaded otherwise, though... Andrew Gray (talk) 00:41, 24 June 2012 (UTC)
WhatamIdoing, I did a random sample of 100 deaths in 2012 on a category page with 200 on it and only 1 was missing both the birth and death months, while 3 other were missing only the birth month. Seems that the month is listed on a lot of them, rather than not. At any rate, I don't think that would inhibit us in putting [[Category:XXXX births]] and [[Category:January XXXX deaths]] if one month is unknown.
Andrew Gray, these two categories are unique case of both navigational and as a container category. They mostly serve as a container because of the on-going task of identifying living people and their dates of birth and such. They are navigational, just not very useful ones (which is why I was suggesting this). We have 102 months worth of articles where people navigate using a month. Granted, it's mostly Wikipedia years that have been accounted for because we detailed deaths and births at a rapid rate then, so it's only really useful to break down 2004 to 2012 based on that premise. Even if that was accomplished though, it would serve to benefit the 100+ articles that have been broken down by month and have their own article. — Moe ε 02:02, 24 June 2012 (UTC)
I'm not surprised that we have more detailed information for the very recent deaths, but most of our BDPs didn't die in the last six months. WhatamIdoing (talk) 03:12, 24 June 2012 (UTC)

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)

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)
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)
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)
Redlinks to plausible articles are a Good Thing. WhatamIdoing (talk) 16:24, 30 May 2012 (UTC)
...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)
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)
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)
see also one editor here Penyulap ☏ 00:07, 31 May 2012 (UTC)

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)

how come I can't disambiguate redlinks ? I am sure I created B.M.E. -> bachelor of mechanical engineering, and now it's gone. Penyulap ☏ 12:35, 14 Jun 2012 (UTC)
Who said you can't disambiguate redlinks? I am not sure I understand the second part of your reply. If B.M.E. is a redlink, like it is right now, and you place a redirect there, then it will no longer be a redlink. However, not every redlink should be a redirect, some should be proper articles. -- Toshio Yamaguchi (tlk−ctb) 11:41, 15 June 2012 (UTC)

Oppose. Per the discussion above, redlinks are of great value and users IMO should be encouraged to create them and should not be admonished when they do. --Tagishsimon (talk) 12:59, 14 June 2012 (UTC)

perhaps Oddbodz can edit the common.css in their own userspace to turn red into blue, or turquoise even. Graeme Bartlett (talk) 13:26, 14 June 2012 (UTC)

Slight oppose:Not all users create redlinks by mistake. Also, redlinks should not be visualized as bad. Suppose that someone enters into a page with red links (say minerals). He might be knowledgeable about minerals. If he is, he may decide to create the article. Please note that searching in Requested articles to create an article is quite distracting and many users may not even visit there. A knowledgeable user who finds a redlink in a page and feels interested will create the page. Note that the presence of redlinks in an article or directory will remind as that we are still not complete and has a lot to do to reach our goal. It gives inspiration to contribute more to Wpedia
The project to which you belong named WikiProject Red Link Recovery, (which is currently active and having a page for articles with most red links) is helpful in removing unnecessary redlinks. The participants may find many users who create unnecessary redlinks. In that case, those users, who contributes unnecessary redlinks, must be informed. All these users, whom you would be informing will be assuming good faith, so that they deserves to be informed of their mistakes. It should not be a warning as it may make him disappointed/frustrated and he may loose interest in contributing to Wpedia. (To me, contributing is more boring and takes much energy than fighting vandalism and participating group discussions). The result would be an encouragement to the current decline in no. of active users!
So, if you are proposing a friendly comment for users who contributes unnecessary redlinks, then I cannot find any reason to oppose your proposal. But the real problem with this would be the side effects. Either the user may stops contributing (useful) redlinks or he will not contribute at all. Also, those who is in charge of informing must know that redlinks are useful and should not instinctively hate redlinks. Vanischenu mTalk 11:19, 22 June 2012 (UTC)

Do we have statistics? Blue/red ratio by topical category and year made, rate of converting red to blue, who creates the most red, who blues the most, etc? Jim.henderson (talk) 11:45, 22 June 2012 (UTC)
  • Support - honestly...apart from Wikipedians, who would take time to create an article themselves? Most visitors to Wikipedia are not editors and this gives a bad impression. (Of course if that Wikipedian really wants to create that article...chances are s/he has already done it.) Either that or the end result would be a short, incomplete stub. CyanGardevoir (used EDIT!) 03:30, 27 June 2012 (UTC)

media enrichment

Port Wikipedia to YouTube. Mention a song, movie, incident, click on the blue link and go straight there. Upon conclusion of the video, go back to the Wikipedia article. — Preceding unsigned comment added by 70.112.3.200 (talk) 10:42, 21 June 2012 (UTC)

To a certain extemt, we already do. Where there's a very good reason to link to a yuotube video, we will do so. HOwever we don't tend to link to songs and movies since we have a policy of not linking to copyright violations - and I suspect many songs on youtube are there without permission. I think you'd have to refine your suggestion greatly before you got any traction. WP:EL might be worthwhile reading. --Tagishsimon (talk) 13:09, 21 June 2012 (UTC)
With a few notable exceptions -- see http://www.youtube.com/vevo. --SarekOfVulcan (talk) 19:51, 22 June 2012 (UTC)
  • youtube has an unacceptably high level of link rot to be very useful as links from Wikipedia. It seems like when I bookmark something on Youtube, half the time it isn't there even a week or two later. I'd imagine things like songs and movies go away even more quickly. There's also the trickly legal situation of linking to things of dubious copyright status. Andrew Lenahan - Starblind 21:35, 26 June 2012 (UTC)

WP:Community portal: rethink and redesign?

As you may or may not know, we have a page called the Community portal in the Wikipedia namespace. It's linked to from the sidebar, which means that a link to it appears on every single page on Wikipedia. It gets about 10,000 views per day. However, judging by the comments of the few Wikipedians I've talked to so far who actually use it, I haven't been able to discern the purpose it's currently serving. Is it intended to be a place for new editors? Current editors? Readers/potential editors?

Right now the page is filled with links and templates that cover all three of the aforementioned use-cases, many of the links there are old/outdated, much of the content seems to duplicate other pages (like Help:Contents and WP:Directory), and the bot that was updating the open tasks list stopped running in February of this year, so the tasking is all going stale. Given the high-value real estate this page is currently occupying, I really think it could stand a significant rethinking and redesign. But in order to avoid a "shuffling the deck chairs on the Titanic" kind of situation, I'd really appreciate it if you folks could give me a sense of:

  1. ... what people are currently using this page for (if anybody's using it at all)
  2. ... what they think is the intended audience (readers, newbies, established editors, all three?)
  3. ... and what they'd ideally like to see there

If you have thoughts on this, could you please respond here or on the discussion I just opened up on the talk page of the CP? (This isn't a formal proposal or RfC quite yet; I just want to get some fresh eyes on this forgotten corner of the wiki, and hopefully also get some inkling of what direction we should proceed in.) Thanks in advance for your help :) Maryana (WMF) (talk) 20:55, 26 June 2012 (UTC)

Template:Talk header

User:Faizanalivarya has added Template:Talk header to a large number of talk pages, including ones where no discussion has ever existed. This has been discussed on User_talk:Faizanalivarya#Talkheader. I would like to propose no large scale adding of this template be done to articles where there currently is no discussion, and the only content is existing project pages. --LauraHale (talk) 21:22, 16 June 2012 (UTC)

Dear Laura and all fellow Wikipedia friends, With all your due respect, I highly appreciated your certain concern however I would like to inform you that according to Wikipedia Talk Pages Guidelines which you may look at Fixing layout errors, Its nothing to do with article its just for layout and its good to be on page as it inform other new editors who are coming on page, to focus on given below things
  • Be polite,
  • welcoming to new users
  • Assume good faith
  • Avoid personal attacks
According to you, there should not be a Template:Talk header in any newly created article or articles where there is no discussion held, means you believe in that any article without any discussion would not be discussed? and would not have discussion ever? well that does not make any sense as I said, It should on every article in order to avoid any personal attack, hate speech or negative talks, as being a responsible Wikipedia Editor we should have good faith on fellow Wikipedia contributor, that what all i have to say, now I hope people should support it, what do you think now?--Faizanalivarya (talk) 21:39, 16 June 2012 (UTC)

I may have proposed this in the past, but if it is standard and expected to have a talk page header on every talk page, why don't we use a MediaWiki default that would appear on every talk page? To me that makes more sense than jamming a template on each and every talk page and would reduce clutter as far as wikitext on the talk pages are concerned. --MuZemike 23:07, 16 June 2012 (UTC)

Making a MediaWiki change would be the better option, just not by much. In the meantime I don't see adding the template en masse as any particular problem. It's a pretty tiny piece of code. I'm not sure where the "jamming" comes in... I mean aside from making it sound bad, what practical problem does that describe exactly? :) But yeah I'd be all for a MediaWiki interface change, no reason not to that I can see. Equazcion (talk) 00:26, 17 Jun 2012 (UTC)
There are several settings that can be used with the talk page header to do various things, afaik there is no way for non-admins to configure mediawiki on a page by page basis. That would mean we would need to move that functionality into a new template, and place it on every talk page. Also, not all talk space pages are actually talk pages, in article talk space there are things like GAN reviews that shouldn't get the header, any many things wikipedia talk, is it possible to only have the banner appear on talk pages, but not subpages in the talk space? Monty845 00:56, 17 June 2012 (UTC)
We would have to handle the parameters with a template, yeah, but we wouldn't need to put it on every page -- only those that we want to deviate from the default. In fact, the present template could be re-tasked for that function -- it would no longer activate a talk template itself, but any parameters specified with it would affect the default one that's in the MediaWiki interface. That way, when this change were implemented, no bots would be needed to go around removing or replacing it. Equazcion (talk) 02:37, 17 Jun 2012 (UTC)
Keep in mind that, just as the MediaWiki namespace can only be edited by admins, Template:Talk header is likewise full-protected as a highly-visible template. Nothing would be gained or lost in this case if something like this was implemented. --MuZemike 21:41, 21 June 2012 (UTC)
@Faizanalivarya: People who engage in personal attacks, hate speech or "negative talks" will do so whether or not there is a talk header template on a page. Most people will just see it as another wall of text and skim straight past it. Forcing your own view of how talk pages should be laid out by mass-editing is not on. Graham87 05:58, 18 June 2012 (UTC)
You guys are right, I will certainly take of that and I am agreed Graham that its like forcing my own view of how talk pages should be laid out , I will take care of that, and put talk header only where its required, I hope you all appreciate it.?--Faizanalivarya (talk) 13:48, 18 June 2012 (UTC)

How about only having a MediaWiki default message on all Talk pages that are not subpages? And, if for some reason, a talk header should not be included, a template could be used to "hide" the default heading, which I would think would occur less often. --MuZemike 21:09, 21 June 2012 (UTC)

  • I strongly agree with MuZemike's statement. If a MediaWiki default isn't changed, I have long felt that every talk page should have a talk header. How are we to expect normal readers to understand the purpose of a talk page? Ryan Vesey Review me! 21:19, 21 June 2012 (UTC)
    We have a default message on talk pages now. It says "This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes (~~~~)." What more do you want it to say?
    Myself, I'd support a bot that removed all instances of talkheader on pages with no discussions. Spamming it everywhere turns it into the background, and then people will look right past it. WhatamIdoing (talk) 19:15, 22 June 2012 (UTC)
That message appears on the edit screen. What I am talking about is having a talk header displayed by default on all talk pages before you go to edit the page. --MuZemike 21:22, 22 June 2012 (UTC)
  • Limit use of talk header template This template should only be placed on pages where users have already failed to follow the guidelines. If you put signs everywhere, people simply ignore the signs, and thats true of overused template messages as well. D O N D E groovily Talk to me 12:33, 27 June 2012 (UTC)

There is currently a proposal at "Featured picture candidates" to rephrase and modestly increase the minimum size requirements of new featured pictures. Please join the discussion at Wikipedia talk:Featured picture candidates#Proposal to change size critiera. -- Colin°Talk 12:03, 27 June 2012 (UTC)

RfC on user warnings

Hi all, just a heads up that there is a new open RfC on the level one user warnings, based on the work done at WP:UWTEST. Please join in, especially if you're a vandalfighter or member of WikiProject user warnings. Thanks, Steven Walling (WMF) • talk 18:14, 27 June 2012 (UTC)

Authority Control Integration

Main page: Wikipedia:Authority control integration project

I am Max Klein the Wikipedian in Residence for non-profit member cooperative OCLC. There is a template {{Authority control}} which is in use on 4,000 pages to link to VIAF. We've determined ~260,000 more where the template would be useful with the corresponding VIAF number. This project and template serve the educational goal of linking more information about Creators. VIAF contains information that is not currently on the encyclopedia but would be useful if a reader wanted to learn more about their publishing history and preferred name forms etc. Are there any objections before we undertake the effort to write a bot add this template?

  • I certainly would not object to this being added via bot, as Authority Control seems to be to artistic and literary works as the digital object identifier or the bibliographic code are to academic papers. We already have a bot which adds DOIs and bibcodes to articles, and the only reason it's not a true "bot" right now is because it is activated by a user on each page, but upon this activation it works automatically (Users have to clean up after it, of course!). The only reason this arrangement is used is because some bugs in the bot need to be ironed out. I suggest that you start with the user-activation model before moving on to a true bot. Wer900 • talk • coordinationconsensus defined 18:45, 18 June 2012 (UTC)
Just to be sure, your objection to the bot lies in the uncertainty of it's technical soundness? Maximiliankleinoclc (talk) 18:43, 19 June 2012 (UTC)
Yes. Wer900 • talk • coordinationconsensus defined 03:21, 26 June 2012 (UTC)
  • I think of the objective of adding 260k {{Authority control}} templates to articles is a great idea. It is very helpful with disambiguation and allows access to great number of databases with additional information about the person. --Jarekt (talk) 18:54, 18 June 2012 (UTC)
  • Will VIAF numbers be persistent enough for that purpose? As I understand, in the past they sometimes have been a bit unstable especially in cases of lesser known persons where VIAF participants had incomplete information and their respective records could not always find together? -- Gymel (talk) 19:10, 18 June 2012 (UTC)
You are right in an academic sense, that each time VIAF updates some source records can move to different clusters. The URIs are mostly very persistent, and to find a full summary on the topic you can read The lead scientist's explanation. Maximiliankleinoclc (talk) 18:43, 19 June 2012 (UTC)
  • Strong support for adding VIAF inks using {{Authority control}}. At some point, it would be good to look at including the links in infoboxes, so that they can be part of the emitted metadata, but that's a separate debate. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:20, 18 June 2012 (UTC)
  • I was asked to comment here. I don't have much to add other than to say that you should be sure to use a flexible template that will work well and not require 250,000 edits more than once. In the past, sometimes people don't do enough prior planning and end up having to iterate over the full data set multiple times, which is nasty and a waste of resources.
    Broadly, putting this data into the page's wikitext is just about the nastiest way to store it, at least in the short term. If/when Wikidata comes along, this might get better. But as an intermediary step, it's awful. Putting the data into the article wikitext means not storing the data in a queryable manner. That is, any time you want to pull the data, you'll have to download the wikitext of each page and parse it (or download a dump and scan it). If there are additional time and resources available, it'd be nice to use the page_props database table and a parser function in an extension for this, in my opinion. Something like {{#authority control:foo}} or {{#viaf:foo}}. Then the MediaWiki parser could catch this parser function on page save and store the associated data in the page props table so that the data can be easily queried. --MZMcBride (talk) 19:53, 18 June 2012 (UTC)
  • Well, democracy also "works," but I wouldn't use it to store data like this. I imagine the Germans are doing database dump scans. (You should research how the data is extracted, to be sure.) Using database dumps for something like this is rather awful. You want something structured and queryable (it's 2012, for God's sake). I guess you all are just hedging your bets on Wikidata here? --MZMcBride (talk) 23:21, 18 June 2012 (UTC)
  • Regarding a db table, would this be scalable in the event of using other authority control mechanisms? VIAF is a union system, but it's only one of many - potentially in the future we could be using multiple independent AC systems for different groups of articles, with some pages having two or three overlapping identifiers. Andrew Gray (talk) 21:13, 18 June 2012 (UTC)
  • It'd be scalable if you normalized the data, sure. You'd have something like this:
pp_page | pp_propname            | pp_value
12      | authority-control-gnd  | 16
12      | authority-control-viaf | 2343
35      | authority-control-viaf | 213423
49      | authority-control-lccn | 1109
  • This is just an example. For something this specialized, you'd probably want your own database table. It would make it easier to do things such as index pp_value, which is a blob in MediaWiki's database schema. And I'm guessing you'd definitely want the values indexed (so that you can do lookups such as "find every book using this VIAF ID number"...).
  • I guess it'd be helpful to judge this if there were more information about how you intend to extract, for example, every article using a particular VIAF number in your proposed system. Looking in on this, it screams of "you'd use a database for this." But given that you're going in the direction of storing this in the wikitext, I'm curious what comes next. --MZMcBride (talk) 23:21, 18 June 2012 (UTC)
I entirely agreed. This data integration should be done in a more flexible way. I'd like to stress that if you read the full proposal that this is only single phase of many. In the end we are planning for WikiData integration. I have been in contact with WikiData and active on the mailing list. Although it's not full defined yet, item properties one would imagine would be extrated from the text (at least where templates are called with parameters). If this didn't happen it would mean recontributing the entirety of structured text in all of the Wikipedias again, which would make this integration rather insignificant. And besides DBpedia already does extract data from WP, so at least to concept has been proved that it could occur in WikiData. Maximiliankleinoclc (talk) 18:43, 19 June 2012 (UTC)
  1. When the template says "At the moment, it is used almost exclusively in biographical articles." What are the exceptions, and is the exception rule bot-interpretable? If we want to have 300000 links and keep them consistent, bot maintenance is going to be important. Stuartyeates (talk) 20:27, 18 June 2012 (UTC)
  2. Should VIAF work with Works of Rabindranath Tagore or Rabindranath Tagore ? William Shakespeare or Shakespeare's plays ? (or both?) Stuartyeates (talk) 20:27, 18 June 2012 (UTC)
It should always be the creator page, that is the subject of VIAF. Maximiliankleinoclc (talk) 18:43, 19 June 2012 (UTC)
  1. Who does VIAF consider to be the author(s) of the Christian bible, the Quran and the Biblical apocrypha? Have you written bot rules around these issues and to handle pages currently under sanction of various types? Stuartyeates (talk) 20:27, 18 June 2012 (UTC)
    I am not Max, but I worked with him on this proposal and hopefully he won't mind me leaping in :-) As I envisaged it, authority control metadata in this form should be like {{persondata}} - at least for now, people and only people. Not daughter articles, not specific works, not related topics - each identity should only match a single page. So #1 may involve some standardisation of where the template is used and what it's used for; #3 is relatively academic, as we won't be tagging the Bible, thank [anonymous author] ;-) Andrew Gray (talk) 21:03, 18 June 2012 (UTC)
    Since non-person-authors are in VIAF (see [1]) and the template is only going to be used for person-authors, the template needs to contain some text/warning about this. Stuartyeates (talk) 21:38, 18 June 2012 (UTC)
That seems reasonable enough Maximiliankleinoclc (talk) 18:43, 19 June 2012 (UTC)
  1. We have Category:Document forgeries, but no systematic way of identifying person-authors associated with such forgeries, fabrications and mistaken authorships. My understanding is the VIAF follows the AACR2 approach of documenting the work in hand rather than the scholarly consensus (as wikiepdia does). Is there a plan for dealing with these discrepencies? Stuartyeates (talk) 21:38, 18 June 2012 (UTC)
    Why would you? This is a really minor quibble. Wikipedia's role is to rely on the sources, as you say, but that doesn't mean we should only point to references that conform to our own content policies. Dominic·t 16:16, 19 June 2012 (UTC)
    It's not a question of only pointing to references that conform to our own content policies. It's a question of being sufficiently clear in the template and associated documentation that bot operators can run bots that don't screw things up. Bot operators need to know a lot more about how the VIAF works than is current on the template page. Stuartyeates (talk) 19:46, 19 June 2012 (UTC)
    "At the moment, it is used almost exclusively in biographical articles." - I wrote that back when I created Wikipedia:Authority control, because back then the template was used almost only on biographical articles (at least here on the English WP). I wanted to change that sentence for some time now, but totally forgot about it. Of course the template can be used on articles about any other topic where corresponding authority records exist. Over on the German Wikipedia, it's also used for corporate names (companies, bands and all kinds of other organizations, e.g. de:Bodleian Library), geographic names (de:Amerikanische Jungferninseln), works (de:Troilus und Cressida), events (de:Centennial Exhibition) and index terms (de:Messerschmitt Bf 108). --Kam Solusar (talk) 09:48, 19 June 2012 (UTC)
  1. VIAF seems to have the Western library scene covered (USA, Europe and English speaking oceania), but I'm seeing a complete lack of participation from China, Japan, Korea, Thailand and the entire Muslim world, wouldn't we be better to wait for a more comphrensive library consortia? I'd not be keen on having to add another 300k links with a different scheme to those libraries. Stuartyeates (talk) 20:27, 18 June 2012 (UTC)
  2. VIAF is very library centric, wouldn't we be better to wait until the EAD-speaking world (i.e. archives) was included too? I'd not be keen on having to add another 300k links with a different scheme to archives. Stuartyeates (talk) 20:27, 18 June 2012 (UTC)
    • I don't really understand either of these two suggestions. We'll be waiting for a long time before we get a single comprehensive international authority file of all the world's libraries and archives. It's an evolving field, and we would do better to progress with it, rather than just wait around. If other authority files would fill in holes in VIAF's records, there is no reason we can't add them, as well. Dominic·t 16:16, 19 June 2012 (UTC)
      • Max and I originally talked about using ISNI, which is VIAF + lots of other stuff (including a very good chunk of material on performers). However, it won't be practically useful for some time yet, and "perfect is the enemy of good" - we can always "merge up" into a larger, more comprehensive file when one comes into existence. Andrew Gray (talk) 22:22, 19 June 2012 (UTC)
  • Strong support for the idea. The better we link up with established forms of metadata, the better. And since this is Worldcat-related, I don't think that we should hesitate to implement based on hopes for a more comprehensive consortium. Per WP:ELYES, it's generally good to provide links to "Sites that contain neutral and accurate material that is relevant to an encyclopedic understanding of the subject and cannot be integrated into the Wikipedia article" for whatever reason, and a major authority file sounds like a good example of that situation. My only hesitation comes on the practical implementation side; I don't know how familiar you are with the coding, but I know I'm definitely not sufficiently familiar with it. Have you already talked about the implementation side with someone who's familiar with bots or other technical elements of the process? Nyttend backup (talk) 21:21, 18 June 2012 (UTC)
I have some proficiency. Also I've spoken with user:dcoetzee (mainter of the mwclient documentation) and user:slaporte (renound bot enthusiast) and both have agreed to help write and test the bot.
In that case, I have no more hesitation. Strong support. Nyttend (talk) 00:52, 20 June 2012 (UTC)
  • Strong support for the idea. Very good idea, especially for people to be able to identify persons whose names are spelled in different ways. Very important also to find books written by and about Russian and Arabic (and other!) authors. My proposal would be to have this order: 1. WorldCat, 2. VIAF, 3. LCCN and then 4. GND. Why? Because WorldCat gives most added value (book titles, timeline), VIAF gives alternative names, Library of Congress is concise and GND is trustfull. Best, JosephDamen (talk)
  • Sounds great. James F. (talk) 22:07, 18 June 2012 (UTC)
  • Better template documentation. I don't have the background to know if this is a good idea, but if it is done, the authority control needs better documentation. If an editor sees that template appear in an article and goes to the template to see what it is, the editor will have to look on several pages to get the general idea that it is a library catalog entry devoted to one person, and has something to do with helping librarians keep track of authors with similar names. Jc3s5h (talk) 22:23, 18 June 2012 (UTC)
  • Sounds very desirable but serious planning is needed with plenty of time for community discussion on specific examples, and trial runs with more time for discussion. Need to plan how a bot can verify/update the data. How can the data be maintained (what happens if a user or IP changes a value)? Johnuniq (talk) 03:26, 19 June 2012 (UTC)
We don't normally safeguard data at the template transclusion level. There is a good point that in rare occassions people shift around VIAF UIDs so there will need to be maintenance that is run periodically. I think VIAF is refactored once a year, so we can run the diff's as often as well. Maximiliankleinoclc (talk) 18:43, 19 June 2012 (UTC)
  • Strong support. I've waited a long time for the English WP to adopt this on a large scale. --Kam Solusar (talk) 09:48, 19 June 2012 (UTC)
  • Strong support. Ironholds (talk) 13:54, 19 June 2012 (UTC)
  • Support I have had the privilege of talking to Max Klein about the Authority Control Project and I would like to support both this project to add the {{Authority control}} to as many relevant articles as possible and for Max Klein personally to be the person who can organize this effort. Connecting Wikipedia content to external existing databases is a dream project which Wikipedia has been lacking and this project, if successful, will be a major accomplishment. This proposal starts with a simple template; I assert that the Authority Control template is an uncontroversial useful addition. There is almost no chance of harm if something goes wrong. This project will set a precedent for great and amazing things.
User:MZMcBride shares the same concern I have - Wikidata is trying to do this same thing and with more architecture. Unfortunately, their solution is years away. I know that 250,000 edits is a lot but I have no access to evidence which indicates that this is burdensome, and my totally unfounded guess is that the benefits I understand probably outweigh the costs which I cannot estimate and do not understand.
User:Gymel, User:Stuartyeates, and User:JosephDamen all have expressed concern that VIAF is not sufficiently inclusive and perhaps is unstable. I agree with all of them, but I still think that this is the best possible solution which can be had now.
I second User:Jc3s5h's request for more documentation on the authority control template. Blue Rasberry (talk) 14:34, 19 June 2012 (UTC)
User:Kam Solusar can you update the documentation as you've already mentioned that you wrote it originally and have intended to update it for some time? Maximiliankleinoclc (talk) 18:43, 19 June 2012 (UTC)
I updated Wikipedia:Authority control a bit. I hope this already helps. However, the beauty of the concept and the many possibilities don't really emerge from the text, I'm afraid. E. g. the BEACON/SeeAlso technology is just great, and look what you can achieve just by entering a GND number and let the BEACON files do the rest: http://beacon.findbuch.de/seealso/pnd-aks?format=sources&id=118540238 or http://beacon.findbuch.de/seealso/pnd-aks?format=sources&id=118520539 --AndreasPraefcke (talk) 13:04, 20 June 2012 (UTC)
  • I support addition of the authority control template to as many articles as possible, but note that there are names in the big list above that have already had the template added. --SarekOfVulcan (talk) 14:48, 19 June 2012 (UTC)
I acknowledge that there are preexisting uses of this template, and the bot would check to see if the template was already in use before adding. Maximiliankleinoclc (talk) 18:43, 19 June 2012 (UTC)
  • Support, but not VIAF-only. Actually, VIAF is the least "authorative" of any of the "authority files", since VIAF tends to change its clusters a lot, and frequently redirects to newly found clusters; and since it is a machine-driven file without the "authority" of human review. A bot run of 260,000 edits should at least include the corresponding LCCN number in the template. Before the automatically generated list of VIAF identifiers is added, those articles that have interwiki links to de.wikipedia should be checked first and the VIAF and LCCN numbers that are stored there should be given preference over the "big file", since they are handpicked by real people. --AndreasPraefcke (talk) 16:38, 19 June 2012 (UTC)
This is a good point. It would substantially increase the complexity of the bot, from trivial to difficult. I will ask around about the feasibility of this. This can also be done in a maintenance phase. And it would also be a good test to see with what accuracy the English/German data matches. Maximiliankleinoclc (talk) 18:43, 19 June 2012 (UTC)
Copying from de.wp is a good idea and it has been brought up before. There is no reason one has to be done before the other, though, and I'm not sure why to complicate things like that. Dominic·t 20:27, 19 June 2012 (UTC)
I think it is indeed crucial to do the copying before the "big" bot run. It is not even complicated, and has been done in large scale on the Commons before. VIAF data is actually quite bad, since machine-driven matching is bound to have lots and lots of mistakes. I have added thousands and thousands of authority data files to de.wikipedia, including thousands of VIAF identifiers, and more often than not there are multiple VIAF clusters for one persons, and very often there are complicated issues where people with similar names are very confusingly mixed up. I know that this happens as soon as some library data is bad (i. e. if titles are attributed wrongly), but VIAF inherits these problems, and believe me, it really happens a lot. In de.wikipedia, LCCN and VIAF usually have been checked manually which means that for tens of thousands of people in en.wikipedia, it is not necessary to inherit all those VIAF mistakes but use correctly matching sets from the very beginning. It also helps to maintain at least some consistency between de.wikipedia and en.wikipedia, and the Commons (whose authority data has been mostly copied from de.wikipedia as well). --AndreasPraefcke (talk) 21:06, 19 June 2012 (UTC)
AndreasPraefcke, Just to be clear in the sampling done on the big list, it is found to be 98% accurate. I do appreciate your work on de.wp filling it in by hand. So it would be preferrable to have a check there, and I will make it a point to put that in as part of the spec of the bot. However I have these concerns, about just trusting the de.wp data as much as trusting hte big list.
1)It's possible that interwikilinks link to the wrong people if it's an ambiguous situation.
2)It's possible that even work done by hand is wrong.
3)It's possible that there are false positives and false negatives since the all the files are not solid and people move between clusters depending on which revision of the files were used.
So the question really is, which is more innaccurate the 2% algorithm matching, or the sum of the three issues above? Maximiliankleinoclc (talk) 00:03, 21 June 2012 (UTC)
Well, that's difficult to say. (1) is pretty rare, (2) is difficult to say, and (3) is one of the VIAF problems in any method we deploy. Maybe we just need a list of all records in the big list where de-links exist and where de links to another VIAF cluster. The necessary review in these articles (on de and en) could be done manually then, which could happen after the bot run. --AndreasPraefcke (talk) 08:17, 21 June 2012 (UTC)

I think your suggestion is a really good idea. The point is that both de and en are going about this in different ways. We shouldn't try and compete for which language is the Authority on authority control integration, but rather do a research project on how they are different. Would you be amenable to supporting if we took the project as is, and then added a phase to implement your idea of inspecting "where de-links exist and where de links to another VIAF cluster" as a debriefing project after the bot runs? Maximiliankleinoclc (talk) 19:05, 21 June 2012 (UTC)

Yes, of course. The concerns are all minor in comparison with the great benefit that authority control will have in Wikipedia ASAP. --AndreasPraefcke (talk) 06:48, 22 June 2012 (UTC)
Another thing I just found from Jonathan Gross which I am think is brilliant to include is a noticeboard to report inaccuracies. Germans already do this at de:WP:PND/F Maximiliankleinoclc (talk) 18:24, 22 June 2012 (UTC)
That is indeed a great thing, but, of course, it is only useful if the corresponding organization promises to actually use it. Reporting errors with no one correcting them would be a waste of time. Since for most people numerous VIAF records exist, I alone could fille the noticeboard with hundereds of entries, every day. Mistaken combinations are rarer, so the noticeboard probably should be restricted to those. Ceterum censeo... that VIAF needs to implement some sort of crowdsourcing to combine and separate clusters in its own system. --AndreasPraefcke (talk) 07:21, 23 June 2012 (UTC)
  • Support in principle, but unsure about the technical choices. Getting such data in a well-structured form is a step forward, but is this the right way to do that? Will this in effect commit us to accepting any erroneous input that the VIAF accepts? Will it exclude valid input that VIAF does not accept? Will it lock us in to specific sources or formats? Is the resulting data fully open, so as to be usable under the licenses on all MWF projects? Is it attributable? (That is, are putative tombstone data, other names, etc in a record about a person attributed to specific works by specific authors?) Is this initial number scalable to be able to eventually encompass records for every person if necessary (already the number would be well over 10 billion considering living, dead, or corporate persons and closeted pseudonyms)? LeadSongDog come howl! 18:05, 19 June 2012 (UTC)
    • There are good points that, if VIAF was erroneous then the bot would commit erroneous data, although with the maintenance that is proposed as VIAF corrected itself, as would the bot relfect. It will not lock us into any specific formats. Its is yet-another-format, just one that 20 or so countries have agreed upon. The license is ODC-BY and OCLC consider using the canonical link (i.e. viaf.org/viaf/xxxxxxxx) to be sufficient attribution. Also VIAF does not record every living person dead or live, just people (or corporations, geographic names, and ships) that have source records in the participating libraries. Maximiliankleinoclc (talk) 18:50, 19 June 2012 (UTC)
      • Perhaps I've not correctly understood. Is there a fundamental decision to only address authors of books, or is it broader than that? There are many massive metadata resources available with authors of academic papers, journalists, and other forms. At some point there will be pressure to extend this to bloggers, tweeters, etc, many of whom are routinely archived, after all. We ought to recognize that as large as the LOC Authorities file is, it is still just the tip of the iceberg.LeadSongDog come howl! 16:33, 20 June 2012 (UTC)
        • This is a specific proposal to mass-add a certain large set of linkages to the VIAF database. No one is proposing a change in policy to exclude any other data sources or types of authority records. Dominic·t 18:01, 20 June 2012 (UTC)
        • As Dominic said, the proposal is specifically to add VIAF now; it doesn't preclude the addition of parallel identifiers now or in the future. I had originally hoped to use ISNI - a superset of VIAF,
actually ISNI won't include people who are already dead, so it's not a true superset Maximiliankleinoclc (talk) 23:45, 20 June 2012 (UTC)
and potentially an indefinitely expandable one - but it is still somewhat pre-production. Maybe in two years! To pick another example, it'd be great if at some point we could include ORCID or ResearcherID on articles about academics. Andrew Gray (talk) 20:48, 20 June 2012 (UTC)
    • To quickly clarify one point, we'd be using VIAF as a source of an authority identifier; we wouldn't be taking authority data (eg birthdates) from it. If VIAF and Wikipedia agree that their two entries reflect the same person but differ on factual details (which is quite possible in some cases), or if VIAF later change their details, we would each retain our own information but use the identifier to tie the two together. Andrew Gray (talk) 21:50, 19 June 2012 (UTC)
  • Strong Support in principle, adding authority control records (not just VIAF, but also others) to our articles is a fantastic idea to build links between our data and other repositories of free information out there. As has been pointed out above, there are many technical challenges and issues that will first have to be addressed, but the concept is sound. Lankiveil (speak to me) 11:58, 20 June 2012 (UTC).
    • Strong support: I have been hesitant to comment since I am not sure if it would be a conflict of interest. Some of you who know me on WP and offline know that I work at the Library of Congress. I work with the LCNAF (LC Name Authority File) every day. I am able to explain how it works and give you all an idea of what decisions had been made over time and some other decisions that are being made now. Since the LCNAF is a freely available government website and a number of the other things I mention below are public information, I think I am ok… I should have added last night that I am NOT speaking for the Library only for myself as a Wikipedian who happens to work for LC. Please do not take anything I have said as an official policy statement of LC. I am only speaking for myself...


1. Justification of choice of heading: The authority record structure includes a field (670 field) where the justification of the choice of the heading is given. The form and usage of the name and other relevant data are given in this field to justify the choice of heading and cross references. This information is fairly robust; research is done by librarians themselves.


2. Permalinks: LC uses permalinks; this hopefully may solve the concern about instability?


3. Invalid LCCN: Sometimes duplicate authority records are created; when they are detected, a librarian will go in and update the record; the invalid LCCN will be put in a subfield that tells the computer and the librarian that the old number and heading have been "zapped" and replaced with the existing number. It will be important to find the correct LCCN to point to the correct heading when using the WP AC template though. I can explain further if necessary.


4. Undifferentiated names (non-disambiguated names): At ALA this week (June 21) a discussion is taking place about breaking apart undifferentiated names into discrete differentiated name headings (aka disambiguation); for example, John Smith. If there is information on a certain John Smith (he was active lets say between 1903 and 1910) we would be able to create a new authority record using that information. This ties into RDA (the new cataloging code) which allows more flexibility in creating names for 20th century persons than AACR2 did. The consensus so far is to do this; this will mean a lot more headings in the LCNAF.


5. RDA: RDA (Resource Description and Access) is the new set of instructions to replace AACR2; along with the information above, RDA allows librarians to add more fields to the authority record for Semantic Web integration; information will be moved into new fields and the authority record will increase in size (and complexity).


6. NACO: Name Authority Cooperative Program: several hundred libraries participate in this endeavor at the Library; usually remotely. They provide authority records for persons, etc. who are not represented in the Library's collections (altho LC does have a lot of the material also).


7. CJK, Arabic, etc.: There are actually several headings in the LCNAF for various non-Roman languages (Chinese, Japanese, Korean, Russian, Hebrew); a choice had been made to Romanize the headings and provide cross references to the non Roman forms.


8. The LCNAF is not complete; right now it has over 9 million entries in the file. It undergoes dynamic update, 7 days a week. It contains personal names; corporate names, and uniform titles. The subject authority file is NOT part of the name authority file; it is a parallel file; but could be used as part of this project if desired, I imagine. The file has some names the German files do not have; conversely, the PND probably has names LC does not. There is some overlap, but not always.


I hope this helps enrich the discussion. Please feel free to ask any questions you may have. --FeanorStar7 (talk) 01:25, 22 June 2012 (UTC)

FeanoarStar7, what's your experience in crosswalking between VIAF and LCNAF? Maximiliankleinoclc (talk) 18:51, 22 June 2012 (UTC)
  • Thanks everyone for the feedback and comments here - we've significantly revised the proposal based on this feedback. The updated and somewhat streamlined version is now open as an RfC on whether to deploy it, and all comments and opinions are welcome (even, and in fact especially, if you've already commented here). Thanks again, Andrew Gray (talk) 22:14, 28 June 2012 (UTC)

Insert line breaks so paragraphs contain multiple lines

In order to gauge community consensus on a wikitext issue, please comment on a proposal that editors should insert line breaks into paragraphs consisting of one long line (example}. The displayed text would not change since MediaWiki ends paragraphs only at blank lines. The motivation for this proposal is that inserting line breaks would significantly reduce the size of diffs for future changes to the article, making it easier to read a diff. This issue arose when line breaks were inserted into several articles, leading to a discussion at Talk:C++#Line breaks where different views can be seen. Is there a relevant guideline? Johnuniq (talk) 23:40, 27 June 2012 (UTC)

Can't we just state there is some benefit to it under some circumstance and leave it at that ? Trying to change how people write whitespace in prose seems like an unattainable goal by nature. Programmers can't even agree nor adhere to rules on that and for them there actually is a significant benefit. Next to that, I would say that any wikitext authoring to work around a software imperfection in general is a bad idea, especially if that doesn't match the 'natural' way people would write the text. —TheDJ (talk • contribs) 12:07, 29 June 2012 (UTC)
1. No hope of changing users behaviour in this regard. 2 Disbenefits in that the edit screen no longer resembles the rendered article. Poor idea fixing a mostly non-problem. No support for it whatsoever. --Tagishsimon (talk) 12:16, 29 June 2012 (UTC)
@TheDJ: While I agree there will never be unanimity regarding whitespace, I am wondering what people would think if an editor were to change existing articles by inserting line breaks into paragraphs. To me, it's like WP:ENGVAR and referencing—if I create an article, I can use whatever English spelling and referencing style seems suitable to me, and others should not change it without good reason. Likewise, others should not insert line breaks into existing articles? Johnuniq (talk) 01:26, 30 June 2012 (UTC)
I experimented a while ago with putting line breaks into long paragraphs and found that they cause more problems than they solve. Inside an editor that word-wraps, like the one you get in most web browsers, the breaks create a jarring appearance. They only break lines in an appropriate place if the window is set to just the right width. The worst problem: even if you edit with a text editor like vi, which can word-wrap the text for you, they complicate diffs with changes that don't affect the appearance or content of the article, because the breaks have to get moved around every time you insert or delete more than a couple words in a paragraph. —Ben Kovitz (talk)

RfC on the verifiability policy lede

Hello all. I'd like to draw your attention to an RfC about the lede of the verifiability policy. We have been drafting this RfC for some time as part of a MedCab mediation, and it is finally ready for comment. In the RfC we have included a few specific drafts of the policy lede for you to comment on, and we have twelve general questions to find editors' views about how the lede should look. All editors are warmly invited to join the discussion at the RfC page. Thanks! — Mr. Stradivarius on tour (have a chat) 02:07, 29 June 2012 (UTC)

We have Highbeam, what about NewsBank?

I discovered I could get a free subscription to Highbeam Research but haven't encountered a situation where I could use it to contribute to Wikipedia. What are the chances we could get a similar deal with NewsBank? I happen to go to a library that has it, and it has been a tremendous source of information for Wikipedia articles i have contributed to. Who knows how long this particular library will keep NewsBank, though?— Vchimpanzee · talk · contributions · 20:01, 28 June 2012 (UTC)

I think you'd need to talk to some Wikimedia foundation members to work on that, but I am under the impression that HighBeam contacted us with the proposal. In addition, it may be possible that it would violate some sort of agreement we have with HighBeam. Ryan Vesey Review me! 20:05, 28 June 2012 (UTC)
Okay, thanks.— Vchimpanzee · talk · contributions · 20:13, 28 June 2012 (UTC)
Details on Highbeam can be found here, I believe it was arranged primarily by User:Ocaasi [2] so you might want to talk to him about how he went about it. And since we are under no contractual agreement with Highbeam (see Wikipedia:HighBeam/Plan#What it's not), that would not stop us having something similar with another company--Jac16888 Talk 20:24, 28 June 2012 (UTC)
Thanks for pointing that out. Ryan Vesey Review me! 22:42, 28 June 2012 (UTC)
I don't know about the US, but here in the UK a lot of libraries provide access (online) to newsbank-type resources (clickthough-type sign-on). Grandiose (me, talk, contribs) 22:33, 28 June 2012 (UTC)
I'm waiting on a response from Ocaasi. At least for now, I can access this resource and use it a lot to improve Wikipedia.— Vchimpanzee · talk · contributions · 17:41, 29 June 2012 (UTC)

Improving the useability of wikipedia:Graphics

A big part of the useability of wikipedia I think is how the site is presented. I find with changing the font and size on my browser, wikipedia becomes better aesthetically for me. Whilst there is nothing dreadfully wrong with the default design (a little bland maybe), I find the current number of skins very limited and most of them are rather bland or pretty pointless (search box at the bottom) for instance. What I think we need is better graphics on wikipedia and to have the chance to customize your own skin with a broad range of design and creation tools and some new set skin designs introduced. It would make the site much more enjoyable for me if I could design my own skin. I know we have main page alternatives but I literally wants something which gives the editor the freedom to design something to their own modifications. Does anybody know the best person to contact over this?♦ Dr. Blofeld 12:39, 29 June 2012 (UTC)

You can, within limits, design your own skin by editing your personal CSS and JS files; if you want, you can even set your skin to "myskin" to start with a relatively clean slate. The major limitation is that you cannot change the rendered HTML of whatever skin you start from, any such changes would have to be done via Javascript DOM manipulation instead. Anomie⚔ 14:44, 29 June 2012 (UTC)

Mandatory edit summaries

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Proposal to make edit summaries mandatory so that when viewing the article's history, editors will know what changes have been made during an edit. This is better than no edit summary at all. So when someone tries to save the changes without an edit summary, a notice can be put, saying 'you have no provided an edit summary' or something like that. Then they will be required to fill in the edit summary to save the change. Till I Go Home talk 01:27, 29 June 2012 (UTC)

Wikipedia:Perennial_proposals#Automatically_prompt_for_missing_edit_summary. Rd232 talk 01:52, 29 June 2012 (UTC)
Bleh. Obviously this is going nowhere now. Till I Go Home talk 01:56, 29 June 2012 (UTC)
I do think that edit summaries should be strongly recommended because they reduce the number of misunderstandings between editors. Then again I don't like the fact that they are limited in length and you can't correct them after the update. Regards, RJH (talk) 15:02, 29 June 2012 (UTC)
  • Now set by Special:Preferences - Editing - Advanced options: Use Special:Preferences and select the option under section "Editing - Advanced options", currently worded as:
[ ] Prompt me when entering a blank edit summary
That prompt-option is smart enough to treat the default edit-summary contents (such as topic "/* xxx */") as being equivalent to a blank, so the user is prompted to change the summary during edit, and cannot save the first time without changing the default summary text. However, I agree that editing (and replies) of long summaries becomes an issue, so perhaps users should describe a complex edit on the article's talk-page, with the ability to revise the wording later, and politely allow other users to discuss the edit-summary text, now placed in the talk-page. Meanwhile, I think some users like the idea of shouting opinions into edit-summaries (so forcing short summaries can help reduce POV-rant distractions), as it can be a very tempting soapbox where comments are rarely revdel'd to censor remarks. I have even had some people rewrite my talk-page headers to censor my findings, so in a sense, an edit-summary line is a last resort of free speech. -Wikid77 (talk) 22:32, 30 June 2012 (UTC)
The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

Remove links, please!

As an outsider to wikipedia and unaware of any ongoing/resolved discussions on this topic, I'd like to suggest severely reducing the number of inline links in any article on wikipedia. By this I mean at most a dozen or so under a section near the end of the page (preferably another name than See also) and some scattered links, if any, in the article body. I say this because I don't remember the last (or the first!) time that I read an article, with satisfaction, from start to finish. Almost always there's a bunch of side tabs/windows (that seemed tempting at first to open but are actually quite irrelevant) which would all be a waste when you run out of time and close the whole session, eventually feeling that not much was gained. For this, I'd be especially happy to see the disappearance of 'main article', 'see also', etc. which just add to a sense of scattered parts strewn together to make an article and which really shouldn't be there. (Paragraph header links are slightly better since the change in colour is quite unnoticeable).

Overall, I feel a sense of a unified whole is what is required not only to make articles a) more informative but also b) more pleasurable to read. Apologies to anyone if I'm hurting their stance/strong opinions on this (I don't want to be pulled into an argument) but I really felt it necessary to make this suggestion. — Preceding unsigned comment added by 219.91.245.232 (talk) 11:45, 29 June 2012 (UTC)

Lots of readers like many hyperlinks so it's unlikely they will be reduced to your preference. Maybe you would prefer to read the printable version of articles. If you create an account then you can change link colors so they become less distracting. See Wikipedia:Link color#Making links appear a different color just for you. PrimeHunter (talk) 12:05, 29 June 2012 (UTC)
We do have an WP:OVERLINK policy that is aimed at reducing an excessive number of links. There's a WP:LENGTH limitation, which is why the main article links are necessary. I do agree overall that limiting the number of distractions in an article is better, but some features are too embedded in the Wikipedia philosophy to do away with, or even severely ration, at this point. There may be some configuration actions you can take that may help, but I'd like to suggest that you may just need to learn to look beyond the distractions and focus on the text. Regards, RJH (talk) 15:00, 29 June 2012 (UTC)
Making the reading of an article a pleasurable experience is quite important, arguably one of the most important goals. If it isn't read, it doesn't exist.
That said, I'm not fully comprehending your concerns. It is a problem if people are clicking on things that turn out to be irrelevant, or at least, not central to why the reader is reading the article. That's specifically why there is a See Also section - to identify things that the reader might also be interested in, but are not central enough tot he article topic to be included in the main article. So I'm puzzled that you object to the See also section, as that sounds like exactly what you would want. If you are simply observing that the name is imperfect (maybe it sounds like a strong exhortation that you MUST read it?) we can discuss alternative phrases.
You expressed concern about the 'main article'. I don't recall an article with a section. Are you talking about a section with that label, or are you simply talking about the main article itself, in which case I don't follow your point.
Can you give some specific examples of "side tabs/windows" that you mention. We do have a separate infobox in many articles, but that is deliberate to help the user.
Finally, I agree that blue links can be distracting. Many readers find them valuable, but some find them distracting. Luckily we can eat our cake and have it to. If you go to any article with blue links, look at the panel on the left side of the page and click on printable version. You can now read the article without blue links, and without temptation to click away from the article.--SPhilbrick(Talk) 16:24, 30 June 2012 (UTC)
Could you provide some details about a session where you found yourself with lots of tabs or windows that you regretted opening? That is, what page did you start on, and which links did you click, and why did you click them? Normally Wikipedia links do no spawn new Windows; have you set your browser so it always starts a new window when you click a link? The links on Wikipedia serve a lot of different purposes for different readers. To usefully inform our ever-changing link policy, we need something more than "get rid of nearly all the links!" Understanding specifically why/which links caused you problems will help. —Ben Kovitz (talk) 21:59, 1 July 2012 (UTC)
Here's something you could try: if you register an account you can enable the navigation popups gadget. Then, whenever you hover over a blue link, you'll see the first sentence or two of the linked article. This could help you decide whether or not to open the link in a new tab or window. -- John of Reading (talk) 06:28, 2 July 2012 (UTC)

Divide Category:British film actors

Every Scottish, Welsh, and English film actors are British film actors. How about change every article in category British film actors to category Scottish, Welsh, or English film actors?--王小朋友 (talk) 02:25, 30 June 2012 (UTC)

I disagree, there is often confusion as to who is Scottish, Welsh and English much simpler and no less useful to leave it as British. Bevo74 (talk) 16:42, 30 June 2012 (UTC)

Many Scottish, Welsh and English actors have no category "British", then should we add it?--王小朋友 (talk) 10:23, 1 July 2012 (UTC)
No, per WP:OCAT they should be only at the lowest level & "British" is a parent. But yes, it is very messy, like all UK people categories. Johnbod (talk) 01:20, 3 July 2012 (UTC)
Then, according to WP:OCAT, Category:British film actors should be divided, execept for a few special cases such as unclear or controversial? --王小朋友 (talk) 12:32, 3 July 2012 (UTC)

Prohibit creation of username with a "(WMF)" string

I cam across an incident which occurred at Wikipedia:Requests for permissions/Autopatrolled. A person created this account User:Jordon (WMF) and made a claim that he was recently appointed to WMF and is a trusted user so should be granted the rights. Eventually it was proved that he isn't a staff of WMF and was indefinitely blocked. Since, the person was not a member of staff and was still able to create a username with string; "(WMF)", more similar incidents can occur and anyone can built a fake userpage by making claims that they are member of the foundation. Such username are fake and only intended to misguide editors or even sometimes just to troll around or get rights easily. Like this one, many others can also create a username with a string of "(WMF)" at the end of their name and misguide so my proposal will be to make few technical changes so that it becomes impossible to create a username with "(WMF)" string unless there is a special permission from the foundation or a special code. Thus to avoid confusions and misuse of the string, restrict creation of username with "(WMF)" to editors who actually are member and not to any other. Thanks for reading :) →TSU tp* 14:24, 30 June 2012 (UTC)

I think I'd support this. It sounds similar to disallowing non-bot accounts from having "bot" in the name. - jc37 14:36, 30 June 2012 (UTC)
As already mentioned at Wikipedia:Requests_for_permissions/Autopatrolled: we have a blacklist for that and as far as I know (WMF) and (WMDE) was either on the local or the global list. Dunno what happen, I will invstigate later into that problem if nobody has done it then already. mabdul 16:36, 30 June 2012 (UTC)
The entry at meta:Title blacklist is commented out; see discussion at meta:Talk:Title blacklist#Fakes of Wikimedia Deutschland (WMDE) staff. The current situation seems to be that it's disabled because it prevents SUL auto-creation of these accounts for WMF staff members who aren't in the "staff" global group. Anomie⚔ 21:37, 30 June 2012 (UTC)
  • Most rules forget valuable exceptions: In general, having too many mandatory rules gets too cumbersome, with the ultimate bottleneck: articles must be pre-approved even to be displayed. Remember that, before Wikipedia, the rules to get articles approved limited the accepted articles to less than 24 total articles in the first year before Wikipedia's wiki-based approval of what gets left inside articles. In reality, most problem cases get fixed relatively quickly. Just because someone causes a car accident, that is not a reason to ban driving for everyone. So, just because a rare user creates a username with "(WMF)" is not a reason to pre-restrain usernames to deny inclusion of the WMF portion. In this case, there was the valuable exception to allow auto-creation of usernames which include "(WMF)". Likewise, people have suggested absolute rules for excluding some text phrases, but then many direct quotations from references would be unable to repeat those phrases quoted exactly from the source. In general, WP has used the concept of "suggested guidelines" with WP:Ignore_all_rules, and then we WP:Assume good faith that the vast majority will do fine, but have an emergency procedure for the occasional problem cases. -Wikid77 (talk) 06:01, 1 July 2012 (UTC)
An Amen and halleluiah to that Wikid77. Mugginsx (talk) 16:28, 2 July 2012 (UTC)
If we're going with broken analogies, this is less like "banning everyone from driving," and more like "banning everyone from impersonating a police officer." — The Hand That Feeds You:Bite 19:34, 2 July 2012 (UTC)
Can we do something in the edit filter? --Rschen7754 01:28, 3 July 2012 (UTC)
  • Just to jump in; we're not too fussed, to be honest :). Impersonation is a rare thing - as noted above, things like the blacklist would be (at best) problematic. The edit filter...I'm not sure how you'd do it - I'm not a regex person - but you'd need a solution that didn't prevent new WMF staffers creating new accounts, which I imagine would be awkward.
  • We're looking at better and tighter ways to identify staff as part of "GlobalProfile" software, which should help. In the meantime, all actual staffers should have had Category:Wikimedia Foundation staff added to their userpage by me, Maggie, Philippe or one of the other community-facing staffers - this is a better indicator than username :). If you spot anyone without said category, gimme a shout (it'll probably be a real staffer who forgot to ask one of us to add it, but we should fix that ;p). Okeyes (WMF) (talk) 20:07, 3 July 2012 (UTC)
    At the risk of making a tantalizing suggestion: you are checking that category frequently, just to make sure that nobody adds any unauthorized pages to it, right? WhatamIdoing (talk) 23:50, 3 July 2012 (UTC)
    I am, yeah; it's in my "pages to hit F5 to to see if anything has happened in the last 20 minutes" list, along with things like my watchlist. Okeyes (WMF) (talk) 01:41, 4 July 2012 (UTC)

Give editors @en.wikipedia.org emails

Many users are uncomfortable about making their email addresses public or accessible to the general public, due to concerns about privacy and outing, as a real name may be present within an email address. However, some users may want to maintain private communications with others, without the risk of enduring ridicule or unnecessary loss of reputation due to actions or positions which may be considered embarrassing.

My proposal to resolve this is simple: create an email address where the domain name is en.wikipedia.org. Email addresses could be automatically assigned to all autoconfirmed users, or it could be a new user right email in order to prevent abuse. The address itself would be constructed with the syntax username ignoring diatrics and splitting æ or œ into their constituent parts@en.wikipedia.org. Thus I could be reached under the new system at wer900@en.wikipedia.org (note: this email address does NOT yet exist!)

This shouldn't cause problems, as WMF personnel should have an @wikimediafoundation.org email. My proposal could be implemented on the same framework that the OTRS system is implemented on, but the two would obviously be kept separate; only the technical framework would be the same. Wer900 • talk • coordinationconsensus defined 01:12, 3 July 2012 (UTC)

Where would the WMF get the servers for storing all the mail? --Rschen7754 01:27, 3 July 2012 (UTC)
Does this add anything that a user talk page does not already provide? Chris857 (talk) 01:39, 3 July 2012 (UTC)
Yes it does. It adds the ability of a user to communicate privately with another. As for the server space restrictions, a user's email inbox could be limited to, say, 10 MB of content before it becomes "full." The entire size of Wikimedia content right now is only 1.2 TB (see Wikipedia:FAQ/Technical#How big is the database?) so I don't imagine that size is too much of a concern for the Wikimedia Foundation. Plus, if you look at their financial reports, they're flush with cash. Wer900 • talk • coordinationconsensus defined 03:15, 3 July 2012 (UTC)
Are users able to talk privately, without disclosing their main email address, by creating a free email account on other web sites (Hotmail, Yahoo, anonymous email servers, etc.)? —Ben Kovitz (talk) 03:31, 3 July 2012 (UTC)

What is known about the potential for abuse that this would open us up to—spammers, people misrepresenting themselves as spokesmen for Wikipedia, people sending abusive email, people sending illegal email, and all the other troubles that free-email providers contend with? —Ben Kovitz (talk) 03:34, 3 July 2012 (UTC)

Ben Kovitz said it all. This would generate numerous problems without solving any not already solved by simply registering a dedicated e-mail account with a free provider. —David Levy 03:41, 3 July 2012 (UTC)

Okay. I stated that this could, alternatively, be part of an email user right, which is earned rather than just given. This will ensure that users are legitimate and that only users who show that they can responsibly use the right will be able to have it. Alternatively, this could be merely used as a shortcut email address to a free provider (gmail for example) wherein we use the server space for an existing free provider but use the en.wikipedia.org domain. (We could also append an automated signature stating that @en.wikipedia.org does not indicate that the user is a WMF employee). — Preceding unsigned comment added by Wer900 (talk • contribs) 03:54, 3 July 2012 (UTC)
Again, what problem does this solve which can't be solved by the user getting a free account. Why do you want to burden the admins (who I presume would be giving these rights) with more tasks? --NeilN talk to me 04:14, 3 July 2012 (UTC)
I stated that this could, alternatively, be part of an email user right, which is earned rather than just given. This will ensure that users are legitimate and that only users who show that they can responsibly use the right will be able to have it.
In other words, new editors should have their personal information exposed until proving themselves worthy of being awarded an @en.wikipedia.org e-mail address (as opposed to simply registering a free e-mail account elsewhere upon joining Wikipedia). And the benefit would be...?
Alternatively, this could be merely used as a shortcut email address to a free provider (gmail for example) wherein we use the server space for an existing free provider but use the en.wikipedia.org domain.
That certainly is technically feasible. Now please explain why the Wikimedia Foundation should invest its donated funds on this or any other implementation of the idea. What problem(s) would it solve? —David Levy 04:30, 3 July 2012 (UTC)
  • Hey guys
  • So, I've just spoken to C.T. Woo - he heads up our Operations department, which deals with the servers and networking. He confirms this isn't a direction they're looking to move in at this time - the practical costs are just too great, both with setting the system up and then maintaining it in the long-term, and (obviously) unbudgeted, too. He echoes NeilN's comment above, and recommends that people simply sign up for things like Gmail to get the same kind of privacy protection but with more space to boot :). Okeyes (WMF) (talk) 21:05, 3 July 2012 (UTC)
  • Special:EmailUser doesn't reveal your e-mail address if someone sends you e-mail through Wikipedia. Your e-mail address is only revealed if you send e-mail. So if you don't want a disposable email account and you don't want to share your existing e-mail address, but you still want to receive e-mail messages, then you need take only two steps: never send e-mail to another Wikipedian through Special:EmailUser, and never reply to any e-mail messages you receive from another user. WhatamIdoing (talk) 23:54, 3 July 2012 (UTC)
Many users, probably most, with e-mail enabled set up an alternate e-mail account with Gmail or the equivalent, and it works for them. I actually prefer using my personal address, because I feel as an active administrator who sanctions a lot of people I should make myself easy to contact, but in my case it doesn't have my name anywhere so I won't inadvertently give away more information than I want to. I recommend doing that if you're comfortable with it, but it's easy enough to just do what I described above at the beginning of my post. The Blade of the Northern Lights (話して下さい) 05:16, 4 July 2012 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_89&oldid=1144526761"