Jump to content

Wikipedia:Village pump (proposals)/Archive 32

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

Proposal to disable hotlinking

For all those interested, I have made a proposal to disable hotlinking on all Wikimedia projects. Please join the discussion at Meta. ~ JohnnyMrNinja 20:46, 27 July 2008 (UTC)

For those not familiar with the term, "hotlinking" means using a Wikimedia site as an image storage and image server site, pulling images (for display elsewhere) without ever doing anything that a normal viewer would do (say, looking at a Wikipedia article). -- John Broughton (♫♫) 12:36, 28 July 2008 (UTC)
This proposal was very well received and picked up steam before it was torn to pieces and left bleeding and crying in a gutter. To quote my summary - "Regardless of bandwidth, disabling hotlinking on the projects as things stand is a bad idea, especially for Commons. My proposal was based on the pictures found in the PD categories of EN, assuming that those reflected the whole of the projects. A few kids uploading pictures of themselves kissing their girlfriends for their MySpace page is no reason to not allow access to the many images which are on the projects to specifically to be accessible. Keeping images for use on our servers prevents the need to download and copy, breaking the history and license. Allowing other sites to use our images (even when we are not credited) just increases attention to our projects, even if it's just someone seeing that the URL leads here. Hotlinking costs us (currently) at most 10k a year, which is cheaper (and more useful) than many other forms of global advertising. Not to mention the technical problems associated, and the possibility of losing readers from image searches." My proposal is withdrawn, I am posting this here for those interested, and for those who might search the archives for "hotlink" some day. ~ JohnnyMrNinja 08:25, 29 July 2008 (UTC)
OK, so why not go the other way and do as many other sites do - provide an HTML snippet for embedding a picture, complete with title text that specifies the provenance/license, and a hyperlink straight back to the relevant wikimedia page? Pseudomonas(talk) 13:47, 30 July 2008 (UTC)

comments, positions and responses to nominations for deletion

It occurs to me that while responding to comments and positions on a nomination for deletion page that the title of the comment or position on the issue is proceeded with a asterisk and made bold instead of being made a subsection enclosed with triple equal signs on each side to make it a subsection and thereafter using colons and asterisks for indentation within the subsection as on any discussion page. Doing this would make it much easier to go back and clarify wording, etc. for the closing administrator to read. Currently doing the editing under a single edit section means that it is very easy to get lost after only a few detailed comments or responses. Julie Dancer (talk) 12:27, 28 July 2008 (UTC)

for almost all discussions I would find the current way much clearer. The difficulty comes only when people start elaborate replies to each other and start wandering from the topic in excessive levels on indentation. DGG (talk) 08:26, 29 July 2008 (UTC)
That is exactly my point for this proposal... If and initial comment or position is made and it is set as a subsection the all of the point, counter-point discussions are indentations the at least all of the indentations, even if they are so elaborate the have to start over from the margin again are at least contained within the same edit block. With subsections limited to initial complaint and comments there is no way to stay organized when point counter-points get lengthy and elaborate. Julie Dancer (talk) 13:39, 30 July 2008 (UTC)

Blacklist words such as "recent(ly)" (or pop up a warning dialog)

I have mentioned this sometime before, last year I think. There are MANY articles where people unintentionally use the word "recent(ly)" when describing events that have happened...err...recently. Problem is that a reader has no idea when "recently" is supposed to refer to. There are no circumstances (except for direct quotations) under which this word should ever be used in an encyclopaedia. We should always phrase sentences such that they are date-invariant.

A couple of proposals on the above spring to mind:

  1. Add "recently" to the spam blacklist (and monitor how many problems it creates i.t.o. inability to reproduce direct quotations). Requires no change to any software.
  2. Pop up a warning or dialog box on clicking "Show preview" and/or "Save page" when the word "recently" has been detected.
  3. Add "recent(ly)" and other such terms to the watchlists of bots (which ones?) that would flag them and either notify the editor/article talk page/special bot "recently" watchlist or some such.
  4. Add "recently" to the spam blacklist (or create a new "word blacklist") and create "per article" whitelists that would individually enable the word. The blacklist-whitelist approach has the advantage that it could be extended. e.g. we can block obscenities such as "fuck" or a phrase such as " is gay" (which is commonly intended as vandalism), except on articles where such are needed. Don't know how useful this will be as we have bots looking out for these things already.

Added the bot option as #3 which bumped the blacklist-whitelist option to #4. Zunaid©® I'd like to gauge support more specifically for the "recently" issue. The other uses which option 4 gives us can even be considered as a separate proposal if anyone wants to take it further. Zunaid©® 20:21, 29 July 2008 (UTC)

Comes across as somewhat creepy to me. Is the use of the word "recently" that egregious of an issue that a global approach needs to be implemented to attack it? While I do agree that there are very few legitimate uses of the word "recently" in the context of an encyclopedia, I don't see it as that big of a deal. I suppose it would not do any harm to add it to the blacklists of some of our bots, as the number of false positives is likely to be low - but again, I question just how bad the "recently" problem is and if it warrants this level of attention. Shereth 21:10, 29 July 2008 (UTC)
Sorry, didn't mean to creep you out ;) This is only my anecdotal experience, but it does seem extremely prevalent - people always want to put the latest news into articles whenever something newsworthy happens (current food price inflation, U.S. sub-prime mortgage problems, etc. Just browse through any topical article at the moment and you will inevitably find "recently" cropping up). In itself addition of new events is not always a problem, but the phrasing of such additions inevitably is, and there are a LOT of them. Inevitably these are not cleaned up once the event has passed "recent" status. If someone could string together a Google search (I couldn't) that filters out non-article space results for "recent(ly)" that would help. I get 1.9 million results for "recent" on wiki.riteme.site/wiki, this includes WP, Talk and Template space so the actual number of articles should be a lot less. I do however think the false positive ratio will be EXTREMELY low. There are a few articles with recent(ly) in the actual title which will need to be excluded, but apart from these the success rate of any tool we may use should far exceed 95%. Zunaid©® 22:45, 29 July 2008 (UTC)
How will this actually be tackled, then? Our spambots and the like are programmed to simply undo edits with blacklisted words, because the entire edit is likely to be spam. Simple grammatical/textual changes are easy as well. The problem is when a user updates an article with information and uses the word "recently" - having a bot-fix is not so simple. Reverting the edit is likely to redact useful information merely for the unfortunate use of the word "recently". Nor is there an easy substitution that works - the proper fix would be contextual and vary depending upon the word. The only solution would be for the bot to flag the article, in some manner. Is that what you would propose, then, a bot that flags articles containing "recently" for editor improvement? Shereth 22:50, 29 July 2008 (UTC)
The term "recently" is obviously context-dependent but its use is perfectly acceptable in any usage where it won't date (i.e. anyplace where the reference time is not the present). Christopher Parham (talk) 23:50, 29 July 2008 (UTC)
I think we agree. However I like to use examples. So here it is : If for example I have an article whereas I cite someone, I think it's perfectly legitimate to use the term. However, if I'm making reference to a "new" law or "recent law" and the term recent is actually utilized to describe it then it is a POV. --CyclePat (talk) 23:56, 29 July 2008 (UTC)
Thousands of articles say "more recently" when comparing one thing to another. And in some situations, for example in geology, evolution and cosmology, "recently" may imply such a long period that it's likely to remain "recently" for a very long time. I don't think there should be any automatic software reaction to the word. It would cause more confusion and annoyance than it's worth. PrimeHunter (talk) 00:13, 30 July 2008 (UTC)
I agree with Prime Hunter. Consider these sentences from John F. Kennedy assassination: 1) "There were concerns about security, because as recently as October 24, 1963, United States Ambassador to the United Nations, Adlai Stevenson, had been jeered, jostled, struck by a protest sign, and spat upon during a visit to Dallas." 2) "During the evening of November 22, the Dallas Police Department performed paraffin tests on Oswald's hands and right cheek in an apparent effort to determine, by means of a scientific test, whether Oswald had recently fired a weapon."The word recenly has more that immediate current recency as a meaning, so blacklisting it would cause problems when it is used in other, more Wikipedia-suitable ways. Grutness...wha? 00:51, 30 July 2008 (UTC)

I just have to say, when I think about it, the word recent(and *ly) is indeed very unlikely to be a commonly used word. All the same, the idea of seeking it out disturbs me. My problem with this is the fact that there are many words and phrases that could be the focus, but if you protected against them all eventually Wikipedia would become annoying to edit and I think it would hurt morale. What is great about Wikipedia is not that everything is worded perfectly from the moment a stub is created but that one author can start an article, and another can improve that article, and yet another can fix the mistakes that editor made and before them. (and so on) next thing you know you have an amazingly informational article that people all over the world can read and learn from. I think babysitting for words and terms makes the whole process too automated and takes out part of the value that goes along with Wikipedia's human element. So while I do agree with the idea that the word is rarely applicable I disagree that any process should be put in place to stop it %%-SYKKO-%% (talk to me) 01:53, 30 July 2008 (UTC)

Seems like something that is better done with AWB or twinkle or whatever (I've never really looked at these, so I don't know). Just search for the word, read the context, and change it if appropriate. Or, in that respect, you could use Google. ~ JohnnyMrNinja 02:04, 30 July 2008 (UTC)

Hmmmm...I think the JFK and geological examples are good counter-examples that I hadn't considered. Although I do think an automatic way of flagging those articles would considerably speed up the process of finding and correcting inappropriate uses. Is there a bot that could do this and produce a list of articles that could be checked by editors? Zunaid©® 09:02, 30 July 2008 (UTC)

Proposal so that talk page cannot be edited by own user

I was wondering if there would be a kind of protection where the user (example: User:Example) cannot edit User and User talk:Example, but anyone else can, so they can be warned of future discussions (ex. Sock tagging) Narutolovehinata5 tccsdnew 09:21, 30 July 2008 (UTC)

A user can be banned from editing certain pages, but this isn't a technical nor physical mechanism. But I've never known a situation where a user is prevented from editing his/her userspace unless that user is indefinitely blocked or is abusing {{unblock}} templates. For one thing, one needs to communicate on Wikipedia and their userspace is used for that, irregardless of whether or not they reply on their own talk pages or someone else's. x42bn6 Talk Mess 09:26, 30 July 2008 (UTC)
Well I was thinking about that. Alright. LEt's STop this. Narutolovehinata5 tccsdnew 09:28, 30 July 2008 (UTC)

Possible change of wording at WP:FN

Following this edit, consensus is now gathering at WT:FN that the guideline should not make a recommendation on editing practice, but instead outline the pros and cons of each approach. Papa Lima Whiskey (talk; todo) 17:14, 30 July 2008 (UTC)

Access to password-protected journal articles

This issue has probably come up but is there any way for Wikipedia to provide online access for editors to all those password-protected journals? I'm fortunate to have an institutional "Athens" account that enables me to access nearly all journal articles I want to, for free, with a single username & password. But I would find it so frustrating if I didn't have that, and I don't like the idea of so many not being able to access them. It doesn't seem in the spirit of Wikipedia or of equal access to sources and knowledge.

I realise Wikipedia isn't like a university or institution with a set number of qualified and ID-registered staff and students for a set period of time, like those who join up to schemes like Athens. So it's probably easy to say that it's impossible and the existing schemes couldn't manage it or the journals wouldn't want it...but is there any chance at all? No doubt the set of eligible editors would have to be restricted in some way, perhaps those who are "established" or whatever...and I guess there would have to be a small payment by each editor wanting to sign up for a year's access or whatever, and maybe their password/username linked to their IP address or whatever to stop passwords/usernames being too easily obtained and passed around.

I'm not sure how schemes like Athens work the financial side but surely the more users and funds the better for them and in turn for the journals. And the better for Wikipedia if more people can access more high quality sources (even if that requires increased guidance on the interpretation and use of such sources, noting that people who can afford it can already acccess the articles regardless of scientific or academic credentials). EverSince (talk) 21:27, 24 July 2008 (UTC)

That's actually a pretty good idea; I'm in the same boat as you are and have institutional access to pretty much anything that I would ever need, but I know that there are a lot of editors who don't have the opportunity of being academically involved with anyone and either have to depend on whatever limited resources their library can provide. Celarnor Talk to me 21:32, 24 July 2008 (UTC)
A nice idea but probably not going ever be anything more than a nice idea. As much as we might hope otherwise, the project will never be regarded in the same light as a traditional academic pursuit, and just don't see how any subscription-based entity is going to be OK with an open project like Wikipedia having group access to their materials. Shereth 21:35, 24 July 2008 (UTC)
Publishers and aggregators normally charge universities based on their combined student and employee FTE. Wikipedia could fairly reliably count the number of "established" editors, but many versions of "established" would likely push that number and the accompanying price well beyond the wikimedia foundation's resources. I doubt the WMF has the money to even purchase access for the en.wiki admins.
I don't think there would be any problem with the WMF not having an academic reputation. Publishers are not concerned with such things. Publishers are somewhat concerned about anonymous access, but they already have mechanisms in place to cut off abused access. Many university libraries do not require users to be associated with the university in any way; some cannot by federal law. Publishers have learned to deal with this. JackSchmidt (talk) 21:41, 24 July 2008 (UTC)
Maybe the Wikimedia Foundation could purchase only minimal access upfront, then wait until enough fees had come in from editors signing up with them, before purchasing more. Unless the charge to institutions per user is much greater than what a reasonable individual sign-up fee for editors would be, I don't know. EverSince (talk) 22:43, 24 July 2008 (UTC)
The main trouble with this is that the bar for joining Wikipedia is so low that people would be happy to join solely to gain access to these records. It might make sense to have some class of approved and verified users who gain access to these resources, or get a discount on them; just admins for example. The question is whether the money spent on this would be best spent this way, or whether these users typically have access to these resources by other means. Dcoetzee 18:28, 25 July 2008 (UTC)
This proposal would be nice and here's an article on Athens http://www.pubmedcentral.nih.gov/articlerender.fcgi?artid=2268217 . Although I didn't understand all the details of this article, my impression is that it would be very difficult to get a system like this for Wikipedia. --Bob K31416 (talk) 20:02, 25 July 2008 (UTC)

Please see my thread located below. I am quite concerned that there is a creeping into Wikipedia of a sentiment that if text is not in a proprietary data form, it is not valid. By the way, I suspect the utility of the hard copy pay for content scientific journal is rapidly diminishing. Just as software should be open source, so should scientific discourse. Menalaus2

What thread below? EverSince (talk) 06:22, 30 July 2008 (UTC)
Well anyway, I very much agree that sources should be judged on their own merits and scientific discourse should be open. This would be a move in that direction - using the combined numbers of established Wikipedia editors to gain cheaper and easier access to this vast online repository of sources, rather than each individual having to purchase individual articles/journals or rely on abstracts that can be misleading. EverSince (talk) 13:03, 31 July 2008 (UTC) p.s. realised there's a Wikipedia:WikiProject Resource Exchange for listing or requesting sources like this but don't know how much use it gets. EverSince (talk) 13:22, 31 July 2008 (UTC)

Copy histories when moving talk pages to archives

This proposal is related to the one above, but I am less sure about its validity. I think there should be some automatic method of moving a talk page's history along with the talk page when creating an archive of the talk page. Is this already possible? I have a hunch this is the case. If so, I think this action should be more prominently proscribed in the archive help or archive template docs. SharkD (talk) 03:04, 30 July 2008 (UTC)

Are you talking about copying histories (per the section heading) or moving histories (per your actual post)? For article talk pages it is generally suggested that the history be kept in one piece on the main talk page and not broken up between multiple archive pages. See: Help:Archiving a talk page to quote the key point:
it is widely preferred to use the "cut and paste" method described below, which retains the talk page history in a single location. Do not use "move page" archiving for article talk pages unless there is a countervailing consensus on that article's talk page that it would be more appropriate.
Dbiel (Talk) 03:20, 30 July 2008 (UTC)
OK, that pretty much answers my question. SharkD (talk) 20:14, 30 July 2008 (UTC)
One way to achieve this is to move the page (instead of copy-and-paste) in order to archive the page. I'm not sure why this is a desired method of archive, though. -- Taku (talk) 03:23, 30 July 2008 (UTC)
The purpose of doing this is to be able to more easily retrieve diffs from talk pages. I.e., if you are trying to find the diff for a comment, and the page the comment resides on happens to be an archive page, then it's kind of difficult to find the diff for the comment since the history resides on another article. The best (and probably final, come to think of it) argument against this is that it is not reversible. If you were to, for instance, want to later merge two archived talk pages for some reason, you would not be able to also merge the histories. SharkD (talk) 20:16, 30 July 2008 (UTC)
Easiest way to find a diff is to search a user's contribs for a matching timestamp. However, the timestamps in the interface are adjusted by your time zone prefs and the timestamps in user's sigs remain constant, so this only works well if you use UTC +/- 0. I could probably make a javascript which does this automatically. Give me a few days. — CharlotteWebb 22:18, 30 July 2008 (UTC)
If the talk page is large enough to warrant moving, then presumably people are discussing the subject frequently. If people are discussing the subject frequently, then moving the talk page will probably disrupt ongoing discussions. − Twas Now ( talk • contribs • e-mail ) 05:33, 30 July 2008 (UTC)
I'm not sure what you mean. Moving a page merely turns the original page into a redirect. In this case, the redirect would then be converted into the new talk page with its own, brand new history. SharkD (talk) 20:14, 30 July 2008 (UTC)
The argument is that a "brand new history" would omit ongoing discussions. — CharlotteWebb 22:18, 30 July 2008 (UTC)
Yes, but discussions are already (usually) only archived after the topic has died down for a period of time. I don't think an additional risk is undegone by doing this. SharkD (talk) 01:41, 1 August 2008 (UTC)

It's helpful to be able to view the history of the talk page at once, like [1]. If it had been archived by page-move one would have to load several pages rather than one large one. — CharlotteWebb 22:18, 30 July 2008 (UTC)

White Background to Dimmer Color Shade Options

If there is a way to change the background color of Wikipedia articles, please let me know. Otherwise, it would be a nice option to be able to click a button to change the background color from white to gray, or another less intense color. I tried saving the articles to my hard drive and then changing the body tag to include bgcolor="#CCCCCC", e.g., <body bgcolor="#CCCCCC"> but this does not work, and when I went to the *.css files, there was just too much there to try and muddle my way through.

ELApro (talk) 20:42, 31 July 2008 (UTC) elapro@yahoo.com

You can do it my going to your custom stylesheet page and modifying your stylesheet. I am not sure of the exact syntax, but it can be done there. I am sure someone will come by with the exact code you need. Chillum 20:44, 31 July 2008 (UTC)
To change the background of the content box (everything below the page tabs and to the right of the menu) you need to add the following line to your custom stylesheet page:
#content { background: #CCC; }
Replace #CCC with a different hex colour code to use a different colour. You may also want to look through Meta:Gallery of user styles for some ideas, there are a few darker styles there if that's what you're after. All the best – Ikara talk → 01:36, 1 August 2008 (UTC)
Because of the way the 'mainspace is white, everything else light blue' CSS is set up, that doesn't affect the mainspace. Algebraist 01:41, 1 August 2008 (UTC)
You just have to override the CSS that sets the mainspace pages white:
.ns-0 * #content, .ns-0 * #p-cactions li.selected a, .ns-0 * #p-cactions li a:hover {
    background:#ccc;
}
Anomie⚔ 02:12, 1 August 2008 (UTC)

Bot creation of disambiguation redirects

A discussion at Wikipedia:VPP#ALL disambiguation pages to end "(disambiguation)" did not reach any consensus as to whether or not to enforce a policy change in terms of naming conventions for disambiguation pages, although it was proposed that all disambiguation pages at Foo at least have a redirect to it created at Foo (disambiguation), where the latter does not already exist. It was also pointed out that this would be a suitable task for a bot. A request was subsequently made at Wikipedia:Bot_requests#Disambiguation_redirects. After reviewing the technical aspects of the request I have decided to bring it up here so that some of the concerns can be addressed by a broader audience.

As a quick summary of the rationale for this proposal, it is merely suggested that redirects be created where they do not yet exist, without enacting any page moves, changes to existing articles or changes to existing policy. It has been stated that this is for the sake of consistency and as a search aid. It was also pointed out that, while not particularly harmful, it may also be unnecessary to create these redirects.

I performed a survey of what articles use the {{disambig}} template (and its derivatives) and discovered that there are 114,402 disambiguation articles located at Foo rather than Foo (disambiguation). While some of these do already have an existing redirect, a quick look at the numbers indicates that, as a minimum, this proposal would create 88,043 articles. Given the scope of the proposal (the creation of 88,000-115,000 redirects) I feel it requires some scrutiny here.

Again, from a technical standpoint, this is quite simple - it is just the scope that is large. Therefore, I am seeking input of the community. I imagine that most opinions on the matter will fall in to one of a few different types:

  • That this proposal is beneficial and should definitely be implemented
  • That this proposal is not harmful and may be implemented
  • That this proposal is not harmful but not likely worth the effort of implementation
  • That this proposal is unwarranted and should not be implemented

If there is sufficient interest in implementing this proposal, I will follow up on the bot request by bringing it up with WP:BAG for approval with the technical implementation of the bot. If there is insufficient will to implement or considerable opinion that it should not move forward, I will recommend to the original requesters that the issue not be pressed further. Thanks in advance, Shereth 19:26, 28 July 2008 (UTC)

I guess I would be in the third or fourth group. If I'm searching for "Foo," I'm going to type "Foo" into the search box. Even if I know there's a high likelihood that there are multiple articles named "Foo," I'll take the risk that I might have to click a link in the hatnote on top of an article to get to the disambig page, if the "Foo" I end up on isn't the right "Foo." I'm not going to spend the extra time typing out "Foo (disambiguation)." Since the odds of people actually searching for these are low, and we should avoid purposefully linking to redirects, I would oppose creating the redirects unless many links to it (redlinks) already exist. If there's only a few links it would be better to just update them. Mr.Z-man 20:27, 28 July 2008 (UTC) — (amended) Didn't see the part about 88,000+ pages initially, that's just ridiculous. Mr.Z-man 23:30, 29 July 2008 (UTC)
I fall into group 2 or 3... mostly feeling apathetic, but I don't see any harm that it can do. That is contingent that Wikipedia:Don't worry about performance applies to the creation of this many pages, though - do we know if there is any downside site-wise to it? -- Natalya 00:13, 29 July 2008 (UTC)
Even if there are (which I doubt), the bot could be programmed to run slowly enough to remove any such side-effects.--Aervanath lives in the Orphanage 03:54, 29 July 2008 (UTC)
While there are cases where performance could be a concern — gargantuan "Templatezilla" constructs, for instance — creating and editing pages are the two most basic functions of any wiki, and should be optimised enough to do more-or-less anything we want. I fall in one of your top two groups, I don't think it will cause us any disasters to do it. I have a feeling that ninety thousand (redirect) pages probably isn't the largest bot-creation run ever done, either.{{citation needed}} --tiny plastic Grey Knight ⊖ 09:12, 29 July 2008 (UTC)
Hello everyone, I'm the original instigator of this proposal and I'd just like to reiterate my arguments in favour of this bot being made. With my original proposal at WP:VPP#ALL disambiguation pages to end "(disambiguation)", I started off by suggesting that pages which contain {{disambig}} like Foo all be redirected to Foo (Disambiguation), but it turned out that that was against current Wikipedia policy and people were generally against that idea. The idea then became to create currently non-existent pages such as Bar (Disambiguation) and have them redirect to Bar which contains the {{disambig}} template. This would mean that if someone typed "Bar (disambiguation)" because they were unsure what the article about bars of metal would be called, they would always be taken to an appropriate page pointing them in the right direction (as opposed to being taken to the bartenders-and-bar-brawls bar article [or vice versa]). The example I originally gave was Taxi (disambiguation) which was a redlink when I first started the proposal but which was then created as a redirect later on. However, 60,000 or so such non-existent disambiguation pages still remain so there is still a lot of work that can be done.
If the idea of someone typing "(Disambiguation)" seems silly, I can assure you all that I for one do it for precisely the reason that I outlined above; and so, presumably, do other people. As for relying on hatlinks, they always have to be created manually as some human thought is required as to which template to use and what exactly to type; with redirects and disambiguation pages, however, we can be certain that a link to the page that a user was looking for will be there (as long as the disambiguation page is sufficiently detailed), and the redirects I propose can be performed by a bot, which gives redirects and disambiguation pages the edge over hatlinks, in my opinion.
My main argument for creating Foo (Disambiguation) → Foo redirects is that they will not do any harm. There are no companies, people or anything else with "(Disambiguation)" in their title so these currently non-existent pages will certainly not be needed for anything else in the future. Moreover, such links will either (at worst) sit there and do nothing or alternatively help someone find the article they need, and so they can only be benificial to Wikipedia.
And, again, let me reiterate the fact that the proposal as it currently stands will not involve any policy changes or page moves, only the creation of redirect pages.
Some people have suggested that there may be scope for debate with such redirects. For instance, there may be more than one disambiguation page for a certain topic, or the disambiguation may contain another template other than {{disambig}} (a full list can be found at CAT:DRT). These are all fair points but I suggest that, for the time being, our bot be made to ignore any pages with any template other than {{disambig}}, and also be made to ignore any pages with the {{disambig}} template and with either the ( or the ) character in their title. By my reckoning, that should stop the bot both from creating Foo (Disambiguation) → Foo (place) and nonsensical Foo (Disambiguation) → Foo (Disambiguation) redirects. Then, once the bot starts churning out easy, uncontroversial edits, we can talk about how best to expand the project. For the time being, however, I am only seeking consensus on the "barebones" bot, as it were.
It Is Me Here (talk) 09:23, 29 July 2008 (UTC)
Support. I can see this being useful for some users, harmful to nobody, and if you can find someone willing to do the bot work, I say more power to you. It'll bump up the totals on the links to disambiguation pages statistics, but a comment can be added to the project page explaining why it happened. Mlaffs (talk) 15:28, 30 July 2008 (UTC)
Thanks for the support - but as for the links to disambiguation pages problem, wouldn't that rule presumably refer to links from the article namespace to disambiguation pages (just like Article namespace → Wikipedia namespace links are discouraged), as opposed to redirect pages? It Is Me Here (talk) 19:42, 31 July 2008 (UTC)
I'm not sure - you'd have to check with the operator of RussBot to see how the logic works. It's always seemed to me like redirect pages are included in the counts, but I could be wrong. I don't think it's really a problem though. Mlaffs (talk) 15:16, 1 August 2008 (UTC)
It conceptually would increase the count of total number of links to disambiguation pages, but the main work of the Wikiproject Disambiguation pages with links is to deal with disambiguation pages that have large numbers of links to them. If the bot were to do this work, each disambiguation page would only get one more link, which wouldn't bump up each individual page's count much at all (in fact, only by one. :) ). The total count of links to all disambiguation pages would certainly go up, but I'm not sure how big a deal that would be/if it would be a deal at all. -- Natalya 19:56, 1 August 2008 (UTC)

As it stands, it looks as if this support for this proposal is tepid but there is little serious objection. I will let th is discussion run for the weekend, and unless additional objections are voiced I'll bring it up at WP:BAG for review. Shereth 23:01, 1 August 2008 (UTC)

Categorizing Commons images used here (en.wikipedia)

I've recently been undertaking the task of utilizing the Media feature in categories to group together images users might find useful (e.g. Category:Images of butterflies and moths). While i was aware many of our free (libre) images were hosted from commons, i failed to note that so many of our images are sourced from there without a corresponding page here. For example, putting together the butterfly category, i found 3000+ images that are being currently used from commons - 3000+ images being used in articles. Well obviously I'd love to categorize these for readers and editors alike, not only to have a nice visual index of our articles, but also to aid in management of images (categorization adds a second chance to check for needless duplication). But you'll note that on one page in Wikipedia, squirreled away at WP:COMMONS#Categorization, is the single sentence saying "No, please categorize Commons instead." Now, I love the idea of Commons, check out the rationale. But if, ideally, all free images should be moved to commons, and we cannot display non-free images outside of articles - then what's the point of being able to display images? I feel it's a disservice to our users and editors alike to say that there is no way to be able to visually index all free images used on the English Wikipedia. This guideline comes with no rationale from a page that gets maybe a couple non-bot/non-vandal-related edits a month, with a talk page where the last reply came 3 months after a question was asked. I'd like to open the floor to any thoughts or comments about this. -ΖαππερΝαππερ BabelAlexandria 00:43, 31 July 2008 (UTC)

You can create blank image description pages here for English-wikipedia specific categorization. However, if you do so, please categorize Commons as well. Superm401 - Talk 05:26, 31 July 2008 (UTC)
your response seems to run counter to the guideline(???) at WP:COMMONS - but it is one that i, personally, could reconcile with. is there any previous discussion (either way) that anyone can point to? and/or how does any else in the community feel about this? -ΖαππερΝαππερ BabelAlexandria 03:20, 2 August 2008 (UTC)

Wikipedia:Local Embassy

This is something which is quite frankly under staffed and seems to be almost unstaffed in that there hasn't been some responses for over a year, and really needs to be firstly more easily available to our international users and secondly more integrated into mainstream use into with support from editors. I would like to suggest about including this in the interaction sidebar or perhaps integrating it into the Community Portal or village pump. I mentioned this to a user who has been actively present on wikipedia for nearly 3 years and they hadn't heard of it. Seddσn talk Editor Review 21:06, 25 July 2008 (UTC)

Oh! Not a real embassy. It would be cool if we could to the nation of Wikipedia. I say "Yes! My dear fellow Wikipedians" we must stand up for our beliefs." Wikipedian Passport's could integretated with our login accounts to prevent from those annoying sock-puppets. --CyclePat (talk) 21:35, 25 July 2008 (UTC)
My understanding was that it was supposed to essentially be a list of users who can speak a certain language so people coming from other wikis can find someone who can understand them. Personally, I would say it would be nice to put it in the sidebar but I think you'll struggle to get consensus for that, GDonato (talk) 20:07, 27 July 2008 (UTC)
Why not a name like "the Rosetta Stone of Wikipedia", "Wikisetta Stone", (see Rosetta Stone) or "WikiBabel Fish", "Babel Wikifish", (see Babel fish) or simply "the WikiTraductor", "Translitarater", or why not "Translingua" : Since "Trans" means "through" or "across, beyond, to go beyond" and Lingua means "speech, language"... If we go back to the Proto-Indo-European, the hypothetical reconstructed ancestral language of the Indo-European family we could probably even say Trans-dnghwa (for immediate translation). Or better yet "Trans medius Lingua" which would mean "Through the midle language". --CyclePat (talk) 05:41, 29 July 2008 (UTC)
I don't think it's necessary to have this item automatically on the side. It could however be an option where users could chose if they wish to have it from there user settings. I think that would be a better option. --CyclePat (talk) 05:45, 29 July 2008 (UTC)

I strongly agree with the original proposal. This has the potential to be an excellent on=wiki feature and center for co-ordination. It should be integrated into the Community Portal. Mr. IP 《Defender of Open Editing》 14:51, 2 August 2008 (UTC)

Purchasing power of wikimedia

I would like to know what is the purchasing power of wikimedia. I've found an old vinyl for 199$. Can wikimedia pay part of all of the purchase of this old vinyl if I was to republish the content onto wikimedia under of course GFDL... etc? b.t.w. the vinyl in question is no longer copyrighted so we could republish the content. Also, on occasion, some people have asked for court transcripts. If these are order and payed for by an individual copyright status indicates (in Canada anyways) that the employees work belongs to the payer. Hence this material would or could also be freely released into GFDL. Anyways, this one Vinyl I've found is circa 1928 and is about King George V. It's in excellent condition. It's also one of his rare and first audio recordings. How do you think we could solve this problem? Should we? Could wikisource become some sort of purchasing power like a type of museum and republish the material? Then could wikipedia use this material? talk:George V if the UK is the current propossal but, I believe this could be used on a larger scale (Macro). --CyclePat (talk) 21:39, 25 July 2008 (UTC)

I doubt very much that the Wikimedia Foundation is going to budget money for buying information; I doubt they see that as their role, and it would be an administrative nightmare to set up and run a system to accept requests, decide which to fund, disburse the funds, and monitor whether what was promised was in fact delivered. (All this, of course, not just for the English Wikipedia, but for all 200+ language Wikipedias, because it wouldn't be fair to do this for just one; and, of course, many if not most Wikipedias involve multiple countries, so provisions would have to be made to avoid a small clique in one country taking over the process for a particular language Wikipedia, and treating this like free money ... ) -- John Broughton (♫♫) 22:38, 25 July 2008 (UTC)
I'm not asking to implement this into other languages. --CyclePat (talk) 17:26, 26 July 2008 (UTC)
Wikimedia doesn't have money problems, but neither does it have money to burn- I do not think that would be a very good way to spend Wikimedia's funds, and nor do I think it's quite what we're aiming to do anyway. J Milburn (talk) 18:10, 26 July 2008 (UTC)
Considering a good portion of Wikimedia's Board of Trustees (who would probably have to approve a program like this) have their "home wikis" in other languages, making this an "English-only" system would likely never happen. Mr.Z-man 20:55, 26 July 2008 (UTC)
Your free to have that opinion, but nobody has said this would be an english-only system. If others Wikipedia systems want to follow along afterwards that's up to them. Right now, however, I'm request funds for a vinyl of King George's innaugural speech of the Tyne Bridge in 1928. In Canada there is a copy at the National Archives but it's not available to the public. I've found one that is for sale for 199$. I'll buy this copy, make a digital copy, take pictures and post it onto wikimedia only if Wikimedia is willing to pay for half of the expenses or approx. 100$. In this proposal, I will host the vinyls for perusal by anyone (upon request) and could also get it verified by other local wikipedians if necessary or even a fellow Canadian National Archivists. This is a proposal and I believe it belongs here. However, thank for your advice... I will also bring this up to the board of Trustees. --CyclePat (talk) 21:29, 26 July 2008 (UTC)
I believe that you said it would not be for other languages. I'm not sure what you mean by "other Wikipedia systems" - Wikipedia itself has no money. Its just a website. If you want the money to come from the foundation, it would have to be a Wikimedia-wide (all projects, all languages) system or only for a project like meta or commons, which are both multilingual projects. If you want a system for this project only, the money would probably have to come from individual contributors, not the foundation, which is responsible for all projects, not just this one. Mr.Z-man 21:38, 26 July 2008 (UTC)
If the Foundation purchases material like this, what do they do with it? Do they start a library and ship stuff out to anyone who needs it? --—— Gadget850 (Ed) talk - 01:28, 29 July 2008 (UTC)
I would strongly oppose spending Wikimedia Foundation funds on aquiring information since the result would be to make it more dificult to get stuff donated for free. (You paid for his stuff. Why won't you pay for mine?Filceolaire (talk) 16:14, 2 August 2008 (UTC)

Page protection explanations

For a lot of users, it can be frustrating or confusing to find that an article has been protected. In some cases, anyone can figure it out, but in others, the reason is mysterious and can take some digging. Might it be a good idea to include the text of the RFPP entry on the article talk page automatically? And good policy to require this inclusion? I've never worked closely with protections, so any refinement of the idea is appreciated.  Mr. IP, Defender of Open Editing  15:09, 27 July 2008 (UTC)

Sounds like an interesting possibility for a bot; perhaps someone could make a request at WP:BOTREQ? Probably should be triggered by an entry in the protection log, rather than a posting at RFPP, though. -- John Broughton (♫♫) 19:46, 27 July 2008 (UTC)
Why not just check the protection log yourself? That should explain why it was protected. J Milburn (talk) 16:46, 29 July 2008 (UTC)
The protection log isn't very accessible. I would support a move to make the protection log easy to access directly from an article. Also, I thought all protection edit summaries were supposed to state a reason. --.:Alex:. 16:49, 29 July 2008 (UTC)
There should definitely be a reason for why a page is protected on its talk page. New/inexperienced users may not even know that a protection log exists, much less where to find it. It would also be easier if there was a noticeable template at the top of the talk page saying "This page has been protected because..." and then the reason. This should be a simple task for a bot to do. -- Imperator3733 (talk) 17:03, 29 July 2008 (UTC)
Just for an update, I made an entry at BOTREQ, and Happy-Melon (Happy‑melon) will be folding this new function into an upcoming bot he is developing for purposes of protection-template maintenance. Thanks all for support. Mr. IP 《Defender of Open Editing》 14:45, 2 August 2008 (UTC)

Peer reviewing Wikipedia with digital signatures

I wrote an article about creating a new trust model to Wikipedia. Since the article is quite long, I'm just linking it here.

The idea is that an optional peer reviewing scheme could be integrated with Wikipedia. When a reviewer agrees that an article doesn't contain errors or misinformation or is otherwise of suitably high quality, the reviewer can just sign a particular revision of the article with a digital signature. Anyone can sign an article, and it's up to the reader to decide if the reviewers seem reputable enough. The idea is to help the reader to decide wherher or not an article is suitable for citing or other serious use.

Ipuustin (talk) 13:21, 28 July 2008 (UTC)

We could easily create a talkpage template that holds a (collapsible) list of revision signatures by various users. I am less sure about putting the info on the article page, but maybe we could have some little corner-icon akin to the "This article is a Featured Article" stars or "This article is protected" padlocks, that prompts an informed user to check the talkpage for the list. Users can keep their public-key commitments on their userpages, and if in-place creation of a signature is desired I'm sure someone can cook up a user-javascript solution and/or Firefox plugin, etc. In short, it seems possible to create an entirely optional infrastructure to do this without needing any changes to Mediawiki at all! :-) --tiny plastic Grey Knight ⊖ 15:24, 28 July 2008 (UTC)
Just as the featured articles have a little star at the top, I think this could somehow follow a similar, if not be integrated within the same format. --CyclePat (talk) 07:17, 29 July 2008 (UTC)

I don't understand how it would work. I know quite a lot of articles that I am sure are both of high quality in what they do say and of poor quality in saying so little. (That's because they're mine, all mine and I created them very scrupulously and slowly and for this reason quickly got bored, tired or both and thereupon gave up.) May I certify them as authoritative stubs? However, when it comes to well developed articles, I don't know for sure that any article is good, because (even aside from questions of potential bias, etc.) I haven't gone through any article of FA length and checked its every assertion against its cited reference. I can see that certain articles appear to have been put together very scrupulously by people who appear to be scrupulous and knowledgable (editors in whom I have the same degree of confidence that many editors once had in the august theologian User:Essjay). Am I going to stake my own reputation on these articles (in reality, on these other editors' reputations)? Uh, thanks but no. What am I overlooking here? -- Hoary (talk) 09:46, 29 July 2008 (UTC)

Like everything else in Wikipedia, the proposal is for a community-oriented voluntary effort. There would be no requirement for anybody to sign anything, but if, for instance, you yourself have certified a particular article, scrupulously checking it, then you might wish to state this by giving a "digital signature" for that revision. Other readers who value your opinion (or who value the opinions of other people who certify you yourself — see web of trust) would then have a bit more confidence in that particular revision. If several people a reader trusts have signed some revision, then that is even better. Obviously complete trustworthiness isn't achievable in this fashion — you could be wrong about everyone — but it provides a certain satisfactoriness in some cases. --tiny plastic Grey Knight ⊖ 10:27, 29 July 2008 (UTC)

Here is an example of a talkpage box we could use (it could probably be improved a good bit). I also made an experimental {{has signed revisions}} template that adds a "topicon" on the article itself; again, probably a better image could be found. For reference, the below is constructed from {{signed revisions top}} and {{signed revisions bottom}}, with {{signed revision}} making up each of the body elements. 

{{signed revisions top}}
{{signed revision|123456|Exampleuser1|24CB016EA}}
{{signed revision|234567|Exampleuser2|20A75E12D|signer-user=ExampleuserOther}}
{{signed revision|345678|Exampleuser3|1C83BABCA|signer-url=http://example.org/keydatabase/exampleuser3}}
{{signed revisions bottom}}

Does that look any use? --tiny plastic Grey Knight ⊖ 11:16, 29 July 2008 (UTC)

This looks quite interesting as a concept. If it's to be useful then there needs to be a decent way that a reader can tell who the signer is and what their credentials are. Also, I can see COI potential as editors sign their own edits. So long as we don't get too many people just looking at the last signed version (and hence not helping to improve the current live version) it would be useful as a reference. Pseudomonas(talk) 13:59, 29 July 2008 (UTC)

Furthermore, I think the main problem is not technical, but social - one of areas of expertise. There are some (few!) fields where I can read an article and verify that the information is pretty much OK. In most others, all I can do is check that it's well-written, and that the references say what they're being quoted as saying. Pseudomonas(talk) 14:22, 29 July 2008 (UTC)


Like everything else in Wikipedia, the proposal is for a community-oriented voluntary effort. Really? I read it as a way in which I, "Hoary", were to personally guarantee that an article doesn't contain errors or misinformation. If I slap "Approved by Hoary" on a certain version of an article, this means approved by me, and not approved by Total Plastic. ¶ But then (let's imagine) User:Total Plastic is an old wiki-chum of mine: we go way back to the early 2006 defensive war against the "Tom Cruise is famous so his views on psychotherapy are noteworthy and he should be prominently quoted in pyschiatry articles" wacko; Total is always very congratulatory about my articles and I am about his, even though I secretly think he hasn't a clue about prosody and that his occasional, earnest efforts to edit articles on poetry are often to their detriment. To my embarrassment but secret delight, Total just stuck his seal of approval on my completed push to GA of Kanendo Watanabe (even though he hasn't actually read any of the source material, because it's all in Japanese), and he's just happily announced completion of his mammoth revision to Hudibras. My own limited understanding of prosody suggests that Total screwed up again; however, it's only one month since the FAC of Total's genuinely first-rate article on Nicaraguan English collapsed amid a pile-on of spectacularly silly objections from the kind of "English maven" who still takes Strunk and White seriously, so I don't have the heart not to stick my "Approval" on the wonky Hudibras. Whereupon User:Bituminous (who thinks Marjorie Morningstar is Great Literature, and labors under the delusion that I know my poetry) sees this "Approval" and therefore rushes to add his own; if asked, he'll swear blind tht he's read Hudibras whereas of course none of us has. ¶ There would be no requirement for anybody to sign anything, but if, for instance, you yourself have certified a particular article, scrupulously checking it, then you might wish to state this by giving a "digital signature" for that revision. I think it's extremely rare for anyone to scrupulously check any article. They'll attack it (or praise it) as a whole, they'll scrupulously check some particular part of it -- but a whole article, including a check of accuracy of citation (which would involve interlibrary loan and the rest)? I don't think so. ¶ No, this is going to need a bit more thought. I rather hope that there's some way to make it work, as I resent the strong suspicion I always have that what I'm reading could be wrongheaded, the fruit of a discredited theory, or plain fictional. -- Hoary (talk) 14:30, 29 July 2008 (UTC)
I've done a few interlibrary loans and checked a couple facts out. Never say never. I've verified sources and in fact I've utilized a template at one point in time that said something like "I'm CyclePat and I think this article is good" (on the talk page). nevertheless, lets play along with your idea that most people only check out a few facts. If you take a look at my currently working on user page, you'll notice I have a "My references" section. "Robert Tremblay reference for example links to several pages. I've even added a fancy [edit] button. I think a small verrified sign such as http://www.aperfectworld.org/clipart/symbols/check.png at the end of verified citation would be a better thing to consider. The facts in an article often come from various sources and often I disagree with many article because of the lack of proper referencing per WP:CITE. Not only does the lack of formating create a problem per wikipedia's guidlines and policies, it would create a problem, I believe for me anyways, to vote for an article as being good. Hence, given the complacency of many editor to add improperly formated references, I say this tool should concenctrate on evaluating "references", there verifiability, and trust worthyness. Nevertheless, nothing is stopping any user from presently doing this by creating a sub-page or a template on the talk page. So why not just start with that first and see what happens? Implementing, the works for security seems a little extreme... And by the looks of it, I think it's only going to create some "Poll" vote, so you or someone can have some weak argument that the status quo of an article is better than a proposed change. Essentially, I would see this being used as a type of weapon for Wikipedia article hogs to justify the current status of an article and to ignore change. B.t.w. thanks for trying to make this feel like our current political system in Canada! That is, like politicians, we usually let someone else read and make a decision for us...(sarcastically) Sounds good to me! No. Not really. Please speak for yourself. I think the idea is good. --CyclePat (talk) 19:39, 29 July 2008 (UTC)
I think we are talking at cross-purposes here. Let me try addressing how a "web of trust" setup works in more detail. First of all, the point of signing an item is not to rush around signing things willy-nilly, but that the signer actually be reasonably scrupulous in their check; after all, they are committing their word to this statement of trust. This leads to the next point, namely what if somebody does not follow that rule but signs whatever they like? This is where the inter-user trust comes in; the "web" part. The existence of the signed revision doesn't mean anything by itself; let me clarify that with an example.
  • Now, it's obvious that a given person — let's say User:NonesuchReader is reading the article about greater crested grabbarwobbits — User:NonesuchReader can't, philosophically speaking, ever really 100% know about another's motives and actions. Instead, there are certain people she trusts the opinions of. Let's say she trusts User:NonesuchPanjandrum, who she has interacted with regularly in WikiProject Grabbarwobbits, where he is noted for his careful and thoughtful approach. She also trusts User:NonesuchCharlie, who is an experienced vandal-fighter and a good judge of character.
  • She discovers that there is a signed revision of greater crested grabbarwobbits by User:NonesuchDoctor; who is he? Is his opinion worthwhile on this? User:NonesuchPanjandrum says, yes, that revision checks out, so he signs it as well for the sake of argument, and maybe after checking a few of User:NonesuchDoctor's verifications of grabbarwobbit-related articles, decides to "sign" User:NonesuchDoctor's ability to do so, adding him into the "web of trust"; he's proved his worth. User:NonesuchCharlie also decides to trust him, but based on an impression of his character rather than his expertise. This gives User:NonesuchReader two things she decides to rely on about him; that he is reliable regarding the verification of grabbarwobbit articles, and that he is generally of good character.
  • Now, User:NonesuchWanderer does not know either User:NonesuchPanjandrum or User:NonesuchCharlie. Therefore, she does not gain anything from this exchange; until she determines the nature of these users, their opinions regarding User:NonesuchDoctor are not very reliable to her. She subsequently decides to trust User:NonesuchCharlie's judge of character after seeing him defend a number of editors who were caught up in a large flamewar not of their own devising. Based on this, she is now fairly confident that User:NonesuchDoctor is, at least, of good character. However, until she forms an opinion of User:NonesuchPanjandrum, the existing statements of trust regarding his grabbarwobbitology knowledge and efforts aren't verified to her; she therefore reserves judgement on his signed revision to greater crested grabbarwobbits.
  • Note that the mere existence of a signed revision is meaningless. It is a starting-point from which you can determine who trusts that revision, and then you can start to determine if you trust their opinion in this matter.
None of that is absolute; it doesn't prove anything beyond a shadow of a doubt. But used properly, it can be a useful tool for following lines of trust beyond the "first degree" of people you trust directly and doesn't, in the end, leave us any worse off :-). --tiny plastic Grey Knight ⊖ 15:36, 29 July 2008 (UTC)
Apologies for the huge wall of text. :-) The web of trust article has more discussion about the general nature of such arrangements, where you may find answers to general questions about the process. Essentially, nothing new is added; people still trust each other for particular tasks, including trusting their ability to evaluate the trustworthiness of others. We do it all the time. All such a system does is quantify that trust in a verifiable manner, such that you can tell who trusts whom for what, and on that basis decide if you also trust them for anything. --tiny plastic Grey Knight ⊖ 15:42, 29 July 2008 (UTC)
I must oppose this proposal and concept due to the belief that it might lead to less open editing. Over time, the entrenchment of such a system might generate considerable pressure against the alteration of any version signed by a person of authority, thus inclining any such article toward stagnation. Since articles would be signed primarily for factual accuracy, rather than cohesion, style, or comprehensiveness, signing might retard the overall growth and improvement of an article in any area beyond mere accuracy. In general, a signing system might place us a little bit farther down the slippery slope toward the monstrosity of "stable versions" or the ill-advised creation of a hierarchy of editors. Mr. IP 《Defender of Open Editing》 14:37, 2 August 2008 (UTC)

MediaWiki:Protectedpagetext

Hi everyone, after looking at both the semi and full protected page messages (both at MediaWiki:Protectedpagetext), I was wondering if it would be possible to have a section like the one displayed when a non-admin tries to edit a protected page, where it informs them to use the template {{editprotected}} followed by your request to flag down an admin to make the edit for you be added to the semi-protection message, the only difference would be to tell the anon/new user to use the template {{Editsemiprotected}} instead of {{editprotected}} to flag down any auto confirmed user to make the edit for them, I have created an example of the text that could be used below,

This page is currently semi-protected, and can be edited only by established registered users.

  • Semi-protection is sometimes necessary to prevent vandalism to popular pages. Most articles can be edited by anyone.
  • The reason for protection can be found in the protection log.
  • If you have a user account, log in first. If you do not yet have an account, you may create one; after a while, you will be able to edit semi-protected pages.
  • You can discuss this page with others. If you have noticed an error or have a suggestion for a simple change, start a new section and insert the text {{editsemiprotected}} followed by your request. An established user may then make the change on your behalf.
  • You may request unprotection of the page.


I am requesting this because some semi-protected pages talk pages are not closely watched which could mean that a requested edit (Without using the template {{Editsemiprotected}}) could go a long time before being noticed by an established user, with the template used it would add the page to Category:Wikipedia semi-protected edit requests which would make it much easier to track and make edits to a semi-protected pages on the behalf on anons and new users. Thoughts? --Mifter (talk) 20:56, 30 July 2008 (UTC)

 Done Seems like an eminently sensible idea. Happy‑melon 15:21, 2 August 2008 (UTC)

Proposal of emergency measures in C68-FM-SV

Due to the unexplained disappearance of the Arbitration Committee, we now face a pressing need to form an emergency Acting Arbitration Committee until such a time as the real Arbitration Committee may return to us. I will be spearheading these efforts. The Acting Arbitration Committee will be appointed on a volunteer basis, with no Wikipedian in good standing excluded. Requests for membership will be accepted immediately, and the Acting ArbCom will take office on August 7th. A decision on the C68-FM-SV matter will be reached within 48 hours, and then pursued through Arbitration Enforcement. Thank you :D Mr. IP 《Defender of Open Editing》 18:48, 2 August 2008 (UTC)

A nice idea , but you can't just start your own arbitration committee - It's just a little too bold. There are serious problems with the case, but this is not the right way to go, and any decision you make would be totally unbinding. Ryan PostlethwaiteSee the mess I've created or let's have banter 18:53, 2 August 2008 (UTC)
Hehe, I think not (per Ryan). Who would be the first volunteer, I wonder? Happy‑melon 19:01, 2 August 2008 (UTC)
This is largely tongue-in-cheek, but it's an attempt to get the actual ArbCom to wake up and do something, or at least let us know that they plan to. For that reason, I definitely want actual volunteers! Mr. IP 《Defender of Open Editing》 19:05, 2 August 2008 (UTC)
All "Wikipedians in good standing", raise your hand and say "aye". That ArbCom takes no hostages. SandyGeorgia (Talk) 19:06, 2 August 2008 (UTC)
What unexplained disappearance? Can you provide evidence that the ArbCom has disappeared? Corvus cornixtalk 19:54, 2 August 2008 (UTC)
The C68-FM-SV case certainly isn't evidence for the existence of active arbitrators. Kusma (talk) 20:22, 2 August 2008 (UTC)
Moreover, as I was preparing my cereal this morning, I spotted the ArbCom on the side of the milk carton. I hold out hope...but I also fear the worst. It has been quite some time now with no sign...no ransom note, no flying saucer contact, no severed fingers or toes arriving in the mail.. What can I say - I'm a realist. But let me clarify now, for those worried that the Acting Arbitration Committee will delay or curtail the ongoing efforts to locate the actual Arbitration Committee: do not be afraid. We are continuing our search and will be combing project space in search of clues or survivors for the next several weeks. Mr. IP 《Defender of Open Editing》 20:36, 2 August 2008 (UTC)
I shall provide manpower and equipment to aid in the search... It is to the best interests of us all to locate the Arbitration Committee as soon as possible.
In the middle of the summer, we desperately need people to complain to about, well, everything. (Especially when something actually concerns them.) Waltham, The Duke of 21:48, 2 August 2008 (UTC)

Make all wikipedia articles accessible to all Countries

In some countries like China they block certain wikipedia pages like the Dalai Lama etc because they believe in internet censorship. Everyone from any country should have the right to un-censored wikipedia pages. Maybe wikipedia could develop a new technology or work with the organisations that manage the internet so all wikipedia pages can be accessed in countries like China etc who block wikipedia pages that they do not like. Danielspencer2 (talk) 04:28, 3 August 2008 (UTC)

Hi, Daniel, and welcome to the project. While I don't know much about the subject, my understanding is that it would be very difficult for a resource-poor project like Wikipedia to enter a software "arms war" with a massive government like the PRC, and virtually impossible to design around their censorship software without intimate knowledge of its details. The future probably lies in end-user run-arounds, rather than anything we can do. Mr. IP 《Defender of Open Editing》 06:51, 3 August 2008 (UTC)

More ways to donate to wikipedia

Some people I know do not have credit cards but want to donate to wikipedia. Alot of them were asking why wikipedia doesn't have an option for people to donate using their cellphone because they can purchase ringtones etc using their cellphone so it should be easy for wikipedia to setup an sms donate option where users can text(sms) message their donation.

I also know people who have their own website and use google adsense on it and they say it would be easy for them to donate funds to wikipedia directly from their google adsense earnings. Wikipedia should work with google and have an option for google adsense users to donate their adsense funds to wikipedia by having an option where adsense users login to their account and type in an amount(no minimum or maximum donation limits) and it will be passed onto wikipedia. Danielspencer2 (talk) 04:42, 3 August 2008 (UTC)

There is no way to "text their donation" to Wikipedia. Purchasing a ringtone through your phone either requires A) you be using a pre-paid phone (in which case the funds are deducted from the money on your account) or B) you are using a contract phone (in which case the funds are added to your bill). In either case, it's treated as a purchase made through your cell phone carrier. For Wikipedia to accept money through such a service, they would have to go through a lot of legal hoops to become a provider of a service accessed through the cell phone. It's not worth the expense to get donations that way.
If people want to pay without using a credit card, I'd suggest either using PayPal with a checking account, or buying a prepaid credit card and using that to do the donation. — The Hand That Feeds You:Bite 14:37, 3 August 2008 (UTC)
Just go to the post office and buy a money order and some postage. It is simply a question of taking advantage of legacy technology. Chillum 14:42, 3 August 2008 (UTC)

Is the Main Page an article?

On our Main Page, in the top left corner, there is a tab labelling the page as an article, when it clearly isn't. On the German Wikipedia, it's labelled as part of the project side of the wiki, on the Spanish it's a cover page, on the French it is the reception, Italian sensibly calls it the main page, in Dutch it's the head page, and Japanese it's the neck page (possibly a mis-translation), and in Russian it's title (shortened version of title page). Yahoo doesn't translate Polish. All the major Wikipedias (except Portuguese, they make the same mistake) label the main page for what it is. Why can't we do the same?

There has been discussion over at MediaWiki:Nstab-main, and I can't understand why we can't do this minor alteration, since other Wikipedias have done so without trouble. Anxietycello (talk) 15:35, 3 August 2008 (UTC)

Wikipedia:Village_pump_(technical)#Proposal:_Move_main_page_to_a_different_namespace Juliancolton Tropical Cyclone 15:39, 3 August 2008 (UTC)
Apparently it causes too much server load. --.:Alex:. 19:15, 3 August 2008 (UTC)

New proposal: Wikipedia:Fictitious references

I noticed someone going around adding wikilinks to Wikipedia:Fictitious references from various existing guidelines today. If it's useful enough to be a "See also" for existing guidelines it must be ready for community input, but all involved seem to have neglected to mention it anywhere. Please comment at Wikipedia talk:Fictitious references. Anomie⚔ 03:02, 4 August 2008 (UTC)

Proposal to nulify or reverse WP:N

The reason I use an encyclopedia is to have a brief but in depth look at a topic. In most cases the very reason I need an encyclopedia is to find sources and expansion on a topic which may or may not be notable. The current idea, however, is that an encyclopedia should only cover notable topics versus touching briefly on any topic that at least one person has found notable enough to edit. It is this fundamental difference in concept that sends me first to Google to find out if a topic exists, to the Wikipedia or other online source to get a complete summary and next to sources and expanded works via links and citations within the online summaries. In other words Google to search for something, Wikipedia to find a complete summary (if the issue of notability were reversed or nulled) and to books and other sources to explore greater depth. That way, as a reader or researcher, I get everything I need. The current way I get nothing from the Wikipedia if a topic is not considered to be notable by users who have absolutely no interest in the topic I am researching. Julie Dancer (talk) 03:49, 30 July 2008 (UTC)

I don't think any proposal to simply strike down the notability guidelines is going to get very far. I'd suggest you look at WT:N to see some ongoing discussion on potential changes to them, however. Shereth 03:55, 30 July 2008 (UTC)
I am so glad you got to this before me, Shereth. You are indeed very kind. S. Dean Jameson 04:21, 30 July 2008 (UTC)
I agree, but other users who participate in a deletion discussion may indicate support for a DELETE or a KEEP based entirely on what they feel is interesting and with a majority of DELETEs posted in the discussion an article may be deleted due only to how interesting a majority of deletion discussion users feel the article is. Find a way to prevent mob rule and I might fully agree. Julie Dancer (talk) 05:56, 30 July 2008 (UTC)
Have you actually participated in many AfDs? In the scenario you describe (people commenting "Delete, I've never heard of it) the article would be kept. It's becoming apparent that your position in regards to some obscure subject having its article deleted is what precipitated this. Just as IDON'TLIKEIT isn't a good argument for deletion, so IREALLYREALLYLIKEIT isn't a good argument for inclusion. S. Dean Jameson 13:03, 30 July 2008 (UTC)
But the admin reviewing such a discussion looks beyond that, to opinions that use policy or guidelines to back them up. So an opinion of "Delete. I have never heard of it." is going to be outweighed by "Keep. These reliable sources show notability." Admins are more than just vote counters, even suspected Communist Chinese cabalists like myself. (Julie asked if I was one in an email) Kevin (talk) 06:04, 30 July 2008 (UTC)
The question of your political affiliation or allegiance was raised externally in private, not within the body of the Wikipedia itself because it may in the real world not be taken so lightly as it would be here. It is the same reason email addresses are deleted here to keep the real world from sneaking in. That said, you have not actually read the primary reference and looked up the references it contains or visited the Lovelace Center where the method is used extensively everyday or for that matter visited any of the institutes in Russia who's scientists came to the Lovelace Center and helped develop the method as well. You have not corresponded with the publisher of Dr. Rypka's work or with other users of the method to see how even with high speed computers the method, a method developed in 1971, still has major application today. The question now is who can trust the Wikipedia if its administrators consider such methods unnotable on the basis of Wikipedia user opinion on either side, including their own that would prevent future researchers from becoming aware of the method. Shame on you. Thank God such a method is welcomed for publication somewhere else. Julie Dancer (talk) 06:21, 30 July 2008 (UTC)

I cannot believe this proposal is ever going to be implemented, but I still want to make a response. As I understand (and this isn't necessarily official or anything), the "notability", our inclusion criterion, essentially follows from two things (i) the fact that Wikipedia is an encyclopedia (ii) verifiability or attributability (see Wikipedia:ATT for definition). (i) is the founding principle, and isn't subject to change, probably. If (i) were to change, for one thing, our very slogan has to change: Wikipedia, the free encyclopedia. But since we are thinking about adopting Creative Commons license, this might not be out of possibility; if enough Wikipedians think Wikipedia should become something more than an encyclopedia, then this can happen. So, (i) isn't quite a strong argument, I think. I know you can start a fork, as many have already done. (Knol can be seen as an example of the approach along this line.) But that's missing the point: a significant number of people want "Wikipedia" (not anything else) to become something beyond an encyclopedia, something fitting to the digital age, not restricted by an old-fashioned notion invented in the era of enlightenment. (I wonder what is a procedure to make a proposal of a constitutional amendment. This page isn't for that, for sure.)

Moving on. (ii) is probably a more sever constrain, necessitating notability. In my view, this is exactly what Citizendium calls "maintainability" [2]. I don't know about your experience, but it is very hard to maintain articles on non-notable topics, because by definition, a topic is notable if and only if it has sources that can be used reliability to write an article that is not a joke or junk. Local newspapers or small obscure academic journals contain a full of non-sense, so they cannot be used reliably. Since Wikipedia doses contain a fair amount of jokes as well, it cannot be reliable, either. To relax (ii), in other words, we need some kind of quality assurance mechanism. Maybe Wikipedia:Flagged revisions is the answer, since we pretty much reject the idea of experts or real name verification, etc. I started contributing to Wikipedia when there was no "notability" criterion, so I won't be surprised if Wikipedia drop "notability" criterion in the future. -- Taku (talk) 04:35, 30 July 2008 (UTC)

So, aside from the wonderful suggestions that previous editors have mentioned (such as pointing you to the ongoing discussion possible changes), you think we should change WP:N because it currently interferes with your ideal of "Google for a search, Wikipedia for a summary, and books for depth"? I think the cabal that makes such decisions will need more compelling evidence than "because this is how I want it". − Twas Now ( talk • contribs • e-mail ) 05:44, 30 July 2008 (UTC)
I can only speak for myself, even though my opinion is likewise limited to my online experiences going back to the old dial-up message boards days of... lets see that would be about 1978. Julie Dancer (talk) 06:01, 30 July 2008 (UTC)
Interesting, I didn't know of any encyclopaedia projects back in the day. Can you remember any names? We might get some neat articles out of this if we can look up some sources. --tiny plastic Grey Knight ⊖ 16:31, 30 July 2008 (UTC)
Julie's post followed the deletion of his/her article Optimal classification at Wikipedia:Articles for deletion/Optimal classification. I believe they would be more effective in generating positive discussion if they are open and honest about their motivations. Dcoetzee 22:24, 30 July 2008 (UTC)
There are other Wiki hosts without notability requirements, may I suggest you use on those? -93.96.212.203 (talk) 15:07, 4 August 2008 (UTC)

Proposal to change WP:As of policy

WP:As of has been the subject of some debate over the last few months, culminating in a deletion proposal in May. The result of this proposal was no consensus; the intended substitute {{Update after}} was not generally believed to be sufficient to replace "As of". However there was some agreement that the [As of ...] links needed to be replaced with something less obtrusive (see also the original proposal). This led me to create my proposal for a new project page (see Wikipedia talk:As of#Proposal for new project page). I have already implemented the page, but following the suggestion of another user, I have posted the change for discussion and, if necessary, reversion.

The proposed policy implements the heavily modified {{As of}} template to categorise statements in (hidden) subcategories of CAT:ASOF rather than linking to the [As of ...] pages. The default "As of..." text also encourages the use of precise language, which was one of the concerns regarding the {{Update after}} template. The categories are low maintenance and easier to browse and access than the WhatLinksHere/[As of ...] pages, and most helpfully the template creates no visible wikilinks in the statement itself, which was the reason for the original deletion proposal. For reference you may also wish to see the old project page. Thanks – Ikara talk → 16:00, 31 July 2008 (UTC)

I support a policy using {{As of}} instead of [[As of ...]] links which cause confusion and are often deleted or altered in good faith by editors who haven't heard of the As of policy.
To reduce duplication in maintenance work, I suggest adding an optional url parameter for a url which seems likely to be updated if the status of the as-of statement changes, for example a relevant page on the official site of an entity the statement is about, or a page which currently maintains updated results and may continue to do so. Maybe there could be an option in preferences (off by default) to display a link to the url at the as-of statement. Even if such a link were never shown, editors seeing the source could copy the url.
And a minor suggestion: Let {{As of}} print lower case "as of" whenever the parameter lc is present, instead of having to type lc=on. PrimeHunter (talk) 16:52, 31 July 2008 (UTC)
Thanks for the support. The lc parameter will actually give lower case if the parameter is defined and not whitespace (you cannot simply use {{As of|...|lc}} as that would behave as {{As of|...|#=lc}} where the # is the parameter name and depends on other defined parameters). You could use, for example, {{As of|...|lc=1}} or even, with slight modification to the code, {{As of|...|lc=}}, but I proposed using lc=on as it makes the wikitext more readable. The same is actually true of the df parameter, although df=US allows addition of new date formats later if required. I will modify the template documentation to make this clearer. As for a url parameter; am I correct in thinking this should be a non-functional parameter? If so simply using url=[URL] in the template would suffice. It is possible to create an inline flag such as: [URL] to appear at the end of the template, but it would have to be hidden by default, and only visible to users who modify their Monobook.css file correctly. I am also wary of doing this as users who do not have CSS enabled will see the flag by default. Please note that these statements should usually be referenced anyway, and if such a URL is available it should be used as the reference. For now I will modify the documentation to suggest using the url parameter in a non-functional capacity only (it will probably be forwards-compatible). All the best – Ikara talk → 00:42, 1 August 2008 (UTC)
Anyone viewing wikipedia without CSS support will be viewing one of the blandest and most confusing sites on the internet. Without CSS, the interface (sidebar etc) won't display properly, never mind the actual content. Amboxes and talkspace messages will all display as plaintext, as will many navboxes, references, co-ordinate templates, etc etc etc. Wikipedia assumes CSS support for a sensible browsing experience, so the idea you propose above is a good and usable one. Incidentally, I think this proposal is an excellent idea. Happy‑melon 14:04, 2 August 2008 (UTC)
In that case, I will look at adding the flag assuming this proposal is accepted (given current reactions I expect it will be). The documentation now encourages the use of the url parameter to assist future editors. Thanks – Ikara talk → 21:54, 2 August 2008 (UTC)
I also strongly support this change. "As of" is very useful indeed, but has needed reform for a long time. I like everything about this unobtrusive new system. One small thing: the current template renders linked dates when Y/M/D are all provided, correct? Is the final product going to do that as well? I would remove datelinking from the results entirely. It's not a big deal, as I doubt that many users are going to provide tripartite dates in their as-of tags, but since datelinking is gradually on its way out, it might be nice to leave it out of this entirely. But anyway, great job. Mr. IP 《Defender of Open Editing》 13:47, 2 August 2008 (UTC)
'Scuse me, this is off-topic but: datelinking is on its way out? I thought that datelinks were part of accessibility? Am I confused with my definitions? Franamax (talk) 14:07, 2 August 2008 (UTC)
There is a group of editors who absolutely hate date linking and/or the date auto-formatting preference. They managed to get WP:MOSDATE changed from recommending datelinking to making no recommendation either way, and there has been activity on Template talk:cite web regarding the dates in citation templates. I have no idea how large this group is versus the (unorganized?) opposition group or the uninterested group. IMO, the only way datelinking is "on its way out" is through attrition as others get sick of fighting over it. Anomie⚔ 17:22, 2 August 2008 (UTC)
It's true. "On its way out" was sort of my way of saying "I intend to kill it dead" :D Seriously, as the practice is no longer recommended, I would prefer to see it left out when we're remaking templates and such. I admit that the earlier phrasing was tendentious. Mr. IP 《Defender of Open Editing》 17:49, 2 August 2008 (UTC)
The current template uses the {{Start date}} template to display the date, which automatically formats the date, adding the wikilinks. It does not add the links or have any control over whether the dates are linked currently, aside from manually adding the date without links using the alt parameter. – Ikara talk → 21:54, 2 August 2008 (UTC)
I would oppose making this into anything much more than a strong suggestions. This is policy creep at its finest. There's no feasible way we can require people to do this, and sanctions for not doing this would be downright silly. Once this becomes standard practice and more widely known, it could become a WP:MoS-type guideline but this is far too trivial to be a policy. Mr.Z-man 14:10, 2 August 2008 (UTC)
The use of "policy" here just appears to be sloppy wording. I don't think anybody is suggesting this becomes an official policy - I'm not although I copied the word from the original post in my responce. PrimeHunter (talk) 14:20, 2 August 2008 (UTC)
Agreed. This isn't policy so much as the improvement of a useful tool for keeping our encyclopedia up to date. Mr. IP 《Defender of Open Editing》 17:50, 2 August 2008 (UTC)
Apologies, that was my sloppy wording. "As of" is not and never has been an official policy. What I meant was to change the policy (guideline) of the project page and not of Wikipedia itself. Getting it included as a MoS-type guideline would be beneficial, but is still some way off. Hope that helps – Ikara talk → 21:54, 2 August 2008 (UTC)

Update: I have now added inline reference support and updated the template documentation and WP:As of to reflect this. You can see a static example in the documentation, for use in articles you need to add a line of code to your monobook.css page. Feel free to look over the changes and tell me if anything needs fixing. Thanks – Ikara talk → 02:40, 5 August 2008 (UTC)

Watchlist for sections

This may be a bit ambitious, but I would like to request that one be able to watchlist a particluar section of an article. I must admit that the only reason I am requesting this is to watch portions of high-volume talk pages, such as here in the various Village Pumps. SharkD (talk) 01:26, 1 August 2008 (UTC)

I checked Wikipedia:Perennial proposals and was a little surprised that this wasn't listed. Among the problems is that Wikipedia is page-based (in terms of storage, data tracking, etc.); sections are highly modifiable and transitory. For example, I just moved a "See also" section in an article to be above the "References" section, per WP:GTL; that's easy for a person to understand (when looking at the diff), but potentially nightmarish for computer software if, somehow, it were to try to keep track of sections for the purpose of watchlisting. And what about subsections, which are even more transitory? (Not that I'm not sympathetic; this is why pages like lists of AfD discussions are primarily transclusions of individual discussions - so that editors can follow individual discussions.) -- John Broughton (♫♫) 01:54, 1 August 2008 (UTC)
Yes, everyone wants this, nobody is objecting. Now, all we need is someone with the programing skills to improve the open software we run off of to do that. Despite what John says, I don't think it would be that complicated to program. Chillum 01:56, 1 August 2008 (UTC)
Thanks for the replies. I didn't think it was a likely possibility, anyway. SharkD (talk) 02:08, 1 August 2008 (UTC)
Given the difficulties John mentions, a more practical (though also quite revolutionary) way to go would be to eliminate the multi-topic discussion pages, like the village pumps and certain others (is it Requested Moves that causes similar problems? can't remember now), into dedicated discussion pages which can be merely linked to from a central location, as is done with AfD.--Kotniski (talk) 06:33, 1 August 2008 (UTC)
That's an idea. It would also mean that links would never die if you linked to a discussion and wanted to keep it as a reference. SharkD (talk) 07:05, 1 August 2008 (UTC)
I'd strongly support this. The subpages could be transcluded to give the page an identical appearance to that at present. Watching the main page would give notification as to when subpages are added or removed. Pseudomonas(talk) 11:30, 1 August 2008 (UTC)
Ditto. But, two (that I can think of) complications: "New section edit"s would get a little more complicated; and, wouldn't the various archiving bots have to monitor a number of pages for activity, then modify the "parent" (actually, that one doesn't sound so tough) Saintrain (talk) 22:31, 1 August 2008 (UTC)

There should be some consideration for moving this discussion to WP:VPT, as it is pretty much a technical suggestion. Shereth 22:59, 1 August 2008 (UTC)

well, supposing this is extermely complicated and will be a long time in coming, i think it would be a good idea to at least shift all XfD discussions to the AfD format, it is extremely frustrating to have to wade through archives when non-articles are suddenly deleted and the closing admin decided they didn't need to leave a relevant link in the deletion summary. as for a workaround:
  • Go to preferences
  • Click on Watchlist
  • Check box marked 'Expand watchlist to show all applicable changes'
this isn't a perfect solution, but at least this way you see whether specific sections on a page have been modified -ΖαππερΝαππερ BabelAlexandria 03:45, 2 August 2008 (UTC)
It wouldn't be hard to do a partial solution, but this would be highly fragile in the face of section name changes and archiving. We need a more robust solution complete forum solution in the long term. Dcoetzee 06:56, 2 August 2008 (UTC)
There was a proposal a while ago to convert other XfD processes to be like AfD, it got a lot of support, but I don't think it was ever implemented. As for a more robust forum solution, something like mw:Extension:LiquidThreads? Development is a little slow, but I think the goal is that it will eventually be used on Wikimedia projects. That would still only work on discussion pages though, it wouldn't work in sections that aren't being used for threaded discussion (sections in articles). Mr.Z-man 13:40, 2 August 2008 (UTC)
do you know where that discussion was? I wouldn't mind being bold about implementing it, so long as i had a relatively recent discussion to point people to. -ΖαππερΝαππερ BabelAlexandria 14:26, 4 August 2008 (UTC)
Wikipedia:Village pump (proposals)/Archive 29#Transcludable XfD discussions. -- John Broughton (♫♫) 17:59, 4 August 2008 (UTC)

Static Wikipedia

Recently a user falsely defended his wrongful deletions on the fictitious grounds that the article had no references so, as he claimed, to assure user confidence in Wikipedia articles as being trustworthy such deletions had to be made according too him. (The real reason for the deletion, BTW, was a grudge against the author.)

The problem with this argument, however, is that as a continuously open edit source Wikipedia articles are inherently untrustworthy since vandalism may occur moments before any article is downloaded or correction or update may occur moments after the article is downloaded.

To remedy this (in theory) and expose the problem I am proposing the creation of a static Wikipedia that is created once a day, week or month with only changes being looked at and deleted by administrators for the time interval selected. --iggy 10:14, 2 August 2008 (UTC)

I don't understand your proposal. Can you explain further? — Cheers, JackLee –talk– 12:28, 2 August 2008 (UTC)
It is essentially a proposal to end truly open editing forever, regardless of the specifics. I strongly oppose all such ventures, no matter what their intentions. Mr. IP 《Defender of Open Editing》 13:13, 2 August 2008 (UTC)
Not to end but rather to supplement in a manner where the static version contains the reviewed and approved changes for a previous time interval. Users would continue to edit the dynamic version but at the end of the time interval only the reviewed and approved changes would be included in the version that was no longer editable and static. Currently archived versions which could provide this function are currently open edit as well. (...of course I'm not really serious, however, this idea is just a spoof.) --iggy 13:37, 2 August 2008 (UTC)
Check out Wikipedia:Flagged revisions. − Twas Now ( talk • contribs • e-mail ) 15:42, 2 August 2008 (UTC)
And Veropedia. -- John Broughton (♫♫) 17:53, 4 August 2008 (UTC)

Discussion about activating WikiTimeLine extension on Wikipedia

This is the WikiTimeLine interface with the events "Earth", "Trilobites" and "T-Rex" added. At the top is the main with all events and at the bottom the overview area (with a much larger scale). You can move the timeline around with the help of the mouse courser and zoom in/out, remove events and click on events to get more information about them (even go to their article page).

Activating the WikiTimeLine extension on wikipedia would be a good idea I think. Its the, kind of, interactive and real-time version of easytimeline. Controlled by the reader of the article instead by the writer. You add tags to an article, if the reader clicks on such a link, an event will be added to the timeline. You can add the events you want (and so create an individual timeline), zoom in/out and move around. See the live example and more information here (just click on a few of the links at the top) and its MediaWiki page here. Its like a mix out of WikiTimeScale and the Simile Timeline. The interface is in JavaScript, so there's no heavy load put on the server since nearly everything runs client-side. Thus it can be used by heavy traffic wikis (like the wikimedia foundation wikis) too. The guys at bugzilla told me we would need to be interested here first and afterwards the admins of wikipedia could go to bugzilla/the developers of mediawiki and request the activation of the extension. Any interest in this extension for wikipedia? Please show your support here if so. ColdCase (talk) 12:25, 2 August 2008 (UTC)

Looks very interesting yes. Could you clarify what we would use it for exactly? Skomorokh 19:40, 2 August 2008 (UTC)
Of course. For example: Timeline of the dinosaurs, timeline of the roman empire, timeline of the evolution, timeline of the universe, timeline of our solarsystem, and so on. And when I'm talking about a timeline here, I mean dozens of events that can be seen parallel. And the best: You can stick them together as you like! So you can watch: Ok, when did the humans emerge compared to the existing of the earth? When were the dinousaurs? You can go from one article to the next and add the events which are listed there. So you can stick together your individual timeline. As you can see in the picture above: It's a comparison between: When did the T-Rex exist, and when the Trilobites, compared to the existing of the earth. Its just like: Ok, I want to see that, and that, and that, compared to each other on a timeline. Its realy interesting to see that humans are only a very narrow band at the right end of the timeline compared to the whole existing of the earth ;) Even complex life itself did emerge very late in the earthly evolution... Anything that ever was history (or can be predicted for the future) can be displayed and compered to each other, no matter what topic it is. It's just like a little timeline wonderland ;) ColdCase (talk) 01:26, 3 August 2008 (UTC)
I think it would be great. Just about every article about a topic in history would benefit. I'm not a fan of too much javascript, but this would be worth it. My only concern is that it doesn't work with older browsers. ·:· Will Beback ·:· 01:39, 3 August 2008 (UTC)
It has been successfully tested with: Internet Explorer 6, 7, 8 (as well as with the IE 5.5 engine); Firefox 2, 3; Opera mini; Opera 8, 9.5 (partially functional with 7 and 7.5); Safari 3.1, 4; Mozilla 1; Netscape Navigator 8, 9 (partially functional with 6 and 7). Should a browser not support javascript, simply nothing will be shown. If a browser doesn't support AJAX, it still works as long as you doesn't change the article/page (so you can at least add the timelines of one article). So I would say it should work for 99% of all users ;) ColdCase (talk) 12:09, 3 August 2008 (UTC)

FWIW, timelines are already used on Wikipedia using existing markup - see Timeline of Macintosh models for example. -93.96.212.203 (talk) 15:03, 4 August 2008 (UTC)

There is a lot of information about timelines in the editor's index. -- John Broughton (♫♫) 17:51, 4 August 2008 (UTC)
Please, I would appreciate if interested users would read what this extension is about before saying "there are already timelines". This extension would put the timelines on a whole other level, interactivity, and so on... please read and try it out yourself (see live example in original post). Don't just lable it with "already existing". This is not easytimeline. If it's about history, wikitimeline is million times better. On the other hand, if its about statistics, you'll need easytimeline. EasyTimeline is server side, WikiTimeline is clientside (javascript) and can do things easytimeline could only dream about ;) Its also easier to use than easytimeline (again, nothing against easytimeline, it can do things wikitimeline cannot do). So, please take just the little bit time for a live example. Again, here's the link to the live example, just click on the links in the first line ;) If you still oppose it after you'd taken your time to know what this is about: ok, no problem! ColdCase (talk) 21:56, 4 August 2008 (UTC)
So, per mw:Extension:WikiTimeLine, the extension is at version 1.0 as of July 2008. Shouldn't take much to activate it - though I'm not sure exactly what is needed. -- John Broughton (♫♫) 22:45, 4 August 2008 (UTC)

Renaming

I've made a proposal to rename WP:Editor review at Wikipedia_talk:Editor_review#Renaming. Comments and ideas are welcome. MBisanz talk 18:48, 4 August 2008 (UTC)

Need better handling of Ogg video in articles

(This may be a software proposal that perhaps should go into BugZilla, though at the moment I don't claim to understand the layers of software well enough to know exactly where this should go.)

There are some major problems with the way video is currently handled on Wikipedia, and I assume this extends to other Wikimedia projects:

  • Video is treated like a image in articles even though the data format is not the same at all. The keyward "Image:" is used to display video files for no apparent reason.
  • Wikimedia software actively transcodes images to a smaller size when an editor wants to post a thumbnail or otherwise resized image in an article. This transcoding is done to conserve bandwidth and send no more data than is required to show the image. This is done transparently for users.
  • Wikimedia software does not actively transcode video and in fact does nothing at all to video when displayed with a frame size smaller than the original. If a 640x480 video is uploaded to the Commons but then displayed in an article at 128x96, it still streams to the reader at the full 640x480 bit-rate and consumes a massive amount of bandwidth unnecessarily.

It doesn't seem like video handling has been properly considered by whoever designs this software, compared to the handling for image auto-resizing.

DMahalko (talk) 14:09, 27 July 2008 (UTC)

Changes that don't require added functionality

In general I am proposing two changes here to the way video is handled, which would better deal with how video is used now:

  • 1. Use "Video:" to designate all video content in wikipedia
  • 2. The image thumbnail template needs to be modified to be able to recognize when video is being displayed, and to not attempt to resize the video frame to smaller than the original since it saves nothing and wastes bandwidth, and to ignore attempts by editors to display a video with a smaller frame size than the original video.


With this change in place, it will reflect the realities of working with video as it stands now. If an editor wants a smaller frame size they are going to have to:

  • Download the current large video
  • Transcode it on their local machine
  • Upload the smaller video as a retouched version of the original (not replacing the original)
  • Link to the smaller video they have uploaded, showing it at full frame size without using "100px" resizing methods

I have created an example of how these transcoded alternate video files can be linked to the original. I will be using something like this for my future video work: Image:Rhof-histWaschmaschine.ogv


TIrreler Bauerntradition shows an early Miele washing machine in the Roscheider Hof, Open Air Museum
This video size: 50% 100kbit
Other sizes and bitrates: 25% 64kbit‎ 75% 220kbit 100% 270kbit Original 1100kbit

Since I know that the image template is broken and that resizing of video should not be attempted, I am experimenting with my own freeform wikitable video template style that makes no attempt to resize the video, as seen in the washing machine article:

(I am also showing this example on Wikipedia:Creation and usage of media files.)

DMahalko (talk) 14:09, 27 July 2008 (UTC)

Automatic video transcoding

A much more extensive change to functionality is that the Wikimedia software should add a capability to transcode video into smaller frame sizes and lower bit-rates automagically without any further input from the user, just as it already does resizing for image users.

There is no defined method for doing this so it would have to be created. Image templates can already use "100px" to designate a width. Something similar should be possible for video, perhaps with an additional "kbit" designation:

[[Video:Example.ogg|200px|200kbit|thumb|Example video shown at 200 pixels wide and 200 kilobits maximum streaming rate.]]

DMahalko (talk) 14:09, 27 July 2008 (UTC)

How to handle the time needed to transcode?

A potential problem here has to do with the time and processing power required to transcode video. It takes me about two minutes to transcode a one minute video clip.

Wikimedia transcodes images live and on the fly since the data volume to be transcoded is small. Doing on the fly video transcoding may not work, especially since there may become a backlog of video to transcode as thousands of people add and edit video in articles.

Also it seems possible for the transcode queue to be subject to abuse since it does take a certain finite amount of time to transcode a video file. A vandal could queue up hundreds of transcodes, each with sligtly varying transcode parameters, and fully block transcoding for anyone else.

Capping transcodes to a certain number per day doesn't seem like a good option since a vandal can just keep overflowing the limit each day. I do not know of a good way to handle video transcoding issues and dealing with potential system vandalism.

DMahalko (talk) 14:09, 27 July 2008 (UTC)

How to handle the storage needed for transcodes?

A second issue has to do with storage. Apparently wikipedia transparently stores resized images in a cache so they don't need to be recoded again when viewed by thousands of people in an article. Presumably if wikimedia did its own transcoding of videos, these too would have to be cached, and the space used by these transcodes is not trivial.

Here too I have concerns about vandalism since a vandal could generate many transcodes of a 20 meg video which end up consuming hundreds of megs of Wikimedia storage.

DMahalko (talk) 14:09, 27 July 2008 (UTC)

Maintaining status quo

If automatic transcoding is not used then we are stuck with the current system, where each user is left to their own devices to muddle through using a local transcoder on their own computer and uploading each size variant of the same video.

There are no guidelines for what bandwidth rates should be used for transcoding or for frame resizing, and so the results of transcodes created by each user are already highly nonuniform and inconsistent from one video to the next.

I am trying to make a stab at finding consistent methods here: Wikipedia_talk:Creation_and_usage_of_media_files#Offering_multiple_video_bit-rates

The annoyance factor for local transcoding seems to be a limit on vandalism abuse, though I don't see anything that prevents a vandal from uploading hundreds of recodes of the same video and wasting wikimedia storage space that way, too.

Overall I just don't see a good way to handle this, but something should be done to make it easier to use video in articles.

DMahalko (talk) 14:09, 27 July 2008 (UTC)

Interesting. I didn't realize Wiki(media) supported video formats. I guess a solution is to offer several (standardized) sizes of a video, maybe in steps of powers of two (e.g., 128x128px, 256x256px, 512x512px, etc.), except sized to fit the more common 4:3 aspect ratio. They could either be, a) uploaded by the editor or, b) created automatcally by the server. The actually displayed video would then be chosen from among these possibilities and squeezed into whatever size is specified in the article itself. I would suggest reducing the number of possibile sizes to a finite (low) number. Making this value finite and basing the scheme on powers of two (or powers of some other number) ensures that minimal amounts of local disk space are wasted on very large files. SharkD (talk) 18:08, 27 July 2008 (UTC)

I always thought the reason we didn't have that much video was because of some conspiracy from "Big Brother" to reduce Wikipedia's already very large bandwith. Hence I always though there was some sort of unwritten rule that we try and keep this fact a secret. Maybe, instead discussing this here, there you could consider a better venue. Have you looked into wikipedia to see what type of documentation already exist regarding the uploading of media files (images)... ogg files... etc? (Try gathering up as much information on this) I remember looking into, but getting a couple road blocks primarilly from the "upload" mecanism. Instead of what now appears to attempt to denny the fact we can upload video's why not simply have a section which actually deals with it. I think this proposal brings up a valid question. First off, 1) it's difficult to format an OGG file (or at least the last time I tried it was) 2) It's hard to figure what are the specs we should use. So again, instead of ignoring the problem I think we should look into this issue a little further. Elaborate a plan that deals with videos. Which ones should be kept, which one deleted. The maximum size. Etc. Maybe it's time to start WP:VIDEO (and place that gathered up information there) which could follow similar guideline to WP:IMAGE. --CyclePat (talk) 06:00, 29 July 2008 (UTC)

I would even recommend adding mecanisms to prevent "new" users to upload videos. And add a security code feature; like some random letters. Or a maximum upload ratio for video of maybe 3 videos per IP range (that covers Sockpuppets that try to upload more) --CyclePat (talk) 06:05, 29 July 2008 (UTC)
We find using a codec that is so obscure that currently no one outside hard core free content enthusiasts knows about it and how to transcode into it keeps uploads under control. The reason our video handeling is fairly poor compared to our image handleing is that for images it was mostly a matter of building ImageMagick and RSVG into mediawiki. However at the moment support for Theora is somewhat lower (which is why a lot of us who upload videos still use command line based ffmpeg2theora in order to do it). Cortado (software) is better than nothing but it is still fairly basic. There is however going to be at least some work to improve this. See here.Geni 15:43, 29 July 2008 (UTC)

So transcoding to produce multiple bitrates is a long term goal for MediaWiki. However because video recoding is so CPU expensive (compared to resizing a single image) it needs a lot of special systems/mediawiki infrastructure that no one has created yet. It will come eventually, however. As far as bandwidth goes... Video really not a problem today, in fact there are a number of complicated reasons why it would be very good for Wikimedia to have a lot more video traffic.

As far as creating Ogg files, there is pretty good tutorial on commons, improvements welcome.

For now we can do what we did before mediawiki supported thumbnailing images: We can encourage people to upload high-res and we can manually make lower quality thumbnails. It wouldn't be hard for someone to setup a bot doing this. Not ideal, but not the end of the world either. It would probably be useful to make a set of recommended bitrates and resolutions for manually generated thumbnails... I don't believe anyone has done that yet.

People interested in this subject may also be interested in this list post. --Gmaxwell (talk) 00:02, 31 July 2008 (UTC)

So, you are saying that users are being encouraged to upload high-res versions of videos? For some reason I expected otherwise. SharkD (talk) 01:33, 1 August 2008 (UTC)
There is a 20 megabyte file size limit for all file uploads to Wikipedia and the Commons, so the choice for an uploader is high resolution but only for a few seconds, or a small low-quality low-res movie running for minutes. That seems to be enough of a usage limiter alone. DMahalko (talk) 13:42, 5 August 2008 (UTC)

Request for flagged revisions

Let's face it, flagged revisions will not be implemented on the English Wikipedia because of lack of consensus. (At least I'll be very surprised if it is.) And maybe that's a good thing, it's impossible to tell now, there's a lot of convincing arguments on both sides.

My proposal is to make flagged revisions available for certain pages. Admins would be able to set a page to flagged revisions with a process similar to WP:RFPP. This could be used as an alternative to semi-protection. One page that could use this that comes to mind is evolution but I'm sure there are many others. (It wouldn't replace semi-protection, just be another alternative.)

Under this way, the majority of Wikipedia would be unchanged, just a few articles would have it; Unregistered users would be able to edit some pages they previously could not, albeit it would take some time before their changes appear. Every page would require consensus on whether or not to have flagged revisions.

To keep things simple, I would recommend against making a new user group, and would give the new rights to rollbackers, admins, etc..., but I am open to a new user group if consensus goes that way.

This proposal has a much better chance of gaining consensus, I believe, and would also allow us to see flagged revisions in action in a non intrusive way. If it turns out to be really helpful and is implemented on a lot of articles, people would be more open to the full flagged revisions. If it doesn't, then we can just go back to the status-quo.

Please let me know what you think. Jkasd 07:05, 30 July 2008 (UTC)

Hmm, I just brainstormed up an idea: what about some kind of poll of anonymous readers/editors? Since flagged revisions, as currently proposed, won't affect logged-in users at all, it makes sense to seek input from the people it will affect. We could stick a link in MediaWiki:Anonnotice. The question is, a link to what—we could do just a standard project page, but I'm not sure if the opportunity cost of looking at the page, going to edit, and typing out a response would lead to low interest (and sample bias). A simple click-and-submit poll might be better; maybe the devs can hack up Special:Boardvote, or something could be put up on the toolserver. --Slowking Man (talk) 10:05, 30 July 2008 (UTC)
I don't think that's a good idea; such a system is probably gameable. {{Nihiltres|talk|log}} 11:47, 30 July 2008 (UTC)
It's probably even more 'gameable' to have a discussion about a feature that affects only anon users and then basically not tell them about it. --VectorPotential Talk 11:53, 30 July 2008 (UTC)
It will affect logged in users - their changes will not be immediately visible. Hut 8.5 20:14, 1 August 2008 (UTC)
Well, personally I think flagged revisions should be enabled with the only real effect (i.e. what anons see) being for those "flagged-protected" pages, so this sounds like a great idea. Adding the basic support for flagging of a) featured articles (just as markers, give ability to set to admins +perhaps a new usergroup) and b) clean of vandalism (just as markers, give to either rollbackers or a new group, and admins) would be a bonus that wouldn't have much effect on what anons see but would be useful to the community. {{Nihiltres|talk|log}} 11:47, 30 July 2008 (UTC)
Yes, I'm prepared to support this. Maybe we could enable it for all articles, but make unregistered users see the newest version unless an admin sets the page otherwise (in a way similar to this proposal). Hut 8.5 20:14, 1 August 2008 (UTC)
I'm an extremist opponent of universal flagged revisions, but I could almost get behind this. With luck, it would permanently establish FR as an option only for Wikipedia's most troubled pages, preventing the insidious idea of FR from creeping its way all over the rest of the project. What I would like to see is an established hierarchy of "emergency page status" measures that admins could employ for troubled pages - a unified system with several classes of page protection, in which FR would be one of the options. In fact, I would like to see full protection deprecated entirely, and possibly replaced with FR. Semi-protection would remain in place, but full protection would be replaced by "flagged revision status" where the default is set to the most recent flagged edit. Mr. IP 《Defender of Open Editing》 14:19, 2 August 2008 (UTC)

I'm quite a skeptic too, but I agree it seems reasonable to make a trial. We can each continue to guess indefinitely what the effect would be, but we won't be the wiser for it. I think it may have been suggested elsewhere to start with BLPs generally. That seems broad, but I'd support it to take the pressure off making yet more drastic limits on BLPs that would really impair the principle of NPOV. We could start with certain definable classes, like politicians currently running for office. DGG (talk) 05:39, 3 August 2008 (UTC)

What should I do from here, should I post a request at bugzilla? Jkasd 04:20, 5 August 2008 (UTC)
Yes, a general request at Bugzilla would be a good idea, though I personally hope that this discussion gets more eyes to improve its chances of implementation. {{Nihiltres|talk|log}} 13:45, 5 August 2008 (UTC)

This has been discussed for a long time at Wikipedia:Flagged revisions; why not add to the existing proposals there, or add your own if you think it's warranted? —Preceding unsigned comment added by B. Wolterding (talk • contribs) 15:50, 5 August 2008

Yes, the seed for this idea came from this discussion WT:Flagged revisions#Split proposals, where it seemed hopeful, but nothing seemed to come of it. I've refined the idea, and I thought it would be better to discuss it here instead. Jkasd 21:05, 5 August 2008 (UTC)

Add "Welcome-auto", "Welcomeusername" and "uw-coi" to Friendluy

It would be nice if these would be in Friendly, so we can place it there better. Narutolovehinata5 tccsdnew 09:32, 30 July 2008 (UTC)

Well, if you want to add those templates to Friendly, you can tell Ioeth to do so, he is the creator of Friendly. doña macy [talk] 21:36, 2 August 2008 (UTC)
I have tried to contact him, but no luck... Narutolovehinata5 tccsdnew 11:39, 5 August 2008 (UTC)

Re-proposal: Tiered deletion and "established" user group proposal

This was proposed a while back, but it seemed to get buried under all the other proposals, so I copied it to WP:VPR/PP. Please comment on my revised proposal there. -- Imperator3733 (talk) 16:22, 6 August 2008 (UTC)

bob dylan

bob dylan's real birth date is not may 24, it's may 11. this is how it appears in his id, which appears in the booklet of the bootleg series vol 1-3. and i don't think he uses a fake id. you should look for yourself. —Preceding unsigned comment added by Alexadamalex (talk • contribs)

A Google search [3] finds plenty of sources saying May 24. Talk:Bob Dylan would be a better place to suggest changes to the article. PrimeHunter (talk) 22:44, 6 August 2008 (UTC)

Prompting an editor, before submitting an edit, if not logged in

Sometimes a registered user forgets to log in when editing. The result is that the registered user's IP address is displayed in the history instead of the user name. I propose that when people who aren't logged in submit an edit, they should receive the prompt, "Would you like to log in before submitting your edit?" The possible choices would be "yes" or "no thank you". --Bob K31416 (talk) 17:34, 17 July 2008 (UTC)

I would agree with this suggestion and add the following problem that has happened to me. I was reviewing my watch list (which implies one is logged in) but when clicking on an entry to open it in a new window, that new window was not logged in. This does not happen very often, but results in an IP edit when you think that you were actually logged in. Dbiel (Talk) 18:36, 17 July 2008 (UTC)
  • Comment: I really like this idea. This has almost happened a couple of times, and I wish that the Wikimedia software would ask if you wanted to log in when you begin to edit a page. It currently displays an unobtrusive notice at the top of the edit page when you are not logged in that isn't really noticeable. Perhaps that notice could be changed to be displayed in an {{ambox}} with a little log-in specific picture. That would be easier to implement than a log-in prompt during the page save. — OranL (talk) 19:13, 17 July 2008 (UTC)
I strongly support this idea, mainly because it's happened to me too, and there is no prominent visual indicator that alerts users they are not logged in. --.:Alex:. 19:27, 17 July 2008 (UTC)
This sounds like a good idea. In the meantime, users could shove something in their custom .css files so that the appearance of the edit page when they're logged in is distinctive - bright purple background or something. This would make the difference more obvious. Pseudomonas(talk) 19:29, 17 July 2008 (UTC)

Question: Would it be possible to have the prompt stop after the first time one clicks on "No thank you" for that particular article/session? I would imagine IP editors becoming quite frustrated if they had to face that prompt every time they made an edit. Zain Ebrahim (talk) 19:33, 17 July 2008 (UTC)

I was thinking of a global notice like this, but with a different coloured box (I don't know how to change it, and yes everyone is free to change it). --.:Alex:. 19:34, 17 July 2008 (UTC)
About 30% of our edits come from anonymous users. Do we really want to hit them with popup messages every time they try to edit? --Carnildo (talk) 19:40, 17 July 2008 (UTC)
Seeing as login information can be stored on a computer, so when it detects your IP or whatever it automatically appears in the box, maybe we could make it so it detects you are possibly a registered user and causes the box to appear then? --.:Alex:. 19:44, 17 July 2008 (UTC)
The problem with this is that there are a lot of users that do not have a static IP address and the IP address may change every time the connect to Wikipedia. But a session cookie might be a possibility.

Here are a couple ideas:

  • This one looks like a warning:
  • This one looks like a notice:
  • Both are more noticeable than:

You are not currently logged in. Editing this way will cause your IP address to be recorded publicly in this page's edit history. If you create an account, you can conceal your IP address and be provided with many other benefits. Messages sent to your IP can be viewed on your talk page.

Props to .:Alex:. for the text that I used from his page. — OranL (talk) 20:17, 17 July 2008 (UTC)
Though it should say something about creating an account if you don't already have one... Mr.Z-man 22:57, 17 July 2008 (UTC)
I thought the point was that this should only be seen by editors who normally have an account.
In any case, I find using ambox a very bad idea; the particular series of templates is associated with problems in articles, and the nature of these messages is mostly of temporary issues concerning pages in the mainspace. If you want a format more suitable to general use, I highly suggest {{ombox}}. Waltham, The Duke of 23:27, 17 July 2008 (UTC)
I don't think its possible to display it to only users who have an account but are not logged in without displaying it to all anon users. Mr.Z-man 23:59, 17 July 2008 (UTC)

I changed the template to use {{ombox}} and the text of the current logged-out message. View it above and comment. Feel free to edit the template or the text. — OranL (talk) 03:01, 18 July 2008 (UTC)

_________________________________________________________________
Thank you all for your responses. I appreciate the consideration you've given to my proposal. It looks like I should give a more detailed explanation to clear up some things.

The proposed prompt is for all users that aren't logged in when they submit their edit. This includes both registered and non-registered users. Both are included because I don't see a way to easily differentiate registered from non-registered users.

The prompt does not come up when they begin to edit. It only comes up when they submit their edit. This choice was proposed because someone may only wish to view the edit page without submitting an edit and the prompt would be unnecessary in this case.

Since the users that will view the prompt includes users that are not registered and new to Wikipedia editing, I tried to make the language as simple and friendly as possible so as not to discourage them from editing. The prompt was,

Would you like to log in before submitting your edit?

and the choices to click on were meant to be as simple and friendly as possible too,

<yes>          <no thank you>

--Bob K31416 (talk) 03:16, 18 July 2008 (UTC)
___________________________________________________________________

Actually, there is an easy way to differentiate between registered and unregistered users. When you log in, a cookie is created. When you log out, the cookie saves your username so that you only have to type your password the next time you log in. So I suppose the software could be programmed to detect cookies when the user is logged out and prompt them to log in. This would work as long as the user uses the same computer and the cookies are not deleted. – FISDOF9 04:00, 18 July 2008 (UTC)

As I said, I was thinking something like this in terms of style. Noticable enough as it's not seen usually on the page, but blends in for any IPs that see it.

You are not currently logged in. If you wish to use your account to submit changes, click here to login.


--.:Alex:. 08:37, 18 July 2008 (UTC)
This looks good but I am still opposed to the idea of a prompt each time an edit is submitted. Zain Ebrahim (talk) 09:51, 18 July 2008 (UTC)
I see the advantages of this idea. It doesn't require any action and is thus unobtrusive. It should be positioned just below the "save page" button. It would only appear if the editor was not logged in. That way a registered user is likely to realise, "Something's different here!" It would be of no consequence to an unregistered user. So I agree with the idea and would only suggest changes in the wording of the reminder to make it simpler and softer,
If you would like to log in before submitting your edit, click here.
An additional feature may be helpful. After the user logs in, there could be a button to click to get back to where the user was on the edit page, but this time as a logged in user. However, since this isn't already a feature during routine Log in, I suspect it is difficult to implement.
--Bob K31416 (talk) 14:48, 18 July 2008 (UTC)

If you commonly have trouble with this and you don't want to wait for the devs, something like this in your monobook.css (or other skin css file) might be helpful. 

/* Turn the "Save page" button green if I'm logged in */
INPUT#wpSave {
    background-color:#88ff88;
}

It will turn the "Save page" button green when you are logged into your account. If the button isn't green, it means you're not logged in (so don't click it!). Anomie⚔ 11:25, 18 July 2008 (UTC)

Clever and simple solution! I like it. I'm using it myself now, although with different colours and whatnot. --tiny plastic Grey Knight ⊖ 12:13, 18 July 2008 (UTC)
A great idea, except it doesn't work for me. At all. Any code whatsoever never ever works on my monobook.css or monobook.js or whatever. Anyone why that is? --.:Alex:. 13:04, 18 July 2008 (UTC)
Are you using the Monobook skin? If you're not, you'll have to use the .js or .css page for that skin. Occasionally when I need to stir things up I'll use the Modern skin, and so for when I do that my modern.js contains importScript('User:Nihiltres/monobook.js');. {{Nihiltres|talk|log}} 13:29, 18 July 2008 (UTC)
Oh, it's decided to start working, but when I AM logged in. Why is this? Hmm... --.:Alex:. 08:43, 20 July 2008 (UTC)
Did you forget to clear your cache after making the change yesterday? Anomie⚔ 13:51, 20 July 2008 (UTC)
I purged the cache and it had no effect. --.:Alex:. 16:30, 20 July 2008 (UTC)
Your monobook.css modifications can only affect your personal user account. It cannot, for instance, make the button red if you aren't logged in. — OranL (talk) 18:32, 20 July 2008 (UTC)
And as OranL has said above, that is the point of using the monobook.css. Using the example given above, the save button would be green when logged in, but grey if not logged it. It was my first monobook entry. The green button took me a little while to get use to, but it does make it apparent by its absence that I am not logged in; and thus a reminder to log in before clicking on the grey save button. Dbiel (Talk) 18:57, 20 July 2008 (UTC)
Oh I see. I misread it. I thought the green would appear when not logged in (don't know how that would even be possible in a userscript). My bad. --.:Alex:. 20:59, 20 July 2008 (UTC)

I like this proposal a lot. It would give all of us a better idea of who the noobs are around here, instead of having established users' contribs diverted to IPs. --Pwnage8 (talk) 18:46, 20 July 2008 (UTC)

I think this green button thing should be incorporated as a gadget actually. --.:Alex:. 15:23, 22 July 2008 (UTC)

I strongly oppose this proposal. While I understand the good intentions behind it, this polidy would presume that IP editing is some sort of mistake, rather than an intention, or the majority mode of editing Wikipedia. It would also introduce a further step of annoyance into IP editing, and we have done far too much to IP editors already. It is also yet another step toward the gradual elimination of IP editing, even possibly delivering "warnings" to IP editors that look suspiciously similar to the warnings delivered to vandals. I must oppose in the strongest possible terms. Mr. IP (talk) 08:58, 26 July 2008 (UTC)

  • Comment I think all it would take is for the skin to be a different color for logged in editors than for IP editors. Heck, even if the lines surrounding the edit window that I'm typing in now were a different color it would alert me that I'm not logged in. Phlegm Rooster (talk) 09:19, 26 July 2008 (UTC)
    • Well said, Rooster. Well actually my skin is very different from that when I'm not logged in, and deliberately so. However, it's not different enough. The edit window for IPs could be green or pink or blue or whatever Mr IP would consider pretty. -- Hoary (talk) 09:26, 26 July 2008 (UTC)
      If you want to change the edit window, just apply CSS to #wpTextbox1 as I suggested above for the save button. You could also throw in #wpSummary to do the same for the edit summary box. Something like this:
#wpTextbox1, #wpSummary {
    border-color:#0f0; /* Give it a green border */
    background-color:#cfc; /* Give it a light green background */
}
    • Sure, you could try to get the devs to somehow change colors and such for non-logged-in editors. Or you could do this right now, the only difference being the "standard" appearance means you need to go log in. And this way you can make it as obvious or non-obvious as you want; I think I'll stick with just a green Save button, but you can turn the entire page Magic Pink if it concerns you that much. Anomie⚔ 20:45, 26 July 2008 (UTC)

______________________

Please note that in my previous comment I have modified my original proposal in response to suggestions and comments, especially the suggestion from Alex.
I'll try to make the modified proposal more clear here. Instead of a prompt that requires action there would be a blue box positioned just below the "Save page" button row, only if the user is not logged in. It would not require any action and would be for information purposes only, and it would have a convenient link for logging in:
________________________________________________________________________________________
<Save page>    <Show preview>    <Show changes>
If you would like to log in before submitting your edit, click here.
________________________________________________________________________________________

It would only appear if the editor was not logged in. That way a registered user is likely to realise, "Something's different here!" It would be of no consequence to an unregistered user.
Note that a similar statement already appears when a user is not logged in. The problem is that it appears at the top of the page, away from the "Save page" button and is thus not noticed when the user goes to save the edit.
-Bob K31416 (talk) 13:07, 26 July 2008 (UTC)
Then we should replace the old notice with the new one. Who is in favour of that idea? --Pwnage8 (talk) 15:47, 4 August 2008 (UTC)
Thank you for your input. I think that the old notice is fine. It gives some useful details and may alert some editors, when they start editing, that they have the option to log in so that they can log in before they start to edit. Other editors may not even notice the present message and just go directly to the edit box and start their editing. What I feel is needed is the short notice in the blue box, previously mentioned, that is near the "Save page" button. Because of it's close proximity to the "Save page" button, it has a good chance of getting an editor's attention and the info in the box will remind the editor of the option to log in. --Bob K31416 (talk) 20:22, 7 August 2008 (UTC)

I strongly support a strong visual difference between editing logged and logged out. rootology (C)(T) 13:15, 8 October 2008 (UTC)

Wikipedia:Notability (Septuagenarian female plumbers with red hair and freckles)

Wikipedia:Notability (Septuagenarian female plumbers with red hair and freckles) has been proposed as a further but necessary extension of the notability infrastructure. As this infrastructure of subject specific notability guidelines grows, we must keep pace with the need to define every permutation of expectations at AfD and prevent the dangerous application of independent thought. Not only must we determine consensus on this critical issue immediately, but we must also hasten to define every possible situation which may tax the good judgment of our AfD closers. --Kevin Murray (talk) 14:58, 5 August 2008 (UTC)

This discussion of a humorous page does not belong here. --Boring old (fart) 12:25, 7 August 2008 (UTC)
Only the format is humorous -- the message could not be more serious! We are being overwhelmed by narrowly-defined, conflicting, and redundant rule-sets. With the best of intentions, people are proposing more and more rules each month and then a short time later claiming consensus for acceptance based on agreements between just a few editors. See the proposals for notability guidelines listed at the template:IncGuide. --Kevin Murray (talk) 15:59, 7 August 2008 (UTC)
I have to admit that this mock proposal is one of the most cogent points I've ever seen made.--Father Goose (talk) 20:17, 7 August 2008 (UTC)
We already have an essay that does what you are complaining about: it's called WP:CREEP. We don't need another and we certainly don't need a WP:POINT. If you think there are too many policies then say so and give specific ones, but don't make a point. Deamon138 (talk) 22:29, 7 August 2008 (UTC)

Printer-friendliness

It seems like a no-brainer that wikipedia would have the good old "Printer Friendly Version" button somewhere, but I haven't been able to find one. It's a pain that it prints out all the stuff that I don't need (headers, footers, [edit] links, etc.), wasting ink and trees.

It is in the left sidebar under Toolbox > Printable version. --—— Gadget850 (Ed) talk - 19:52, 6 August 2008 (UTC)
Any half-decent modern browser will automatically use the printer-friendly version anyway. We have a print stylesheet on every page which excludes all the extraneous stuff. If you're using Internet Explorer 6 or 7, or any version of Firefox, it certainly shouldn't be printing the navigation or edit links. — Matt Eason (Talk &#149; Contribs) 20:43, 7 August 2008 (UTC)

New CSD criterion proposal

Just a quick note to invite comment here on a proposal to create a new criterion for speedy deletion. The proposed criterion is that where an uploader has supplied a copyright tag but has specified a third party as the content owner, without any evidence that their permission was ever given, the media will be speedied seven days after the uploader is notified if no such permission is forthcoming. This is equivalent to the NPD process used at Commons, and parallel to our NSD and NLD. Please weigh in! --Rlandmann (talk) 21:01, 7 August 2008 (UTC)

GA marker for articles

I'm sure this must have been proposed before, but could we get a little marker to sit in the top right corner of articles that have been awarded GA status? Just like how we currently have for FAs. The German Wikipedia has a little blue square containing a letter L (for Lesenswerte Artikel; article worth reading), which works quite nicely. An example can be found here: de:Nordsee. Perhaps we could use the GA symbol for the English Wikipedia? - Anxietycello (talk) 00:57, 8 August 2008 (UTC)

Well, you're right. This has been proposed again and again, and it is always shot down. It's a slippery slope. If we have FA's and GA's marked, why not A-class? Is it against NPOV to only advertise our better articles? Why not B-class, or starts, or stubs? Also, being a Good Article is determined by one reviewer, while FA's are determined by community consensus. It isn't a terrible idea, it would just be impossible to get a clear consensus to act on it. Paragon12321 (talk) 02:15, 8 August 2008 (UTC)
Fair enough, that's kinda the answer I expected. Shame really, seems (to me at least) like it'd be a useful feature. Should this be put on WP:PEREN if it's suggested that often? Anxietycello (talk) 02:30, 8 August 2008 (UTC)
You can enable such a feature for your own use, however. Go into My Preferences → Gadgets. Under "User interface gadgets" there's a box to tick to "Display an assessment of an article's quality as part of the page header for each article". As for the perennial proposal, you might be interested in reading the last "Green Dot Debate". Gwinva (talk) 02:54, 8 August 2008 (UTC)
Yes, this needs to be added to WP:PEREN; I suggested it last time, and a record of the gazillion times this proposal has been defeated should be included there. SandyGeorgia (Talk) 02:58, 8 August 2008 (UTC)
I added it. Please adjust it as you see fit. Grandmasterka 06:30, 8 August 2008 (UTC)

Wikipedia Article and User Policy Compliance Score Card (template)

Rather than rely on arbitrary nomination for deletion or arbitrary user blocking I propose that a Wikipedia Article and User Policy Compliance Score Card (template) be used to provide a running status of both articles and users where policies are listed with a dynamic compliance rating shown as a sum of positive and negative ratings on the score card entered for a user or article by users and administrators. Deletion and blocking decisions can then be made by several administrators who can reach consensus more easily. (Numbers in the table below are merely random numbers generated by computer)

See: Wikipedia:WikiProject Council/Directory/Wikipedia

Wikipedia policy Dynamic Compliance Rating
Article User
What Wikipedia is not 41 -18
Ignore all rules -80 5
Neutral point of view 7 71
Verifiability 75 86
No original research -49 21
Biographies of living persons -34 -1
Civility 8 53
No personal attacks 24 56
No legal threats -7 21
Consensus -47 -32
Dispute resolution -16 -12
Conflict of interest 46 -50
Do not copy sources -50 46
Disambiguation 24 24
Do not create hoaxes -1 -28
Patent nonsense 50 -55
Reliable sources 14 38
User page -44 15
Notability -8 52
Be bold 55 1
Build the web -13 -9
Edit summary 14 -65
Article size -52 63
Etiquette 57 -7
Assume good faith -1 -58
Do not disrupt Wikipedia to illustrate a point -23 37
Do not bite the newcomers -27 37
Do not "game the system" -52 7


Julie Dancer (talk) 05:46, 30 July 2008 (UTC)

I'm sure your intentions were good, but I think this actually makes things more arbitrary. A "value judgement" is still needed to, for example, decide whether or not to increment the "Do not game the system" column; was the user really doing so? This is the same as the current setup. However, the difference with this would be that it removes any context; when was the value incremented? Was it a long time ago? Did the user subsequently apologise? What is the relationship of the incrementing user; were they involved in the incident? There is all sorts of context that should be taken into account in order to more fairly evaluate users' activities; and the same goes for articles. This is similar to the concept that Wikipedia:Polling is not a substitute for discussion. Sorry! --tiny plastic Grey Knight ⊖ 10:27, 30 July 2008 (UTC)
There is nothing wrong with prior discussion to help a user or administrator decide whether to enter a negative or a positive value following the discussion. The only difference is that the table affords a current status summary following each discussion on the discussion page rather than the table replacing any discussion. Think veggiesaurous, Lex, veggiesaurous! Julie Dancer (talk) 14:17, 30 July 2008 (UTC)
This is definitely creepy. Problem articles/users should be dealt with on a case by case basis, rather than introducing something like this. It seems unnecessarily complicated and overly devoted to a "by the numbers" approach. I do not like it. Shereth 15:27, 30 July 2008 (UTC)
I think of it like grades in school more than anything else. The current system means that all of the sudden out of the clear blue sky all another user with a grudge has to do is to put a borderline article up for deletion. They know that all they have to do next to send it over the edge is to drop a few claims that the reaction of the original author is a personal attack or that the original author is being uncivil, knowing all the while that if they drive that interpretation home the article will be deleted and the author blocked. Such nominations might be more difficult if compliance history could be pointed to which would show that personal attack or incivility is a wrongful interpretation of the reaction. Most importantly it would stop articles from being nominated for deletion out of the clear blue sky. The original author deserves some warning that there might be something about the article, such as notability, which a history of status would eventually tend to reveal. The instructables uses a rating system that is very helpful in that regard, the only difference being that here it would be applied to every policy regarding article and user status. Think veggiesaurous, Lex, veggiesaurous! Julie Dancer (talk) 16:15, 30 July 2008 (UTC)
(ec) We already have the ability to do that. Talk pages are very rarely deleted, so there is no point in trying to misrepresent a past discussion; a simple link to the talk page and the accuser's position is immediately undermined by the primary source of the conversation itself. You seem to be proposing replacing this with a secondary source, and one that removes any kind of context at that. We can't reduce questions of policy compliance to raw numbers, it's too subjective. And for that matter we're allowed to disobey the rules if it helps the encyclopaedia! --tiny plastic Grey Knight ⊖ 16:29, 30 July 2008 (UTC)
Think summary Lex. You get done with a discussion as an administrator on your own talk page perhaps and return to the article discussion page or user discussion page and want to indicate your thoughts without further ado. You say yeah they were not being uncivil, enter a negative amount and you are out a there ta-da (tä dä′) (Informally used to suggest the sound of a fanfare: an exclamation of triumph or pride accompanying an announcement, a bow, etc.) Julie Dancer (talk) 16:35, 30 July 2008 (UTC)
My name isn't Lex (at least, not here). I understand what your proposal is, I just don't see why it is any improvement over just saying "I do not think such-and-such a comment was uncivil", which conveys all of the information incrementing your table would, as well as more conveniently displays the attribution of who said it, and allowing to talk about individual issues rather than lumping everything the subject user has ever done into one pile (which sounds like a recipe for huge arguments). --tiny plastic Grey Knight ⊖ 17:02, 30 July 2008 (UTC)
I still think you are overcomplicating the matter. If an article has potential notability issues then it should be tagged as such. If it has potential verifiability issues, it should be tagged as such. If these issues are particularly egregious, it goes instead to AfD. This notion of a scorecard over time is far too much. The task of "scoring" articles and editors is far too onerous, particularly when we have a system that works by and large. Shereth 16:27, 30 July 2008 (UTC)
That would be okay if a nomination for deletion tag for any reason for which there is an existing tag like notability or references then that tag should have forced or obligatory precedence over the nomination for deletion tag. See what I am trying to say? Julie Dancer (talk) 16:38, 30 July 2008 (UTC)
A rather labyrinthine statement, but I think you are saying that people should put cleanup tags on rather than going straight to a deletion tag. This is already considered polite to do, although it is not required. What we are trying to say is that having cleanup tags and a "scorecard" table stating how many cleanup tags there are seems like duplication of effort to no real benefit. The table is not even as helpful as it doesn't indicate what the cleanup problems are. (In fact, even a cleanup tag should be accompanied by a talk-page explanation, although at least its positioning can give some clues.) --tiny plastic Grey Knight ⊖ 17:02, 30 July 2008 (UTC)
The difference between an article needing cleanup tags and one warranting deletion debate is not well-set and is open to interpretation. That is the whole purpose of the discussion itself - to determine whether or not an article should be deleted or whether it is salvageable. Shereth 17:31, 30 July 2008 (UTC)

My impression now is that no one wants to edit anything and if editing requires the least bit of work someone will nominate for deletion instead of even posting a reference tag. The idea seems to be if there is no reference section forget it. That means there are no inline references (although the article could be chocked full of hyperlinks) and have you ever seen one of the reference sections, I mean all the detail? Dang! stick a nomination for deletion tag on it and lets get out a here. Julie Dancer (talk) 13:24, 31 July 2008 (UTC)

I wouldn't trust such a system unless it could be done programatically, which is not even close to being the case. SharkD (talk) 01:29, 1 August 2008 (UTC)
I agree. I would go along with it if were it automated and the results of automation were accurate and true to purpose.

This would turn Wikipedia into a police state. --Pwnage8 (talk) 08:30, 6 August 2008 (UTC)

As others have pointed out, this is far too arbitrary to be useful. We already have things in place to deal with all of the issues in your chart. If something has potential problems with notability, then it gets tagged. If it has potential problems with verifiability, then it gets tagged. If it has especially egregious problems that someone thinks can't be fixed through the regular editing process, then the article can be taken to AfD. Talk pages are wonderful things, and can be used to solve a lot of these problems that you've put forth.

I'm even more strongly opposed to the idea of grading users. This isn't school; there isn't any goal of creating users who are good at doing everything that they get graded on; everyone here does their best, and when their best isn't good enough for our standards, someone else comes along and picks up the slack. The benefit of having any kind of thing that says "User A sucks at writing NPOV-style biographies" is minimal compared to the damage that it does to our cohesion and morale. Whenever you implement any kind of scale, people are going to see it as a contest, which Wikipedia is not. Celarnor Talk to me 12:19, 8 August 2008 (UTC)

Alternate user names

Alternate user names have a bad reputation because they were used originally and extensively by vandals and by users wanting to have apparent extra support of their position. The question of legitimate alternate user name under one Wikipedia account has already been addressed by requiring an additional account for a user's wiki bot. In my case the need for multiple user names is not for wiki bots but to track my own projects which are on separate computers. What I am proposing is that multiple accounts be in fact permitted just as they are for user bots giving each account the same user name followed by a sequence number. In my case the would amount to three accounts, for example Charlie-1, Charlie-2 and Charlie-3. I need these accounts to track and to separate each of the projects I am working on. Without such capability I may as well have no user name at all.—Preceding unsigned comment added by 71.100.0.179 (talk • contribs)

Erm, you don't have a username at all, unless you count your IP address... Alternate accounts may have a bad reputation, but they certainly aren't disallowed in all cases except for bots as you seem to suggest. I would suggest reading over the multiple account policy. I believe what you're proposing is already allowed. Mr.Z-man 06:51, 3 August 2008 (UTC)
See User_talk:Julie Dancer, Wikipedia:Requests for checkuser/Case/Julie Dancer, WP:ANI#User:Julie Dancer, repeated personal attack and harrassment for the full background here. Kevin (talk) 09:22, 3 August 2008 (UTC)
There was no personal attack but only statement of fact. Unfortunately Wikipedia policy allows Communists to be administrators as well. Check your self Kevin and the user you claim that was harassed and you will find that your block and the nomination for deletion and the reason behind it was in truth a personal attack of actions rather than of words. 12:13, 5 August 2008 —Preceding unsigned comment added by 71.100.0.126 (talk • contribs)
Yes, Wikipedia policy allows Communists - and socialists, and anarchists, and atheists, and pagans, and pretty much anyone regardless of political or religious or other personal aspects - to be administrators. So I strongly suggest you find another website where the rules are more to your liking. -- John Broughton (♫♫) 12:41, 5 August 2008 (UTC)
Why is that unfortunate? Celarnor Talk to me 12:24, 8 August 2008 (UTC)

Prposed additional definition of the word Phake

Proposed addition

"phake" as in computer made ph(otographic f)ake image.

It is quite common to find software generated photo montage or enhanced images. Sometimes these are obvious sometimes not however they are all phakes.

Real Samson (talk) 08:46, 7 August 2008 (UTC)

I don't think the term is notable enough to deserve its own article, nor even to deserve mention at Photo manipulation#Photoshopping. Sorry. − Twas Now ( talk • contribs • e-mail ) 11:31, 7 August 2008 (UTC)
I suggest you submit it to the Urban Dictionary. --Slashme (talk) 12:12, 7 August 2008 (UTC)
Jokes site. Already definitions for phake, but not this particular one yet. Should make a great addition. And it's referred to as "urban dictionary", just FTR. --Pwnage8 (talk) 19:04, 8 August 2008 (UTC)

improving accounts

hello my names Kari I have an account with you guys. and I was curious, if you have though about improving account settings? I would really like to be able to save some certain articles so i could go back to them later... some what like youtube does with their videos, where you can put that as a favorite and find it on your home page.

If you are logged in you can "watch" an article by clicking the tab at the top that says "Watch". Then, if you click "my watchlist", located at the top of the page next to your account name, you can see all of the articles that you are watching, much like a favorites list. Shereth 15:12, 8 August 2008 (UTC)
And, of course, there isn't anything preventing you from setting up a "Wikipedia articles" folder within your web browser's bookmarks menu, so you can bookmark them. Or even setting up a user subpage (if you've created an account - free!) where you add the articles to the subpage. (Then you can easily add notes, group them however you want, etc.) -- John Broughton (♫♫) 15:51, 8 August 2008 (UTC)

Main Page pagetitle

With rev:38730, it's now possible to change the pagetitle of the Main Page. It's currently "Main Page - Wikipedia, the free encyclopedia". Does anyone think it should be changed, and if so, to what? Perhaps removing "Main Page - "? --MZMcBride (talk) 00:03, 9 August 2008 (UTC)

I've set it to simply "Wikipedia, the free encyclopedia". This should make it easier to bookmark Wikipedia, since the bookmark will by default start with "Wikipedia" instead of "Main Page". It should also be a bit more intuitive to newcomers. Any other thoughts on this? —Remember the dot (talk) 00:54, 9 August 2008 (UTC)
This seems to be a similar discussion to what's going on at Wikipedia:Village_pump_(technical)#Proposal:_Move_main_page_to_a_different_namespace. Deamon138 (talk) 01:04, 9 August 2008 (UTC)
The new functionality was created in concert that proposal (see the feature request at bugzilla) and I support the change of the page title to just "Wikipedia, the free encyclopedia".--Father Goose (talk) 02:16, 9 August 2008 (UTC)

Further reading

Having found Wikipedia excellent as an entry point into new subjects (epilepsy, dietary issues, etc.), I wonder if there's reason to encourage writers and editors to also add a short list of further reading, related to key topics covered (separate from text references, with short description of item content). This then helps put any interested readers onto up-to date, relevant/recommended publications. 09:07, 6 August 2008 —Preceding unsigned comment added by WECIU? (talk • contribs)

The "Further reading" section (per WP:GTL) is supposed to be for sources that could be used in the article, but haven't yet been. As for getting readers to up-to-date publications about key topics, to the extent that links in the "External links" section doesn't accomplish this, the citations ought to be in separate Wikipedia articles about those other topics, as footnotes or in the "External links" section. And readers should be able to get to those topics via either wikilinks in the article, or links in the "See also" section. -- John Broughton (♫♫) 14:21, 6 August 2008 (UTC)
That's just one of the uses the guideline (Wikipedia:GTL#Further reading) recommends.
It explicitly states that it is to be used for "any books, articles, web pages, etc that you recommend as further reading, useful background, or sources of further information to readers." (currently anyway ;) -- Quiddity 03:06, 7 August 2008 (UTC)
Ah, perhaps I was mislead by the following, also in that section, which you didn't mention: This section ... is generally for resources on the topic that are not specifically cited in the article. -- John Broughton (♫♫) 23:31, 7 August 2008 (UTC)
Ah, whoops. I love it when it contradicts itself. Discordianism/IAR in action! consistency is... ;) -- Quiddity 05:55, 10 August 2008 (UTC)

Flood flag proposal at meta wiki

Of interest to the English Wikipedia, since a revision to the core program could be enabled here / not enabled by consensus on a local project. flood flag. NonvocalScream (talk) 17:56, 9 August 2008 (UTC)

Nobody is going to remember to turn this setting on and off at appropriate times. If we want this effect wouldn't it be easier to add a "hide admin edits" setting, maybe enabled by default? — CharlotteWebb 18:18, 9 August 2008 (UTC)
Surely. I'm just posting here in case the community may be interested in enabling it on this wiki. The meta proposal if for meta enabling only. Interesting reading, and like I said, if we want this for en wiki, we should start a discussion here. Best, NonvocalScream (talk) 03:50, 10 August 2008 (UTC)

Utilisateur SUL

Hi all, I'm french from fr: and also one of the creators of fr:Modèle:utilisateur SUL (I translate this template here), the idea is about putting this template on your user's page. It's to inform readers where is your main wiki. Do you think that we could make this a "meta/general" template like babel ones ? Otourly (talk) 20:29, 8 August 2008 (UTC) Question also asked on meta:Metapub#Utilisateur SUL

I see no reason why your proposed template shouldn't be copied to Template:SUL Box, but I'm not a template expert. EdJohnston (talk) 18:55, 10 August 2008 (UTC)

Proposal to overturn Privatemusings' arbcom restrictions

Moved to Wikipedia:Administrators'_noticeboard#Proposal_to_overturn_Privatemusings.27_arbcom_restrictions. NonvocalScream (talk) 20:48, 10 August 2008 (UTC)

Watch Sections

There should be a way to watch a specific section, i.e. a specific question on the RD. (or a suggestion on the proposal village pump)--omnipotence407 (talk) 11:53, 10 August 2008 (UTC)

Not possible. The watch system is on a per-page basis, because the contents of each page can change dramatically. — The Hand That Feeds You:Bite 13:54, 10 August 2008 (UTC)
See Wikipedia:Perennial proposals#Allow watchlisting individual sections of a page. Mr.Z-man 14:13, 10 August 2008 (UTC)

Use of "LEAD templates" as content in article sections

I'm not sure if this would work and would like to see a discussion of this proposal. Basically I'd like to:

  1. streamline editing
  2. eliminate imprecise duplication
  3. eliminate lags in updating information
  4. eliminate conflicts between what should be identical material in different places.

Many (often large) "primary" articles have sections that contain a little bit of content and a link to another article that is a legitimate "fork" article. The purpose of such article forks is usually to conserve space in the primary article. Now if we were to place a template (which is based on the content of the LEAD in the fork article) in the relevant section in the primary article, we'd save alot of work, and also possible editorial conflicts (and conflicting information) when further revisions to a fork article (as now) aren't reflected in the related section in the primary article. This proposal would automatically ensure uniform content.

Let's take an example:

The Large Hadron Collider primary article has a section entitled Safety of particle collisions. Fine and good....

That section contains a "Main article" template that looks like this:

Main article: Safety of the Large Hadron Collider

which is followed by a paragraph of information on the subject, preferably identical to the LEAD of the fork article. If the fork article is serving its purpose, then a template of the content of its LEAD should be sufficient content for the related section in the primary article.

Such sections would then contain nothing but two templates:

  1. a "Main article" template
  2. a "LEAD" template

If this proposal is adopted, we could even combine the functions of those two templates into one template that would include both the link and the LEAD content.

What think ye? Will this work? Any potential problems? Can they be solved by tweaking this proposal, rather then just trashing it? -- Fyslee / talk 08:32, 10 August 2008 (UTC)

Although there is a need to update such sections following updates in the main articles, I do not believe it is so important a problem to warrant such measures. First of all, the lead of an article is the part thereof least likely to change, given that it introduces the subject and only includes the most important information. Changes there are not a daily phenomenon (unless, that is, the lead is rather bad, or concerns a current event), and events important enough to warrant the revision of a well-written lead should ripple throughout all relevant articles anyway, causing changes in all. Apart from that, there is also the difference in scope; a proper section must be well integrated into an article, constituting part of its body, whilst a lead must introduce an article and follow certain style conventions pertaining exclusively to introductions (including bolding and referencing practices). Even though some sections are almost identical to main articles' leads, like your example, there will usually be differences, and simply replicating the text will force editors to use identical text for very different article parts. It will cause problems, and I find the benefits insufficient to justify the cost (even if this is applied to only few cases, its use will inevitably spread, and it's a slippery slope from there). I am against this idea. Interesting, but problematic. Waltham, The Duke of 09:22, 10 August 2008 (UTC)
I appreciate the thoughts. You mention ".. should ripple throughout all relevant articles anyway, causing changes in all." Well, that's precisely what this proposal will automate, and I'm proposing it because I have observed that it doesn't always happen. The articles I edit are usually very large and controversial, and the LEAD gets revised in keeping with changes in the article. Such changes don't always "cause changes in all" related articles. Conflicts then occur, including vicious edit wars between editors who control different articles related to the same topic. Since NPOV requires that opposing POV are included, this could automate the inclusion of POV on both sides of the fence. NPOV loses if one side wins. Everyone wins if no one side wins in this situation. My proposal obviously applies in all situations, including uncontroversial, as I first considered and suggested before writing the above afterthought. -- Fyslee / talk 09:42, 10 August 2008 (UTC)
This isn't a new proposal; perhaps it could be added to WP:PEREN? What is basically being proposed is to transclude the lead section of a daughter article into the main article, so that the two stay synchronized, and so that edits only have to be done in one place.
There are at least two problems with the proposal. The lesser one is that that this adds yet more complexity to editing; experienced editors can figure out what is going on, but others might not. And with complexity comes not only confusion but the possibility of mistakenly breaking things. (This problem would be less so if mw:Extension:Labeled Section Transclusion were implemented.) The more major one is that, in fact, the content of the lead section of a daughter article and a section of the main article should not be the same. The lead section of the daughter article should be written as if the reader has no understanding of the topic, while the section in the main article should assume that the reader has read the sections above, and should not repeat information. The differences can be as trivial as whether words are wikilinked or not, or as significant as duplicating entire sentences, in the daughter article, in order to orient the reader. (As commented on by the Duke, above.)
Finally, one option is to add {{Sync}} when you find things getting seriously misaligned. -- John Broughton (♫♫) 15:51, 11 August 2008 (UTC)

A page for "meta" Wikipedia-related news

Proposal to create a page (somewhere like WP:METANEWS or WP:ENWIKINEWS) that would list news from en.wikipedia. Prompted because I've been away for a few weeks and I'd rather not read through 29,000 pages of AN/I archives to find out what's happened while I was gone (and I'm sure I'm not alone in that). The community is such an important part of this site that's it's a shame I feel like I'm in totally in the dark compared to the beginning of July - really wanting to catch up on the latest ArbCom ruling or prolific vandal on the same page :]. Cheers, Alex Muller 16:35, 10 August 2008 (UTC)

I like the idea. "Centralized Disucssion" seems like a good starting point, but summaries of ongoing debates, important threads and the like would be really useful to have. Celarnor Talk to me 16:38, 10 August 2008 (UTC)
Could be added as an extra weekly section of the Wikipedia:Signpost. — CharlotteWebb 18:21, 10 August 2008 (UTC)
There is already a signpost article on the ARBCOM cases each issue. - Icewedge (talk) 01:18, 11 August 2008 (UTC)
This reminds me of the fabled discussion about belling a cat - everyone agrees it should be done, but ... If you look at m:List Summary Service, for example, you'll find that some mailing lists did have summarizations, but none (apparently) do now, because (I'm speculating, but I'd give long odds) (a) this is a lot of work; (b) summarizing a discussion about a controversial subject (and most subjects that are discussed at AN/I probably are controversial) in a way that is both accurate and fair is hard (and people will still object, anyway); and (c) given the amount of work involved, and the issues with fairness and accuracy, it's certainly less stressful and quite possibly more useful to Wikipedia to do other things instead. -- John Broughton (♫♫) 16:01, 11 August 2008 (UTC)

Making a new redirect in the SVG template family

Having recently looked over Template:ShouldBeSVG/doc again, I suddenly realised that I have been flagging up images incorrectly in some cases. Namely, I have been using the code {{SVG|icon}} in a lot of cases when flagging images on http://wiki.riteme.site and http://commons.wikimedia.org. The correct category, it has transpired, is not icon but symbol. Further investigation has revealed that a fairly large number of images have been flagged up both at Wikipedia and over at the Commons, and so there now lie the two automatically created pages Category:Icon images that should be in SVG format and commons:Category:Icon images that should use vector graphics, the images in which will most probably go entirely unnoticed as those categories do not appear on Category:Images that should be in SVG format and commons:Category:Images that should use vector graphics. Thus, in order to correct my mistakes and stop such mistakes from being a problem in future, could {{SVG|icon}} be made to automatically redirect to {{SVG|symbol}} and the images flagged with {{SVG|icon}} placed either on Category:Symbol images that should be in SVG format or on commons:Category:Symbol images that should use vector graphics, just as {{ConverttoSVG}} itself redirects to {{ShouldBeSVG}}? It Is Me Here (talk) 18:45, 10 August 2008 (UTC)

If you need help changing a template, WP:RT is the right place, not WP:VPP. -- John Broughton (♫♫) 16:04, 11 August 2008 (UTC)
Thanks, reposted (although I believe that this page is WP:VPR ;) ). It Is Me Here (talk) 19:39, 11 August 2008 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_32&oldid=1142509459"