Jump to content

Wikipedia:Village pump (proposals)/Archive 40

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, 215

OK I've moved discussion to here.


If the proposal is to use Wikimedia fundraising money for this, this isn't really the right venue. m:Wikimedia Forum or foundation-l would be better forums. Individual projects really don't have a say in how the money is spent as its primarily designated for operational expenses. Mr.Z-man 19:04, 25 November 2008 (UTC)

Newsletter project

I brought this up on IRC, and was directed here - so here goes ;)

I wanted to know what users thought of creating a newsletter project to send, make, copyedit, and write newsletters for any WikiProject. I've noticed recently that some users who run newsletter bots have been inactive somewhat, and aren't around as often to send the bots out, or the project forgets to make a newsletter one week, or a new project uncertain on how to make one.

This project could offer designing a newsletter, taking information given by the project, and writing it into a newsletter, holding bots that are prepared to deliver the newsletters of any project, and get them around on time. Many projects have newsletter (many many) and a space to gather everything together and get them out would be nice. Suggestions, thoughts, or comments would be appreciated. iMatthew 20:51, 25 November 2008 (UTC)

Date Linking RfC

There is a new request for comment underway at Wikipedia talk:Manual of Style (dates and numbers)#Date Linking RFC as to the proper linking of dates in articles. This is the RfC that is the result of a lengthy, collaborative process. Another RfC was removed from the RFCstyle list by an admin due to controversy over its neutrality. Please comment, or if you commented on the prior RfC, please do so again on this more detailed an less controversial RfC.--User:2008Olympianchitchatseemywork 08:09, 25 November 2008 (UTC)

Another one? Why don't we just declare that anyone linking or unlinking a date in the next six months gets a six-month ban, and re-visit the issue later, when editor exhaustion is no longer a problem? --Carnildo (talk) 08:34, 25 November 2008 (UTC)
This RFC has been in development for a week. Another editor, a proponent of date unlinking, chose to side step the RFC developed by consensus in favor of an RFC written entirely by him. —Locke Cole • t • c 08:45, 25 November 2008 (UTC)
@Carnildo: put up an RFC on that (six-month ban) and you have my vote. ;) -- Fullstop (talk) 10:53, 25 November 2008 (UTC)

Why don't we just disable the autoformatting of linked dates? :-) — Werdna • talk 23:35, 26 November 2008 (UTC)

template:Wikinews

Please discuss my suggestion about making {{wikinews}} a short-living link (the keyword here is "news") in Template_talk:Wikinews#Outdated_news. `'Míkka>t 17:10, 26 November 2008 (UTC)

When comparing article revisions to check for vandalism (such as here), the top of each revision is headed with links to the edit's user page and talk page, along with (if you're an admin) a block button. I'd like to suggest adding in a link to the editor's contribution list - that way it's far quicker to check whether the edit was a one-off aberration or whether the account should be blocked as a repeat offender/vandalism only account. Is there any way of adding such a link? Grutness...wha? 21:29, 23 November 2008 (UTC)

It's there already. Labelled as 'contribs' for registered users, and with the IP address for IPs. Algebraist 21:33, 23 November 2008 (UTC)
Been like that since IPs stopped having user pages about six months ago. CIreland (talk) 21:35, 23 November 2008 (UTC)
Uhhh. So what I thought was a link to a user page (which I was never aware no longer existed for IPs) is a link to the contribs. Oookay - shows how much I know about what's going on with these things. Grutness...wha? 08:44, 28 November 2008 (UTC)

"robot fatality"

I'm fishing for ideas. Robert Williams (robot fatality) is the name of the article about the unfortunate first human to be killed by a robot. I want to change "robot fatality" to something else, as "robot fatality" means "the death of a robot" rather than "death caused by a robot," which is the subject of this article. I'm not coming up with anything immediately. Any ideas? Tempshill (talk) 20:13, 24 November 2008 (UTC)

God Save us all. The Robot revolution cometh, quick, block all the bots. Seriously though how about something simple like Robert Williams (factory worker), since that's what he was, then just create several redirects such as Robert Williams (killed by robot), Robert Williams (first robot death), Ford tries to take over world with killer robots etc. As long as its on the disambig page, it doesn't matter that much really--Jac16888 (talk) 21:54, 24 November 2008 (UTC)
It should probably be named Robert Williams (first casualty in the war against the machines), but failing that, Robert Williams (factory worker sounds good. EVula // talk // ☯ // 23:05, 24 November 2008 (UTC)
Robert Williams (terminated)?-gadfium 03:51, 25 November 2008 (UTC)
Make sure to use Robert Williams (forgot training around machinery) to stay fair and in touch with reality. // FrankB 21:52, 25 November 2008 (UTC)
Was he ever nominated for the Darwin Awards? -- Another Stickler (talk) 17:23, 26 November 2008 (UTC)
Never heard that term before, but the article is hilarious--Jac16888 (talk) 17:28, 26 November 2008 (UTC)
"death of a robot"? Don't let the Aurorans hear that, they'll laugh you off their planet.--Goodmorningworld (talk) 14:56, 27 November 2008 (UTC)

New Wikiproject Proposal

Hi everyone. After some discussions here, (noted further up the page here) I have proposed that we create WikiPedia Outreach as a WikiProject. The project would serve as an umbrella/parent project for all outreach/recruitment of new editors, including school and university projects. The discussion is located here. I'd appreciate everyone's input. //roux   07:16, 28 November 2008 (UTC)

Thorough review for dispute resolution?

I have been thinking that Wikipedia needs a process similar to Peer review or Good Article review, but as a form of dispute resolution rather than for the direct purpose of upgrading the article's status. For example, if a fairly lengthy article's neutrality is disputed due to the manner in which sources are used, and discussion fails to resolve this, what do you do? An RfC asking whether the article now has a NPOV will only work if those responding have examined not only the article but also the sources in some detail. Ditto for a noticeboard listing, mediation, request for feedback, or third opinion. If the article is tagged for a content dispute, Peer review is not an option, and a Good Article review, though it could generate helpful feedback if done, would be difficult to get. But if there were a place to request an in-depth review for the purpose of resolving a complex dispute, that would be the way to go. PSWG1920 (talk) 05:24, 24 November 2008 (UTC)

I have begun a draft of a page which could host such a process. PSWG1920 (talk) 05:46, 30 November 2008 (UTC)

Brainstorming: two ideas!

Dear fellow editors, I have thought of two ideas that I thought I might run past everyone:

  • 1. Having a "Wikipedia Hall of Fame" page that honors and recognizes those who have contributed greatly to our project. We can include people like the site's founder, Jimbo Wales, or maybe even editors who have the most edits or most featured pages, or something as further incentive and thank you to our best contributors and maybe even donors.
  • 2. And yes, I am actually serious about this one...at some of these Wikimania type of get togethers as a means of ironing out differences and maybe even raising funds through tickets, feature boxing matches between rival editors. I got the idea from Uwe Boll#Critic boxing matches .28Raging Boll.29 and "Unfinished Business" (and to a lesser extent from "Get in the Ring"). Obviously, we couldn't have totally mismatched bouts, but it could be a fun way to get opponents to respect each other through physical competition and I can imagine editors donating to see some epic matchups. Again, I do not mean this suggestion as a joke.

And as third bonus idea, I still think established non-admins should be allowed to see deleted contributions. Anyway, any thoughts or ideas? I personally like Hall of Fames and really think the first one is a good idea, but thought I might as well throw that other idea into the mix as well. Anyway, I hope these suggestions are helpful! Sincerely, --A NobodyMy talk 18:30, 29 November 2008 (UTC)

Well, a hall of fame is problematic at best. Remember there are hundreds of editors that don't necessarily contribute to featured articles, but make many small edits that often go unnoticed. It can reward editors while forgetting others; we're all equal on this project. I have no comments on the second one, as I think meetups can include that if the organisers wanted to do that. Thirdly, deleted edits will never be available to non-admins per Mike Godwin, who said that it would cause definite legal problems. Best, PeterSymonds (talk) 19:09, 29 November 2008 (UTC)
What could be some criteria? I suppose I could always have a personal "hall of fame" of sorts and editors whom I have found nice, which I sort of already do at User:A_Nobody#List_of_editors_who_have_agreed_with_my_arguments_or_made_other_nice_observations_about_my_efforts. Best, --A NobodyMy talk 17:34, 30 November 2008 (UTC)

Non-admin viewing of deleted material was explicitly vetoed by the Foundation's legal counsel. — Werdna • talk 08:31, 30 November 2008 (UTC)

I suppose I have a personal interest in that one as, while I do not really see myself having an administrative role in at least the immediate future, I do still participate in DRVs and RfAs on occasion where being able to view deleted material would be useful and I certainly would never just unilaterally restore it or share potential copyrwight or libelous with anyone. Best, --A NobodyMy talk 17:34, 30 November 2008 (UTC)
Indeed, I'm sure you'd use it wisely; but that's the only administrative function that will never be unloaded to non-admins per the legal counsel. Best, PeterSymonds (talk) 17:41, 30 November 2008 (UTC)
The one thing that gets me about that is that even admins can misuse their ability to see deleted contribs, so how does that get taken into consideration as well? Sincerely, --A NobodyMy talk 17:55, 30 November 2008 (UTC)
We have had at least one admin desysopped for providing inappropriate contents of a deleted article to a wider audience; it's certainly not ignored. But admins must have the undelete because they have delete; if they're trusted with one of the tools then they should have access to all of them. Abuse of undelete is, however, rare. Best, PeterSymonds (talk) 18:53, 30 November 2008 (UTC)
Okay, and I do hope some of my other ideas get some more discussion too!  :) Best, --A NobodyMy talk 18:56, 30 November 2008 (UTC)
Which admin was that? (It wasn't Everyking; he said in response to a request that he'd look into it, and declined to provide it when he saw what it was.) --NE2 18:58, 30 November 2008 (UTC)
Yes, my mistake, here is what I found. The point about (ab)use of the undelete privilege is, however, still valid. Thanks for correcting my mistake. :) Best, PeterSymonds (talk) 19:02, 30 November 2008 (UTC)

NSLE/Chacor was also desysopped for providing the contents of deleted pages. Generally speaking, A Nobody, you should read the discussion which occurred, and the message which was sent by Mike Godwin, the Foundation's legal counsel, on this issue. — Werdna • talk 22:40, 30 November 2008 (UTC)

Wikipedia SSML (speech synthesis) webservice

This is, I guess, a feature request for wikipedia.

It could be potentially useful if wikipedia could provide a service for people to use which returned a SSML Speech Synthesis Markup Language representation of an article instead of the webpage.

I'm imagining a really convenient, voice controlled program for Windows, Mac, or Linux where one asks the computer about some topic, and the computer searches wikipedia. For example, "Computer, what's Buddhism?" or "Computer, look up New York City." Then the program uses the webservice to get an article's SSML, which it can then feed to the OS's voice synthesis engine, which then reads the 'article' to you.

I see two problems with this system, 1. Pronunciation; we have enough edit wars on titles and content, do we need another on TOE-MAY-TOE vs. TOE-MA-TOE? Also, how do we set the pronunciation on made-up or complex words that would be difficult to synthesise? Aditionally, how are maths equations pronounced, some articles have them as extra content, but for other topics, it will make no snese without them. 2. Server usage; en.wp has over 2 million the last time I checked, can the servers cope with, adition to hundreds of edits a second, having to regenerate the speach file as well? This is a great idea, and I commend you for it, but I doubt it can be implemented in the near future. Foxy Loxy Pounce! 07:18, 3 December 2008 (UTC)

Proposed gadget to remove articles from one's watchlist quickly

Wouldn't it be nice to be able to remove a watched article from your watchlist directly (on the Watchlist page), rather than editing the watchlist? Next to the diff and hist links, or at the end of the line, there could be a remove link that would drop the article/page from the present user's watchlist. Shouldn't be too hard...anyone feel like taking this on? hgilbert (talk) 15:49, 23 November 2008 (UTC)

There's already an easy way: click the page's link, then click the "unwatch" tab and wait for it to change to "watch"; then back to your watchlist display or wherever else you want. This is one of many WP useful facilities that are poorly documented.
Thanks, but the request is for a one-click solution, and I would welcome it as an editor who accumulated over 6,000 watchlist items before realizing the wisdom of not auto-watching every edit. What you're describing is “click, wait, click, wait, back.”
By the way, you can bulk-edit your watchlist by clicking View and edit watchlist or Edit raw watchlist at the top, but isn't quite the same kind of drive-by unwatching. —Michael Z. 2008-11-23 18:52 z
In terms of interface design, you are spot on. It is extremely bad design to suggest that to unwatch, one must first go to watched page from the watchlist, then click unwatch, and finally return to the watchlist. It should be a single click process, and I can see no good reason for it not to be. LinaMishima (talk) 19:39, 23 November 2008 (UTC)
I agree that one-click would be better. I'd been thinking of proposing this. The problem with going to the page is you have to wait for that page to load; some pages load slowly. It would be nice to be able to click off checkboxes next to pages on your watchlist, then click a "remove selected pages from watchlist". (OK, that still isn't quite exactly one-click, but it would be nice.)
Going off slightly on a tangent, I just thought of an idea. What if the watchlist gave you a link that let you sort-of go to the page but without actually displaying the page. It would show you all the tabs at the top: history, unwatch, etc., but without having to wait for the page to load. That would allow relatively quick unwatchlisting, and might have other advantages. ☺Coppertwig(talk) 20:53, 23 November 2008 (UTC)
See User:Js/watchlist, and possibly some of the others, listed at Wikipedia:WikiProject User scripts/Scripts#Watchlist. -- Quiddity (talk) 21:20, 23 November 2008 (UTC)
Well, glory be! Thank you, that's just the ticket. hgilbert (talk) 21:57, 23 November 2008 (UTC)
WP:Popups provides a one click (ok hover and click option). --Nate1481 15:15, 25 November 2008 (UTC)

(unindent) I, like many people, am one of the those people who are near-phobic, and/or just lazy, and/or technically illiterate, about departing from default settings. So I would not import javascript, or even bother to go to gadget preferences. I did not even know of gadgets for the longest time. It would be really timesaving it there were one-click removal of items from watchlists as the default setting. My huge watchlist is rarely cleaned, and so it hinders my editing. Cleaning it is very difficult. Finding stuff takes a long time with a long watchlist like mine. --Timeshifter (talk) 00:15, 26 November 2008 (UTC)

I agree with Timeshifter. There seems to be spare real estate on Special:Watchlist that could be well used for unwatch links. Until I installed pop-ups and began to use 'hover and click' to unwatch articles, my watchlist too grew out of control. I suspect that only a tiny minority of editors install javascript tools, and unwatching is useful command to everyone who looks at their watchlist. --Hroðulf (or Hrothulf) (Talk) 21:29, 1 December 2008 (UTC)
I too agree with Timeshifter. Changing (diff; hist) to (diff; hist; unwatch) or (diff; hist; unw) would not add undue clutter and would make life much easier for those of us who set their preferences to add every page they edit to their watch list. --agr (talk) 22:10, 1 December 2008 (UTC)
I also believe that a interface change would be useful. If/when there is consensus, give me a holler on my talk page and I'll open up a bugzilla report to get it changed (although your welcome to file it yourself it you know how). Foxy Loxy Pounce! 07:26, 3 December 2008 (UTC)

[Help] About Participate in Wikipedia — we will donate to the Wikimedia Foundation

Dear friends, We are conducting a study on the motivation of the knowledge sharing on Wikipedia. Your experience of the read from and write to Wikipedia is very important to the design and management of this knowledge platform. The survey will take about two minutes. We deeply appreciate your help on answering the following questions. After the survey is done, we will randomly select twenty persons and present them with USB 2GB Flash Drives. Besides, with each valid questionnaire, we will donate US $1 dollar to the Wikimedia Foundation. The result of this survey is analyzed in an anonymous way and is only regarded as the academic use. Please feel free to fill out the questionnaire. Thanks again for your time and valuable input.

May happiness and health be with you everyday! ★ On-line Questionnaire: http://140.119.19.152:8080/wiki/ [1]

　 Shari S. C. Shang Eldon Y. Li Professor, Department of Management Information Systems, National Chengchi University Tel.: +886-2-82374038； Fax: +886-2-29393754 ； E-mail: 94356502@yahoo.com.tw

WARNING I think one can safely assume that this is a scam, and I advise people not to participate. ╟─TreasuryTag►contribs─╢ 11:33, 27 November 2008 (UTC)
It's a real university in Taiwan (National Chengchi University), and the name Shari S. C. Shang - Google Search is widely associated with the institution. I advise you not to assume anything. -- Quiddity (talk) 23:00, 27 November 2008 (UTC)
Farming real contact details from random university faculties is also extremely common; indeed don't assume anything unless someone's contacted the proffessor. I would be very surprised indeed if the Chengchi University didn't have its own e-mail server... Happy‑melon 17:14, 28 November 2008 (UTC)

Might as well give the quiz a whirl. It only takes a few minutes. — Werdna • talk 06:30, 29 November 2008 (UTC)

Suprisingly, the IP at least seems to actually belong to the university:
$ whois -h whois.twnic.net 140.119.19.152
National Chengchi University

   Netname: T-NCCU.EDU.TW-NET
   Netblock: 140.119.0.0/16
—Ilmari Karonen (talk) 21:37, 2 December 2008 (UTC)

Page deletion by non admins

Not sure if this has been asked before couldn't see it on Wikipedia:Perennial proposals. But what I propose is that blatant attack pages and pages with no content or as many new page patrol editors come across pages with strings of letters or numbers should be allowed to get deleted by non admins. The system could be along the lines of Rollback and only given to trusted editors. This IMO would reduce the workload on admins who already have a lot on their plate. BigDuncTalk 14:01, 28 November 2008 (UTC)

I see no great problem with this - however it would have be tightly controled - literally garbage pages and should be restricted to those with (picks number out of air) 5000 edits and no blocks. --Cameron Scott (talk) 14:08, 28 November 2008 (UTC)

I see a big problem with this. As a former admin, declining many many wrongly-tagged CSDs, allowing non-admins access to the delete function is a bad idea. Granted, it probably can be removed, but I'm opposed to splitting the admin package to delete. Will they also have access to undelete? What if a mistake is made? Undelete can't be restricted to a certain type of deletion. It could potentially cause too many problems. Oppose. PeterSymonds (talk) 14:12, 28 November 2008 (UTC)
Per MGodwin undelete will never be unbundled to non-admins. Which would set up a problem if you hit 'delete' by accident. //roux   14:13, 28 November 2008 (UTC)
OPPOSE - This could really, really fail if someone accidentally deletes a page that shouldn't have been speedied. Undelete is always needed, just in case, and we can't just hand that out to non-admins. This would cause too many problems to be worth it. DavidWS (contribs) 14:15, 28 November 2008 (UTC)
Oppose It's a perennial actually, see Wikipedia:Perennial proposals#Hierarchical structures. There is no reason to unbundle the tools for admins - if there is a backlog, it just means we need more admins. And if we trust them to delete, we should trust them to block and protect as well. So, instead of giving rollbackers a delete-button, just nominate them for adminship, if they can be trusted, they will be made admins. Simple as that... SoWhy 14:25, 28 November 2008 (UTC)
Not everyone wants to be an admin for numerous reasons. And as Jimbo says it is no big deal being an admin. If such a tool can help the community then why not unbundle admin tools? BigDuncTalk 14:44, 28 November 2008 (UTC)
In my opinion, one should not have delete without undelete. They go hand-in-hand. As undelete will never be given to non-admins (as confirmed on the proposal to allow non-admins to see deleted history), the proposal will not work. Best, PeterSymonds (talk) 14:46, 28 November 2008 (UTC)
Big, the easy way to do this is to blank the page. If no one reverts you, an admin will eventually delete it. For non-garbage pages, one should blank and redirect. Emmanuelm (talk) 17:30, 28 November 2008 (UTC)
Tagging it with a WP:CSD tag will get it deleted. I'm not quite sure where "blank and redirect" comes from. If its non-garbage, why would we blank it? And then why would we redirect it? The proposal is about attack pages and obvious vandalism. In almost all cases such pages should just be tagged and deleted. Mr.Z-man 17:47, 28 November 2008 (UTC)
Wasn't to sure what Emmanuelm meant in above post. Obviously they should be tagged but say an attack page that the creator puts the {{hangon}} template on it this can lead to a situation were said article can remain for a considerable lenght of time. A delete button for trusted users would end such cases. BigDuncTalk 17:55, 28 November 2008 (UTC)
Give the admins some credit of common sense. {{Hangon}} tags are not binding, and if the admin does find it a blatant attack page, nonsense, etc, it will be deleted without question. No admin will knowingly leave a nonsense/attack page even if the hangon tag is present. PeterSymonds (talk) 18:50, 28 November 2008 (UTC)
No sorry Peter that's not what I meant of course an admin will spot it but IMO when a {{Hangon}} tag is added it slows down the time between initial speedy tag and deletion. BigDuncTalk 19:23, 28 November 2008 (UTC)
Ah okay, I see what you were getting at. But the hangon tag keeps the article in CAT:CSD; an admin will arrive at the page no slower than if the tag were not placed at all. Hangon is just a tool used for good-faith editors, especially new users, who are trying to write and develop their first article. Granted, an admin may check the talk page first, but the process will happen no slower if the hangon tag wasn't there. PeterSymonds (talk) 19:36, 28 November 2008 (UTC)
I wonder if admins look at articles without the hangon tag first and as such create a delay, could an admin answer that for me thanks. BigDuncTalk 19:40, 28 November 2008 (UTC)
I would imagine that most admins do what I do which is go to CAT:CSD, check the attack pages subcategory first then just click on the links in the main category at random. CIreland (talk) 19:47, 28 November 2008 (UTC)
I also start by attack pages, then empty and nonsense/vandalism pages, then user requests, broken redirects and copyvios. Those are the easiest and/or more urgent to delete. The hangon tag won't remove the deletion category the page is in. Cenarium Talk 23:48, 28 November 2008 (UTC)
  • Oppose per PeterSymonds in the beginning of the thread. There are way too many things to go wrong. has anybody seen Destroyed in Seconds? –Juliancolton Tropical Cyclone 20:31, 28 November 2008 (UTC)
  • Oppose Even if we allowed them to delete only recently created pages and only to undelete pages they have deleted themselves, and even if they would be allow to see only the pages that they have deleted themselves and for a limited period of time, and even if we created a review process: a special page listing deletions/undeletions by authorized non-admins ....... it wouldn't be a huge progress compared to our actual process and would require too much supervision compared to actual benefits. Cenarium Talk 23:48, 28 November 2008 (UTC)
  • I think that of all the sysop abilities, deletion, along with blocking, are the ones that a user absolutely has to go through a full rfa in order to gain - they are probably the most commonly used, and the ones which garner the most controversy. Besides, even if it is technically possible to create a user group who can delete things in a certain category of csd, which seems unlikely, whats to stop a vandal getting it then tagging 200 articles with csd:g10 and deleting them all--Jac16888 (talk) 00:00, 29 November 2008 (UTC)

This is relevant to queued deletion. — Werdna • talk 06:28, 29 November 2008 (UTC)

Queued deletion, what is that?--Jac16888 (talk) 14:11, 29 November 2008 (UTC)
Do you mean some sort of recycle bin that non admins place deleted articles to get reviewed by an admin. BigDuncTalk 14:13, 29 November 2008 (UTC)
I think Flagged revisions may be useful here. Ruslik (talk) 18:07, 29 November 2008 (UTC)
Flagged revisions would likely turn into an epic failure on such a large wiki. However that's a discussion for another day. BigDunc, see the screenshots of the proposed deletion queue at User:Werdna/dev. Best, PeterSymonds (talk) 18:17, 29 November 2008 (UTC)

While on the one hand I am open to the idea of unbundling admin rights, I find that this particular proposal is weak as it doesn't account for misuse, which is exactly what must be guarded against if we're giving the right out easily. {{Nihiltres|talk|log}} 21:26, 29 November 2008 (UTC)

  • Oppose. In my modest patrolling experience, a CSD by non-admin is usually deleted within 6 hours max. Sometimes, an admin presses the button faster than a non-admin finds a proper CSD tag. The category for speedy deletion is no more than a half-page. That is, there is no urgent need to "help" admins, they can do this part with outside help. NVO (talk) 20:54, 30 November 2008 (UTC)
  • Oppose. If there was a fool-proof and water-tight method where this would work as intended, then I would support, but that is impossible on a project like this; there is always a way to abuse the system. Foxy Loxy Pounce! 08:04, 3 December 2008 (UTC)

Pronounciation Guide

I think wikipedia should add a "pronounciation guide" to the entries. A lot of the entries are technical or scientific terms that we don't usually encounter in verbal English. If there was a wav file that could play how certain terms are supposed to sound, it would be really useful. Merriam Webster's Online Dictionary has this capability and I use it a lot. I imagine foreign users would appreciate this too.

A lot of articles do have spoken versions or voiced pronunciation. You're more than welcome to make one for an article(s) that is lacking one, but please remember that uploads should be with a .ogg extension (see Wikipedia:Media help). Best, PeterSymonds (talk) 11:02, 2 December 2008 (UTC)
Many of our articles have an IPA pronunciation, like this: (IPA:/pronunciation/). I suppose a good proposal could be a tool that generates a synthesized voice from these pronunciations on request, or, although this will probably bring the wrath of Brion upon me, automatically. Foxy Loxy Pounce! 08:11, 3 December 2008 (UTC)
I created the relatively inactive task force Wikipedia:WikiProject Spoken Wikipedia/Pronunciation task force for this purpose. See also Category:Requests_for_audio_pronunciation_(English). Dcoetzee 10:25, 3 December 2008 (UTC)
With which accent? I remember being amused by an English-Spanish dictionary in which the phonetics in the Spanish to English part clearly specified an American accent (I'm a Brit). --Philcha (talk) 08:55, 3 December 2008 (UTC)
I think it's best to have both US and UK pronounciations, where they differ. Dcoetzee 10:25, 3 December 2008 (UTC)
Which UK pronounciation? Which US pronounciation? Regional accents of English might be of interest to you. --Carnildo (talk) 22:20, 3 December 2008 (UTC)
It's a best effort thing. Any regional pronounciation is better than none, and I'm not picky. Interest is low enough in producing these things as it is. Dcoetzee 00:05, 4 December 2008 (UTC)

Automatic alphabetical sorting of categories at the bottom of pages.

IMO, it makes no sense that categories are not automatically sorted at the bottom of pages. So how about having the wiki software automatically sort things rather than have users do it with AWB or other tools. Headbomb {ταλκκοντριβς – WP Physics} 09:54, 2 December 2008 (UTC)

No reason for them to be sorted alphabetically - let editors choose the most appropriate logical ordering.--Kotniski (talk) 10:59, 2 December 2008 (UTC)
As a default behaviour that can be overiden then.Headbomb {ταλκκοντριβς – WP Physics} 11:08, 2 December 2008 (UTC)
How would the system know how to categorize then?  Marlith (Talk)  00:31, 4 December 2008 (UTC)
Well, by default it would be alphabetical, and if overridden (by something like {{Catsort:no}}, or whatever), it would list them in the specified order, like it does now.Headbomb {ταλκκοντριβς – WP Physics} 03:29, 4 December 2008 (UTC)

Wikipedia Chat bot

I am founder of JIxperts project http://jixperts.com . Its idea is to build source of information everyone can talk to. Some users talk to system, other - "experts" teach system by trying to continue dialogs system gives to them.

Possibly together we can construct chat-bot for wikipedia, which will be able to answer user questions about wikipedia articles.

Its advantages
1) Users can get the information from the conversation with the system. So it is not just "question-answer" like Powerset.
2) JIxperts algorithm could be applied to any language, where words are separated with a space.
3) JIxperts use wiki-principle for improving database

How do I see road map of bot development

1) to make wikipedia chat-bot and its web-page
2) teach to answer questions for wikipedia beginners
3) start showing this bot on some pages of wikipedia
4) Make it public for all users of wikipedia


Good luck to everyone,
Dmitry Tinitilov,
JIxperts team, Odessa

All of Wikipedia runs on MediaWiki code that is free, and available for public viewing. Are you offering to donate a system you have developed, to become a component of MediaWiki? That would be cool! --A Knight Who Says Ni (talk) 16:16, 3 December 2008 (UTC)
But the question is whether or not this will be very useful to the project. I sure hope it is.  Marlith (Talk)  00:29, 4 December 2008 (UTC)

Scrap Template:Copyedit, or at least explain how it's useful

Hosei University is a pathetic little stub of an article. However, I think (or I delude myself) that what very little it does say, it says competently enough. Meanwhile, I'm open to complaints that no, it doesn't.

By adding a very few characters, another user recently made it start A This article or section needs copy editing for grammar, style, cohesion, tone or spelling. You can assist by editing it now. A how-to guide is available. (November 2008). He and I have been discussing this (look 2/3 way down the page) to little effect, other than to establish that the beef is (beefs are) in style rather than grammar, cohesion, tone or spelling.

Let's suppose for a moment that this or some other article is indeed a stylistic nightmare, making the informative content (locutionary force?) of the template thoroughly deserved. Right then, I'd like to know:

  1. How this template helps the potential readers of the article.
  2. How this template is of more help to potential editors of the article than would be served by something similar (but preferably more informative) on its talk page.
  3. What other benefit this template has to anyone.

Note that I have no objection either (i) to being told (even brusquely) that I've committed stylistic solecisms, or (ii) to the conspicuous placing atop articles of templates such as Template:Unreferenced. For the first, you'll have to take my word for it that I'm thick skinned. As for the second, "Unreferenced" is one of a number of templates that serve to alert readers of potential danger (even fraud), readers who might otherwise be lulled into credulity by burnished, pseudo-encyclopedic prose. By contrast, if an article needs copyediting, literate readers will likely realize this for themselves, and even if they don't IMHO won't be helped in their understanding of the subject by being told the article needs copyediting. Tama1988 (talk) 07:28, 16 November 2008 (UTC)

PS You may wonder why I didn't simply send this template to Templates-for-Deletion. Two reasons. First, I'm willing to be persuaded that the template is helpful. Secondly, that I was sure any nomination for TfD would be dismissed as sour grapes at best, and more likely speedily removed as "pointy" and/or disruptive. Yet I hope that politely making a point here about the template might lead to some improvement: whether a radical revision of the template, its deletion, or something else. Tama1988 (talk) 07:37, 16 November 2008 (UTC)

Might be better to put stuff like that on the talk page. It's designed to make articles needing copyediting visible and searchable. — Werdna • talk 08:02, 16 November 2008 (UTC)

I wouldn't call your article "a pathetic little stub". It is a stub that provides an overview of the subject and, like all stubs, "it will greatly help WP if you can expand it". The problem is not the template itself but its application to a stub that does not have any major spelling or grammar problems. I think you'd be justified in referring the other party to WP:UCS. Regards. ---BlackJack | talk page 09:32, 16 November 2008 (UTC)
Well, thank you--but I don't want to air a grievance with this specific user of the template, or to score points off him. I was slightly irritated at first, it's true; but that quickly gave way to a bigger question: What possible use is there for these templates? Tama1988 (talk) 15:14, 16 November 2008 (UTC)
The use I see for a template like this on the article rather than the talk page is that it invites the reader to become an editor by pointing out something specific they can do. Anomie⚔ 14:05, 16 November 2008 (UTC)
But:
First, it doesn't point out anything specific. The person using the template has the option of making it slightly more specific (an option that this person did not take). As far as I understand it, the template doesn't even have the option of pointing the reader to a supplementary explanation on the talk page, and all in all it does nothing to encourage the template-fastener to do anything helpful whatever.
Secondly, at least for educated readers of English as a first language, errors of spelling, grammar and style should be (perhaps painfully) obvious. Why would the presence of such (utterly unspecified) errors need to be flagged? I don't see why those qualified to copyedit should need to be told that copyediting would help, particularly when I consider that such extra encouragement is just as likely to trigger "improvements" from people who don't know what they're doing. (Putting aside the matter of the stylistically clueless, we have well-intentioned beginners who may well turn "wrong" [in fact OK British] spellings to "correct" [in the US] spellings, or vice versa.) Tama1988 (talk) 15:14, 16 November 2008 (UTC)

Well, I'm not sure if it's appropriate for me to even be in this discussion, but your template question here is essentially just one of many more article issues templates. (See Template:Articleissues) In the documentation, you can find the list of all the different tags. These tags are used to flag articles for other editors to work on them (not to serve as one user's to-do list). Essentially, since the article has not reached a certain level of quality, this article is considered to be incomplete (my most Wiki assessment rubrics). Since it is incomplete, it is logical for - let's say - a grader, to mark spelling, style, etc. errors on the page if it is in print. Instead of using a red pen and marking sections with "awkward style" or "incoherent sentence", a simple copyedit tag is added above the article to show that copyediting is needed. - Jameson L. Tai talk ♦ guestbook ♦ contribs 17:56, 16 November 2008 (UTC)

Of course you're most welcome to join the discussion, and indeed to do so forcefully.
This is indeed one of a set of templates, but it seems anomalous to me as it's about matters that are on the surface. (It's not as if actual or suspected problems lurk to ensnare the gullible reader.)
The huge majority of articles, even of those on more or less static subjects, are incomplete. This one is very, very incomplete. Indeed, it's a stub, and it's so labeled. But are you really saying that incompleteness implies a need for stylistic work? If so, I don't follow this at all. (Indeed, if it were true then the stub template would render the copyedit template superfluous.)
Anyway, let's agree that, whether in this article or elsewhere, copyediting is needed. 1. Shouldn't the need be apparent to those people who are linguistically/rhetorically equipped to do the copyediting? 2. If no, a direct nudge would somehow be helpful, why should it appear on the article itself rather than in the talk page (where it could easily be augmented with detail)? Tama1988 (talk) 04:51, 17 November 2008 (UTC)

"Issue" templates that appear at the top of articles are themselves an issue, and their use (especially their "passive" use) seems to be increasing. First and foremost, they fail to recognize that Wikipedia is a work in progress, and that, barring egregious problems, there is no reason to point this out at the top of every article. Second, they are almost always placed without any accompanying discussion by the "editor". The unspoken rule about article templates that passively point out "problems" is this: unless the editor who put them there has actually begun a discourse about the problem they see with the article, you are free to remove the template, and certainly no explanation can be expected of you when none was given by the first party. Third, these templates make articles ugly. I'm all for general disclaimers about the content of Wikipedia, and in fact I'd support more prominent, global disclaimers about that content, but drive-by tagging is unproductive, unacceptable and revertable on sight. It is not editing; it is not another branch of "wikignome" editing. It is nothing. –Outriggr § 05:23, 17 November 2008 (UTC)

Interesting: You seem more strongly opposed to them than I am. As I've said, I can see the benefit of a template that says "This article has this [less than utterly obvious] problem (and so you should take its content with a shovelful of salt)." Although come to think of it you could be right about more prominent, global disclaimers as an alternative: after all, the more "unreferenced" tags readers see, the greater the risk that they'll take the lack of an "unreferenced" template to mean that an article's content is referenced (perhaps via some arcane method to which, as newcomers, they're not privy). Tama1988 (talk) 08:52, 17 November 2008 (UTC)
Well, I've taken up this "school of thought" quite seriously after seeing the atrocities—generally, the lack of any thought or insight—that accompanies most of this templating. What you echo above is a key point: every templated article, to a random reader, can be taken to imply something about every un-templated article. Wikipedia is hardly that simple and hardly that consistent. A template could highlight an important disagreement occurring on the talk page—fine—but at least in your case, there is no disagreement; after all, your interlocutor (and this is quite common) has had, what, four chances (as of the 15:42 message below) to explain his or her position—why the article needed "copyediting"—and still hasn't done so. It's hard to assume good faith when you have, right in front of you, a passive-aggressive action combined with evasion when questioned. Issue templates are another oversimplification of the kind we must avoid on Wikipedia—they pack great rhetorical power without requiring the instigator to accept the responsibility associated with their template-statement. And they should not be doled out using programs called "Friendly" (which is Wikipedia irony at its best). –Outriggr § 00:10, 18 November 2008 (UTC)
I think we need to be clear about the specific problem which is inappropriate use of the template on Hosei University and other stubs. There is absolutely no need whatsoever to tag a stub with a template like that. To quote Outriggr, it is drive-by tagging and it achieves nothing except to annoy readers and other editors. If there was a spelling mistake or a split infinitive in the stub, why didn't Jamesontai simply make a couple of quick corrections? Would it have taken any more time and effort? Would it have been a less positive action to take?
On the other hand, if Hosei University held 35k of content and it was littered with typos, errors and poor syntax, then application of the template would be necessary and correct.
There is nothing wrong with the template. The problem is that there is a minority of people using the site who do not understand when and how such a template should be applied. ---BlackJack | talk page 10:17, 17 November 2008 (UTC)
Just to be clear, it wasn't a simple spelling mistake. And even if it were really cluttered with spelling mistakes (and the user was lazy...) a quick AWB run-through would have taken care of it as well. - Jameson L. Tai talk ♦ guestbook ♦ contribs 15:42, 17 November 2008 (UTC)
To me, the specific article Hosei University is a side issue. Let's forget the periphery and go for the crux.
Outriggr writes: if [an article] held 35k of content and it was littered with typos, errors and poor syntax, then application of the template would be necessary and correct.
Why?
As I've said, an article in crap prose wears its ghastliness on its sleeve. Those capable of fixing it will see that it needs fixing; this doesn't need to be pointed out to them. (Contrast this with a template warning of a suspected hoax.)
I can think of one use for this template. Suppose a ghastly article is created by a series of IP numbers, and you get the impression that this person is (these people are) not the type inclined to waste valuable time (as they might say) in talk page discussions. A message (whether friendly, curt, firm, or informative) on a user (IP) talk page or the article's talk page would therefore be unlikely to have any effect, if it's read at all. So the top of the article is a good place to, well, start to knock some sense into the creators.
What other benefit of this template have I missed? Tama1988 (talk) 06:48, 18 November 2008 (UTC)
First, writing is not limited to either FAs or "crap prose". Second, en-wiki is full of non-native readers/writers like yours truly; we are not as sharp in spotting faint "shades of crap", especially in our own writing. I suspect that a lot of native speakers aren't perfect too; there is a gray area where the notice is relevant. I agree with the quoted statement in general: 15k or 35k, content comes first (with NPOV, RS and all that alphabet soup). First fix contents, than polish the prose. An {{unreferenced}} or {{npov}} renders {{copyedit}} useless: who would bother copyediting the content that needs a radical change or even deletion? NVO (talk) 17:55, 18 November 2008 (UTC)
Yes, there are plenty of articles that would benefit from copyediting. But how is it better--no, no, I'd ask the same question that I'm asking some lines below in response to a comment by Edjohnston Tama1988 (talk) 09:06, 19 November 2008 (UTC)

I hope it won't be considered intrusive if I chime in here. In my opinion "Drive-by tagging" or "drive-by templating" is a huge problem. I am faced with it at present in an article I started, Bethmanns and Rothschilds. To give a brief run-down, one editor dropped two Templates on the Article, "peacock" and "essay", with no explanation on the Talk page. There ensued a rather unhappy contretemps between myself, that editor and another who sided with him. I put my concern into an AN/I thread which unfortunately gathered almost no comments and slid into the archives unresolved. One of these two editors concurrently (and paradoxically) nominated the article for deletion at WP:Articles for deletion/Bethmanns and Rothschilds. A few hours ago the closing admin sent this back to the Article's Talk page as a "no consensus". Now in spite of this closure and in spite of my detailed and lengthy exposition of why the Article should be kept which I posted a few seconds after the admin's closing, one of the critics now has slapped an "original research" Template on the Article and again insists that the Article be deleted (Talk:Bethmanns_and_Rothschilds). I'd like to assume good faith but this kind of conduct just makes it very very difficult. I agree that the Article has issues and acknowledge that it needs to be improved, but telling me that the Article should be deleted a few hours after the AfD closes and slapping on a Template is, well, not so "Friendly", even if the software they used to put it on calls itself that. --Goodmorningworld (talk) 17:34, 17 November 2008 (UTC)

"Friendly" is Newspeakish, isn't it? Of course you're most welcome to chime in. But since you bring up this article, I have to say that my interpretation is different. Although the writer says that he hasn't changed his mind and that he still thinks the article should be deleted, he doesn't threaten to do anything about it. Does the article include "original research"? I haven't spent long enough reading and thinking to do more than start to form an opinion about this; however, I do think that some articles do contain OR and that flagging them accordingly might serve as a useful warning to some readers. (Ditto for the "peacock" template.) Whereas I can't say this about the "copyedit" template. (Or, come to think of it, the "essay" template.) Anyway, I'd encourage you to copy what you wrote at the end of the AfD and paste it onto the article's talk page. Tama1988 (talk) 10:58, 18 November 2008 (UTC)
Just FYI: A less intrusive approach to "copy and pasting" the entire AfD discussion onto the talk page, you might want to just transclude it and put it in a collapsable navibox so it can be hidden if it isn't needed. - Jameson L. Tai talk ♦ guestbook ♦ contribs 15:47, 18 November 2008 (UTC)
Back to the general question of excessive tagging, a tag is really a comment by one user that he thinks a discussion is needed about a specific fault of the article. The person who *places* the tag should be willing to engage in a discussion about the problems they see, whenever asked. If for any reason the person placing the tag is not available, or doesn't have time to join in on the Talk page then, after notice has been given on the Talk page and a reasonable time has elapsed, the tag can usually be removed. EdJohnston (talk) 16:48, 18 November 2008 (UTC)
Yes yes yes, bags of articles would benefit from copywriting. Yes there may be some reason for a person to point out the need (rather than to just go ahead and copyedit). But, bearing in mind that an obvious need for copyeding will anyway be obvious to those who are capable of copyediting, how is it better to point out the need by sticking an imprecise--"grammar, style, cohesion, tone or spelling"--notice on the article than to say what's wrong more precisely within the talk page? Tama1988 (talk) 09:06, 19 November 2008 (UTC)
It might be true that "an obvious need for copyeding will anyway be obvious to those who are capable of copyediting", but it is not useful if the ones willing to copyedit won't find the article itself. And there are two ways to find an article to copyedit: 1) it is possible to search for candidates in some subcategory of Category:Wikipedia articles needing copy edit, 2) it is possible to browse Wikipedia "normally" until an article to be copyedited is found. Now the {{copyedit}} template helps in both cases: it assigns the article to the category (and the copyeditors that use the category can find it), and someone who finds such article "normally" and copyedits it knows that it is necessary to remove the template (as otherwise the copyeditors who use the category will have to waste time searching for errors where none are to be found). --Martynas Patasius (talk) 19:15, 19 November 2008 (UTC)
OK, but then why not instead do one or other of this pair? (1) Put the template (or a version of the template adjusted for this purpose) on the talk page. (2) Use a category, e.g. Category:Articles in need of copyediting. The second lends itself to helpful elaboration: Category:Visual arts articles in need of copyediting, Category:Education articles in need of copyediting, etc.
Incidentally, after further brains-wracking, I've come up with an arguable justification for retaining a conspicuous "Essay" template: without it, the person browsing Wikipedia might encounter some essays (or belles lettres) masquerading as articles, and might be more likely to infer that this was an acceptable way to write articles, and might essayfy existing articles or create new essays. However, this justification can't be extended to the "Copyedit" template, because an article that obviously needs copyediting, uh, obviously needs copyediting. Tama1988 (talk) 10:05, 20 November 2008 (UTC)
Because both template on the talk page and the category as such would not be that easy to see for everyone (including potential copyeditors). Remember, if the article belongs to the category and a user corrects a mistake, the user has to remove the article from the category (unless there are more mistakes left). And that is impossible if the user doesn't even see the notice to be removed - the relevant categories are hidden and it might seem pointless to look at the "discussion" when there doesn't seem to be much worth discussing... Yes, the experienced users would probably adapt if necessary, but what about the new ones (for all we know, the tag might actually encourage them to be bold about correcting the mistakes)? And since I don't really see any serious downside of having a tag (I doubt that tags make articles ugly - who knows, some articles might even be beautified by some tags - well, de gustibus non est disputandum), I'd say that the tags should be used.
By the way, the idea to group the articles in need of copyediting (and probably some others) by subject does seem interesting... --Martynas Patasius (talk) 17:33, 20 November 2008 (UTC)
But remember, we're talking about an alleged need for copyediting. Anybody capable of copywriting who arrives at such an article won't need to be told that it needs copywriting. Yes, for all we know, the tag might actually encourage newbies to be bold about correcting the mistakes; but it might also give the message that a Wikipedia editor's normal procedure when noticing flaws is to do nothing that's directly constructive but instead to tut-tut about the flaws in a fancy rectangle in the expectation that somebody else will fix them.
The other disadvantages of these tags? The way they provide a lazy alternative to actual copyediting, and their unhelpfulness to either the general reader or the general editor. Go back to the beginning of this section and you'll see how they were first brought to my (first irritated, then mystified) attention; I still don't know what was (and thus presumably remains) wrong with the article in question. (Contrast this with, say, "{{dubious}}", which points any baffled would-be editor to a discussion on the talk page.) Tama1988 (talk) 05:12, 22 November 2008 (UTC)
(unidenting) Once again, the user capable of copyediting still has to find the page - that's the main use of such tags. And, well, if "anybody capable of copywriting who arrives at such an article won't need to be told that it needs copywriting", how would a more detailed explanation help? I suspect it would only be so if the original author wants to find out the mistakes to learn to avoid them - and then a much longer discussion (concerning the editor and not the article) is likely to be necessary.
And on the matter of "a lazy alternative to actual copyediting" - yes, in most cases it is better to correct mistakes than to add a tag, but adding a tag is still much better than not even adding a tag. After all, Wikipedia is not a concentration camp - the editors are volunteers and can do as much (or as little) work, as they want. --Martynas Patasius (talk) 16:50, 28 November 2008 (UTC)
But if the goal is to make an article appear in a list of articles needing improvement, it isn't necessary to place the tag at the top of the Article, a step that stirs up a lot of bad blood and resentment. The tag can go on the Talk page instead. The "copyedit" tag you have been discussing with Tama1988 above is part of what I call "non-self-explanatory tags" (the self-explanatory tags being tags such as "references missing").
WP:DRIVEBY, a how-to guide on the use of the NPOV tag, has this useful piece of advice:

Drive-by tagging is strongly discouraged. The editor who adds the tag must address the issues on the talk page, pointing to specific issues that are actionable within the content policies, namely Wikipedia:Neutral point of view, Wikipedia:Verifiability, Wikipedia:No original research and Wikipedia:Biographies of living persons. Simply being of the opinion that a page is not neutral is not sufficient to justify the addition of the tag. Tags should be added as a last resort.

The last sentence especially, Tags should be added as a last resort is spot on. Even if a rules change to mandate placement of tags on the Talk pages of articles is not forthcoming soon, the guidelines quoted above are common sense. They apply not just to the "NPOV" tag but to each and every "non-self-explanatory"-type tag.
  1. Do not engage in hit-and-run tagging, ever.
  2. ALWAYS provide an explanation for the tag on the Talk page at the same time.
  3. Raise the issues on the Talk page first.
  4. Use the tag ONLY as a last resort.--Goodmorningworld (talk) 02:07, 1 December 2008 (UTC)
And it is truly the correct way to deal with NPOV tags. Those tags say "(something) has been disputed". Now, if there is nothing on the talk page, and even nothing in the edit comment, then nothing has been "disputed", meaning that, technically, the tag does not belong here. But the other tags (including the one about copyediting) say "(something) is wrong with the article". The truth of this statement does not depend on anything in the talk page. And what can be written on the talk page? If one is expected to write a detailed explanation ("There are 10 spelling mistakes and two style mistakes in this article.", or even listing every single of them), that would require about as much work and skill as the actual copyediting, which would probably mean that the mistakes would stay as if they were unnoticed. And if one is expected to write something like "The article needs copyediting.", how would that really differ from the use of the tag? Also, with NPOV tags we expect that the explanation on the talk page will start a discussion to determine the best couse of action. And what discussion can be expected in case of message "This article needs copyediting."? Do we really expect it to result in "a lot of bad blood and resentment"? Personally, I suspect that the situation with Tama1988 was the "worst-case scenario" in this case (maybe even "worse-than-worst-case scenario") - or were there any Arbitration Committee cases about "copyediting" tags (as opposed to NPOV tags)?
Finally, the "copyediting" tag seems rather "self-explanatory" to me - while Tama1988's saying "an obvious need for copyeding will anyway be obvious to those who are capable of copyediting" might be an overstatement, I suspect that in many cases a more detailed message would not be that useful. Now, it would be nice if someone who adds such a tag would give one or two examples of mistakes (let's say, in the edit comment), but turning that into a requirement seems to be somewhat dangerous. --Martynas Patasius (talk) 19:26, 1 December 2008 (UTC)
Very reasonably said, for the most part. While I flatter myself that my English is moderately good, I've certainly had the embarrassing experience of looking at something I'd written earlier and realizing that it was bristling with this or that word or phrase that's fine in small doses but terrible when multiplied. I'm happy to be told that my prose suffers from an an overabundance of this or that, or is too ornate or prolix or curt or parenthesis-riddled or whatever. (I have less time for any complaint that it's not sufficiently formal or is "PC"; but I mustn't let myself get started on those kinds of allegation.) But if this tag is really necessary -- and I'm still wondering about taking it to TfD -- then why not at least (i) change
This template takes the optional parameter for=grammar, style, cohesion, tone or spelling. (this is the default, you may remove parts you don't need, e.g. {{copyedit|for=grammar and spelling.}} (Note: please include the final period)
to
*This template takes the parameter for=grammar, style, cohesion, tone or spelling. (this is the default, you should remove parts that don't apply, resulting in e.g. {{copyedit|for=grammar and spelling.}} (Please include the final period.)
and (ii) in some other way urge the would-be templater to decide between (a) adding the template and and informative comment on the talk page or (b) going elsewhere?
Incidentally, I'm amused to see how the instructions for this prissy [ah no, gotta be polite] helpful template themselves have superfluous words ("note") and screwy capitalization, and even lack a final period in the context of pointing out the need for a final period. Tama1988 (talk) 03:04, 4 December 2008 (UTC)
Yes, in this case changing "may" to "should" does look like a good idea. --Martynas Patasius (talk) 23:29, 4 December 2008 (UTC)

Change default category sortkeys

This perhaps belongs at VPT since it's a technical setting, but it will probably get more interest here. First, a somewhat length explanation of the problem...

The default setting for category sort keys is to use, effectively, {{FULLPAGENAME}} - the namespace prefix is prepended to the page title so that categories are largely separated by namespace: all Talk: pages appear by default under "T", all images under "I", etc. Of course there are some instances where this is beneficial, but there are innumerable other instances where it is not, and we make extremely widespread use of the construct [[Category:Foo|{{PAGENAME}}]] to make pages sort based on their title only. However, using explicit sortkeys like this destroys the utility of the {{DEFAULTSORT:...}} magic word, which allows us to set new default sortkeys on a per-page basis. So by using {{DEFAULTSORT:Enstein, Albert}} on Albert Einstein or Talk:Albert Einstein, we can make it categorise by surname rather than forename. However if a category link of the structure above is present on a talk page, say (to stop it categorising under "T" instead of "A") then the DEFAULTSORT key has no effect. The only way to circumvent this is to not use the PAGENAME construct but instead ensure that every page outside the mainspace incorporates a DEFAULTSORT keyword; consequently a large number of our WikiProject banners include a DEFAULTSORT magic word, explicitly setting the default to PAGENAME if no other value is given. So we have constructs like this: 

{{DEFAULTSORT: {{#if: {{{listas|}}} | {{{listas|}}} | {{PAGENAME}} }} }}

...

[[Category:Foo]]

This solves the issue by defaulting to PAGENAME, but allowing the sortkey to be overridden using the |listas= parameter. However, this causes yet another problem when there are two such templates on a page: the last DEFAULTSORT on a page overrides all the previous instances, so if the last such call is using the default values, then the previous implementations are overridden. This can be problematic, see for instance Talk:Charlie McCreevy, where the undefined |listas= parameter in {{WikiProject Ireland}} overrides the correctly set parameter in {{WPBiography}}. The devs have only very recently created a warning message that flags up these errors, previously they were entirely silent. I've just added a tracking category to the message (Category:Pages with DEFAULTSORT conflicts), and it's already filling up (note that categories populated from MediaWiki messages populate incredibly slowly).

This situation is, to be frank, a complete mess, and it's all caused by MediaWiki setting the default sortkey to {{FULLPAGENAME}}. However, it is possible to change this: there is a configuration variable, $wgCategoryPrefixedDefaultSortkey, that controls whether categories use {{FULLPAGENAME}} or just {{PAGENAME}} as their default sortkey. On en.wiki this variable is set to true; by asking the devs to change it to false for en.wiki, we can entirely eliminate this horrible mess. If the default category sortkey is just the page title, we won't need to take any action at all in the majority of cases to get pages to categorise properly. Only if we want to, say, order by surname for BLPs, will we need to include a DEFAULTSORT. So we can adopt the (normal and expected) way to use DEFAULTSORT - include it only when there is an explicit value for it to be set to, and not include it otherwise.

In order to get any configuration change enacted, we need to present a clear consensus to the developers. So the question is: is this change a good idea, and should we request it? Happy‑melon 22:55, 23 November 2008 (UTC)

Support - I see no problems with implementing this change. -- Imperator3733 (talk) 04:04, 24 November 2008 (UTC)
Support—this makes total sense, after considering the details. The {{PAGENAME}} default seems quite superior for most general purposes. {{Nihiltres|talk|log}} 04:32, 24 November 2008 (UTC)
Support - {{PAGENAME}}, not {{FULLPAGENAME}}, would be typically useful. -- Fullstop (talk) 16:48, 24 November 2008 (UTC)
Neutral - I'm wary to leave my support for this; while I don't know if any such exist, nor do I know if such are allowed, it is a possibility that categories have intermixed namespaces in them, possibly making them difficult to navigate should the behavior of the default sortkey be changed. It would seem such should be hunted down, but all the same... --Izno (talk) 17:14, 24 November 2008 (UTC)
While I know of some such categories, some would probably be improved by this alteration. If the category is large (more than a few hundred pages) then sorting by namespace first renders the list essentially unsearchable, as it is not possible to get closer to a target page than the first (or last) page in the same namespace. There are certainly no examples I am aware of where the category is not added by a template, so where sorting by PAGENAME only is not desirable, as with, say, Category:Pages with incorrect ref formatting, an explicit sortkey of FULLPAGENAME can be trivially added to the category link (in {{broken ref}} in this case). Resolving these issues would form a part of the cleanup required after this change is implemented. Happy‑melon 18:20, 24 November 2008 (UTC)
Support - I have worked a lot with category handling, and I agree, this would be a big improvement. --David Göthberg (talk) 04:52, 25 November 2008 (UTC)
Support - This would also fix several problems with user categories. Also, for categories which categorise things from several namespaces, there is already a symbol system for sorting. (See Template:Template category.) - jc37 17:20, 25 November 2008 (UTC)
Support, as long overdue... shoulda thunk to question this default four years ago. // FrankB 21:44, 25 November 2008 (UTC)
Support. This'll fix a lot more category sorting problems than it'll cause, and explicit sort keys can still be applied where the default is unsatisfactory. —Ilmari Karonen (talk) 21:59, 2 December 2008 (UTC)
Support Having to use [[Category:Xyz|{{PAGENAME}} has always annoyed me and this is an elegant solution. Additionally, it will not break any pages using the Village pump (proposals)/Archive 40 sorting format and I have never seen a category that uses Wikipedia:Village pump (proposals)/Archive 40 sorting. Foxy Loxy Pounce! 07:37, 3 December 2008 (UTC)
Support. Sorry I'm late to the party. This is a great idea. --Kbdank71 19:04, 3 December 2008 (UTC)
I've now opened a bug (T18552) for this; please do continue to comment on this proposal so we can present as clear a consensus as possible to the developers. Happy‑melon 19:40, 3 December 2008 (UTC)
Strong support - this anomaly has been ticking me off for a while. – ukexpat (talk) 05:05, 5 December 2008 (UTC)

Deletion of list articles needs a WP:LAFD (list article for deletion) page as a different category of article

In light of the discussion at WP:CLN it is apparent that lists and categories complement each other on Wikipedia, and are often used to do many of the same things. There is much overlap and duplication between them, and that's good. It is not good when deletion discussions involving them are not handled by the same people. Which is occuring now.

When somebody has a problem with a category they don't like, they come to category-for-deletion WP:CFD, because the criteria are not the the same as for articles (we also have separate deletion discussion boards as you see in WP:XFD, eight in all, for other things). However, when people want to delete a list article (list of ships, List of trees, List of birds), which is essentialy the same thing as a category, but in list-form, they go to the article deletion discussion page, WP:AFD. That's not good, because the criteria for notable articles are not the same as those for list-articles. The latter only need a header paragraph to explain themselves (see WP:LIST and especially WP:STAND), and then elements which are individually notable. As in List of birds. But other kinds of wiki-articles normally put up for deletion have more stringent notability requirements, and their verifiability methods are not of the same type (a list article many only have hyperlinked elements and nothing else).

All this produces very WP:LAME edit wars, as you see on the WP:DRV page. For example, List of bow tie wearers has been up for deletion 4 times, and has only survived by now having many, many in-article cites, which makes it look very much unlike List of birds. All that because nay-sayers demanded article criteria for what is essentially a category in list-form. You can see much the same type of problem with List of notable people who wore the bowler hat, which is now up for deletion review on WP:DRV on the grounds that some people are arguing that the existence of the list itself needs defending as a point of WP:V, when in fact, this is really a "what categories are natural?" discussion.

  • I propose that a separte page be created for proposed deletions of list-articles.

Comments? I'm going to repost this around on the several TALK pages which deal with this matter. SBHarris 01:25, 27 November 2008 (UTC)

Well, some are, and some are not. If you want to boggle your brain, consider what is happening at List of Chinese people. But I still think we need a separate page which discusses list articles WP:LAFD, so we can deal with this odd (neither one thing nor the other) category. SBHarris 23:31, 30 November 2008 (UTC)
If you just duplicate an existing process, either CFD or AFD for lists, all that's going to happen is that the new process will get less participation simply because it hasn't been around as long. You'll probably get a higher percentage of people interested in lists, but a lower number overall. And I'm not even sure a higher-percentage of people interested in lists is a good thing, for example if you get a large number of people interested in keeping lists because they don't care about OR and like lists better than categories. Its less likely to attract diverse opinions. I think as long as we consider lists "articles" we need to treat them the same way we treat articles. Mr.Z-man 23:52, 30 November 2008 (UTC)
But the problem is, we don't consider stand-alone lists as "articles" insofar as what they need in the way of references. Again, see WP:STAND. Any new category or list on Wikipedia that exists nowhere else on paper or on the web, is really (in a way) a kind of original research, since it involves organizing information within the encyclopedia, in a novel way. That's what makes it like a category. But original research, or at least original thought, is against policy; at the same time, a low level of it cannot be avoided. So you see the problem. Example: you will not find a book or reference that actually attempts a List of Chinese people, or even a List of British Jews. But WP bravely does -- the Chinese one will be split soon, no doubt ;). What do we do, in the meantime? SBHarris 23:59, 30 November 2008 (UTC)
WP:V applies to everything we present as content to readers - articles, categories, images, portals. Saying a person is Chinese or is both British and Jewish are statements of basic facts. As such, it really doesn't need inline references as its easily verifiable if not plainly obvious or common knowledge. We're free to organize information in articles in any way we please, we don't have to cite sources just for organization, else how would we write articles where there isn't any one source that covers in every section of the article? I don't see why we need to do anything. AFD works. Just because people repeatedly nominate an article for deletion means there is a problem. And even if it was, creating a new deletion process isn't going to fix that unless it forbids multiple nominations of the same page. People are just going to use the new process instead of AFD, and the outcome will likely be the same each time. Mr.Z-man 00:40, 1 December 2008 (UTC)
  • I am strongly opposed to such a proposal because per Wikipedia:Stand-alone lists, "stand-alone lists are Wikipedia articles, and as such are equally subject to Wikipedia's content policies such as Verifiability, No original research, Neutral point of view, and others." Any attempt to change orloosen the list criteria or seperate lists from articles will undermine the spirit of Wikipedia's core policies. While lists and categories can be synergistic, every category doesn't have to be backed up by a list. Lists adhere to stricter guidelines than categories and if a list doesn't meet Wikipedia's content guidelines, then just stick with a category. Themfromspace (talk) 00:54, 5 December 2008 (UTC)

IMO, it makes no sense that categories are not automatically sorted on the sidebar. So how about having the wiki software automatically sort things rather than have users do it with AWB or other tools.Headbomb {ταλκκοντριβς – WP Physics} 09:56, 2 December 2008 (UTC)

I agree with this one though. And the less common languages (at least those that don't have a two-letter code) should be kept out of the way of the others, preferably in a drop-down "other languages" list at the end of the main list.--Kotniski (talk) 11:01, 2 December 2008 (UTC)
There was a big debate on this at some point - by what criterion they ought to be autosorted. In the end they weren't. I'm afraid I have no links. Dcoetzee 10:28, 3 December 2008 (UTC)
Currently, AWB sorts them alphabetically (full name, not by the two letter tag). I've never seen anyone complain, so I assume this behaviour has consensus.Headbomb {ταλκκοντριβς – WP Physics} 03:30, 4 December 2008 (UTC)
What does it do with those which are not written in Roman letters?--Kotniski (talk) 09:29, 4 December 2008 (UTC)

Backing up wikipedia

does wikipedia have backup hard drives and other storage mediums to back up the main servers? if not wikipedia should immedietly make backups and store them in a bomb proof freezer.Julius Ceasarus From Primus (talk) 00:35, 4 December 2008 (UTC)

I think you want a fridge, not a freezer. --NE2 00:40, 4 December 2008 (UTC)
I sure hope so. But all that we know is that Wikimedia is buying truckloads of Sun servers. That might signify a move to more secure ways of storage.  Marlith (Talk)  00:41, 4 December 2008 (UTC)

It's backed up. Don't worry, we have experienced systems administrators who know what they're doing, and who know that we need backups. — Werdna • talk 01:01, 4 December 2008 (UTC)

Better, you can back up the whole thing on your server, and legally too. This will be particularly useful for the day when the internets go bankrupt and that nice Professor Bernanke says because all the money has gone into keeping the pointlessly-macho-truck industry on life-support, the internets will close down for good, but you still have a pressing need for authoritative information on comic strip heroes or porn actresses or Pokémon or one of the other encyclopedic subjects that Wikipedia does so well. Tama1988 (talk) 03:13, 4 December 2008 (UTC)

I could tell the horror story about the time I was a computer operator (early 1980s) and we all made a trip to the vault to see where they were storing the "permenant" long term back-up tapes we'd been sending down there for years. Let's just say, there was a humidity problem. You know the sound masking tape makes when you peel it off the spool? Nuff said. --A Knight Who Says Ni (talk) 21:23, 4 December 2008 (UTC)

mw:Extension:Nuke

Seeing the discussion regarding "EmergencyDeSysop" reminded me of another extension debate. Does anyone know what is happening with mw:Extension:Nuke? From what I recall, the discussion here was clearly in favour of implementing it on EnWiki. --Ckatzchatspy 00:02, 5 December 2008 (UTC)

I seem to remember consensus went the way of wanting an unnuke ability to match before activating it, whether that was ever proposed to the developers I don't know--Jac16888 (talk) 00:09, 5 December 2008 (UTC)
See this. --Kanonkas :  Talk  01:15, 5 December 2008 (UTC)

Sister Projects

Hi. First of all: I am mostly on the norwegian Wikipedia and do not usually follow the talk here (so please let me know, and direct me to the talkpage, if this has been proposed and rejected before). I proposed Sister Projects on the no.wp village pump november 7th, but the proposal was rejected (some positive response and the negative was mainly that the possibility exist with templates like {{Wikisource}}, {{Commons}} etc. and it might clutter the lefthand menubar)

Here on en.wp I can se {{Sisterlinks}} and the other templates mentioned above is used in articles. But on commons, some wiktionarys (like the German) or on wikipedias (like the Italian) the linking is added in the lefthand menubar above "Languages".

So my proposal is to do like the Italians and make a SisterProjectbox above the Languagebox instead of cluttering the articles with boxes all over the article. But I know some articles is more than one-to-one and therefore more than one link to one sisterproject is permitted (but of cause the total number of links can not be to great due to limited amount of space). Ulike the solutions on the other projects I think it would be more smooth to let the Sisterikon link to the project mainpage and the articlename link to the sisterarticle – maybe it is easier just to try my proposal out:

sisterprojects

Wikitionary Main Page
 Einstein
Wikiquote Main Page
 Albert Einstein
Commons Main Page
 Albert Einstein
CommonsCommons Main Page
Commons
   Cat:Albert Einstein
Wikibooks Main Page
 General relativity
Wikibooks Mainpage
   Special Relativity
Wikisource Mainpage
 Albert Einstein

Prillen (talk) 15:02, 27 November 2008 (UTC)

Hmmm... interesting. Certainly the it.wiki implementation is feasible; they wrap their sisterlinks in an id'd div in it:Template:Interprogetto and then move the whole block into their sidebar in it:MediaWiki:Common.js. It's portable, and although we could certainly clean it up (I'd prefer to see individual links in individual templates, to get as close to the interlanguage interwiki syntax as possible) it's doable here. We'd have to be careful though, on sisterprojects there is a distinction between "equivalent pages" and "related pages"; we have many templates on articles, for instance, linking to Commons categories. I'm not sure if these are very well suited to being sidebarred. On the other hand, for articles on living creatures, an equivalent article on WikiSpecies may well exist. Some things to think about (I must dash, maybe I'll expand later).... Happy‑melon 17:41, 27 November 2008 (UTC)

A definite improvement over the sister project boxes. We have single or multiple individual boxes, and grouped boxes. Sometimes there's no suitable endmatter section to put them in, so they are in the text, in an empty section, or hanging below all text. Messy, and constantly being shuffled around.

A standardized sidebar layout is definitely better.

I'm not convinced that the icons are necessary—they may stand out too much from the other sidebar boxes. I'd like to see how they look in context. They should probably be smaller, and aligned with the little blue square bullets. And I'm sure they shouldn't be repeated—use a project icon for the main list item bullet, and then plain blue square bullets for subordinate items. This would avoid repetition and make the hierarchy clearer.

Start with a simple version. Features can always be added, but it's hard to delete them if it's too busy to begin with. —Michael Z. 2008-11-28 19:29 z

I would just add a simplyfied version following the sugestions made by MichaelZ., but I think the icons are nessessary, otherwise we need to write out what project we link to. (If you want to do your own ajustments to the layout you are welcome to copy/edit User:Prillen/Sister projects2)
Wikitionary Main Page
 Einstein
Wikiquote Main Page
 Albert Einstein
Commons Main Page
 Albert Einstein
  Cat:Albert Einstein
Wikibooks Main Page
 General relativity
  Special Relativity
Wikisource Mainpage
 Albert Einstein

. Prillen (talk) 20:43, 28 November 2008 (UTC)

I certainly think we should write out what project we link to (but I'm not opposed to retaining the icons as well). Sure, it takes a little extra space, but it would make people interested in actually using the box. Very few people, I assume, know what these icons stand for (especially in that small size), and of the ones who don't, almost nobody will hover over them to find out. If people don't know what the box is for, chances are they'll just disregard it. Which is a shame, because I think this layout would be a real improvement. -- Jao (talk) 21:49, 2 December 2008 (UTC)

Have a look at http://zajac.ca/wikipedia/sisterprojects. It's a pain to add list-bullet images in wikitext, so I did a proposal in plain HTML, on another site. No tables or embedded images, just nested lists with CSS-styled bullets. —Michael Z. 2008-12-03 00:38 z

Support Mzajac's proposal is elegant and looks good. I believe it would help create a stronger web between projects and make the sidebar more attractive (the pictures give it a nice touch). Foxy Loxy Pounce! 08:00, 3 December 2008 (UTC)
Second that. Great improvement on an already great proposal. -- Jao (talk) 13:40, 3 December 2008 (UTC)

To me it is important that this feature is implemented, not the actual layout though I agree that Mzajac's proposal is easier to understand for a firsttimer (and I guess a script could change the layout for each individual user). The reason I used a table is that I can not program and this was the only way I could make the illusion... I others words I can not do the implementation (and run a bot - I suppose thats helpful in changing all the pages containing sister project linkboxes). As I see it this feature would require:

  • The code for the mainpage
  • A bot changing all (or most) of the linkboxes
    • Some manual work on some pages (if a bot can not do them all...)
  • An update (discussion and writing the actual guidepages) to the sister project guidelines

As mentioned above I can not do programming, but I can do (at least some of) the last two subjects. Prillen (talk) 08:53, 3 December 2008 (UTC)

You could update the {{sisterlinks}} and related templates to use the new feature. That way, all of the pages which are currently using the templates will automagically use the new sidebar. Harryboyles 01:15, 5 December 2008 (UTC)
  • I recently came up with the same idea and I fully support it. Having a box that combines sisterlinks in a coherent yet short fashion is useful, because topics with entries in multiple such projects can be overcome by the large boxes. I also believe the icons should be used instead of fully describing the project to save space. - Mgm|(talk) 11:45, 5 December 2008 (UTC)

I've updated the example slightly: included consistent namespace abbreviations (C: for category, A: for author), and added clarifying title attributes (tooltips) to all the links.

Should this box appear above or below Wikipedia's interlanguage links? —Michael Z. 2008-12-12 16:12 z

mw:Extension:EmergencyDeSysop

Ever since I heard of the extension, I wondered why this wasn't active. I propose that we add this Extension to the English Wikipedia, so that if there is ever a rogue admin case, we can stop it in seconds, rather than minutes. - NuclearWarfare contact meMy work 05:20, 4 December 2008 (UTC)

It seems like a terrible idea for a project of this size. Stewards can act just as quickly as any admin could. This is not a good idea. --MZMcBride (talk) 05:22, 4 December 2008 (UTC)
(EC) I don't really like the idea of sacrificing your own bit to get someone else down. It rebels against IAR in my mind. How is this much better than just letting crats be able to revoke adminship as well as give it? bibliomaniac15 05:23, 4 December 2008 (UTC)
I'm not going to comment about the proposal, but on the crats revoking adminship, it's because 1. revoking adminship is much more controversial than conferring it (there hasn't been a time in recent memory where revoking adminship did not cause drama), and 2. the crats were not given their bit on the grounds of being able to revoke adminship, due to controversy that surrounds such an act as mentioned above. —kurykh 05:29, 4 December 2008 (UTC)
Yes, yes, I am aware of the controversy. The stewards do their job fine, it's just that I find the whole thing a little illogical. bibliomaniac15 05:48, 4 December 2008 (UTC)
  • (EC) I can see how this has the potential to be much faster acting than what we have right now (it takes an appreciable amount of time for a steward request to be acted upon, while the drama boards are are always crawling with admins) which could be useful in an emergency, and I think that some sort of emergency desysop tool needs to be implemented, however IMHO this 'sacrifice yourself to take someone else down' idea is a bit more suited to a RPG than WP. Icewedge (talk) 05:37, 4 December 2008 (UTC)
I think it's a good idea if the 'crats use it only as an EmergencyDeSysop tool. עוד מישהו Od Mishehu 13:00, 4 December 2008 (UTC)
This is totally unnecessary, trying to fix a problem that does not exist. The average response time for stewards is, as noted, within minutes, and the steward approach is clean, controlled and mature. Where is the evidence that this is not fast enough? This proposal creates and condones a 'kamikaze' mechanism by which the group of users capable of making desysoppings is increased by a factor of a hundred. It is a highly attention-grabbing mechanism that would serve to inflame disputes if it was ever used in disputes; at the same time the high publicity would make it attractive in precisely those situations. Where is the need? Happy‑melon 13:30, 4 December 2008 (UTC)

The point of the extension is not as, as other people have mentioned, to revoke adminship, but to provide cases where admin accounts that go beserk are easily stopped. During the last Wikimania, I believe, an admin account went on a rampage, and since there were no stewards around, it took 17 minutes and developer intervention to stop this. Luckily, there was no massive permanent damage done then, but there could have been. We're all aware that admin accounts have the capacity to do a huge amount of damage. In the interest of preserving their sanity, this extension could go live. It should be labeled as clear that this is only to be used in the extent of a compromised account, and any case where one admin sacrifices the bit in a nonemergency situation should simply makes it impossible for him to reapply for adminship for a very long time. NW's Public Sock (talk) 16:17, 4 December 2008 (UTC)

I know what the extension is supposed to do; but that doesn't mean that it will only ever be used legitimately. It gives the technical ability to remove sysop rights; deducing what will happen beyond that is dependent on making assumptions about reasonable behavior; assumptions that are not always valid (otherwise the situation of rogue admin accounts would never arise. Happy‑melon 16:38, 4 December 2008 (UTC)
I also do not like this Kamikadze Extension. As it is known from the history kamikadze did not prevent one country from defeat in the war. Ruslik (talk) 17:09, 4 December 2008 (UTC)
There's always at least one steward active in #wikimedia-stewards connect, at any one time, per requirement. It'll be much easier and quicker to flag one of them, than using this tool and thus removing your own admin bit too. PeterSymonds (talk) 18:25, 4 December 2008 (UTC)
Maybe I misunderstand what you mean by "requirement" but it seems unenforceable in the absence of paid wages. My own thought is that an innovation giving incompetent admins more rope to hang themselves (without doing any real damage) can't be entirely bad. — CharlotteWebb 18:46, 4 December 2008 (UTC)
It's a way for incompetent admins to hang other admins, which is a whole different ballgame. Has anyone considered what a compromised admin account can do with these powers? Anyone fancy "emergency desysopping" Jimbo? Or an arbitrator? Or maybe just the most prominent admin involved in countering their work? Working on the very reasonable assumption that 'good' admins will be somewhat reluctant to invoke this option, I see the natural progression as being warn → block → kamikaze. If I were a compromised admin account vandal or just a rogue admin, I would have two tabs open on my browser throughout my spree of destruction: "unblock self" and "kamikaze someone prominent". They're going to lose the bit eventually, why go out with a bang?
Now consider a wheel war, suddenly we have a whole new level of escalation to be afraid of. Admin A blocks user Y; admin B unblocks. Admin A posts to ANI, admin C reblocks. Admin B unblocks again; admin A blocks Admin B, Admin A unblocks self, is blocked again by admin D, admin B unblocks self and kamikazes admin A. What a mess. I'm not saying necessarily that this extension is always or even ever going to be actually employed that way, but by its very existence it extends the possibilities and so makes escalation of some sort more likely. And what is this weighing against? A fractionally faster response to situations that are both extremely rare and usually resolved within minutes? Doesn't sound like value for money to me. Happy‑melon 19:01, 4 December 2008 (UTC)
If they hang other admins, contact a bureau to resysop the wrongfully desysoped one and block the other for being an idiot (alternatively, just leave them desysoped). If an admin chooses to employ this ability, he should know full well that what he is doing will remove his bit, and if used with malevolence in mind, then he probably shouldn't have been administrator in the first place. If the account is compromised, as you say, why would they be the ones to remove the bit on themselves in lieu of someone else's removal as well (you seem to have posted this point, but perhaps not have realized that it supports the opposing side?)? That just ends their reign even earlier than if a steward gets to them first.
As for wheel war, you're taking things out of context I think. Escalation is always possible, and again, the aggressor (Admin B) will likely have their bit removed permanently and then possibly banned and/or blocked. The only negative then being that we have admin A without a bit, which can be granted even faster than removed in the event that the drama (there would be drama anyway) that plays out says admin A was working within his bounds (which I doubt would be the outcome anyway), for the very fact that there are more that can grant adminship available. Your argument that "A fractionally faster response to situations that are both extremely rare and usually resolved within minutes? Doesn't sound like value for money to me." doesn't hold water here to me, because an admin wheel-warring in that manner is just as rare as the vandal that managed to get ahold of an administrator's account. I'd say, EmergencyDeSysop has just as many benefits as negatives, and to me, the benefits certainly make a better case for enactment than the negatives do for rejection. --Izno (talk) 01:26, 5 December 2008 (UTC)

Ah well there will always be admins who are dumb enough to use this feature, whether it is enabled or not. Sure this could be considered a way to "go out with a bang" but the potential for harming the project (compared to deleting the main page, blocking Giano, vandalizing the site-notice, etc.) would be minimal and unrepeated. Even if it is abused the effect would be easier to identify and correct than if the same admin made several less serious blunders over a longer period of time. I'm saying this because the "potential for abuse" argument reminds me of various proposals to make it impossible for admins to "wheel war" or unblock themselves or delete the main page or whatever. My thought on that was if you put everyone in a straitjacket you'll never know which ones were insane beforehand and which ones are just pissed off because they can barely move . I don't really care whether this is enabled, but I do find the paranoia against it somewhat irrational. — CharlotteWebb 20:41, 4 December 2008 (UTC)

Solution in search of a problem. — Werdna • talk 23:56, 4 December 2008 (UTC)

Isn't the Abuse Filter (which you designed, and I highly support) a solution in search of a problem? We have very simple ways of stopping Grawp right now, using unofficial adminbots, but a better solution is always better. So why not do the same for this? - NuclearWarfare contact meMy work 05:03, 5 December 2008 (UTC)

Now, a few users have opposed this based on the fact that using this would lead to drama. Now, currently, what would happen is a administrator who is having an argument with another user and goes over the line would block the other user. No matter what, there would be drama in that case. But if the admin decided to Emergency Desysop instead, they would gain no tangible benefit; they would lose their adminship anyway. That additional measure should keep even the most crazed administrators from desysopping, and administrators doing it in a true emergency could easily regain their bit. - NuclearWarfare contact meMy work 05:03, 5 December 2008 (UTC)

Let me elaborate. The abuse filter isn't relevant here, but I'll humour you. It provides a better, more effective way of dealing with pattern vandalism while leaving minimal mess. In this case, we already have a good way of desysopping rogue administrators. It's sane, dignified, leaves little mess other than the vandalism that needs to be cleaned up, and is fast (average response time is something on the order of a few minutes). This isn't a suboptimal solution, unlike the solutions to the problems of page-move vandalism. By contrast, this proposed solution to the problem of 'rogue administrators' creates more work (somebody has to give the sysop group back), doesn't make a discernible difference to response time (maybe a factor somewhere between 1 and 2 faster), and introduces problems of its own, by allowing 1600 largely unaccountable administrators to remove groups from each other. The removal of the sysop group from both parties is a bit silly, because, with sufficient pretext, an administrator who initiates an emergency desysop could be re-added to the sysop group very quickly, unless we want to make people go through some process to get their rights back after initiating an emergency desysop. This would mean policy and process creep, gaming, and other fun stuff. And for what? A minute or two of saved admin time every few months/years.

This is, of course, an excellent example of a systemic focus on the dramatic things like rogue administrators. In reality, there are very few rogue administrators on Wikipedia who would warrant an emergency desysop in sub-minute timing, these events being the sorts of things that happen once or twice a year, at maximum. More time is probably spent creating this proposal than will be spent on fixing up vandalism by 'rogue administrators' over the next year or two. While I'm sure we all like the idea of playing the hero by sacrificing ourselves for the greater good, Wikipedia is a place for work, not theatrics. Honestly, we need to deal with real content problems – not dramatic things like rogue administrators. — Werdna • talk 12:44, 5 December 2008 (UTC)

New CSD: Newly created unreferenced articles

Moved discussion to Wikipedia talk:Improving referencing efforts - Mgm|(talk) 14:36, 6 December 2008 (UTC)

Close Latin and Sanskrit Wikipedias

It recently came to my attention that the Klingon Wikipedia had been closed against further editing and ultimately transferred to Wikia. I propose the same be done with the Latin and Sanskrit Wikipedias (and all Latin and Sanskrit Wikimedia projects except Wiktionary, Wikiquote and Wikisource) for the same reasons: no native speakers, too few speakers at all to build a strong community, no agreed-upon terms for a lot of important concepts, no way to add new words for new concepts. NeonMerlin 18:54, 7 December 2008 (UTC)

This is a wrong forum. You should try on meta. Ruslik (talk) 19:00, 7 December 2008 (UTC)
See m:Proposals for closing projects. Best, PeterSymonds (talk) 19:00, 7 December 2008 (UTC)

If an external link title spans two lines on a page (not in the editor), there is space behind the last character in the link title. If restricted to one line the same link title precedes a symbol instead of the space. Shouldn't this symbol appear in any case (including that of a link title spanning two lines)? Due to different numbers of characters per line depending on the screen size I give no examples, but everyone can test this bug (?) themselves.--Emaster82 (talk) 20:49, 2 December 2008 (UTC)

Here's a 1-line example
Here's a 2-line example: gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld
Dendodge TalkContribs 16:31, 4 December 2008 (UTC)
Hmm... works fine for me. Dendodge TalkContribs 16:37, 4 December 2008 (UTC)
I can't see the symbol after the 2-line example and as no words follow the link title no space is visible as well. So let's amend the example: Here's a 2-line example: gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld gfhsdgjj hfdsf jhshfklsh gsxhlsfdh ghkhk kljhgldfgj hjlxglk kfjgld no symbol, but space after the link title--Emaster82 (talk) 08:24, 5 December 2008 (UTC)
It's presumably a browser difference. I can see the external link symbol after both of your links just fine on Firefox 3.0.4. —Ilmari Karonen (talk) 00:04, 9 December 2008 (UTC)
You're correct. The Firefox browser works for me as well.--Emaster82 (talk) 16:13, 10 December 2008 (UTC)

Wikipedia should use reCAPTCHA

If you add a link to Wikipedia as an unregistered user, it asks you to fill in a CAPTCHA to reduce spam. Instead of generating your own CAPTCHA, you should use the reCAPTCHA plugin for Mediawiki. Then all your unregistered editors will be helping to digitize books and make information freely available to the public in more ways than one.

Yuck. ♫ Melodia Chaconne ♫ (talk) 04:45, 8 December 2008 (UTC)
Correct me if I'm wrong but most spam on Wikipedia is added by humans, not computers. And once found, the computer-generated spam can be reversed pretty quickly. CAPTCHA would just be more trouble than its worth. Themfromspace (talk) 05:07, 8 December 2008 (UTC)
We already use CAPTCHA here, anons and new users have to pass one to insert a link, hence, no robot spamming, only human. The proposer is suggesting we implement a system that uses old book text as captcha code, to translate it for storage. I do quite like the idea, but I'm pretty sure it has been proposed before and rejected, might have been due to copyright issues, can't really remember --Jac16888 (talk) 05:14, 8 December 2008 (UTC)

This is proposed, on average, once a month. The primary reasons for rejection are from Brion Vibber, our CTO, who states that it is proprietary, they won't let us run it on our own servers (ie it introduces a dependency on an external server), it relies on proprietary technology, the words are rarely readable, and it has a weak audio CAPTCHA. — Werdna • talk 05:19, 8 December 2008 (UTC)

Added to WP:PEREN#Use reCAPTCHA. Mr.Z-man 23:46, 8 December 2008 (UTC)


The words on reCAPTCHA are more readable than the ones Wikipedia uses, and Wikipedia's CAPTCHA is not audio accessible at all ("Unfortunately, this may inconvenience users with limited vision or using text-based or speech-based browsers. At the moment we do not have an audio alternative available.")

The reCAPTCHA page says "reCAPTCHA is mostly powered by open source software. We'd like to thank all open source developers for creating tools that help in developing applications such as ours" http://recaptcha.net/aboutus.html Even if it's not entirely open source, Wikipedia obviously isn't, either. I think this would be a good thing to make an exception for, since it subverts the efforts of spammers by using their labor to support a project that shares the same goals (digitizing books for the Internet Archive to educate the public). Surely Wikipedia has a lot of people trying to post linkspam.

Also, isn't taking load off the Wikipedia servers a good thing? If it's really proposed once a month, maybe there's a good reason. Justanothervisitor (talk) 00:18, 9 December 2008 (UTC)

Wikipedia's servers can cope fine with the current workload (mostly). A change like this cannot be done from community consensus, its a foundation issue, we can't tell them to change something like this. As it, its extremely unlikely the foundation would agree to such a thing, why not try and get the owners of recaptcha let us use it on ours servers?--Jac16888 (talk) 00:34, 9 December 2008 (UTC)
Actually, Mediawiki and the rest of the infrastructure is entirely open source, and that philosophical concern has been a major sticking point. (Personally, I don't know that it should be given so much weight, but it has been.) Dragons flight (talk) 00:37, 9 December 2008 (UTC)
Strong support - supports another project with complementary aims, and would be a lot better than the crappy captcha I had to do today - the word was almost unreadable. DuncanHill (talk) 00:31, 9 December 2008 (UTC)
You had to do a Captcha on Wikipedia? (I'm assuming not, since you shouldn't have too, but just to check)--Jac16888 (talk) 00:50, 9 December 2008 (UTC)
Yes - I had logged out of the secure server (which I was using owing to certain local difficulties affecting the United Kingdom at the moment), and then had to log back in to the ordinary server, and it made me do a captcha. DuncanHill (talk) 00:52, 9 December 2008 (UTC)
Really? I log in almost every weekday morning and never have had to do one. ♫ Melodia Chaconne ♫ (talk) 01:05, 9 December 2008 (UTC)
(EC)Ah ok, had me a bit confused for a minute there. It is damned annoying what all the IWF is doing to the UK, glad I've got the bit to make me exempt, discovered that my house Ip, and the IP networks for both my uni lab and uni library(diff networks) are included in all this.

If you want to argue for the use of reCAPTCHA on Wikimedia projects, you should take it up with our CTO Brion Vibber, who has repeatedly rejected proposals for its use, for the reasons I outlined above (of which I note only two have been addressed substantially). — Werdna • talk 02:26, 9 December 2008 (UTC)

Search box position

It's been suggested a couple times before that we move the search box to the top of the sidebar, as the Wikimedia Commons, German Wikipedia, French Wikipedia, Polish Wikipedia, Portuguese Wikipedia, Dutch Wikipedia, French Wikisource, Russian Wikisource, and Portuguese Wikisource have now done. This can now be accomplished by editing MediaWiki:Sidebar—no CSS or JavaScript trickery required!

This would make the search box more prominent and easier to find, especially on small-screen mobile devices. So, my question is: is there support for doing this, or do you prefer leaving the search box between the "navigation" and "interaction" boxes? —Remember the dot (talk) 22:06, 8 December 2008 (UTC)

Better yet, we could hide the "search" caption too, as the Norwegian Wikipedia has done, although that will require a bit of CSS. —Remember the dot (talk) 23:09, 8 December 2008 (UTC)

I personally prefer it where it is, but that's just me (and maybe just me). PeterSymonds (talk) 23:13, 8 December 2008 (UTC)
All right, well, here's a mock-up of how it would look:
—Remember the dot (talk) 23:28, 8 December 2008 (UTC)

This was just recently discussed at MediaWiki_talk:Sidebar#Moving_search_box_above_navigation. Please continue discussion there. Cheers. --MZMcBride (talk) 23:41, 8 December 2008 (UTC)

Ah, sorry, I missed that discussion. I'll go weigh in there. —Remember the dot (talk) 00:08, 9 December 2008 (UTC)
  • From all the possible arguments you could give, better visibility is the worst one. In both cases the box would be near the top of the first screen of the page. Anyone not noticing the box now would be blind. - Mgm|(talk) 11:14, 9 December 2008 (UTC)
    • Or using a handheld device with a small screen...in any case, it looks more intuitive and aesthetically pleasing at the top. —Remember the dot (talk) 17:51, 9 December 2008 (UTC)
      • Perhaps, but I don't think we should design the main page with mobiles or handhelds in mind when the majority of people use a regular computer. Of course, the mobile main page could be adapted if the users using mobile devices think it helps. -Mgm|(talk) 20:40, 10 December 2008 (UTC)

Adding Good Articles to the main page

I know it is hidden on this page as part of the discussion box link to Wikipedia:2008 main page redesign proposal but this particular discussion deserves broader input and viewpoints Wikipedia_talk:2008_main_page_redesign_proposal#Introducing_GA_to_main_page. Some of the ideas proposed include creating a separate WP:FA-like box to feature the GA, incorporating into DYK or not including GA on the main page at all. AgneCheese/Wine 18:15, 10 December 2008 (UTC)

Revision history filters

On some of the high traffic pages, one of the most annoying things about the revision history page is that well over half the revisions are vandalism related. Vandalism, revert, vandalism, revert. It is difficult to see what are legitimate changes. I also understand the argument that some reverts are presumptuous, and not all with is reverted is vandalism. While there is no perfect system, and i don't have much coding experience, the wiki software itself could have filters for the revision history page. Little check marks so that people can customize what they see. here are some of the filters i suggest.

  • Show member edits only
  • Show established member edits only
  • Hide revert related edits
  • Hide banned member edits
  • Hide banned IP address edits
  • Hide bot edits
  • Hide minor edits
  • Show all edits

What do you think? Oldag07 (talk) 05:19, 12 December 2008 (UTC)

That'd be kind of interesting and would be a nice addition to the history page. This as well as Flagged Revisions would also help in this kind of thing because you would be able to hide all edits that did not have sighted or above. —Nn123645 (talk) 05:58, 12 December 2008 (UTC)

DYK Proposal

I created a proposal at DYK to return to the older methods for determining pages as counting as "5x expansion". This can be found here. Ottava Rima (talk) 19:44, 13 December 2008 (UTC)

Remove default 'content was:...' and 'only contributor was:...' from deletion summary

I propose to remove those default deletion summaries. First because they are almost never used, for example in the latest 2000 deletions, they were used only 12 times. Second because pages sometimes contain inappropriate content and it happened that it was cited this way in the log. Third because this is not an appropriate deletion rationale, those are already easily accessible with the delete reasons. Fourth because when several similar deletions are made manually with as rationale a link to a deletion discussion (not automatically linked), we have to select all the default summary and replace it with the link instead of just copying, this is wearisome. Concerning the 'the only contributor was:...", I beg many users would not like to be cited like this in a deletion summary. While it was useful in the past, it is now superseded and inconvenient. Instead, the deletion summary should be blank by default. Cenarium Talk 18:38, 23 November 2008 (UTC)

Agree fully. Happy‑melon 20:05, 23 November 2008 (UTC)
Completely agree as well; they once had a purpose, but it has been superseded. EVula // talk // ☯ // 20:07, 23 November 2008 (UTC)
Sounds fair enough; I think they do constitute a useful feature in theory, but not at present. {{Nihiltres|talk|log}} 05:19, 24 November 2008 (UTC)
Agree. This would prevent accidental contamination of the deletion log with beans. TenOfAllTrades(talk) 15:27, 24 November 2008 (UTC)
I liked the standard deletion summary -- it gave a lot of information about a page that could help to explain the dletion (better than just a link to the CSD). However, most deletion tools now overwrite or pre-fill the field with other content, making it difficult to use the default summary even in the cases where it is beneficial. I'd love to see a button that allows generating of this summary when you need it, but I agree that it (while not being all that harmful) isn't very useful anymore. It is particularly sad that deletion of pages tagged with {{db-r1}} no longer shows what the broken redirect was in the deletion log (this was a case where the auto-summary was a lot better than what we use these days). Have fun at MediaWiki:Excontentauthor and MediaWiki:Excontent (but do not blank these pages, it will result in MediaWiki defaulting to the auto-summary). There is also some relevant old discussion at the talk pages of those MediaWiki pages. Kusma (talk) 16:28, 24 November 2008 (UTC)
Actually I suggest that the default summary should be "no reason for deletion was given", which is a lot more descriptive than a blank line. Kusma (talk) 16:31, 24 November 2008 (UTC)
I think it should be blank, because we'd still have to replace the default text instead of just writing or copying the rationale when making a series of deletions not included in the delete-reasons. The protection summary and the block summary are default blank, so should be the default deletion summary. How can we change the default summary to blank though if the default summary is used when the Mediawiki pages are blank ? Cenarium Talk 16:39, 25 November 2008 (UTC)

Given the level of consensus here, I settled down to do this... and failed miserably! I can't find any permutation of values for MediaWiki:Excontent, MediaWiki:Excontentauthor and MediaWiki:Exbeforeblank that outputs a null value. The best I could do is reduce it to one character. Does someone else want to give this a try? Otherwise I'm going to consider it a bug... Happy‑melon 17:19, 27 November 2008 (UTC)

I removed the <p></p> again; as that is not a useful message to put into the deletion log. If we change the default message, we shouldn't use something meaningless instead of the sometimes-useful default. A bug (ideally including the demand for a button that gives the auto-summary) is probably the best way to go forward (unless somebody knows a way to really create an empty message). Kusma (talk) 12:29, 28 November 2008 (UTC)
Indeed. I've opened a bug (T18493) on this issue so feel free to suggest that there. Happy‑melon 15:23, 29 November 2008 (UTC)
It seems to have been addressed in rev:44127 (T14647). Entering '-' will create an empty message. Cenarium Talk 18:32, 3 December 2008 (UTC)
Isn't the code implemented yet ? I don't know how to obtain the blank summary. Cenarium (Talk) 17:26, 5 December 2008 (UTC)
Does a space count as a single character? Will that do? Dendodge TalkContribs 17:34, 5 December 2008 (UTC)
A space counts as a blank for mediawiki, it'll still return the default message. Cenarium (Talk) 03:32, 6 December 2008 (UTC)

Can someone try to implement this ? I haven't been able to do so. Cenarium (Talk) 18:58, 11 December 2008 (UTC)

 Done Happy‑melon 22:12, 13 December 2008 (UTC)
Thanks. I suppose that the revision wasn't implemented yet then, or it was a cache issue. Now it works fine. If an admin wants to use the "content was" option, I think the best solution is to add it manually. Cenarium (Talk) 23:00, 13 December 2008 (UTC)

There seems to be a problem with csds, see Wikipedia:Administrators'_noticeboard#CSD_automatic_dropdown_broken. When trying to delete a CAT:SD, the csd is not automatically selected. However it seems to work fine for afds. Cenarium (Talk) 14:03, 14 December 2008 (UTC)

Notice of Poll at DYK

There is an informal poll currently at WT:DYK on three proposals, to allow some level of consensus to be reached. Everyone is encouraged to weigh in. \ / (⁂ | ※) 21:49, 14 December 2008 (UTC)

New Magic Word

I was going to post this at one of the various Help:Magic Words articles (on Wikipedia, Meta, and MediaWiki), but it seemed that no one had been to those pages in ages (1 year+), so I didn't think my question would be answered there. Magic Words ({{CURRENTTIME}, {{PAGENAME}}, etc.) trigger a function in the Wikimedia software to do something. I would like to propose a new Magic word, {{PAGEWIDTH}}. This function would use the javascript parameter window.innerWidth (on IE, document.documentElement.clientWidth or document.getElementsByTagName('body')[0].clientWidth) to find the width of the window. This would be useful in many templates to determine the size of things such as images, tables, etc. If someone wanted to set an image to display at full width of a column in a page (say a 50% column), the user could use this magic word and a combination of expr functions to find out exactly how many pixels this image should be displayed at. The javascript code is shown below: 

<script type="text/javascript">
<!--

// initially set to 600 (lowest resolution we need to worry about) in case none of it works

 var windowwidth = 600;
 
// FF/Opera/IE7/Safari use window.innerWidth
 
 if (typeof window.innerWidth != 'undefined')
 {
      windowwidth = window.innerWidth,
 }
 
// IE6 with a valid doctype as the first line in the document uses the following

 else if (typeof document.documentElement != 'undefined'
     && typeof document.documentElement.clientWidth !=
     'undefined' && document.documentElement.clientWidth != 0)
 {
       windowwidth = document.documentElement.clientWidth,
 }
 
// older versions of IE use this
 
 else
 {
       windowwidth = document.getElementsByTagName('body')[0].clientWidth,
 }
document.write('windowwidth');
//-->
</script>

The window width is now in the variable windowwidth and is outputted. --Dudemanfellabra (talk) 23:41, 14 December 2008 (UTC)

The people who understand these matters are more likely to be found over at WP:Village pump (technical). EdJohnston (talk) 23:47, 14 December 2008 (UTC)
Thanks; I'll move it over there. :) --Dudemanfellabra (talk) 23:50, 14 December 2008 (UTC)

Content deletion

The loss of content through undetected vandalism or incorrect vandalism repair is an issue that plagues Wikipedia. Time and time again I come across articles that have had paragraphs, whole sections, or even multiple sections deleted, and the loss has gone unnoticed for months. If I'm spotting so many instances in the tiny proportion of articles that I look at periodically, then across the whole of Wikipedia it must be a massive problem. To me, it is more serious than the mere undetected insertion of nonsense or inappropriate content: that can always be deleted at a later date, whereas unnoticed deleted content is lost forever.

Have there been any efforts specifically to address this? For starters, to address the very common problem of incorrect vandalism repair, how about we have a warning on the edit page along the lines of:

Repairing vandalism? Please read this.

At the same time we could take the opportunity to redesign the edit page to make the instructions look less like a random collection of pieces of text plonked in random places that no one bothers to read, and more like important information that you really ought to be aware of.

I'd also like to see Wikipedia:Vandalism#How to respond to vandalism specifically include a mention of the fact that large amounts of text may have been deleted by the vandal. A very common scenario, that too many editors seem unaware of, is this:

  1. Vandal replaces a whole paragraph or section with obscenity or nonsense.
  2. Well-meaning user deletes the obsenity or nonsense.
  3. The fact that a lot of content has been lost goes unnoticed indefinitely.

Also useful (though perhaps not trivial to implement) would be a quick one-click way of bringing up the diffs on the edit that first introduced the vandalism. Unless the vandalism was introduced in the last one or two edits it is currently a painful process to try to identify what, if anything, the vandalism replaced. Matt 86.150.102.71 (talk) 01:25, 7 December 2008 (UTC).

First problem - simply write up what you believe to be a good rewrite for the appropriate paragraph, and request on its talk page that someone insert it for you - use the template {{editsemiprotected}}.
Second problem - I fully agree with you. This would, however, require a software modification - please check WP:BUGS for how to make such requests.
עוד מישהו Od Mishehu 17:09, 7 December 2008 (UTC)
Thanks. Sorry, yeah I know about requesting the text change on the Vandalism talk page; I just wanted to keep it all together here. Sorry I didn't make that clear. It's the other aspects I'm not sure about. I don't know what you are referring to by "second problem" given that I mentioned three things in all. The last thing I mentioned is obviously a non-trivial software change, but how does one go about suggesting/discussing changes to the text and layout of the edit page? 81.129.129.82 (talk) 14:31, 10 December 2008 (UTC).
a quick one-click way of bringing up the diffs on the edit that first introduced the vandalism - that begs the question of how the software knows that an edit was vandalism.
I'm not disagreeing that this is a problem - it's one reason why the byte count for each version is now displayed. If you're looking for technical solutions, perhaps a better one would be (a) to keep a hash count for each version (this is already done for images, and is needed for any proposal to hide reverted edits on a history page, and then (b) for all edits that reduce the byte count (by, say, more than 20 characters), distinguish between edits that (1) return the article to a prior version (hash count is the same), versus (2) edits that don't, and might be a mistake in dealing with vandalism. Experienced editors reviewing recent edits could then focus much more on (2). -- John Broughton (♫♫) 22:06, 15 December 2008 (UTC)
I'm assuming that the user would somehow highlight or copy-and-paste the vandalism and the software would find out the edit that inserted it. I don't expect the software to work that out itself!
I have another proposal in my continuing saga. I just undid this edit; I fairly often come across cases like this (incidentally, I'd be really interested to know the thought proceses of the people who do this, and how many instances are just accidental as opposed to malicious). This is the sort of thing that an automated bot could and should pick up. I know there is one that automatically reverts the deletion or near-deletion of whole articles; could we ramp it up to also detect deletions or near-deletions of whole sections by anonymous editors? If that means that anonymous editors can't delete whole sections then tough. The bot would have to be able to distinguish between a section deletion and a section move, since preventing anons from reordering sections within an article would be too onerous I feel. Matt 03:33, 16 December 2008 (UTC).

Setting off links to pages without content

If technically possible and feasible I propose setting off links to pages which may exist but do not provide content. For instance, the redirect About Hello Kitty and her sister is orphaned, i.e. no pages link to it. Nevertheless, the toolbox on that page provides the common "What links here" link linking to the corresponding page, on which the user gets to know that no pages link to the redirect page. Instead, the "What links here" link ought to appear differently from other links (e.g. in another color) as is the case with those links on the left on title pages in the IMDb which link to pages without content [2]. Thus, one would see that no pages link to a page, without having to click on a hyperlink.--Emaster82 (talk) 19:59, 12 December 2008 (UTC)

What about just changing the text to something like "No links to this page" or just get rid of that link if there aren't any links? -- Imperator3733 (talk) 23:08, 12 December 2008 (UTC)
Simply changing the text is a good idea, but just getting rid of the entry in the toolbox might make users wonder where the link has gone and would disarrange the box a bit. And, of course, the "What links here" link is only an example for the case that a page without content may be linked to.--Emaster82 (talk) 23:37, 13 December 2008 (UTC)
Clicking What links here leads to a Special page - a page that is created "on the fly". (I think of "Special" pages as Wikipedia's way of doing reports - some are batch/specified frequency, but most are on-demand, such as a watchlist report.)
In this case, that means that that to make the link red (or to remove it), the MediaWiki software would have to run this report every time someone looks at a page, prior to rendering the page. I don't think that is going to happen. -- John Broughton (♫♫) 21:36, 15 December 2008 (UTC)

Move tab for autoconfirmed users on move-protected pages

Currently, when an autoconfirmed user who is not an administrator is on a move-protected page, the move tab is not shown and if the user tries to access Special:Movepage/PAGENAME, MediaWiki:Protectedpagetext comes up with broken parameters. I propose to make the move tab appear even on move-protected pages, and that instead of having MediaWiki:Protectedpagetext, we use an explanation message, for example named MediaWiki:Moveprotectedpagetext. If an article is fully protected, I think we can still remove the move tab as it's sufficiently clear, and exceptional. The reason is that users often wonders why they can't see the move tab, and that using the icon has not always the expected result and has some disadvantages (see discussion here), while leaving the move tab and directing to an explanation message is much more efficient, has not the problems of the icon and provides more information to users as to how requesting a move. If there is consensus and we can find a good explanation message, I'll create a bug for this. Cenarium (Talk) 23:05, 13 December 2008 (UTC)

I disagree; not showing tabs for impossible actions is perfectly sensible and extremely widespread. The "delete" tab does not appear for administrators on pages they can't delete (currently this is only the main page), "protect" does not appear for pages that can't be unprotected (ie MediaWiki namespace), "watch" does not appear on special pages that can't be watched, etc etc. I agree, however, that the error message that is displayed needs to both work and be informative, neither of which is the case here. Happy‑melon 18:43, 14 December 2008 (UTC)
However, the delete tab appears for pages with more than 5000 revisions even though we can't delete them, 'edit this page' appears for pages not protected but cascade-protected even for non-admins. While technically this may be more sensible, from a usability perspective, it would be preferable to have a move tab directing to an explanation message than nothing, or than a lock that confuses readers. Indeed, it is often confounded with the pp-semi lock, or unnoticed, and it is of very little relevance for readers. On balance, I prefer that the move tab appears. It's much more efficient to inform users how to request a move and doesn't disturb readers. While many times, they just don't know why the move tab is missing. The move option is also seldom used, especially on move-protected pages whose vast majority have no legitimate reason to be moved and are only protected to deal with vandalism. It shouldn't be a noticeable change and would solve the problems of pp-move-vandalism. Cenarium (Talk) 19:11, 14 December 2008 (UTC)
The tab still appears only because the condition proscribing the action is not checked until the action is attempted; you can get the same effect with "move" if you fully edit-protect a page but don't explicitly move-protect it: you can't move a page you can't edit, but that condition is only checked when you attempt to move it. A more robust method of recording restrictions like these would alleviate this and I'd welcome such improved consistency, but that's by the by. I just don't agree that a "go on, move this page, oh wait, you can't, sorry" message is in any way helpful. Happy‑melon 19:40, 14 December 2008 (UTC)
Generally speaking yes. But in this case I think the benefit outweighs the disadvantages. If a user legitimately intends to move a move-protected page and the move tab is hidden, then in most cases the user won't know about move-protection and so won't know what to do. Even if there is a pp-move or pp-move-vandalism, it is not very descriptive and there are reasons not to use it on most articles, and it's often hidden by pp-semi. But if the tab appears and the user clicks on the tab, it'll immediately show a message explaining the situation and how to request a move. If this is a concern for some users, maybe we can create a script to hide the move tab in case of move-protection. The problem with pp-move-vandalism is that it is confounded with pp-semi and, unlike pp-semi, it is generally of very little usefulness and irrelevant to readers, so we could remove the lock by default and only categorize, but still with the possibility to show the lock on certain pages. But then we have to think how to inform the reader, which is why I propose this change. Cenarium (Talk) 21:19, 14 December 2008 (UTC)
The problem isn't when the user doesn't know what to do, it's when they think they know what to do: a cut-and-paste move. Giving them a "move" tab leading to a "you can't do that: conract an administrator" message might cut down on the number of cut-and-paste pagemoves. --Carnildo (talk) 00:21, 15 December 2008 (UTC)
You think there are people who don't know about move protection, but still know that the backdoor entry to the move process is at Special:MovePage? I find that rather hard to believe. Happy‑melon 18:08, 15 December 2008 (UTC)
I'm only considering autoconfirmed users here. The move tab appears for them by default on (most) pages, except on move-protected pages when they are not admins. I'm not suggesting to add a move tab for IPs or non-autoconfirmed users, but just for autoconfirmed users on move-protected pages. Cenarium (Talk) 18:41, 15 December 2008 (UTC)

A need for better reference and citation.

There is a growing trend on Wikipedia.org to use miscellaneous and even fictitious references. To help correct this problem, I suggest Wikipedia.org instates a [Better Citation Needed] marker for posts which could be correct but are otherwise unusable as research. IE. HerpiesHomeRemedies.com and phantomplanet.geocities.com are not usable for any research of value, although entertaining. Pillowmurder (talk) 23:20, 14 December 2008 (UTC)

If a ref is dodgy, best thing to do is remove it, and then either remove the sentence is was referencing, or tag it with [citation needed]--Jac16888 (talk) 23:22, 14 December 2008 (UTC)
There are various relevant tags listed at Template:Fact#See_also, for example {{vs}} and {{rs}}. Cenarium (Talk) 00:03, 15 December 2008 (UTC)
To support what Jac16888 said: a citation that uses a clearly unacceptable source should be removed, not marked. And then the remaining (now unsourced) text should be evaluated; for example, a WP:BLP violation should be deleted. It also wouldn't hurt to drop a note at on the user talk page of whoever added the incorrect citation, pointing out the WP:RS guideline. -- John Broughton (♫♫) 21:28, 15 December 2008 (UTC)

Default images size

I think it's already the time for increasing the default images size. When you add an image and you don't introduce any size like 250px, the image shown is very small for almost all regular monitors, so I think it should be larger. --Moraleh (talk) 04:19, 15 December 2008 (UTC)

Without directly taking a position on the proposal, I'll offer some information: For logged-in editors, the default (see "my preferences", then the "files" tab) is 180px. That's for cases when the image display specifications don't include a size. 180px is certainly smaller than 250px, though not necessarily "very small". I'd guess that the default for non-logged in users is the same, at 180px. -- John Broughton (♫♫) 21:24, 15 December 2008 (UTC)

Editor's quick reference guide

3.--------------- Even after several years, I have a difficult time using the Wikipedia editing reference material to answer my own questions, to locate templates, etc. I need a map, a short summary in one article of all those editing documents, that I can go to as a starting point and click to move to the article I need. My difficulties may relate to my age, 71 or so I'm told, never-the-less the difficulties are real. This user page, User:R. S. Shaw, has been the most help. That Shaw had to create his own quide should be a "proof by example" that the Wikipedia Help/Edit documents are missing something. All new editors would benefit, I believe, from something like Shaw's page, call it "The editor's quick reference guide". tooold (talk) 01:09, 16 December 2008 (UTC)

Have you seen Wikipedia:Editor's index to Wikipedia? It's long but you can search words with your browser, maybe with Ctrl+F. PrimeHunter (talk) 01:25, 16 December 2008 (UTC)
Hadn't seen it and it is indeed useful - I've kept a link to it, But if you compare it to Shaw's page, they are very different and I still think Wikipedia needs a "The editor's quick reference guide". The Wikipedia:Editor's index to Wikipedia would appear to answer, or come close to answering another question I've had. What are all the Wikipedia documents or, as sometimes expressed, where is the site map? As a beginner (and I may be a beginner forever) it seems as if I find things only by wandering around. tooold (talk) 03:44, 16 December 2008 (UTC)

User pages included in Category pages

5.--------------- Users updating an article often copy it to their user page or sandbox. Sometimes they never complete their edits, just leaving the article in the user page. Possibly they complete the edit but don't delete it from their user page. The result is that category pages list those user pages since, of course, the pages contain the catalog entries. For those categories I'm cleaning up I can either edit the user page, inserting the ":" or correspond with the user, both being a nuisance for me and the user.

Please change the category pages, at least in the "general public" area of Wikipedia, to not include user pages. tooold (talk) 01:09, 16 December 2008 (UTC)

All category pages are in the Category: namespace regardless of the intended namespace of the listed pages. There is no automatic way to see that a category should only contain articles. Are you suggesting a feature where editors can tag a category as being for articles, and then the category should ignore pages in other namespaces? PrimeHunter (talk) 01:29, 16 December 2008 (UTC)
"Are you suggesting..." Um, no. I was calling attention to a very obvious problem, hoping that someone else (beyond my knowledge level, I've no ideas) would know how to solve it. Many pages have this problem and your suggestion, a flag, would be simpler to use than contacting the user, editing the userpage, and the user later editing again when the page is restored. Creating a category page could include a prompt/question for such a flag. Anything that works and is less effort than the current situation is fine. tooold (talk) 03:53, 16 December 2008 (UTC)
I hadn't thought of this issue, and I am/was guilty of just this type of editing. Question: Is there a way for a user to purge his history ... meaning the pages within his User:Name section? I've seen admins do it for users, but if we can do it ourselves it my lighten the load for admins somewhat Ched (talk) 12:46, 23 December 2008 (UTC)

Formatting references

I passed these requests to an admin, haven't heard from him and, finding the "Pump" here are my requests.

1.-------------- There are more and more articles with more than 100 references. The algorithm to display those n references runs in something like (n/4)**2 time since, in the 2 column case, for every 2nd addition to the references displayed all preceeding references are reformatted to balance the two columns. This may be no big deal given the latest & best computer, but on a slower machine n squared algorithms take a long time as n approaches 100 or more.

Options. a) Most of the time I don't care about the references, would be happy if the were displayed only if I clicked on that section or if I clicked on a reference number. b) change the algorithm to balance the columns only after all references are displayed. c) change the display; instead of balanced use alternating columns: for a 2 column display the odd numbered would be in the left column, even in the right, both columns in ascending order. And so on for more than 2 columns. tooold (talk) 01:09, 16 December 2008 (UTC)

I'm not sure what "algorithm" you are referring to. The references are formatted with CSS using the "moz-column-count" and "column-count" CSS styles. How browsers implement this isn't up to us. Mr.Z-man 02:28, 16 December 2008 (UTC)
Yes, while the user sees only one algorithm, the implementation involves several - I am quite aware of that. The problem is that the algorithm (combination) as the user experiences it produces for some users (I can't quantify "some") a very bad experience. tooold (talk) 03:38, 16 December 2008 (UTC)
If you can't quantify it, it's almost impossible to figure out what the problem is, much less fix it. I'm still not sure what the problem is here. — The Hand That Feeds You:Bite 22:49, 17 December 2008 (UTC)

Semantic mediawiki

Does anyone know if there are been formal discussions of incorporating Semantic Mediawiki into Wikipedia? I found this essay and some old stuff on the talk page, plus some isolated comments in other places. But I wonder if any of this has progressed to a formal proposal (with usability metrics, go / no-go criteria, etc.). Or does this just suffer from a champion and a suitable test case? Cheers, AndrewGNF (talk) 18:59, 16 December 2008 (UTC)

I've heard various discussions around, although I wouldn't call them formal. The conclusion at the time was that SMW is too monolothic; it's basically all or nothing, which makes it more difficult to evaluate and fix whatever problems there may be (there have been problems with it whenever I've tried it, but it's gotten a lot better, and I believe the bugs I'm aware of are all fixed). Markus had offered to split it up into more manageable extensions, but that's the last I heard. -Steve Sanbeg (talk) 16:08, 17 December 2008 (UTC)

Image/File

This probably happened on Commons and not here, but could someone please tell me why we now have Files instead of Images? And we'd better not have a bot changing them all since Image: just redirects to File: Thanks. 76.248.244.232 (talk) 22:16, 16 December 2008 (UTC)

Wikipedia:Wikipedia_Signpost/2008-11-17/Technology_report details it. --Izno (talk) 22:24, 16 December 2008 (UTC)
There is the briefest of announcements in that report and no details at all. --agr (talk) 05:15, 17 December 2008 (UTC)
If you actually follow through the link to the bug report, it explicitly defines what the proposed change was for. — The Hand That Feeds You:Bite 22:55, 17 December 2008 (UTC)
See the box at the top of WP:BRFA to answer your question about bots. Anomie⚔ 22:45, 16 December 2008 (UTC)

Articles for individual scientific articles

I am considering adding articles for individual published scientific articles to Wikipedia. My main target would at first be articles within neuroimaging reporting so-called "Talairach coordinates" that can be represented in a table on the Wikipedia page. I have an example page in my sandbox area. Note that this example is one where I am a coauthor and where there is a link to web-based database that I have constructed, but this is not the main point: There are thousands of other potential articles within the area not coauthored by me and the external link was just as an example external link. I have noted a group of researchers has automatically constructed several thousand pages on Wikipedia for individual genes (A Gene Wiki for Community Annotation of Gene Function). My idea is much the same. I have a small database that could automatically construct Wikipedia articles. I have previously tried to get feedback on this issue on the neuroscience wikiproject, but none responded. My main problem would probably be the justification for these kinds of articles in terms of notability and encyclopedia-worthiness to potential deletionists. Any comments? — fnielsen (talk) 16:35, 9 December 2008 (UTC)

  • For scientific articles to have their own article, I'd say that you'd have to show how it impacted further research to have any chance of showing notability in the sense of showing its lasting effects on science. -= Mgm|(talk) 11:32, 10 December 2008 (UTC)
1000s of PR articles are released each year that sink without a trace (a couple of mine did that), you'd never satisfy basic notability criteria for most. --Cameron Scott (talk) 12:04, 10 December 2008 (UTC)
  • As a comment to Mgm: Most/many(?) life science scientific articles are cited at least once, so to some extent they have an "impact" on new research. After sampling among five potential neuroimaging articles that I would start with including in Wikipedia I find—according to Google Scholar—the number of times they have been cited as: 33, 99, 55, 146 and 154. (see, e.g., [3]) Within popular culture I find that it is not uncommon to have individual pages for less known works, e.g., the little known The Time Has Come single by Mike Oldfield. So are there a discrepancy between popular and scientific culture representation on Wikipedia? Question to Cameron Scott: What is "PR articles"? Press release articles? I wasn't thinking of them. — fnielsen (talk) 12:24, 10 December 2008 (UTC)
PR = Peer review. --Cameron Scott (talk) 12:30, 10 December 2008 (UTC)
  • The only papers I can think of that have their own articles are the Alpher-Bethe-Gamow paper and An Exceptionally Simple Theory of Everything. In both cases there is independent third party coverage of the paper, which is pretty much essential for establishing notability. In this context simply being cited isn't really enough, rather the significance of the paper has to have been independently discussed somewhere. I think it is probably true that we could write articles about more papers than we do, but I don't think it is as simple as looking at how many times a paper has been cited and deciding that it is important, rather we need to see that there has been non-trivial discussion of the paper by sources outside of the paper itself. Without that, it would be basically impossible to write an acceptable encyclopedia article because the only thing one could do would be to parrot the paper itself, which isn't appropriate. Dragons flight (talk) 13:07, 10 December 2008 (UTC)
    • Incidentally, genes are things which will usually be discussed in multiple sources. I'm not specifically familiar with neuroscience, but if there are subunits there that are well-defined and described by multiple sources, they are a good target for inclusion too. However, that's different than writing an article for each paper in the field. Dragons flight (talk) 13:11, 10 December 2008 (UTC)
  • Of course, the number of citations isn't enough. You also need to look at how the article is cited. But that's how importance and notability is established for papers in the science community. The papers that cite the article are the independent critical sources. I think very few papers are notable enough to be worth an entire article. The most noteworthy ones are usually written by notable scientists and are probably better of as being included in the scientist bio. - Mgm|(talk) 20:30, 10 December 2008 (UTC)
    • We make a distinction, when the issue of notability arises for (say) a person, to not simply count the number of newspaper articles that mention the name of that person. Rather, only articles where the person is the topic of an article, or a major part of an article, are appropriate for establishing notability. For scientific papers, that Foo (2008) cites Bar (2000) is typically analogous to mentioning a person's name; it's only when the Foo paper is primarily about the Bar paper (extending it, refuting it, etc.) that it's appropriate to use it to demonstrate notability.
    • Perhaps more to the point - whatever is in those journal articles that is of interest to the non-specialist reader (Wikipedia's target audience) belongs in Wikipedia articles relevant to that information; it isn't at all clear to me that a Wikipedia article about a technical journal article would be all that interesting to a generalist.
    • Finally, if you're looking for things to do, why not try to make neuroimaging and its daughter articles into featured articles? -- John Broughton (♫♫) 21:52, 15 December 2008 (UTC)
  • Yesterday, 16 december 2008, Nature News had an article, Publish in Wikipedia or perish, about required submission to Wikipedia for publishing scientific articles in RNA Biology. As far as I can understand the Wikipedia articles that is required is not individual Wikipedia articles for the scientific articles but rather more general articles about the topic of the scientific articles. The example given is SmY. In relation to our discussion I made the following comment on the Nature News Web-site (excerpt): "Recently, I have asked how wikipedians would welcome Wikipedia articles for individual scientific peer-reviewed articles (For an example see my sandbox area). I imagined that such articles would present summaries of the research in the scientific articles that would allow researchers and the public free access to the scientific information that otherwise would be hidden behind publisher's fee. I also imagined that such articles could put the research in context, linking and explaining research updates. Finally, the most interesting point I imagined would be to add the quantitative results contained in the scientific article to the so-called Wikipedia templates. That would allow scripts to automatically harvest the quantitive information and build meta-analysis upon them." — fnielsen (talk) 17:04, 17 December 2008 (UTC)
  • I would oppose efforts to write articles about the vast majority of scientific articles. While there are articles that are notable enough to warrant having a page on wikipedia, very few are. What you should instead do is use those sci. articles as sources to expand the pages of the relevant topic.Headbomb {ταλκκοντριβς – WP Physics} 02:05, 18 December 2008 (UTC)
  • I agree that the above attempt to write an article on a scientific paper is taking the wrong approach - as others have said, it is better to use the paper as a reference in an existing article on the topic of the paper. Having said that, we have a fair number of articles on journal articles. See Category:Journal articles. Not all should be articles, and some are merely using the article as a coatrack and chronology on which to hang a history of the development of a theory, but some are classic examples: Annus Mirabilis papers, Two Dogmas of Empiricism and Ars Conjectandi. But really, this is a topic more for historians than scientists. Carcharoth (talk) 02:49, 18 December 2008 (UTC)
  • I think an important distinction between the RNA Biology Wikiproject and the vast majority of scientific PR articles should be made. When a paper is written about, say, an advancement in fuel cell technology, one should use the new advancements gleaned from that paper to enhance or improve existing articles, or in the case of the RNA project, use those papers to create articles about the RNA in question. Notice that the RNA project's wikipedia articles do not discuss the PR Journal articles themselves, but the new RNA types being discovered. If the RNA project were to make articles about the papers themselves, that would be more along the lines of what is being suggested here, and in my opinion, the wrong way to utilize new PR journal articles. Snagglepuss (talk) 17:01, 19 December 2008 (UTC)

New protection templates and categories

In order to cleanup and use more efficiently the diverse protection categories, I think it would be worthwhile to have a few more templates and categories to distinguish articles from project pages and userpages. I have created them to show how they would work.

  • For userpages, we could use {{pp-move-user}}, {{pp-semi-user}} and {{pp-full-user}}. They are default small and don't categorize. Of course, {{pp-usertalk}} should be used when appropriate and not those, but they are instances where it doesn't apply.

Cenarium (Talk) 18:32, 14 December 2008 (UTC)

I'm in favor of using as few templates as possible. Well-written ParserFunctions could theoretically get all of the Pp-move templates down to one or two templates. For example, {{#ifeq:{{NAMESPACE}}|Wikipedia|Fooooo}}. Using fewer templates makes future maintenance much easier and prevents people from using the wrong template in the wrong namespace. ParserFunctions can also categorize based on page namespace.

Also, do you have thoughts on the proposed categorization layout described here? --MZMcBride (talk) 19:52, 14 December 2008 (UTC)

One more thing... you proposed all of this here only after creating all of these categories / subcategories / templates. Can we please slow down and do this correctly and with as little mess as possible? :-) I'm all for boldness, but I'd hate to see you do all of this work only to have it all deleted. --MZMcBride (talk) 19:54, 14 December 2008 (UTC)
Agreed it would be good to merge them in the three categories templates full/semi/move. But we can still redirect them in the end and it'll allow us to work out what we want for each case before merging. I'll look at the categories. Cenarium (Talk) 21:32, 14 December 2008 (UTC)
I proposed a new protection layout here. BJTalk 00:21, 15 December 2008 (UTC)

I strongly oppose a new family of templates to handle namespace issues, and I'd prefer that the mentioned templates be deleted as soon as possible. As one of the people who designed the current protection meta-template system, I know just how much work has been put into making the templates handle multiple namespaces cleanly, and I don't want new templates when a few well-placed namespace-sensing ParserFunctions can handle an issue of categorization. The categorization issue itself I don't particularly mind—separating project-space content from article-space content in categories is reasonable. I'll go leave notices about this proposal at Template talk:Pp-meta etc. about this proposal. {{Nihiltres|talk|log}} 02:01, 15 December 2008 (UTC)

As I said we can redirect them. However we don't have specific templates for user requests, and the {{pp-move-user}}, {{pp-semi-user}} and {{pp-full-user}} could be used for that purpose if the user wishes to display a lock. Contrary to protections due to disruption, they shouldn't categorize. Cenarium (Talk) 02:16, 15 December 2008 (UTC)
Just to note that I completely agree that using parser functions is better to handle categorization issues. I have created the project templates to see how they would render before merging. Cenarium (Talk) 02:23, 15 December 2008 (UTC)
I have proposed categorization codes for pp-full, pp-semi and pp-move at Wikipedia talk:Categorization#New protection category layout. Cenarium (Talk) 17:51, 15 December 2008 (UTC)

Any comment would be appreciated. I've proposed codes for protection templates, but prefer to wait for other opinions before implementation. Cenarium (Talk) 18:41, 18 December 2008 (UTC)

Wikipedia:Protecting BLP articles feeler survey

FYI, based on a conversation on Jimmy Wales's talk page:

Your feedback is appreciated. rootology (C)(T) 19:27, 19 December 2008 (UTC)

2.-------------- "What links here" used to be useful in understanding the tree, locating related articles, in maintaining the intelligence represented by the category tree. No more; the flood of templates has buried the interesting links - with every article that uses a template listed as linking to everything in that template there are now hundreds of links - useless.

Please change "What links here" to list templates once and to NOT list any uses of a template. If I want to know who uses the template, I should be able to go to the template's page and click "What links here". tooold (talk) 01:09, 16 December 2008 (UTC)

I agree. That would make far more sense. --Helenalex (talk) 09:32, 21 December 2008 (UTC)
Something needs to be done, it is really pretty useless now. dougweller (talk) 16:31, 21 December 2008 (UTC)
A more useful solution would be for WLH to display templates in the same way as redirects - an indented list after the redirect pagename - like so:
  • Page A
  • Page B
  • Page C (redirect)
  • Page-C
  • Template X (template)
  • Page D
  • Page E
I am not sure how practical this would be to code, but I suspect no more challenging than the request above - and probably more useful in the long run. Shimgray | talk | 16:55, 22 December 2008 (UTC)

Change default category sortkeys

Restored from the archives for further discussion Happy‑melon 13:41, 16 December 2008 (UTC)

This perhaps belongs at VPT since it's a technical setting, but it will probably get more interest here. First, a somewhat length explanation of the problem...

The default setting for category sort keys is to use, effectively, {{FULLPAGENAME}} - the namespace prefix is prepended to the page title so that categories are largely separated by namespace: all Talk: pages appear by default under "T", all images under "I", etc. Of course there are some instances where this is beneficial, but there are innumerable other instances where it is not, and we make extremely widespread use of the construct [[Category:Foo|{{PAGENAME}}]] to make pages sort based on their title only. However, using explicit sortkeys like this destroys the utility of the {{DEFAULTSORT:...}} magic word, which allows us to set new default sortkeys on a per-page basis. So by using {{DEFAULTSORT:Enstein, Albert}} on Albert Einstein or Talk:Albert Einstein, we can make it categorise by surname rather than forename. However if a category link of the structure above is present on a talk page, say (to stop it categorising under "T" instead of "A") then the DEFAULTSORT key has no effect. The only way to circumvent this is to not use the PAGENAME construct but instead ensure that every page outside the mainspace incorporates a DEFAULTSORT keyword; consequently a large number of our WikiProject banners include a DEFAULTSORT magic word, explicitly setting the default to PAGENAME if no other value is given. So we have constructs like this: 

{{DEFAULTSORT: {{#if: {{{listas|}}} | {{{listas|}}} | {{PAGENAME}} }} }}

...

[[Category:Foo]]

This solves the issue by defaulting to PAGENAME, but allowing the sortkey to be overridden using the |listas= parameter. However, this causes yet another problem when there are two such templates on a page: the last DEFAULTSORT on a page overrides all the previous instances, so if the last such call is using the default values, then the previous implementations are overridden. This can be problematic, see for instance Talk:Charlie McCreevy, where the undefined |listas= parameter in {{WikiProject Ireland}} overrides the correctly set parameter in {{WPBiography}}. The devs have only very recently created a warning message that flags up these errors, previously they were entirely silent. I've just added a tracking category to the message (Category:Pages with DEFAULTSORT conflicts), and it's already filling up (note that categories populated from MediaWiki messages populate incredibly slowly).

This situation is, to be frank, a complete mess, and it's all caused by MediaWiki setting the default sortkey to {{FULLPAGENAME}}. However, it is possible to change this: there is a configuration variable, $wgCategoryPrefixedDefaultSortkey, that controls whether categories use {{FULLPAGENAME}} or just {{PAGENAME}} as their default sortkey. On en.wiki this variable is set to true; by asking the devs to change it to false for en.wiki, we can entirely eliminate this horrible mess. If the default category sortkey is just the page title, we won't need to take any action at all in the majority of cases to get pages to categorise properly. Only if we want to, say, order by surname for BLPs, will we need to include a DEFAULTSORT. So we can adopt the (normal and expected) way to use DEFAULTSORT - include it only when there is an explicit value for it to be set to, and not include it otherwise.

In order to get any configuration change enacted, we need to present a clear consensus to the developers. So the question is: is this change a good idea, and should we request it? Happy‑melon 22:55, 23 November 2008 (UTC)

Support - I see no problems with implementing this change. -- Imperator3733 (talk) 04:04, 24 November 2008 (UTC)
Support—this makes total sense, after considering the details. The {{PAGENAME}} default seems quite superior for most general purposes. {{Nihiltres|talk|log}} 04:32, 24 November 2008 (UTC)
Support - {{PAGENAME}}, not {{FULLPAGENAME}}, would be typically useful. -- Fullstop (talk) 16:48, 24 November 2008 (UTC)
Neutral - I'm wary to leave my support for this; while I don't know if any such exist, nor do I know if such are allowed, it is a possibility that categories have intermixed namespaces in them, possibly making them difficult to navigate should the behavior of the default sortkey be changed. It would seem such should be hunted down, but all the same... --Izno (talk) 17:14, 24 November 2008 (UTC)
While I know of some such categories, some would probably be improved by this alteration. If the category is large (more than a few hundred pages) then sorting by namespace first renders the list essentially unsearchable, as it is not possible to get closer to a target page than the first (or last) page in the same namespace. There are certainly no examples I am aware of where the category is not added by a template, so where sorting by PAGENAME only is not desirable, as with, say, Category:Pages with incorrect ref formatting, an explicit sortkey of FULLPAGENAME can be trivially added to the category link (in {{broken ref}} in this case). Resolving these issues would form a part of the cleanup required after this change is implemented. Happy‑melon 18:20, 24 November 2008 (UTC)
Support - I have worked a lot with category handling, and I agree, this would be a big improvement. --David Göthberg (talk) 04:52, 25 November 2008 (UTC)
Support - This would also fix several problems with user categories. Also, for categories which categorise things from several namespaces, there is already a symbol system for sorting. (See Template:Template category.) - jc37 17:20, 25 November 2008 (UTC)
Support, as long overdue... shoulda thunk to question this default four years ago. // FrankB 21:44, 25 November 2008 (UTC)
Support. This'll fix a lot more category sorting problems than it'll cause, and explicit sort keys can still be applied where the default is unsatisfactory. —Ilmari Karonen (talk) 21:59, 2 December 2008 (UTC)
Support Having to use [[Category:Xyz|{{PAGENAME}} has always annoyed me and this is an elegant solution. Additionally, it will not break any pages using the Village pump (proposals)/Archive 40 sorting format and I have never seen a category that uses Wikipedia:Village pump (proposals)/Archive 40 sorting. Foxy Loxy Pounce! 07:37, 3 December 2008 (UTC)
Support. Sorry I'm late to the party. This is a great idea. --Kbdank71 19:04, 3 December 2008 (UTC)
I've now opened a bug (T18552) for this; please do continue to comment on this proposal so we can present as clear a consensus as possible to the developers. Happy‑melon 19:40, 3 December 2008 (UTC)
Strong support - this anomaly has been ticking me off for a while. – ukexpat (talk) 05:05, 5 December 2008 (UTC)
Support. Makes perfect sense. bd2412 T 16:48, 16 December 2008 (UTC)
Support. This will be a big improvement with regards to how categories are sorted. PC78 (talk) 00:44, 18 December 2008 (UTC)
Yes, but you'd have to make it widely known as editors who don't watch this page will have no idea. If you do so I would suggest that as many people ar einformed about it as possible The Bald One White cat 20:28, 17 December 2008 (UTC)
Support - wow. This is the sort of thing I've been asking for for ages (I pointed out this conflict between different DEFAULTSORTs on talk pages a while ago but never quite managed to follow it all the way through to a developer). Kudos to whoever did this. One point I would like to make though is that it is not sufficient merely to adopt the following: "Only if we want to, say, order by surname for BLPs, will we need to include a DEFAULTSORT. So we can adopt the (normal and expected) way to use DEFAULTSORT - include it only when there is an explicit value for it to be set to, and not include it otherwise." Two reasons: (1) Using DEFAULTSORT should apply to all biographies [i.e. articles titled with the name of a person], both of living and dead people, and not just BLPs; (2) Even if there is no required value for DEFAULTSORT, there needs to be a way to explicitly record on the page "no DEFAULTSORT value needed". If this isn't done, then there is no way to tell the difference between a page that lacks a DEFAULTSORT (but might need one) and a page that lacks a DEFAULTSORT (because it doesn't need one). Even those articles that don't need DEFAULTSORT should be marked as not needing one. The ideal aim is to end up with a large tracking category of biographical articles that lack DEFAULTSORT, and for those to be dealt with by either adding a DEFAULTSORT (taking care with different name sorting conventions), or by marking with DEFAULTSORT not needed. If whoever managed to magic up Category:Pages with DEFAULTSORT conflicts can do something similar to create Category:Pages lacking DEFAULTSORT and to cross-reference with the biographical articles, that would be wonderful. Any chance of that? Carcharoth (talk) 01:26, 18 December 2008 (UTC)
Support. Excellent idea. Hopefully it will be done soon. —teb728 t c 09:42, 18 December 2008 (UTC)

Support. Sorting by namespace prefix is currently broken behavior, so fixing it to sort by {{PAGENAME}} is the right idea. — Gavia immer (talk) 20:53, 18 December 2008 (UTC)

Support. Seems like a great idea. Let's Go! Jake WartenbergTalk 02:36, 23 December 2008 (UTC)

edit=rollbacker

I propose that it is made possible to set a page for "edit=rollbacker". Because rollbackers are trusted users, they should be able to edit vandalism-prone pages, such as high visibility templates (to give an example). -- IRP ☎ 22:27, 19 December 2008 (UTC)

  • Oppose I disagree with the notion that rollbackers are "trusted users". Sure, they have more trust, but it is given out primarily per WP:AGF. It's quite freely available; anyone with a few hundred edits (sometimes less) and a bit of vandalism reversion can get it. Heck, I've seen rollback removed from banned vandal-socks on Special:Log/rights. Rollback is no right of passage, it's just a technical tool, so I see no particular need for an edit=rollbacker, as I wouldn't trust some rollbackers to edit things like highly visible templates. Most highly-visible templates are locked from new accounts or from non-admins anyway. PeterSymonds (talk) 22:34, 19 December 2008 (UTC)
  • Oppose because they are countless editors who are certainly more trusted than most rollbackers and don't have rollback rights, or do not wish to have them. Cenarium (Talk) 23:50, 19 December 2008 (UTC)
  • Oppose Rollbacker is for granting rollback, hence the name rollbacker. It should not be expanded into anything more than its current role. Mr.Z-man 00:10, 20 December 2008 (UTC)
    Well then we need to give the limited administrators proposal another try. -- IRP ☎ 02:35, 20 December 2008 (UTC)
    Is there any indication that {{editprotected}} requests are not being met? My understanding is that most such requests are met within a day — and I suspect it's probably a good idea to have at least two sets of eyes look over every edit to high-traffic templates. TenOfAllTrades(talk) 03:52, 20 December 2008 (UTC)
  • Oppose I support the notion of providing more users with additional rights. However, I would grant rollback with less trust in a user than the ability to edit a fully protected template. Edits to such templates can have wide ranging effects; some of which may not be immediately visible. If someone had my trust to edit a protected template, he would have my trust to handle the entire admin package with maturity. The inverse is not true: I would not be able to trust all users in the rollback group with the entire admin package. Lazulilasher (talk) 04:07, 20 December 2008 (UTC)
  • Comment: I think you're confused. "edit=rollbacker" is not the same as "edit=sysop". This proposal was proposing that it would be possible to set a page to a protection level (a new protection level) where it can only be edited by rollbackers and administrators. "edit=sysop" will still be possible. -- IRP ☎ 13:18, 20 December 2008 (UTC)
  • Ah, yes; perhaps you are correct: I may have misunderstood the proposal. So, if I correctly understand now: there will be a new protection level (edit=rollbacker)? This new level would rest somewhere between the confirmed user and the sysop? Is that correct? Regardless, I don't support that; because, I do not feel that the entire rollbacker group should have editing access to, as you say, "high visibility templates". Perhaps I am in the minority; but, I feel that edit access to such templates requires more trust than other tools (such as rollback, account creation, etc). Lazulilasher (talk) 17:01, 20 December 2008 (UTC)
  • OK, so then we won't set high visibility templates for "edit=rollbacker", but here is an example: when the user talk page of an IP vandal is protected, it is semi-protected so that the IP vandal cannot edit his or her own user talkpage while blocked ("inappropriate use of talkpage while blocked"), while autoconfirmed users can still edit it. But let's say if there is a blocked autoconfirmed user, and that user is inappropriately using his or her own talkpage while blocked, the trusted users (such as rollbackers) cannot edit the page either.
  • I don't think edit=rollbacker is ever going to happen, the two things don't go together, there is always the long standing proposal of having a "trusted user" group, with more than just rollback, such as editing full protected. The problem I have with this idea though is why bother? we semi-prot to protect against vandals, and full-prot to stop edit wars. What would this be for?--Jac16888 (talk) 17:08, 20 December 2008 (UTC)
    • Of course a rollbacker can be trusted more than a user without any user rights, but less than a user with administrator rights. There may be many good faith users without any user rights, but if the users wants the ability to edit certain pages (pages with this protection level), they can request the rollback rights. I think we can use the rollback right as a "community trust" user right. I really believe that there should be something for a "trusted user". It will also make it easier for users to prove that they are trustworthy, and that can help their RfA. -- IRP ☎ 19:21, 20 December 2008 (UTC)
      • The problem is that rollbacker was not intended to be a trusted user group. To date, 6,879 users have been added to the group under the knowledge that all it does is give them rollback and nothing more. This would certainly change the standards for promotion and possibly create a need for all the users in the group to be reevaluated. Mr.Z-man 19:28, 20 December 2008 (UTC)
  • Oppose this, but support a new trusted group, with rights like editing pages tagged edit=trusted and rollback EDIT: and, if and when RlaggedRevs are implemented, sighting revisions 19:40, 20 December 2008 (UTC), and maybe granting rollback or protecting pages or something. Dendodge TalkContribs 19:35, 20 December 2008 (UTC)
    • Good idea, I would support that as well. -- IRP ☎ 19:45, 20 December 2008 (UTC)
      • Granting rollback and page protection should not be done by non-admins. Can I ask the difference here? Semi-protection is done for vandalism and excessive IP warring. Full protection is a short-term temporary measure for excessive vandalism, disputes, etc. Why do we need an extra user group? PeterSymonds (talk) 20:59, 20 December 2008 (UTC)
      • I agree with Peter, what's the use case for this? The only real use I can see are articles that suffer from vandalism by banned users using sleeper socks to bypass autoconfirm at a rate so frequent that WP:RBI is ineffective. I can't imagine we have more than 0-5 articles that fit that description though, it seems excessive to make a new protection level just for that. Mr.Z-man 22:07, 20 December 2008 (UTC)
        • See this link for the reason. -- IRP ☎ 22:28, 20 December 2008 (UTC)
          • I'm not seeing a persuasive argument; either that, or I'm reading it wrong. A talk page is only useful when the !owner responds (in most general cases). If the talk page is locked, it's specifically to prevent the talk page being used by the !owner. So why would it be useful for other people to edit that talk page? If it's to fix links or something broken, ask any admin or post at WP:AN. Not really a reason to introduce a completely new user permission. PeterSymonds (talk) 23:49, 20 December 2008 (UTC)
          • That situation has already been deprecated through a blocking feature that disallows the blocked user from editing their talk page, while still allowing everyone else to edit it. Though if the user is blocked and unable to communicate on their talk page, there isn't much need to edit it. Mr.Z-man 23:56, 20 December 2008 (UTC)
  • Oppose A lot of people who request rollback rights are NPP/CSD'ers who want it to fight vandals. They show trust in that regard. That does not mean that they are trust elsewhere and elsewise. It is a very narrow review.---Balloonman PoppaBalloon 16:40, 21 December 2008 (UTC)

edit=trusted

I like Dendodge's idea, "edit=trusted". Who supports or opposes this? -- IRP ☎ 15:16, 21 December 2008 (UTC)

  1. Support: since it was my idea, but only if it includes other things, such as rollback and revision flagging and stuff. Dendodge TalkContribs 15:39, 21 December 2008 (UTC)
  2. Oppose, per my reasons above, as well as those mentioned by MrZ-man et al. PeterSymonds (talk) 15:43, 21 December 2008 (UTC)
  3. Oppose per my reasons above. We don't have FlaggedRevs yet and we may not get it. Its far too early to consider tying anything like FlaggedRevs into proposals now. Mr.Z-man 16:40, 21 December 2008 (UTC)
    I'm not suggesting this be implemented until after we've decided about FlaggedRevs - when we do, this may make a nice bundle. If we decide not to, there's no point creating a new user group. Dendodge TalkContribs 16:44, 21 December 2008 (UTC)
  4. Support: I like the idea. But like it has been said. This should only be given to users who have other things. Specifically Rollbacker and Account Creator. A user with good standing and is trusted is unlikely..can't say will not...to abuse this and all you are doing is allowing them to edit (technically) fully protected articles. This also takes the load off of administrators. A lot of fully protected articles need information placed into them and you have to wait for an admin to come and check the information and place it in if it is good. A trusted user could do this work for an admin taking the work load off of an admin to free them up to help out in other areas of the website that require urgent attention. This is benefical for Wikipedia. It will of course be abused by some people. Everything eventually will be abused. But that is why you can take the flag away and why we have rollbackers who can revert the edits of some one who abuses the privilage. Rgoodermote  07:49, 22 December 2008 (UTC)
    What load will it reduce? It has not yet been explained what the use case for this is. The only example given is a case that was deprecated by a software change in September. The reason pages are fully protected is because no one should be editing them. Admins can edit them on the off chance that something does need to be changed. "A lot of fully protected articles need information placed into them" - In CAT:PER right now, there is only 1 article waiting for an admin. Mr.Z-man 17:08, 22 December 2008 (UTC)
The other benefit is to stop vandals who make accounts to vandalized pages. You protect the page so that a trusted editor can only edit it. Given we will have a lot people with this flag (you can't say we won't, we have a lot of trusted editors) it could be used on articles that get hit by a lot of vandalism from accounts. Like the Featured Article we have every day. If you protect it so that only trusted editors can edit it for say..an hour...you can stop the vandalism while allowing the article to be changed. To answer your question on load (there are currently 19 in there and it is backlogged. This is not counting the 20 on the bottom.). I bet you there are days when we have tons of articles fully protected. Now think about how much work it must be for the admin to have to go through and verify information for each article that requests information be added. This takes time away from other areas of Wikipedia where they are desperately needed. Been here long enough that I can tell you I have seen days like that. A fully protection is not always because "no one" is not supposed to be editing it. There are articles that have been fully protected to end attacks from account holding vandals. Now a trusted user is not an account holding vandal. If you set it for trusted users only. You can stop the vandalism and allow people to edit it. To protect an article with edit=trusted or edit=sysop is up to the admin's judgment. They will know the proper protection for each case. Edit wars protect them from everyone but admin. Heavy vandalism from various accounts, protect it from everyone but the users who are trusted. This will not removed edit=sysop we need that because we are all human. I am having problems understanding why adding this level of protection is a problem. You would think that we didn't have other levels of protection that are stricter than this one. Rgoodermote  18:39, 22 December 2008 (UTC)
I believe I mentioned pages that get vandalized by sleeper socks to the point where WP:RBI isn't enough. How many pages like that do we have? 1? 5? I would be extremely surprised if it was more than 10. I don't see how that justifies a whole new protection level and user group. Semi-protection requires an account that's 4 days old and has 10 edits, that stops the vast majority of vandals and slows most of the rest down to the point where they aren't a problem. As for load, look at CAT:PER again. There are 20 pages. 19 are heavily used templates that would still probably be left at full protection if this were to happen. 1 is a redirect. As for the featured article for the day, I'm not sure if you are aware, but this is almost never full protected. Its only semi-protected in cases of extreme coordinated vandalism, see WP:MPFAP. Mr.Z-man 20:22, 22 December 2008 (UTC)
I have been here almost 3 years I am fully aware of the fact that it is rarely protected from anything other than from coordinated vandalism. But we are talking about when that protection fails. Your making a pretty good guess at the amount of sleepers that are on the site. But I don't think you are right and no guess I make will be right. There has to be more than 10. With 4chan and Encyclopedia Dramatica and more out there disrupting us on a rather constant basis. I wouldn't be surprised if they are making tons of accounts to mess with us some day. Some politician comes round and they don't like him. What are we going to do, fully protect it? Information on a politician moves fast. We need it to be open. I know a lot of people are going to be watching the article. But if a an article gets too much vandalism you tend to lose track of what is going on and make mistakes. All they would have to do is wait 4 days and make 10 edits. I made 10 edits in the first 3 minutes of being here. We could always changed the autoconfirm requirements to end that. But that would be a whole new conversation that I am pretty sure we have been through (have we been through that before, mate?). I want to point out that vandals have gotten smarter as of late. They are understanding now that they are not going to do well with an IP address. That they need accounts. I have seen an increase in vandals using accounts in the last 4 months. But I am probably the only one to hav noticed this..probably the only one who cares to keep track too. Rgoodermote  21:19, 22 December 2008 (UTC)
I'm not talking about number of sleeper accounts, but number of articles affected to the point where we are using or considering full-protection on them. Off the top of my head, I can only think of one. Mr.Z-man 21:26, 22 December 2008 (UTC)
O, well I can agree completely with you on that. Right now I know that there is at least one article affected by a full protect. But things change rapidly. There have been times where there have been at least 10 or 12 fully protected at the same time. Others bordering. Rgoodermote  21:33, 22 December 2008 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_40&oldid=1257447635"