Wikipedia:Village pump (proposals)/Archive 86

Recently I've seen an editor denigrated at Wikipedia Review and on RfC/U for keeping an embarrassing image on his user page. The impact of the harassment has been substantial. But actually, the file was altered on Commons to make it much more 'embarrassing' than it had been. The result is that anyone could link to his contribution history and it comes up as a page that never existed. The 'remedy' applied appears to have been to delete all the past revisions containing the picture, but that makes it much harder for me to look at the past issues of relevance to the RfC/U, and is no good general answer.

So why don't we just fix this? Change the display of versions from the File History so that they use the historical version of the file from Wikipedia or Wikimedia Commons, so that the page displays the same way as it did?

(You could also do this with transcluded pages)

Wnt (talk) 15:07, 10 February 2012 (UTC)

But if the prior version was removed or altered for cause (like copyright or usage issues) then that would also be a "bad result." I would suggest that where an image is altered for any reason, that links in userspace be noted and an "original image unavailable" notice be returned. Wouldn't that accomplish as much as you wish? Collect (talk) 15:18, 10 February 2012 (UTC)

I don't see the point in that. If an individual revision was a copyright violation it was likely deleted; if not, including it in a historical version here is no different than displaying that historical version of the file page at Commons. Wnt (talk) 15:35, 10 February 2012 (UTC)

Comment: Most non-free files have had the old versions deleted per F5 Unused non-free media. Of course, user pages should not have non-free files, but you would have to have some mechanism to differentiate. ---— Gadget850 (Ed) ^talk 16:02, 10 February 2012 (UTC)

I'd be OK with having a deleted version end up as a redlink in the history version - though of course a bluelink would be a better outcome. Wnt (talk) 20:18, 10 February 2012 (UTC)

• Comment  We don't allow editors to revise old revisions, why do we allow software to revise revisions?  Unscintillating (talk) 18:47, 18 February 2012 (UTC)

• Support  I think that this is possible and practical, by adding a time parameter to the picture-retrieving subroutine.  Unscintillating (talk) 18:47, 18 February 2012 (UTC)

• Support. Of course if the old file revision has been deleted we have to decide whether to show a red link, or the current revision. Old file revisions that are copyvios need to be deleted anyway - merely uploading over them is not sufficient - so that's not an argument against it. Note however that transcluded templates present exactly the same problem - do we want to use older revisions of those too? Dcoetzee 00:56, 25 February 2012 (UTC)
• Comment you're going to have to deal with templates as well as files. I suspect the devs may so "no" on performance grounds. Josh Parris 05:32, 26 February 2012 (UTC)

Performance issues are not stable over the years, given changes in both software design and hardware design.  Nor, as a function of implementation tradeoffs, is it necessary that there must be performance delays.  I'm not one of the devs, I'm just saying that these are general principles.  Unscintillating (talk) 03:45, 28 February 2012 (UTC)

I remember making a proposal to this extent earlier at some point, and quite a few people agreed with my idea. Yet, nothing has happened, the only change made was one apparently forced by WMF legal. I still think that consolidating the messages down there into just one area would make a whole lot more sense. Maybe something like this:

---

For articles...

Before you save your changes: Ensure that encyclopedic content is verifiable by reliable sources and written from an unbiased point of view. If you wish to experiment or test edits before publishing them in a Wikipedia article, please use a sandbox page. Ensure you know your rights: you agree to license all text contributions you submit to Wikipedia under both the CC-BY-SA 3.0 license and the GFDL,and that a hyperlink or URL will be considered sufficient attribution under the Creative Commons license. If you do not want your writing to be edited, used, and redistributed at will, then do not submit it here. Ensure your contributions are legal: any content which infringes third-party copyrights will be deleted on sight unless properly exempted. Please do not copy and paste from other websites; most content found online cannot legally be used on Wikipedia.

And for talk pages

Before you save your changes: This is a talk page, used for discussion of various aspects of Wikipedia. Please stay positive, and don't forget to sign your posts (type four tildes, ~~~~), to sign your post. You agree to license all text contributions you submit to Wikipedia under both the CC-BY-SA 3.0 license and the GFDL,and that a hyperlink or URL will be considered sufficient attribution under the Creative Commons license. If you do not want your writing to be edited, used, and redistributed at will, then do not submit it here. Ensure your contributions are legal: any content which infringes third-party copyrights will be deleted on sight unless properly exempted. Please do not copy and paste from other websites; most content found online cannot legally be used on Wikipedia.

How's this? ViperSnake151  Talk  20:26, 14 February 2012 (UTC)

• Support - I like the idea; it will make the important notices clearer and more comprehensible. ItsZippy ^{(talk • contributions)} 21:02, 14 February 2012 (UTC)
• Comment You're missing the reference to foundation:Terms of use that is required by Wikimedia (see meta:Licensing update/Implementation#Terms for edit screen). And I fail to see how either of the above gigantic boxes are more consolidated than what we have now. I'd oppose this, except that I hide the whole mess with my user CSS anyway so I wouldn't see it. Anomie⚔ 02:55, 15 February 2012 (UTC)
  • Actually, "both the CC-BY-SA 3.0 license and the GFDL" is linked to that. Wouldn't that be enough? ViperSnake151  Talk  13:37, 15 February 2012 (UTC)
    • Oh, it's an easter egg link. It seems to me that "CC-BY-SA 3.0" and "GFDL" should instead link to the texts of those licenses, and a link with the text "Terms of use" should link to the terms of use. Anomie⚔ 15:43, 16 February 2012 (UTC)
• Support and add "not forum" point for talk pages. --lTopGunl (talk) 11:44, 15 February 2012 (UTC)

'Comment: yeah, I looked and thought about the last proposal as well. But it got bogged down in the need for the legal team to have a look. Since none of them were around, it was rather pushed into the long grass. Also as I recall WikiEd or somesuch reorganises the lower sections. Speak to Geoff or someone and come back with approval, I think. Grandiose (me, talk, contribs) 14:23, 15 February 2012 (UTC)

Comment: Yes, please, speak to Geoff. The language of that wording is very specific ("by clicking the save page", implies affirmative consent, for instance). It's really really important that the WMF's Legal and Community Advocacy department be made aware of what language is decided upon here, prior to implementation. I know that Geoff will work with you, but there are some things that have to be, for legal reasons. Philippe Beaudette, Wikimedia Foundation (talk) 09:02, 21 February 2012 (UTC)

Hmm, you really do try to have your finger in every pie, don't you? --MZMcBride (talk) 14:18, 1 March 2012 (UTC)

That's rather what I get paid for.  :) Philippe Beaudette, Wikimedia Foundation (talk) 18:31, 1 March 2012 (UTC)

• You should be looking at ways to reduce the amount of text, rather than simply trying to consolidate it. Nobody reads the warnings because they're too much text. --MZMcBride (talk) 14:18, 1 March 2012 (UTC)

I have a proposal concerning the omission of edit summaries. If a user who edits an article leaves the edit summary blank, their changes (such as text inserted/removed to the article) will be shown, making it an automatic edit summary. However, if an edit summary is provided by the user, then that edit summary will be shown instead. The reason for this proposal is that there are far too many edits without edit summaries, leaving it inconvenient and time-consuming for other editors who want to view changes which have not been explained. Not only will this promote the use of edit summaries, but it can be used to view and stop vandalism to an article as the vandal's edits will be visible. Till I Go Home (talk) —Preceding undated comment added 05:17, 15 February 2012 (UTC).

• Question: The edit filter (the way we would implement this) is dumb. How can you expect it to provide such a detailed edit summary? Or, are you talking about putting the diff into the edit summary (impossible)?Jasper Deng (talk) 05:20, 15 February 2012 (UTC)

Whatever is inserted or removed will be shown in the edit summary (e.g. if "abcde" is inserted in the article then the edit summary will say "abcde". Till I Go Home (talk) —Preceding undated comment added 05:25, 15 February 2012 (UTC).

We can't afford to do that, especially for page blanking, unless we greatly expand the edit summary field (which is not feasible).Jasper Deng (talk) 05:28, 15 February 2012 (UTC)

Perhaps if none is given, something descriptive could be added. For instance, "X characters added/deleted to Y sections" or something of that nature. ♫ Melodia Chaconne ♫ (talk) 05:51, 15 February 2012 (UTC)

Editsummary field has a limit, so we actually can add (as much allowed in that limit) the text that was added or removed with an indication of which ever on a blank editsummary. --lTopGunl (talk) 11:35, 15 February 2012 (UTC)

This makes a lot of sense to me. In fact, for small edits I routinely copy paste the text I added into the edit summary. My Wikipedia:Persondata-o-matic tool automatically produces detailed edit summaries describing exactly what was added, removed, or modified. For larger edits we'd just need a bit of technology to automatically summarize the edit in a useful manner (e.g. I could imagine an automatic program producing "Add paragraph to Cuisine section beginning `Fish are commonly eaten in Japan...'"). Dcoetzee 14:14, 15 February 2012 (UTC)

• Oppose The issue really is that editors don't leave proper edit summaries. This proposal would hide the problem by putting automatic text in for the edit summary. At least seeing it blank is an opportunity to educate the user to proper Wiki etiquette. Plus, no computer system is going to be smart enough to explain why the edit was made. You can look at the diff if you want to see the edit itself. — The Hand That Feeds You:^Bite 14:18, 15 February 2012 (UTC)
  • It seems like it would be easy to add some kind of marker to visually distinguish automatic edit summaries from manual ones, so that nothing is being "hidden." Moreover, intention can often be inferred easily from the content of the edit (for example, if it's "changed serius to serious" you can reasonably infer it was a spelling correction). If an editor omits an explanation or justification for a controversial edit, they're more likely to be reverted and have to explain it on the talk page, so the incentive to include one is still there. Dcoetzee 15:21, 15 February 2012 (UTC)

• Comment: It seems unlikely that such a thing could be done accurately. I love the idea, I just think it is technologically unfeasible. How is the editing process itself supposed to detect then summarise edits not summarised by the editor? See my proposal below... I do actually think my proposal is a better idea because what has been originally stated here is a branch of the problem I have addressed below[1]. My idea in its basis is to try to strongly encourage edit summaries but also to make it clear what the edit summary IS and what it is NOT. Why make things easier for those who are already abusing the edit summary?--Djathinkimacowboy 13:04, 16 February 2012 (UTC)

Addendum to my comment: There is another problem revealed here: many editors do not fully comprehend how an edit summary should be written. I believe some of them don't even see the box when they edit, or simply don't know what to put. I myself as a raw newbie used to mark too many edits as 'minor' because I did not know the proper definition of a minor edit. See, we need to push editors to provide edit summaries, understand it well, not use it as a text-messaging service and be clear about why the summary means so much. Of course there are editors who simply want to make it hard for others to see what they've done and refuse to summarise anything.--Djathinkimacowboy 13:07, 16 February 2012 (UTC)

• OpposeThis will automatically incorporate any attacks, copyvios or other bad edits ("poop fuck shit hahahahahah") into the edit summary. It's bad enough when they occur and aren't revdeleted, but now, instead of being hidden in a prior version and only likely to be discovered or viewed if a user specifically looks at prior versions, will now be evident just by looking at the edit history.--Fuhghettaboutit (talk) 13:40, 16 February 2012 (UTC)
• If a lack of edit summaries is such a concern, and I'm not sure that it is, a much simpler and easier solution would be to have the "prompt for edit summary" option in prefs enabled by default --Jac16888 ^Talk 13:46, 16 February 2012 (UTC)

• I proposed that in the past and it was rejected but I still support.--Fuhghettaboutit (talk) 14:09, 16 February 2012 (UTC)

• Agree, partially: If there is one of two things we can try: a simple prompt to encourage edit summaries with emphasis on what an edit summary is; or, a simple indicator of an edit's length, such as we now have with the indication of words added/removed in the diff.--Djathinkimacowboy 14:53, 16 February 2012 (UTC)
• Oppose per Fuhgettaboutit. - Purplewowies (talk) 21:26, 22 February 2012 (UTC)

• Support as opt-out: can be annoying for regular editors who don't want all their edits filled with the text they add to the articles and are used to adding manual edit summaries for their own edits. Should be enabled by default to allow the benefits discussed above. Edit summary has a limit so there won't be issues of huge amounts of text flooding. On a side note, this can not be taken as an alternative for manual edit summary, so this should be marked as an 'auto-edit summary' like a filter so that the issue is not hidden under the carpet. --lTopGunl (talk) 01:13, 26 February 2012 (UTC)

• Comment would the automatic summary actually be helpful? This already happens on page creation, and its not necessarily clear what is going on from that... Aslbsl (talk) 20:48, 28 February 2012 (UTC)

People have believed that separating titles and URLs from each other in one format may presume link rot and bare URLs. Fortunately, that is precisely one of acceptable formats of MLA. Another format of MLA for websites omits URL because a URL is optional to add.

For example, from previous revision of Sam and Diane:

Shapiro, Ben. Primetime Propaganda: The True Hollywood Story of How the Left Took Over Your TV. New York: Broadside–HarperCollins, 2011. Google Books. Web. 04 Feb. 2012 <http://books.google.com/books?id=ymAWgveoxW8C>.

I have previously discussed this issue in WP:Village pump (miscellaneous)#Presumptions of link rots vs. MLA format. Per WP:CITEVAR, I want the MLA format to be accepted into essays, guides, and guidelines of citations, such as WP:Citing sources and WP:Bare URLs.

Sources for MLA usage:

• http://www.library.cornell.edu/resrch/citmanage/mla
• http://owl.english.purdue.edu/owl/resource/747/01/

Right now, Frasier Crane, Sam Malone, and Diane Chambers are tagged for link-rotting, in spite of using MLA. I wonder if MLA formats are acceptable.

To be honest, I don't like using cite templates anymore; too inconvenient to search and less readable. --George Ho (talk) 06:43, 25 February 2012 (UTC)

I am not sure what your asking - but the format used at Frasier Crane, Sam Malone, and Diane Chambers are what you see when you print a page. We dont realy have a need to do this for our readable version because the print version will make the ugly hard to read references automatically. Are you saying you like the url to be seen at all the time? We have templates to prevent this from happening because some Urls are simply to long and thus makes pages looks sloppy and unprofessional. A bare url does not help our readers and in fact I would say long urls impede readers ability to read references properly. We have tools to help you with this see Google book tool for an example More at Wikipedia:Citing sources#Citation templates and tools. "All that said" - there is no set way for referencing see Wikipedia:Verification methods. Moxy (talk) 07:06, 25 February 2012 (UTC)

This is more user friendly and professional looking

Ben Shapiro (31 May 2011). Primetime Propaganda: The True Hollywood Story of How the Left Took Over Your TV. HarperCollins. ISBN 978-0-06-193477-3.

Then this I think

Shapiro, Ben. Primetime Propaganda: The True Hollywood Story of How the Left Took Over Your TV. New York: Broadside–HarperCollins, 2011. Google Books. Web. 04 Feb. 2012 <http://books.google.com/books?id=ymAWgveoxW8C>. — Preceding unsigned comment added by Moxy (talk • contribs)

Wikipedia is the encyclopedia anyone can edit in any style, as long as you establish the style as the first editor or gain consensus to change it. Given that, you can use MLA with or without templates (which we don't have). You need to discuss style changes on the article talk page. MLA uses bare URLS in that manner because it is a style guide for print. I predict that exposing bare URLs won't be popular. ---— Gadget850 (Ed) ^talk 09:46, 25 February 2012 (UTC)

Which article talk page? Not specific article, such as "Frasier Crane", isn't it? --George Ho (talk) 20:12, 25 February 2012 (UTC)

MLA is already acceptable. In fact, WP:CITE says that editors may use any citation style, including styles they've just made up. See the second question at Wikipedia talk:Citing sources/FAQ. WhatamIdoing (talk) 03:18, 27 February 2012 (UTC)

Then why are formats tagged as "link rots" or something like that? MLA optionally includes URLs separately, but I use the MLA's URL format because I don't like templates as much as MLA. Is this of all MLA formats acceptable? --George Ho (talk) 03:33, 27 February 2012 (UTC)

Maybe because the user who tagged the pages didn't know any better? Maybe because he took a quick look and didn't realize that those are full bibliographic citations? People make mistakes all the time, and Wikipedia is so complicated that nobody can keep up with all the details. Have you considered asking him what he was thinking? WhatamIdoing (talk) 03:59, 27 February 2012 (UTC)

I'm not an administrator or experienced yet. I wonder if you can contact him about this issue. Sometimes, he dislikes bare URLs. --George Ho (talk) 04:02, 27 February 2012 (UTC)

I suspect that it was just an honest mistake of the sort that all of us make on occasion, but I've left a note for the user in case he wants to comment.

By the way, you might like to read the documentation at Template:Cleanup-link rot. As with all such templates, if one is added to an article when it shouldn't be, any editor can remove it. WhatamIdoing (talk) 04:08, 27 February 2012 (UTC)

Not only that user; also those at WP:DYK. See Template:Did you know nominations/Sam and Diane. --George Ho (talk) 04:20, 27 February 2012 (UTC)

I am happy they did. Seriously, compare [2] to [3]. You are free to use any referencing format you want, but other editors are also free to change it if they think it improves the article. Yoenit (talk) 09:50, 27 February 2012 (UTC)

Not exactly. Exactly like you can't convert from British to American spelling "if you think it improves the article", you can't unilaterally convert citation styles from the authors' choice to your preference. The rules are outlined at WP:CITEVAR. WhatamIdoing (talk) 16:30, 27 February 2012 (UTC)

That's not what CITEVAR says. Read it again. "Editors may choose any option they want", and it is "considered helpful" to seek consensus before changing the citation style. CITEVAR is not policy. It's possibly questionable as a guideline. The controling policy is WP:CONSENSUS. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:47, 2 March 2012 (UTC)

The last thing we need is yet another citation style. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 15:47, 2 March 2012 (UTC)

[Grande on MediaWiki] - This page contain the designs in Detail. — Preceding unsigned comment added by 106.67.27.98 (talk) 03:48, 2 March 2012 (UTC)

• Sorry, but oppose for now per WP:NOTSOCIAL. Remove the "article notes" and "reviews" (first screenshot), since we're on the way to a visual editor. Even still, I don't know if the Wikimedia Foundation has the server resources to implement it.Jasper Deng (talk) 04:02, 2 March 2012 (UTC)

This is not WMF sponsored. These designs are done by a volunteer as suggestions; they are not currently anywhere in the plan. You may safely ignore this or delete this entire section.--Jorm (WMF) (talk) 04:16, 2 March 2012 (UTC)

This is only a suggestion, and arguably, it might have been better in Wikipedia:Village_pump_(idea_lab),but I guess that more people look at this page of Wikipedia. My proposal is as follows. It is sometimes said that people will get more out of Wikipedia if they did not merely read the article, but the talk pages (indeed, I am sure I once read a magazine which said that). Can we therefore have a template at the top of at least some articles, encouraging readers to read the talk pages of articles? ACEOREVIVED (talk) 20:35, 28 February 2012 (UTC)

Oppose. Talk pages are for discussing improvements to the article. If we did this then some talk pages would be considered quasi-articles by many readers – and by some editors who would start speculating in spreading their crap on talk pages when it's kept out of articles. All sorts of unverifiable nonsense and rude discussions are already on talk pages. If people want to learn more about the subject than the article and they aren't studying Wikipedia culture then they are better off searching elsewhere on the Internet. Talk pages are also treated less strictly than articles concerning legal issues like BLP violations and copyvios - especially when it's discussed whether something in the article is exactly that. We shouldn't give the impression that we want readers to read talk pages. They are for editors. PrimeHunter (talk) 00:02, 29 February 2012 (UTC)

I'm inclined to agree with PrimeHunter. I will note, however, that many of the article cleanup templates that flag content disputes or biased articles (e.g. {{POV}}) already link to a given article's talk page. While these template messages are principally aimed at editors, other readers are certainly able to discern the presence of a dispute and view any related discussion. TenOfAllTrades(talk) 00:26, 29 February 2012 (UTC)

• Its just more clutter theres a tab at the top of the page already for the talk page, adding a template at the top is just going to detract from a persons ability to read the article Gnangarra 01:50, 29 February 2012 (UTC)

• Comment: Hi ACEOREVIVED, it goes without saying that talk is used to settle disputes, improve the article, etc. However, sometimes it goes... well, way beyond. Please check out talk:Gustave Whitehead... is that what you're trying to engender? Best, Markvs88 (talk) 15:24, 29 February 2012 (UTC)

• Oppose: Yes, readers should read more deeply. I meet people and brag about being a Wikipedia editor, one of millions, and tell them it's one of those iceberg things, 90% underwater. I advise them to use the tabs at the top of the page, and the "About Wikipedia" on the left edge, and the "Help" also on the left, all of which lead them to read the highly informative underwater parts. It's all there; just have to point, click and read though perhaps "Help" ought to be made more immediately helpful to readers and less focused on editors. Jim.henderson (talk) 19:31, 29 February 2012 (UTC)

Support - if we encourage users to actually go on talk pages, there would be a more social and collaborative aspect to the encyclopedia. By encouraging people to use the talk pages, we encourage new WikiProjects to actively improve a certain subject on Wikipedia, and improve the existing and mostly moribund ones. This will also aid in editor retention (our number 1 priority now), as it will allow a forum for discussion of articles. I understand that Wikipedia is not a forum or message board, but discussion on articles does contribute to their quality. Wer900 (talk) 03:36, 6 March 2012 (UTC)

Many thanks to all the people who responded to this proposal. The comments in response are well taken. I should also say that I was very impressed with how polite and civil people who responded to this discussion were, even if the general consensus appeared to be oppose the original proposal. It goes without saying that that is exactly the good manners that, one hopes, will characterise Wikipedia discussions. ACEOREVIVED (talk) 21:12, 29 February 2012 (UTC)

What I wouldn't mind seeing is a count on the 'Talk' tab of the number of recent discussion sections added or updated. (For example: '| Talk (2 updates) |'.) That way I can tell at a glance whether discussions are taking place. Regards, RJH (talk) 23:17, 29 February 2012 (UTC)

RJH's idea sounds interesting, but I would think like the above proposal, it doesn't totally jive with WP as an encyclopedia. All of the behind-the-scenes work should be accessible, but probably shouldn't be to prominent. Aslbsl (talk) 14:17, 1 March 2012 (UTC)

It would be really helpful to be able to create several separate watchlists. I watch pages where my interest is the article itself but I also often watch pages where I only do wikignoming and only need to check whether someone else undoes those edits. It would be cool to be able to maintain separate watchlists for those two types of pages. Therefore I propose to give all editors the ability to maintain more than one watchlist. Toshio Yamaguchi (talk) 19:58, 1 March 2012 (UTC)

I had a similar idea, but I did not mention it outside my talk page (User talk:Wavelength/Archive 1#Watchlist folders).

—Wavelength (talk) 20:11, 1 March 2012 (UTC)

Try Special:RecentChangesLinked - it lists changes to any page linked to from a given page. You populate a page with the pages you want to watchlist, and tada you're done. Josh Parris 20:15, 1 March 2012 (UTC)

I am not sure this works for me. What I need would be the following watchlist categories:

• Articles I am interested in
• Village pumps and help desk
• Specific policy pages
• User talk pages
• Pages where I perform NFCC enforcement

This is only a rough outline to get an idea of what I have in mind. Additional options for "fine tuning" your watchlist might be desirable. Toshio Yamaguchi (talk) 20:37, 1 March 2012 (UTC)

See Wikipedia:Help desk/Archives/2010 October 30#Multiple personal watchlists.

—Wavelength (talk) 21:02, 1 March 2012 (UTC)

Try User:UncleDouggie/smart watchlist.js. --Yair rand (talk) 22:13, 1 March 2012 (UTC)

This one is excellent, been using it since quite some time.. but it saves its settings to your browser, so you won't have the same settings on another computer. Some thing like this should be rolled out in general instead. There was also a consensus for recent watchlist changes... what ever happened to that? --lTopGunl (talk) 11:50, 4 March 2012 (UTC)

Category:Eponymous categories and all other cats beginning with "Category:Categories named after" , have been nominated for being turned into hidden categories. On the Categories for Discussion page there has been a debate about the appropriate venue for this discussion so I am linking it here to try and establish a censensus on venue. If you would like to participate in the discussion, you are invited to add your comments at these categories' entry on the Categories for discussion page. Thank you. RevelationDirect (talk) 04:48, 4 March 2012 (UTC)

Note there is a complementary request to rename such categories to "Category:Wikipedia categories named after...". SFB 17:29, 4 March 2012 (UTC)

See Help talk:Citation Style 1#Centralized talk page.

A week ago, I made a proposal to centralize the talk pages of the Citation Style 1 templates, making an announcement on all 25 talk pages. The response has been minimal, which rather proves my point that these pages are underwatched. Since these templates are so well-used, I thought it best to open this to a broader audience. ---— Gadget850 (Ed) ^talk 14:02, 4 March 2012 (UTC)

Go be bold, imo. --Izno (talk) 14:17, 4 March 2012 (UTC)

The maintenance categories on Wikipedia are poorly organized, and as a result, users are turned off by the massive walls of text which link to them. Category:Wikipedia maintenance categories sorted by month says it all. This is especially damaging to the base of new editors, which will be at best confused and will not be able to target their efforts on where the encyclopedia requires the most work, and at worst will be turned off by the large number of categories and simply become inactive or leave, feeling that there is no way they can help. For anyone, the place is visually unappealing in addition, and difficult to navigate. It is for this reason that I propose organizing the numerous categories into various categories superior to them but inferior to the category of all articles requiring maintenance, which shall give the general area of what must be done with these articles:

• Cleanup and Grammar - this should deal with various aspects such as the prose of the pages, its grammar and spelling, the formatting of its contents, whether they use neologisms, etc.
• Accuracy - this category should specifically deal with pages which have accuracy issues, or have some issue with regard to the style and placement of their references.
• Comprehensiveness - self-explanatory. This category should deal with pages which have issues in the amount of content they have, if articles are stubs, and whether the article explains in depth and with many examples the topic that it covers. This section will also deal with whether lists comprehensively cover what they are supposed to and have basic properties of all of their subjects
• Suitability for Inclusion - this includes articles that are cruft of any kind, non-encyclopedic, example farms, promotional, tl;dr self-shrines, libelous, etc.

In addition, within these categories, the dates they are sorted by should also be subcategorized by year, again so that new users are more invited to edit them and navigation is easier generally. I am not proposing the demolition of any existing category, merely that they be moved into the appropriate supercategory listed above so that the page is more elegant and easier to navigate for new users and old alike. Nothing else will change with regard to the categorical structure.

Also, in order to ensure that the backlog of bad articles is eliminated in the quickest fashion possible, a link should be placed to the maintenance categories sorted by month in a prominent place, perhaps on the left sidebar, or to the left of the "feedback about editing" link. This will ensure that a larger percentage of new and experienced editors alike notice the existence of a backlog, and that more resources will consequently be available to the related WikiProjects to help clear up this backlog, as opposed to merely a small dedicated group (though this group is not in any way harmful, just too small to clear up the backlog without serious firepower). That way, more editors will feel a purpose of being on Wikipedia, more new editors will be retained, and the community can grow back.

Wer900 (talk) 23:56, 5 March 2012 (UTC)

Apparently as of about March 1, 2012, the automatic edit summary on page moves became the stunningly redundant "User name (without the user: prefix) moved page X to page Y". In an article's edit history what is thus seen is a person linked username, followed by their name again, listed as making the move. Here's a screenshot from the article history of a move I made last night to illustrate:

When looking at a person's contributions, or your own watchlist, a person's username is not linked and listed, but since you're looking at that person's contributions or your own watchlist, you know whose contributions you're looking at, so it's just as redundant to see this edit summary. I also imagine this now shortens the number of characters one can add to a page move summary in the Reason: field, which was already pretty short because of the automatic move text (a person with a long name might find any reason they add just gets swallowed when they save because of the character limit). I have no idea where this change was discussed at all, or what would need to be done to change it back but I'm sure responders will illuminate me.--Fuhghettaboutit (talk) 13:04, 6 March 2012 (UTC)

• Support. As you say, it's redundant and it bloats diffs, logs, contribs, etc. Jenks24 (talk) 13:18, 6 March 2012 (UTC)
• Support, redundant. --SarekOfVulcan (talk) 13:44, 6 March 2012 (UTC)
• Comment See WP:VPT#Moving saves username in edit summary for technical details. In short, it will require a code change which will require filing a bug. This comment isn't intended to discourage discussion, as gaining consensus here may help in convincing the devs to make this change. Anomie⚔ 18:34, 6 March 2012 (UTC)
• Support; blatantly redundant. Does anyone know what happens if the user changes name? Could we end up with lists displaying two different names? Favonian (talk) 20:13, 6 March 2012 (UTC)
• Support - You can vote for the bug fix here. Jojalozzo 20:38, 6 March 2012 (UTC)

• Thanks for providing this information. I have voted and apparently a developer has been "assigned" the bug (I assume that means the fix has been greenlighted and put in a queue for that person to take care of?)--Fuhghettaboutit (talk) 15:37, 7 March 2012 (UTC)

• Support, I have voted there as well, and left some comments for the very defensive (and incorrect) developer. Let's hope they leave their rather entrenched position and actually listen to what we are suggesting, or that they at least provide some good examples of where this change is beneficial. Fram (talk) 09:52, 9 March 2012 (UTC)
• Support the removal of this redundancy. ItsZippy ^{(talk • contributions)} 19:44, 9 March 2012 (UTC)
• Support overly redundant, and there was no consensus for the change in the first place. While we are at it, the two periods around the page size should also be removed. For example
  00:00, March 9, 2012 Alpha Quadrant (talk · contribs) . . 2,000 bytes (+200) . . (Edit summary) would take up much less space as
  00:00, March 9, 2012 Alpha Quadrant (talk · contribs) 2,000 bytes (+200) (Edit summary). I have no idea why the devs added the extra periods, but I can't thing of any reason for having those four extra periods on either side of the page size count. It just takes up extra page space. Alpha_Quadrant (talk) 19:50, 9 March 2012 (UTC)

No, they add some much needed breathing room. We don't need to design for 640x480 anymore. - ʄɭoʏɗiaɲ ^τ _¢ 20:09, 9 March 2012 (UTC)

• Support - Marcus Qwertyus supports the removal of this redundancy. Marcus Qwertyus 03:09, 10 March 2012 (UTC)

Hello, all; an RFC has been opened at Wikipedia_talk:Guide_to_appealing_blocks#Adoption_of_new_unblock_appeals_tool to seek input regarding the implementation of the Unblock Ticket Request System as a replacement for the unblock-en-llists.wikimedia.org mailing list. Comments from all users, especially those who have experience in reviewing blocks, would be greatly appreciated. Hersfold non-admin^(t/a/c) 21:13, 6 March 2012 (UTC)

Hello

can we create an official irc channel to discuss the proposals each other ?

I think it's useful. What do you think ? --Tegra3 (talk) 12:13, 7 March 2012 (UTC)

With the creation of any new IRC channel there is the danger it will remain underpopulated and die due to lack of interest. I think it's better to discuss proposals in existing channels like #wikipedia-en. Dcoetzee 22:21, 8 March 2012 (UTC)

Please Wikipedia talk:Categories for discussion#On the categorization of biographies by (perhaps) incidental occupation. Mangoe (talk) 19:56, 7 March 2012 (UTC)

Roaming around Wikipedia, I found Wikipedia's biggest backlog. Category:Persondata templates without short description parameter has 620,000 pages in need of a description parameter. Basically what this is, for those who are new to this category, is a few words that summarizes what a person did for a living for statistical purposes. Now, the few words, like "rock musician" for example, can be predicted through a number of ways. One example is by infobox. An article can only have one infobox, obviously. So, that infobox would describe the thing the person was most famous for. An idea that 1ForTheMoney developed in the idea lab was that a bot lists articles with infoboxes and missing short description. Then, the bot suggests a short description and all an editor has to do is to click an "okay" button which would trigger the bot to ammend the persondata. Other ideas thrown around at the idea lab were using stubs, titles, WikiProjects, and categories.
Vote below with Support or Oppose or suggest using something instead of infoboxes. Thank you, BCS (Talk) 02:45, 24 February 2012 (UTC)

• As per Wikipedia:Persondata#Short_description, disambiguation text should trump infobox text, or both could be used. Stuartyeates (talk) 02:56, 24 February 2012 (UTC)
• I could possibly write this up if there's consensus. My initial thought was a user script, but my second thought was a Web page that just rotates through articles, shows the article title, lead, maybe an infobox if there is one, some automatically-suggested short descriptions, then lets the user enter one and press Enter to move on. If two or three people agree on the short description, it's removed from the rotation and assigned to the bot. — madman 03:50, 24 February 2012 (UTC)
• The remainder of the first sentence after the Forename, surname (19xx-19yy) is another likely contender. Stuartyeates (talk) 06:35, 24 February 2012 (UTC)
• I would guess that this is too difficult for a bot to do accurately. See Wikipedia:Persondata-o-matic for a tool to assist human editors. -- John of Reading (talk) 09:20, 24 February 2012 (UTC)
• I've seen articles with multiple infoboxes, for example both Aussie Rules and NFL players. Categories might work. Josh Parris 11:49, 24 February 2012 (UTC)
• I think what makes more sense is to develop a script that can make a good guess at what the short description should be, then incorporate it into Persondata-o-matic, so that a human can view it and approve it very quickly. I already do this for names, and doing it for short descriptions is an obvious next feature. Dcoetzee 19:50, 24 February 2012 (UTC)

I would suggest starting with the big win categories, Actors, Athletes, politicians and military persons. Depending on how detailed you want the description (can you say American politician or does it need to be Arizona governor) could depend on how easy or difficult the logic need be. Frankly I don't think it would be that hard to kock them out and it should be rather easy to write a script that could be done by a bot. --Kumioko (talk) 20:01, 24 February 2012 (UTC)

Both examples would be okay according WP:DATA. I like your idea. Would you like to volunteer to program the bot? Or will you leave soon? (I saw your userpage) BCS (Talk) 21:03, 24 February 2012 (UTC)

Sorry I'm not really interested in doing any bot work. There are plenty of other folks that can do that though if you take it to the Bot requests page someone may volunteer to do it. --Kumioko (talk) 00:14, 25 February 2012 (UTC)

Here is a small snip-it of AWB code that will add Footballer if the SHORT DESCRIPTION field is blank. This will probably be all you need if you are getting a list of articles based off of a category. I agree with Kumioko, that the big ones should be knocked out first and sportspeople is the #1 big one. I could run this as a bot or if somebody else wants to have some fun, go for it.Bgwhite (talk) 01:15, 25 February 2012 (UTC)

If you have the code ready, then by all means use it. Knock a big one out. WikiProject Football has 37,000 articles missing the short description. Infobox footballer could be a football player or manager if you use that, by the way. So, sometimes a manager who has never played football will have Infobox footballer. @Kumioko It's okay, I wasn't forcing you to make a bot. BCS (Talk) 04:15, 25 February 2012 (UTC)

I would do it by category and not infobox. I can do those that have both footballer and manager categories and then do just the individual categories. The same procedure can then be done for other sports. I think things would be more complicated for politicians, arts and the other groups. Bgwhite (talk) 05:41, 25 February 2012 (UTC)

Sounds good to me. BCS (Talk) 16:25, 25 February 2012 (UTC)

• BCS refers to my idea of adding descriptions based on infoboxes/categories/project banners, and requesting human confirmation (using Madman's idea on the Toolserver or somewhere else) on the ones it doesn't like. Though I was just jotting ideas down at the time, it was made to address the problem of articles with no defining features, and those with multiple infoboxes. (In fact I remember participating in a similar thing with interlanguage links a few year ago, where editors compared articles in different languages and pressed a button to say if the articles were about the same subject or not. If enough people agreed a bot automatically added the links, and if they disagreed that pairing was taken off the database.) 1ForTheMoney (talk) 00:05, 25 February 2012 (UTC)

FYI. Rcsprinter (orate) (Contribs)
(Not Rcs) 20:50, 26 February 2012 (UTC)

• What about using PersonData from interwikis? We could just steal the values from other wikis. Josh Parris 11:43, 28 February 2012 (UTC)

German wiki is the only other wiki to use persondata. Persondata actually started there. How do you steal German language words to put in the short description parameter? Bgwhite (talk) 21:13, 29 February 2012 (UTC)

• Two bot tasks have had BRFAs raised, and they look likely to fail due to unacceptable error rates. I now believe that crowdsourcing is the only viable solution, and encourage development in that area. Josh Parris 11:06, 29 February 2012 (UTC)

Yeah, they shot it down because any bot would produce an error, therefore a bot can't work on it. It sounded like they didn't even like "normal" people working on it because of the errors a normal human would produce. As the number of articles missing the description parameter has gone up every year since persondata was started, this categroy will never be empty. Bgwhite (talk) 21:13, 29 February 2012 (UTC)

That's a reasonable summation. A crowdsourced solution ought to address both problems, by waiting until enough humans agree on what the short description ought to be. I think someone pointed out earlier that the backlog was getting smaller, but I haven't sighted any data one way or the other. Josh Parris 02:27, 1 March 2012 (UTC)

I feel compelled to point out that a crowdsourced solution might seem like a good idea in theory but in reality Wikipedia is the modal of crowdsourcing and these entries have been empty for years (and apparently will be empty for years to come) so if you have a good idea then please present it. You are both very good programmers so I imagine you both have some really good ideas about how to solve this problem other than writing it off to crowdsourcing that you know won't work. 71.163.243.232 (talk) 04:41, 1 March 2012 (UTC)

@Josh: That would be me. I keep a record of the number of templates missing descriptions that I update once a week, though I admit it's more for my own purposes than anything else. And no, I don't think that bots are the best answer to this one - slightly ironically, persondata was made so that biographies could be made accessible to machines, and bots are in fact the cause of this backlog thanks to mass automated additions that should have been reined in before they started. At the moment, the best move is for more people to get involved with the backlog - tools such as Persondata-o-matic allow for semi-automatic additions but with human intervention. 1ForTheMoney (talk) 15:17, 1 March 2012 (UTC)

What about this? Could that be replicated? -- BCS (t · c · !) 19:06, 3 March 2012 (UTC)

I have done some work on this, and it is not that hard. However using cats as is being done now is not that great an idea. The reason is that the categories are as readily available as the short description parameter, so that not only is no information added, but the ease-of-use gain is negligible. Rich Farmbrough, 20:31, 12 March 2012 (UTC).

I've come up with a idea: Why not create a special page called Special:EditCount? I agree that luxo's, X!'s, tparis's ; etc are not bad, but when replication lag is high, problems occur. There is a sample here. It is used in Wikia, also run by MediaWiki, so it's technically possible. There is a consensus for creating this at TestWiki. Dipankan ^{Meet me here!} 14:44, 3 March 2012 (UTC)

• What benefit would such a page bring to this encyclopedia? Phil Bridger (talk) 22:54, 3 March 2012 (UTC)

• It is as accurate as your preferences. Dipankan ^{Meet me here!} 05:03, 4 March 2012 (UTC)

• I didn't ask whether it was accurate, but what benefit it would bring to an encyclopedia. Phil Bridger (talk) 08:42, 4 March 2012 (UTC)

• That consensus is on another website. Historically, the consensus at en.wiki has been that too much attention to one's number of edits may lead to editcountitis, the symptoms of which make for a very unhappy editing environment. — Huntster (t @ c) 05:49, 4 March 2012 (UTC)
• What would be the benefit of letting everyone see everyone else's edit counts so easily? This should stay in preferences where it is not being broadcast. ▫ JohnnyMrNinja 06:07, 4 March 2012 (UTC)
• The example that you linked to uses the Editcount extension. I agree with Huntster, though, that in order to enable it here you would need to show a good reason and how it would be used to improve the encyclopedia, to overcome the concerns described. Incidentally, if you want to see Users' edit counts while browsing talk and contribution pages, Navigation Popups includes that functionality (using the API) when you hover a user name. Begoon ^talk 06:10, 4 March 2012 (UTC)
• OK. I have developed my own script which adds a Edit Count link in your personal toolbar. That is of X!'s, but that will help. Dipankan ^{Meet me here!} 09:39, 4 March 2012 (UTC)

  I'm sure that may be useful for some people, thanks for sharing it. You can list scripts like that which you've created at WikiProject User scripts, to make them easier for other users to find. There are already a couple listed there which do something similar, like User tabs. As I mentioned, the API result from WP:NAVPOP is enough for me. Begoon ^talk 09:43, 4 March 2012 (UTC)

Thanks for giving the feedback. I will continue to develop simple tools using JavaScript when I get time...! Dipankan says.. ^{("Edit count do not matter")} 05:13, 6 March 2012 (UTC)

People who have contributed to this discussion may be interested in the Wikipedia article Wikipedia: Editcountitis, although since I just saw a quote "Edit count (sic) do not matter" perhaps some of them will not! ACEOREVIVED (talk) 22:17, 8 March 2012 (UTC)

Comment I've always thought it doesn't make any sense why our edit count is under "my preferences" instead of "my contributions". Jason Quinn (talk) 04:15, 9 March 2012 (UTC)

It is under "my contributions". If you click on "My contributions", you can go to "Edit count" at the bottom of the screen. ACEOREVIVED (talk) 08:44, 9 March 2012 (UTC)

I was wondering if it is possible to have an EdiCount that has, as an additional argumen,t a minimum contribution size (eg. 1000 bytes) , either fixed or entered by the user. I know editcountitis is spread among some of the top contributors and that all contributions and contributors matter, however it is be good to recognize who the top contributors are. But, in my opinion, we shall not recognize ones that have thousand of contributions only adding lines between paragraphs, brackets in dates and adding unnecessary categories. Perhaps some filter (eg. contribution size) would help. Lgtrapp (talk) 18:31, 11 March 2012 (UTC)

In Wikipedia talk:General disclaimer#For or not for dyslexic and blind people?, I requested an addition about dyslexic and blind people. However, the user suggested that adding a disclaimer about people with difficult accessibility is too good for WP:General disclaimer. There is already WP:WikiProject Accessibility, but it is not itself a disclaimer, I'm afraid. I don't know if WP:NOT addresses accessibility for handicapped people. Should there be another Disclaimer page about Accessibility for people with difficult diagnosis, such as deafness, blindness, dyslexia, and other diagnosis? --George Ho (talk) 02:01, 7 March 2012 (UTC)

I think you misunderstood what I was suggesting. I didn't mean another disclaimer page, because I don't think this is something to be "disclaimed" rather something along the lines of a page with advice on using Wikipedia for the differently-abled, much like Microsoft Windows has an accessibility section with things such as page zoom and speech etc--Jac16888 ^Talk 02:06, 7 March 2012 (UTC)

Shortcomings in the medium are not things to be disclaimed. Note how no other site has disclaimers for these. --Cybercobra (talk) 07:02, 7 March 2012 (UTC)

Sometimes government organizations have to put in some sort of disclaimer where they have not been able to cater properly for people with a disability because of requirements on them to deal with such problems. However the only requirement on Wikipedia is a moral one so no disclaimer is needed just an effort to deal with such problems. Dmcq (talk) 11:48, 7 March 2012 (UTC)

Can you elaborate a "moral one", please? --George Ho (talk) 12:15, 7 March 2012 (UTC)

As in the very first definition in athe first dictionary I googled 'of, pertaining to, or concerned with the principles or rules ofright conduct or the distinction between right and wrong;ethical: moral attitudes.' Dmcq (talk) 12:38, 7 March 2012 (UTC)

As a totally blind person (who happens to have Wikipedia:General disclaimer on their watchlist), I don't understand why a new disclaimer page is needed at all. It'd be very difficult to write a page about using Wikipedia for people with disabilities because users' needs vary enormously. The closest we have is Wikipedia:Using JAWS. Graham87 15:49, 7 March 2012 (UTC)

I think that such a statement is beyond the scope of a disclaimer.

Additionally, what Graham says about the variety of disabilities is important. The list of possible statements is nearly endless. In addition to "if you have trouble reading in general, you'll probably have trouble reading Wikipedia" (dyslexia), we could equally well say that if you have trouble clicking (mouse use is painful to some people with carpal tunnel syndrome), then our wiki links will likely be a problem for you; if you are blind, you won't be able to see the images; if you're Deaf, you won't be able to hear our audio files (including the spoken Wikipedia articles); if you have trouble typing, then you will find your ability to edit pages limited; and so forth. Basically, we'd be telling people what they already know and expect, and I'd expect many of them to be insulted by such a patronizing statement (because no matter how you phrase it, telling a person that their reading difficulties don't disappear merely because they are on Wikipedia is fundamentally patronizing).

Finally, telling people that Wikipedia may not work so well for them isn't really a method of solving any actual problems. If you want to make a difference for users with disabilities, then I'd suggest reading WP:ACCESS and figuring out what you personally could do to improve actual access to articles that interest you. WhatamIdoing (talk) 03:15, 13 March 2012 (UTC)

I think that most editors are unaware of the desirability of using language templates to mark up foreign language text embedded in English Wikipedia. LittleBen (talk) 13:49, 11 February 2013 (UTC)

We have 1500+ admins (several hundred of which are pretty active), yet we still incur large backlogs, especially at WP:RPP. Does this mean that we should have a bot to notify admins at AN (or, possibly, ANI) about backlogs?Jasper Deng (talk) 02:57, 12 March 2012 (UTC)

The script generally used to archive WP:RFPP will put up an admin backlog notice on that page when the queue reaches 10. An example of the notice may be seen in this version, just below the TOC. EdJohnston (talk) 03:19, 12 March 2012 (UTC)

Yeah, but admins do not see it unless they manually navigate to RPP.Jasper Deng (talk) 03:21, 12 March 2012 (UTC)

• Many admins will have a dashboard that tells us of backlogs in areas where we are active. Posting on admin noticeboards about all backlogs is liable to be counterproductive, I'd suggest we reserve that for backlogs at AIV and the deletion of attack pages. With RFA broken the number of admins has fallen by more than a quarter since its peak, and will continues to decline, so we will either have to reform RFA or find other ways to do things that we need admins for. ϢereSpielChequers 13:20, 12 March 2012 (UTC)
  • That's what I'm thinking about, AIV, UAA, and RPP only, where backlogs really are backlogs. We don't have enough admins w/ a dashboard.Jasper Deng (talk) 17:41, 12 March 2012 (UTC)
    • Maybe we need some sort of specific alert that admins can opt in to that emails us about urgent backlogs that they particularly cover. ϢereSpielChequers 22:17, 12 March 2012 (UTC)
      • Yeah, but that would defeat the purpose of the idea, which is to canvass more admins to do AIV/RPP/UAA work; therefore, I believe an opt-out would be a better idea if you want it this way, but I'd find it more efficient to just post at AN or ANI since these are very heavily watched.Jasper Deng (talk) 22:22, 12 March 2012 (UTC)

• With regards to speedy deletion, I recommend installing User:Ais523/catwatch.js and including any of the various cat:csd's you feel like, lets you have a regular steam of csd's on your watchlist, and is handy for other backlogs too like requests for unblock, or edit requests. If enough admins used this script those backlogs would be a lot lower. (Yes this is a blatant plug, but only cos it's so damn useful) --Jac16888 ^Talk 22:47, 12 March 2012 (UTC)

• Would be really nice if that could be installed and enabled by default for admins.Jasper Deng (talk) 00:24, 13 March 2012 (UTC)

Just a small suggestion for added utility on pages containing table structured data.

The short version: Data contained in table format should have an option of exporting in various formats such as: CSV, XLS, XLSX, Tab Delimited, etc... This would allow for a quick way to manipulate and/or translate the data and the respective format of that data.

+++++++++++++++++++++++++++

The longer version/explanation and example use case: I'm a programmer working on a project that requires the storage of SMS/MMS gateways in order to formulate cell phone "email" addresses depending on the carrier the program is sending messages to.

I found the data I was looking for on this "List of SMS gateways" page on your site. The relevant data is contained in an ordered table on this page, but there is no way to export that data in a structured way. The print/export link in the margin of the website allows for PDF exports, but to extract data from a PDF file programatically requires a separate layer of case-specific coding that usually isn't worth the time invested.

My workaround was to use Microsoft Excel's Web Query feature in order to obtain this data in a structured way so that it can be easily manipulated and exported for various purposes.

In my specific case, the table data found on the list of SMS/MMS gateways page needed to be translated into a format compatible for importing into a database table. If the tables on Wikipedia had the option to export the data in various formats, I feel that many people would benefit from this utility.

+++++++++++++++++++++++++++

I imagine there might already be an API available for accessing & obtaining information from Wikipedia. If this is the case, my suggestion shouldn't be ignored completely, because using an API to obtain information requires special knowledge that I presume most visitors of this site do not possess. On the other hand, if my suggestion can be implemented, it would allow for a wider audience to participate in bulk data exports of table data.

Also, if by any small chance, there isn't an API established for Wikipedia yet, you should really look into developing one!

++++++++++++++++++++++++++++

Thanks for your time reading this... and thanks for providing an excellent means of providing and sharing knowledge to the general public. — Preceding unsigned comment added by CheeseConQueso (talk • contribs)

Of course there's an API. It's available at <https://en.wikipedia.org/w/api.php>. :-)

This is a very good feature request. I completely agree that having a little widget next to every table allowing easy export would be great. You should file a bug at Bugzilla. (Or I will shortly.) --MZMcBride (talk) 19:06, 10 March 2012 (UTC)

Why not just copy the table data and paste it into MS Excel or any other spreadsheet, then save it in whatever format you want? That's worked for the last decade... Franamax (talk) 19:34, 10 March 2012 (UTC)

"That's how we've always done it" isn't exactly a reason to ignore innovation, though. And this sounds like a nifty idea, though it won't see use among the average editor. Having that option could be very useful, though. — The Hand That Feeds You:^Bite 18:31, 13 March 2012 (UTC)

I've currently got a css code that I use to turn links that are redirects green:

a.mw-redirect { color: #00aa00; }

I think this would be useful to a lot of editors as a gadget. I know there is a user preference to colour links to articles less than a certain size (in bytes), so this would be nice right underneath it. - ʄɭoʏɗiaɲ ^τ _¢ 19:08, 12 March 2012 (UTC)

I agree. What would even more useful would be to expand redirects into their destination article for their tooltips (not to hijack your proposal, but it seems related). Equazcion ^(talk) 19:20, 12 Mar 2012 (UTC)

This does seem to happen for me... periodically. Sometimes the tooltip will show the article I will arrive at, other times it will just show the title of the redirect. - ʄɭoʏɗiaɲ ^τ _¢ 22:18, 12 March 2012 (UTC)

Probably when the link text shows a shortcut but is actually pointing to the full page address. WP:V shows "WP:V", while WP:V shows "Wikipedia:Verifiability". Equazcion ^(talk) 23:28, 12 Mar 2012 (UTC)

If it's any interest, Wikipedia:Tools/Navigation popups (in preferences > gadgets) will show target articles for redirects, among other things. Shimgray | talk | 22:31, 13 March 2012 (UTC)

User:Anomie/linkclassifier is a very thorough script for colouring links. I find it very useful.-gadfium 21:00, 12 March 2012 (UTC)

I think that may also play a part in making the code I placed above work. - ʄɭoʏɗiaɲ ^τ _¢ 22:18, 12 March 2012 (UTC)

No, mw-redirect is added by MediaWiki itself (since T14968 was fixed by r30871 in early 2008). Anomie⚔ 00:05, 13 March 2012 (UTC)

Sounds good to me; my css has had green redirects for years and when I'm logged out I find the "regular" blue redirects quite annoying. 28bytes (talk) 23:00, 12 March 2012 (UTC)

As a user and editor, I would like to be able to easily distinguish whether an articles talk page has been changed since my last visit and or edit to it. Some of us have a lot on our watch list, and the chances of me missing an updated talk page is high. I don't think a big banner with flashing lights is necessary, but something subtle yet noticable, such as bolding the 'talk' button, or changing the font color could be useful. Mr.weedle (talk) 03:30, 11 March 2012 (UTC)

Just above the actual content of the watchlist is a dropbox that says "Namespace". If you select "Talk" from that and click the "Go" button, it will show you only the recent changes to talk pages. Slightly less convenient that having them highlighted amongst all the others, yes, but it should help a little. Keep in mind you'll have to switch back to "all" to get the non-Talk pages to show back up. —Scott5114↗ [EXACT CHANGE ONLY] 06:01, 11 March 2012 (UTC)

You mean like Facebook's little red square? That would be fine to me. Only problem is, there are too many pages to keep track of. --NaBUru38 (talk) 19:13, 13 March 2012 (UTC)

Sort of - Instead of the red notification icon, which is a bit in your face, and not very wikipedia; I think something subtle like a different text colour that is bold, just as a small reminder that something has changed since your last edit or visit Ideas? Mr.weedle (talk) 07:51, 14 March 2012 (UTC)

Having seen some support and encouragement at the idea lab (archive will eventually be either here or here), I'm ready to move the proposal here. Most of the rationale can be seen there. Having read the discussion, I think we could use mw:Extension:Drafts, but I think it's ultimately up to the developers to pick and/or implement a mechanism, especially since it's not clear to me how much testing that extension has had.

For people unwilling to go and read the idea lab post, here's the short version: New users may not understand the "This page is asking you if you want to leave" dialog and they may be just clicking through it. So we should save drafts of edits to prevent the work from being lost. --NYKevin @828, i.e. 18:52, 13 March 2012 (UTC)

I'd love that! Sometimes when I'm at the uni, I get kicked out of the computer room because there's lessons. When hat happens, I must rush to add the template "in progress" and save, or I lose the whole work. With that, I could leave the computer easily and resume the work somewhere else. Thanks! --NaBUru38 (talk) 19:15, 13 March 2012 (UTC)

This is another case where may other people may be little more responsive if you clarfied exactly what you mean by "the proposal". ACEOREVIVED (talk) 14:53, 14 March 2012 (UTC)

The second paragraph describes it, and I also linked to a post with more information. Basically, I want to save drafts of edits in progress when the user leaves the page, rather than just throwing up a dialog box saying "This page is asking you if you want to leave..." since I don't think the average user is likely to understand that dialog. --NYKevin @796, i.e. 18:06, 14 March 2012 (UTC)

I don't see a practical way of doing that. The dialog at least warns them their changes won't be saved, which is better than nothing. — The Hand That Feeds You:^Bite 20:40, 14 March 2012 (UTC)

Um, I'm trying to get consensus in order to file a bug requesting that the developers figure something out. For example, they might test and/or install mw:Extension:Drafts. That seems perfectly practical to me. Honestly, I think issues of practicality are for the developers to decide, not us. --NYKevin @011, i.e. 23:15, 14 March 2012 (UTC)

My proposal is that at the top of the page of a tv series, such as glee, or family, or house etc, it has one those those italicised sentences that says something like "for the latest episode of _____, which is currently in season _____, see _________." It will save a heck of a lot of time in finding the latest aired episode on a series instead of typing in the name of the series, then scrolling down to click on the latest season article, then scroll down and clock on the latest ep article.--Coin945 (talk) 09:05, 9 March 2012 (UTC)

Those italicised sentences are called Wikipedia:Hatnote but this isn't really what they are for. It would also require frequent updates and often be out of date. And many countries air foreign shows with a delay of weeks or months. I don't support going down this road but if we do then I think it should be a field in Template:Infobox television with both episode name and original air date. PrimeHunter (talk) 15:36, 9 March 2012 (UTC)

What's the view against going down this road? It seems like a logical, helpful thing to do from my perspective...--Coin945 (talk) 10:31, 10 March 2012 (UTC)

Opposing view would be something like... wikipedia is an encyclopedia? --lTopGunl (talk) 12:53, 10 March 2012 (UTC)

.....I've thought about this quite a lot and I've come to the conclusion that we can't actually use that as an excuse anymore. Wikipedia is not an "encyclopedia". It is a hub for all knowledge. When people want to know something, they will always to go Wikipedia - not to Wiktionary, or to Wikinews, or Wikicommons etc. Wikipedia is the be all and end all. That's the same reason why I oppose transwikiing. By all means have a wiktionary article as well, but keep the Wikipedia article as if its not on Wikipedia, it doesn't exist [at least that's the way many people see it]. And it naturally follows that I'm starting to think that just as Urban Dictionary is creating new memes and popular culture that even the media haven't picked up on, maybe it is our job to document them.... screw notability!!! [rant over :P] My point is that people go onto Wikipedia to have easy access to things they find interesting. Yes, the info they get can often be sub-quality, but I for one sure as hell love it when the Wikipedia article is a Simple-English style article that has all the basic facts in simple sentences/paragraphs instead of massive articles that i have to skim through to find what I'm looking for.... and I'm sure for others it's the same. In the same way, making life slightly easier for our readers will be of such great use to them. I don't see how fear of skewing from the "encyclopedic" format is a valid argument. All I am saying is that this might be a very useful little shortcut for people.--Coin945 (talk) 15:31, 10 March 2012 (UTC)

To put it simply: Just because people may use a resource for something doesn't mean that's what the resource is for. ♫ Melodia Chaconne ♫ (talk) 16:40, 10 March 2012 (UTC)

I don't think you'll get much traction for trying to revoke WP:N. I really don't want Wikipedia to become haven for all the fancruft that would allow, as well as minor bands, trivial locations, etc. Just because you can do a thing, it does not follow you should do it. — The Hand That Feeds You:^Bite 18:46, 10 March 2012 (UTC)

I wouldn't like that hat, because the user can find that information in better places (like the infobox). Plus, with so many series around here, it would get outdated very easily. --NaBUru38 (talk) 19:11, 13 March 2012 (UTC)

Some thing rather similar to the proposal here happens with some television programmes. Just take a look at the article on University Challenge. It will not be hard to find a reference to "Series 41" (the 2012 series) and a link to the article on that there. Were you propososing that this should go for drama series as well as quiz series? I think it all depends how much attention Wikipedians feel an individual television series deserves in Wikipedia. ACEOREVIVED (talk) 19:49, 15 March 2012 (UTC)

I think that the Gentry article needs a major Gallery cleanup. For each country there is a gallery with people that are examples of its gentry. The people from each gallery are completely randomly chosen and this leads to two things:

1)The article becomes ridiculous and

2)Some old computers cannot afford such a large amount of images.--188.4.233.216 (talk) 13:46, 11 March 2012 (UTC)

It is kind of odd, especially given the fact that every section has been split to subarticles. The galleries should either be moved to the subarticles or removed completely.

That said, this isn't the place to bring it up. Talk:Gentry would have been more appropriate. :) --Izno (talk) 16:51, 11 March 2012 (UTC)

No one looks at talk pages. Especially in this talk page there is a proposal that has not been answered sonce March 2010...--188.4.233.216 (talk) 19:02, 11 March 2012 (UTC)

If you're getting no responses at the article's talk page, try Rfc. Per Izno, this isn't the appropriate venue. Thanks. --JayJasper (talk) 19:11, 11 March 2012 (UTC)

You're right anyway - just clean it out. Johnbod (talk) 22:39, 15 March 2012 (UTC)

Moved from WP:VPP (Policy) because of letter "P" mistake. [4] -DePiep (talk) 10:48, 8 March 2012 (UTC)

I propose to add a link to every cite template, added to the reference content and so to be shown in the reference section. The link shows "[Edit]" on the page, and when opened it allows editing the reference (template), as entered on that page. Much like one can edit a Section now. -DePiep (talk) 10:12, 8 March 2012 (UTC)

^{[further explanation needed]}. Can you explain what are the benefits of this change? Diego (talk) 10:32, 8 March 2012 (UTC)

It isolates, for editing, the single reference code input (template usage on the page) from other code. Especially since the code is in line, it is complex when editing the full page. -DePiep (talk) 10:42, 8 March 2012 (UTC)

{{Cite doi}} has that feature, but it only works because each reference is a subtemplate. ---— Gadget850 (Ed) ^talk 10:52, 8 March 2012 (UTC)

Spot on. We could limit it to cite templates, I have cast the net a bit wide. -DePiep (talk) 11:01, 8 March 2012 (UTC)

• Have you tried ProveIt? You can activate it in your Preferences->Gadgets. It doesn't work exactly as you describe, but it's somewhat similar, I think, and worth a look if you've never tried it. Begoon ^talk 10:57, 8 March 2012 (UTC)

• I just tried the demo. Very, very good. But hey, I do AWB once a month. I really need to learn HotCat, to use it once a month. Maybe I am a TWinkle-editor, once a month. You get my point? I am a serious editor, with many edits, but having to (learn to) use an App is not good. Just give me an [Edit] click, please. -DePiep (talk) 22:29, 9 March 2012 (UTC)

1) Wouldn't WP:Citing sources (or such) be a more appropriate place to discuss this?

2) The proposal is unclear as to where this edit link is to appear. You mention a "reference" section: does this mean specifically a section titled "References"? Or some other section? Or is the edit link to follow the citation (reference) wherever it is displayed? Or do you propose that these edit links be collected in some special section?

3) If the core problem is the difficulty of template coding being mixed in with article text (and I agree that is a problem), then there is a much easier solution: gather all the templates together in one section (e.g., "References") and link to them using Harv.

~ J. Johnson (JJ) (talk) 17:45, 8 March 2012 (UTC)

Not everyone like Harvard referencing. --Cybercobra (talk) 05:25, 9 March 2012 (UTC)

re JJ: 1) Indeed, "(or such)" is where I ended up. 2) As for where the [edit] is to appear: I think I described that in the first sentence. A more exact location can be decided later, and is not essential for the proposal. {{cite doi}} is a good example. 3) Reducing cite options to just harv is no way forward, and not "easier" (more simple it is, as in "choose any black color for your T-Ford"). I must say, you got the issue right when acknowledging it. -DePiep (talk) 16:57, 9 March 2012 (UTC) Struck my arrogance -DePiep (talk) 22:18, 9 March 2012 (UTC)

You have not explained why this venue is more appropriate than (say) Wikipedia talk:Citing sources. I think that exactly where this edit tab is to appear is a key part of the proposal, and not something that can be "decided later"; the lack of that detail suggests that the proposal has not been adequately worked out. (Could you provide us with a mockup?)

And I find it quite inexplicable how you find "Reducing cite options to just harv is no way forward". I certainly have not suggested "reducing cite options" – I suggested an available option that is likely more useful, and certainly easier, than what you are proposing. That many editors are prejudiced against it is unfortunate, as it does not suffer from the problem you apparently want to address. ~ J. Johnson (JJ) (talk) 00:33, 10 March 2012 (UTC)

JJ, how did I offend you? I am here on this page to drop an immature proposal. Maybe more than just my detailed world is involved (it is: another "[edit]" utton on a page!), but we are here to let it evoluate. -DePiep (talk) 00:03, 17 March 2012 (UTC)

a board game for wikipedia — Preceding unsigned comment added by Duocat (talk • contribs) 15:12, 14 March 2012‎

There's a card game in development - WP:TCG. Equazcion ^(talk) 15:15, 14 Mar 2012 (UTC)

Sounds an interesting idea, perhaps this ought to go on the Wikipedia: Main Page (rather than here) so that more people see it! ACEOREVIVED (talk) 12:00, 15 March 2012 (UTC)

Be serious. Why would we put some half-assed scheme to make a card game out of wikipedia on the main page. ffs. --Tagishsimon (talk) 13:43, 16 March 2012 (UTC)

An RfC has been posted concerning a proposed guideline tentatively by the name Wikipedia:Disruption on talk pages. Please comment. Brews ohare (talk) 18:31, 15 March 2012 (UTC)

This proposal has been moved from user space to Wikipedia talk:Avoiding talk-page disruption. Comments collected so far can be found there. Please comment. Brews ohare (talk) 18:04, 16 March 2012 (UTC)

When I read [citation needed], I can't tell whether the sentence it refers to was written a fortnight ago, and the tag added a week later, nor whether a citation is in the process of being sought . . . OR whether they're both aeons old.

I propose that it be changed to [citation needed (2nnn/nn/nn)] (not retrospectively, of course) so as to help readers know how much weight to give a statement which someone has implicitly challenged.

I've suggested a century-first format to obviate the American mm/dd/yy format versus the European dd/mm/yy format ambiguity.

I propose the date be inserted by software, not by the tag inserter.

Forgive me if it ISN'T called a tag! I'm not anything of a wikipedia editor, so I'm guessing.

There should be a bot that comes along and adds the date to the tag... perhaps it's down at the moment. 28bytes (talk) 17:58, 16 March 2012 (UTC)

I don't think that is what the poster is asking about, 28, since the bot-added date isn't visible on the article page.

I think the main reason that we don't have dates visible in "citation needed" tags is that it would take up more space and, actually, it wouldn't in practice be a very good guide to how seriously to take the tag. Sometimes the tag can be there a long time and it turns out that the info is true. Sometimes it may have only just been put there, but put there for a very good reason. I don't think there's any real rule about it.

I would say that the only way to check out whether tagged info is reliable is to research it yourself. Of course, you should also add what you find out to Wikipedia so that everyone can benefit. --FormerIP (talk) 19:47, 16 March 2012 (UTC)

But if you mouse over it, it shows the date.^{[citation needed]} 28bytes (talk) 19:57, 16 March 2012 (UTC)

Yeah it does. But what I'm saying is if you think a five year old tag is necessarily more for a reader to worry about that a two month old tag, you're not correct. --FormerIP (talk) 20:00, 16 March 2012 (UTC)

Well, sure. I'm just telling him how to find the information he's looking for. How he uses it is up to him. :) 28bytes (talk) 20:59, 16 March 2012 (UTC)

This is a proposal to come up with a systematic means by which members of subsets of Wikipedia articles (chemicals, protiens, railway stations, etc etc) can be accessed by means of Universal IDs.

The subjects of many wikipedia article have unique IDs assigned to them. Chemicals are identified by their CAS registry number, for instance; protein sequences are identified by a range of UIDs such as UniProt; nucleotide sequences and their protein translations by GenBank ... UK railway stations by NaPTAN, etc. As you'd expect, UIDs are used to provide access to all sort of database repositories. Techniques include web service interfaces, APIs, etc. UIDs make information available on a systematic basis.

UID are already widely used on wikipedia, notably in infoboxes of articles. But right now, any info wikipedia has about a subject is (as far as I know) mostly inaccessible by the UID. Searching for the Ensembl UID for Rhodopsin, ENSG00000163914, brings a pretty useless result.

Equally, right now, any number of software products exist to search third party databases for information by UID. Other than by article name, wikipedia will tend not to feature as a source.

The proposal, then, is make such changes as are sensible to make wikipedia articles accessible by UID through the normal web interface. There are a number of ways this could be done; I come here for thoughts and direction both about the general idea and also the specific implementation. A low-tech example implementation is to create a redirect for each UID - e.g. Ensembl-ENSG00000163914 - and expect it to redirect to the article, Rhodopsin. A better approach would be to reuse the data already in infoboxes to seed the interface, so that we're not double entering data.

If it needs answering, the "why do this", "what use will be made of this" questions resolve to "because we can", "who knows", "until we do we'll not find out" and "if we don't, then we prevent these things from being realised". Those seem good enough reasons to me. Grateful for proposal and implementation detail feedback. thanks --Tagishsimon (talk) 21:25, 13 February 2012 (UTC)

I absolutely endorse this proposal - I'd be happy to be considered a co-proponent - which accords with moves to increase Wikipedia's metadata and machine readability; as well as interoperability with other websites and apps. Alternative formats (and there will be others) would be Ensembl:ENSG00000163914 or to set up a UID namespace, for example: UID/Ensembl/ENSG00000163914. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:39, 13 February 2012 (UTC)

Support redirect system. Redirects are cheap, and I can't see how the it would interfere. If other commenters have a negative outcome in mind, then I may need to re-evaluate. At the moment I can't see it. Not sure what "A better approach would be to reuse the data already in infoboxes to seed the interface, so that we're not double entering data." means. Automatically creating (or even maintaining) redirects based on infoboxes could be suitably trialled and implemented, I would think, if that's the sort of thing you meant. Grandiose (me, talk, contribs) 21:45, 13 February 2012 (UTC)

I'm not convinced that "who knows" is a sufficient reason to spend the time & resources of the WikiMedia on fixing a problem which does not yet exist, when they could be used to fix problems that we do know exist. If I've just not fully understood the proposal (which may well be the case), just let me know. ItsZippy ^{(talk • contributions)} 21:48, 13 February 2012 (UTC)

It's hard to say, ItsZippy. Who knows what's in your head? What I know is this: right now anyone who has an app which uses UIDs finds wikipedia inaccessible. If we re-use UIDs to enable access to article text, it becomes utterly trivial for any third party dealing in UIDs to access our content. --Tagishsimon (talk) 21:53, 13 February 2012 (UTC)

To be honest, I don't know a great deal about UIDs. If you think it's beneficial, then I won't be opposed. ItsZippy ^{(talk • contributions)} 22:15, 13 February 2012 (UTC)

Rather than onwiki namespaces, it might be possible to do something using a simple lookup database - toolserver.org/UID/Ensembl/ENSG00000163914 spits out the relevant article, with the option of adding /en or /de to the URL to select the desired language, etc. I do like the idea very much - I can see an obvious application involving LCSH headings resolving to specific Wikipedia articles, for one thing! Please let me know if you go ahead with this...

One other approach would be to increase our use of hidden infobox fields, and make sure they search properly. It's not much help to prominently display relatively technical identifiers in an article, but if we used something like persondata - a hidden metadata template - this would be a great use for it. Including this alongside the referrer database or redirect would also help ensure we don't get errors creeping in due to page moves (which is likely if we start using geographical or personal identifiers); we can have a script patrolling for mismatches and flagging them. Shimgray | talk | 22:40, 13 February 2012 (UTC)

Why would we put something on the toolserver, when Wikipedia itself can host it adequately? Also, I'm not in favour of hidden fields. We should be displaying UIDs in infoboxes; but that's a separate issue and should not be conflated with this one. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:09, 13 February 2012 (UTC)

I'm certainly not wedded to the idea of an off-wiki solution (and toolserver was just an arbitrary suggestion), but I think it's worth considering the benefits. The model I'm thinking of here is the very successful QRpedia, which does a similar trick of going through an intermediate layer before resolving a specific Wikipedia article, rather than leaping straight to an enwiki address.

Firstly, in the short term, it's simpler. We can set up a test database of these links elsewhere as a demo without approval, since it doesn't have to tie directly into the wiki; going straight for onwiki namespaces involves getting consensus before being able to do a practical demonstration, which risks becoming a vicious circle... (Transferring a proof-of-concept database to the wiki should be relatively simple, if the namespaces are later enabled - it'd be a matter of running a script to populate the redirects. The converse is true, as well, of course!)

Secondly, it has greater potential for future development. Using an intermediate layer makes it a lot easier to expand the functionality with things like:

• adding alternate-language capacity via the same URL, without having to seperately query xx.wp and xy.wp and xz.wp to see if there are entries in the preferred languages. (I can imagine a case where a database would say "We need results in Polish, alternatively falling back to German or Russian, and if all else fails use English.")
• more versatility in what we send back - some users might want microformat metadata, some might want full articles, some might want mobile ones, some might want us to spit out a copy of just the lead or the infobox image, etc.

...to take a couple of examples. Shimgray | talk | 12:47, 14 February 2012 (UTC)

This seems desirable, but probably needs a project page somewhere so ideas can be worked through. Is it wanted that a Google search for "ENSG00000163914" would include Wikipedia in its results? And/or a normal (article namespace) Wikipedia search? (Currently, a Wikipedia search finds nothing unless searching in the template namespace.) Roughly how many articles might end up with a UID? How would they be maintained? While a bot might happily create thousands of redirects, there should be some planning for how the results could be maintained. For example, there could be a master list somewhere, and a bot would make the redirects from that list, and would periodically report any changes to the redirects that disagree with what is in the list. Johnuniq (talk) 10:08, 14 February 2012 (UTC)

Yes; a project would be a good idea. Google searching would be one benefit, but the primary purpose would be so that other websites (online databases) and apps could programmatically create URLs like, say, http://en.wikipedia.org/wiki/UID/Ensembl/Foo, where "Foo" is a UID, and be redirected to the relevant article. Hopefully, this would also, eventually, be possible through the API, too. The use of categories would serve to provide lists of such articles. A bot could create the redirects, by scanning, for example, sub-templates of {{PBB}}; like {{PBB/6010}} for Rhodopsin. I like your ideas of a bot reporting suspicious changes. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:36, 14 February 2012 (UTC)

Tagishsimon, POTW, ... will you please stop having good ideas before I have them! .... :-) I'm currently talking to Library catalogue folks in Sheffield. I think we have an agenda! (ItsZippy - our resources are volunteers - the resource is infinite! We just need discussions about where the value and the enthusiasm best match. This might be one of them Victuallers (talk) 10:56, 14 February 2012 (UTC)

I have created WikiProject Unique Identifiers for discussion and coordination of all UID related matters. Please join! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:49, 14 February 2012 (UTC)

A google search for ENSG00000163914 within the en.wikipedia.org domain gives {{PBB/6010}} and Rhodopsin as the top two hits. It is also worth noting that at least one external database can be search for ENSG00000163914 (see for example GeneCards) that leads to a link that points back the the Wikipedia Rhodopsin article. I don't see any harm in adding these types of redirects, but at the same time I do not see any particular advantages either, especially considering that search engines can rapidly locate the desired article. For the rhodopsin article alone, there would be an almost endless list of possible redirects starting the rhodopsin ensemble accession numbers for a half dozen additional species, the refseq RNA and protein IDs, UniProt IDs, etc. Boghog (talk) 20:50, 20 February 2012 (UTC)

The particular claimed advantage is that a third party database using UIDs can link to wikipedia articles at something like nil marginal cost. Given that we have UIDs in articles, leveraging them to create redirects is also pretty much nil marginal cost. There may be many redirects to a single article, agreed, but I don't see that as a problem. --Tagishsimon (talk) 21:03, 20 February 2012 (UTC)

You don't see any cost to adding millions of redirects? --MZMcBride (talk) 14:15, 1 March 2012 (UTC)

That's why bots were invented. When we have large numbers of articles with specific unique identifiers, a bot will not have difficulty figuring out the one that's applicable to each article. This is a simple enough task that I doubt we'll see false positives except for occasional vandalism and typos. Nyttend (talk) 14:35, 9 March 2012 (UTC)

I am still confused as to why we would want all this in the first place? Could someone explain the idea in simple language. (Don't assume people understand what you are talking about). Start with explaining what a "Unique Identifier" is and does. Then go on to explain why and how you think Wikipedia would benefit from having these "Unique identifiers". Thanks. Blueboar (talk) 15:05, 9 March 2012 (UTC)

THere are standard codes for train stations. THere are standard codes for Proteins. I run a web site or database dealing with train stations. And another dealing with proteins. I use these standard codes in my website. Right now, I cannot use these codes to link to wikipedia.

Wikipedia has standard codes for train stations in its train station articles. Wikipedia has standard codes for proteins in its protein articles.

If wikipedia uses the codes it already has, to crate redirects to the appropriate train station or protein page, then by making one simple change in my website code, I can link all of my train station entries to wikipedia: my users can navigate from my website record to the apropriate wikipedia record. Ditto proteins.

That's it in a nutshell. And yes, there are a number of train station and protein web services out there; and ditto the very many other database systems dealing in entities which have UIDs. Does that help? --Tagishsimon (talk) 15:16, 9 March 2012 (UTC)

So you want the Ensembl code for the protein Rhodopsin to redirect to that page, using a predictable format like Ensembl-ENSG00000163914. We should be able to set up something like that using a bot, based on infobox contents. WhatamIdoing (talk) 00:51, 13 March 2012 (UTC)

Support - a unique UID namespace would be the best way to go about this - redirects are going to be cluttered, as one would require an exact format in order to obtain the page. With a UID namespace, people will not have to follow the exact format and UIDs will actually be a useful part of Wikipedia. Wer900 (talk) 18:53, 18 March 2012 (UTC)

Hello. The current MediaWiki software can provide hyperlinks starting with http://. Many new users who want to contribute positively, and is trying to learn Wikimarkup fast rather than using the software for providing external links, write [www.google.com Google] instead of Google Many articles have this problem, having [www.<name>.com Name] in external link, rather than beginning with http website name.com . See a diff here, in my sandbox. I would like to ask for a communal input on this topic. Please be clear in what you try to tell. Thanking you, Dipankan says.. ^{("Be bold and edit!")} 08:55, 16 March 2012 (UTC)

This sounds like a problem that a bot could fix. If the pattern you observe [www.something.tld text] appears the bot could isnert the http:// . If the text is missing it would be better to convert to a raw url without square brackets. Graeme Bartlett (talk) 11:29, 16 March 2012 (UTC)

I don't think the bot could handle so much. There may be more than 10,000+ pages with this issue. Dipankan says.. ^{("Be bold and edit!")} 13:25, 16 March 2012 (UTC)

The MediaWiki software detects the URI scheme to create the link, and a lot of websites do not use www in the URL. ---— Gadget850 (Ed) ^talk 13:34, 16 March 2012 (UTC)

It could have a limited benefit, but overall I think the impact would be negative. People need to realize that a full URL includes the scheme. Some popular browsers are now omitting the scheme in the address bar by default (or in the case of Chrome, totally removing the option of ever showing the http:// scheme), but this is a mistake that we don't have to make. Editors need to have competence, and there is always the preview function; we don't need to encourage laziness in editing. Browsers are usually designed to be "friendly" in that they will try to figure out what you meant, but when writing an article we need to be specific with exactly what we're referring to. See also robustness principle. —danhash (talk) 14:04, 16 March 2012 (UTC)

A bot can easily handle 10000+ pages. The hard part is finding all the pages with this problem, which sounds like a job for WP:WPCHECK. Anomie⚔ 17:23, 16 March 2012 (UTC)

I concur with DanHash. Sloppy link coding like this is actually one of the easiest ways to find would-be reference citations that need to be verified and properly WP:CITEd; having a bot "fix" them would actually do harm to real WP:V/WP:RS cleanup interests, which are way, way more important than extlink formatting cleanup interests. This would effectively hide a symptom indicative of an untreated disease, as it were. PS: poorly coded links are also one of the easiest ways to find crap in articles that violates WP:SPAM and/or WP:EL, and "fixing" it would also harm WP:NPOV cleanup interests. — SMcCandlish   Talk⇒ ɖ∘¿¤þ   Contrib. 19:12, 16 March 2012 (UTC)

I agree. In addition, I have sometimes seen stuff like "an example of a host name is www.example.com" which should not be changed to a link. Contributors should be encouraged to edit, and no one should revert changes merely because they are not properly formatted, so invalid links are not a big deal. As stated above, it would be best for an experienced editor to review the text and decide on the appropriate action (often external links are undue, or plain spam). Johnuniq (talk) 02:31, 18 March 2012 (UTC)

I have a question regarding proper inline tagging of an article when there is a dispute about the accuracy of an image. This is of particular interest in the field of astronomy where speculative illustrations of unresolved objects are more commonplace. Would it be better to use a tag like {{Disputed-inline}}, {{Dubious}} or {{Or}}, or should a new inline template be generated specifically for image concerns? For example: ^{[Image disputed – Discuss]}. Regards, RJH (talk) 19:24, 13 March 2012 (UTC)

This presumably is related to the discussion at WT:NOR about whether images can be banned from Commons for violation the English Wikipedia's "No original research" policy. WhatamIdoing (talk) 00:04, 14 March 2012 (UTC)

Only indirectly. Regards, RJH (talk) 23:07, 14 March 2012 (UTC)

It's a complicated problem. I'd suggest tagging the image (rather than the article), except that most of our images are at Commons, and the English Wikipedia can't really go tag the image files over at Commons for non-compliance with our standards. Additionally, the image could be perfectly fine, but misused in a particular article. For example, you seem to object to using artistic illustrations of exoplanets (someone might be confused into thinking it's a real photograph rather than some artist's vision of the planeet), but I'm sure that we could agree that such an image would be a perfectly fine illustration for an article about Illustration of exoplanets.

I don't really know what the best way to tag such a problem is. I think I'd skip the tag and just head for the talk page. WhatamIdoing (talk) 00:56, 20 March 2012 (UTC)

I have just finished a discussion with some generous folks at HighBeam Research--an online, pay-for-use search engine for newspapers, magazines, academic journals, newswires, trade magazines and encyclopedias. The site has access to over 80 million articles from 6,500 publications, most of which are not available for free elsewhere on the internet. Aside from a free 7-day trial (credit card required), access to HighBeam costs $30 per month or $200 per year for the first year and $300 for subsequent years.

But...as of yesterday, HighBeam has agreed to give free, full-access, 1-year accounts for numerous Wikipedia editors to use, at the discretion of the community. They do not expect there to be a problem with the number of these free accounts; however, the plan is for editors to have a minimum 1 year-old account with 1000 edits in order to qualify.

This is a proposal/announcement of the project not the signup process, which should begin in early April and will be widely publicized. Details about the project are available at WP:Highbeam. Comments and assistance setting up the project are welcome. Cheers! Ocaasi ^{t | c} 09:27, 14 March 2012 (UTC)

Very welcome news; kudos to you and to HighBeam. --Tagishsimon (talk) 14:56, 14 March 2012 (UTC)

Indeed this is welcome news. Ditto on the kudos. Thanks for sharing this.--JayJasper (talk) 20:02, 19 March 2012 (UTC)

I'd like to see a method of having the Article Tab removed on Archived Talk pages such as Talk:Muhammad/Archive 18, in this case it does not make sense to actually have the equivalent article Muhammad/Archive 18. While it is not always true that a talk page with a slash shouldn't link to its equivalent article (like Talk:Face/Off), is there some way that there could be a flag set (which could go in the Template:Automatic archive navigator as well as other appropriate places). (In fact can anyone think of a reason that a talk page that exists should have a link to a "article page for it" that doesn't exist yet?) Note, this is a "like to see"...Naraht (talk) 15:05, 19 March 2012 (UTC)

Or the article tab could like back to the main article, for example on Talk:FL Studio/Archive 1, the article tab would link to FL Studio, not FL Studio/Archive 1. Either way, this would be a useful feature. —danhash (talk) 15:15, 19 March 2012 (UTC)

Also a very valid idea, either would be much better, IMO, than the current situation.Naraht (talk) 15:26, 19 March 2012 (UTC)

A good idea; the current appearance is rather weird and potentially misleading. dci | TALK 22:28, 19 March 2012 (UTC)

This was also discussed at Wikipedia:Village pump (technical)/Archive 97#Can we get talk archives to point to the main? PrimeHunter (talk) 01:04, 20 March 2012 (UTC)

I was going to request this, but I eventually managed to script it myself. There used to be several scripts for this on Monobook, but since Vector I couldn't find a working one, and I figured people might want to know it exists now. User:Equazcion/ContribsTabVector. Equazcion ^(talk) 12:19, 13 Mar 2012 (UTC)

I'm sure Equazcion knows this but for people considering this script who might not, there's a "User contributions" item in the Toolbox menu on the left-hand sidebar when you are on a userpage. Jason Quinn (talk) 03:16, 21 March 2012 (UTC)

Yeah I do :) As evidenced by the three or so scripts that existed for this under Monobook though, many users like to have this in a tab. It feels like it should be one. Equazcion ^(talk) 03:23, 21 Mar 2012 (UTC)

Wikipedia is the natural home for glossary information required by other websites. Rather than building their own glossaries, web authors should be able to link directly to Wikipedia. However, it is often the case that the item of information important to the referencing site is not the article as a whole, but a particular section, paragraph or even sentence, table or figure within the article. This is the Wikipedia counterpart of footnotes in print documents that refer to particular page of another document. Wikipedia already provides a certain amount of fine-grained access with its table of contents, which when used provide a URI that an author can use to link directly to a section.

This ability to link directly to specific information is not true of the lead paragraph, which contains essential definition of the subject of the article, and is precisely the information that would make a Wikipedia article for glossary footnotes. That omission may be unimportant when an author uses an endnotes style of glossary references: a link can take a reader to a Wikipedia page, which he can read and then return from; but it makes using Wikipedia difficult for authors to use frames or other techniques to provide footnotes that can be read simultaneously with the page using the defined term.

For example, if I am writing a page that discusses Aristotle's concept of causality, I can use the URI "http://en.wikipedia.org/wiki/Causality#Aristotle" in a link, with a target of MyFootnoteFrame and the Wikipedia article on causality will open in that frame directly at that section. But if I use the URI "http://en.wikipedia.org/wiki/Causality" the article opens at the top of the page with (today) three inches of page space before the lead sentence. For the purpose of putting footnotes in a compact frame, that effect is quite undesirable.

I tried adding ' {{anchor|Topic}}' tags to the lead sentence, but they are being removed by disapproving editors. Izno merely called them "unstandard". Johnuniq had more to say: "Articles at Wikipedia should not have obfuscating wikitext added simply for the convenience of external websites. I have removed your edit from Uniform resource identifier because it does not assist the article and has the potential to confuse editors (why is it there? what is it for?)."

I respond to Johnuniq by saying that anchors are obfuscating only to those who do not understand the interrelationships among information. Moreover, just as national boundaries have become moot relative to the global economic flow of goods and services, the boundary between what is internal and what is external to Wikipedia is moot relative to the noetic flow of information. Wikipedia is the perfect place to record, debate and refine common knowledge. But the uses to be put to that information vary with every story told by every author in the noösphere. Anchors are the technical mechanism that enables that multiplicity of usage. Wikipedia encourages its authors to build articles out of fine-grained, documented, reusable information. They should also be encouraged to anchor that information so that other authors, both inside and outside Wikipedia, can make effective use of it.

Far from prohibiting anchors, Wikipedia should encourage and standardize them. What should be the standard practice, to enable authors to point directly to the lead sentence or to other fine-grained information? What should be the standard anchor/URN for a lead or other sentence so that it can be referenced by a URI (URL + # + anchor) to that sentence? Should a shortcut template be added so that users can obtain the URI? Should some other link be added so that a reader of a Wikipedia footnote can open the full page in a new window? What instructions should be placed in this MOS article to guide Wikipedia editors in entering lead paragraph anchors? Is it possible that such anchors (and shortcuts) could be generated automatically? These are important technical questions that need to be addressed.

But policy must be set first. Is Wikipedia going to play a significant role in the commerce of information by being a broker of information by allowing fine-grain access to its contents, or is it going to insist that the Wikipedia page is the smallest unit of information that it will provide ready access to, in which case users of information will have to turn elsewhere.

Since I am in the process of building a website that requires a good glossary that I can present in a footnotes frame, I would appreciate some guidance. Should I put my efforts in upgrading Wikipedia to serve this need, or should I write my own glossary that simply links to Wikipedia?

[This is a modified version of the suggestion I put in the Talk section of Wikipedia_talk:Manual_of_Style/Lead_section.]DrFree (talk) 22:23, 18 March 2012 (UTC)

The built in #top links to the pagename, for example Causality#top. #mw-content-text links to the start of the article body, for example Causality#mw-content-text. As in this example, it will often be a hatnote. PrimeHunter (talk) 23:26, 18 March 2012 (UTC)

There's also Causality#firstHeading, which links to the title of the page (below the site notice, if any). In general, if you look at the page source any tag with id="foo" may be linked to with #foo in modern browsers. Anomie⚔ 01:43, 19 March 2012 (UTC)

Thank you for the suggestions but none have the require functionality: Causality#top and Causality#firstHeading open the page at the title, a wasted inch above the lead paragraph. Causality#firstHeading opens the page at the redirect paragraph, closer but still half an inch lead paragraph. Sorry to be picky, but a web page can only allocate a narrow frame for footnotes.DrFree (talk) 22:33, 19 March 2012 (UTC)

The topic caught my attention, but – WP:TLDR. ~ J. Johnson (JJ) (talk)

I didn't read it all either, but this use of {{anchor}} is inappropriate. If you want this functionality go get it done at mw:. Alarbus (talk) 01:16, 19 March 2012 (UTC)

Going to mw: seems inappropriate, for what I am questioning are Wikipedia standards applied within the Wiki software.DrFree (talk) 22:33, 19 March 2012 (UTC)

It appears from [5] and the long post that DrFree wants an anchor when the "main text" starts after any hatnotes, message boxes, infoboxes, images and whatever. That would be difficult to determine for mw. A possible combined editor/mw solution would be that editors could place an anchor with a standardized name like "lead", and if mw detects there is no such anchor on a page then mw automatically makes it at #mw-content-text right below the pagename and tagline. I don't know how much such a feature would be used in practice. PrimeHunter (talk) 02:39, 19 March 2012 (UTC)

All I am really asking is for a more permissive attitude towards anchors. In general it is difficult to anticipate where in an article an author might want to point. The only special place that perhaps needs an automatic anchor is the lead paragraph, which the MOS requires to have both the topic title and a concise definition or explanation.DrFree (talk) 22:33, 19 March 2012 (UTC)

No. While you may want anchors in articles at certain places for your website, other people may want anchors at different places for their websites. How would that benefit the encyclopedia? Articles are not formatted for the convenience of external websites without very good reason (I am unaware of any such cases, although there are some attempts to put some metadata, for example WP:Persondata, in articles). Anchors are for linking one Wikipedia article to another. Johnuniq (talk) 10:06, 20 March 2012 (UTC)

Such a slippery slope is far-fetched, but the benefits to the encyclopedia are obvious: the ability to reference particular items of information, rather than whole pages or just the predefined sections, would make Wikipedia the natural collection of background information to be referenced by web sites doing the original research that Wikipedia eschews. It would become an integral part of the world wide web of information, not a mere, self-contained island. DrFree (talk) 15:46, 20 March 2012 (UTC)

If there is value here, then the anchor should be applied to every article, not just a select few. I checked, but don't see this listed, so file a software enhancement. ---— Gadget850 (Ed) ^talk 10:54, 20 March 2012 (UTC)

Separating the general question of allowing editors to insert anchors where they find them useful, from the question of anchoring the lead paragraph, it would appear that this is not a software enhancement, because it is based on an internal Wikipedia standard which assigns special status to a particular sentence: MOS: Lead paragraph: First_sentence, which is precisely where external glossary references would normally want to point. If the software could be made to recognize and anchor that internal Wikipedia standard, that would be great, but such an enhancement is unlikely in the near term. Hence my current request is merely to be able to anchors to first sentences without their being removed by over-zealous editors.DrFree (talk) 15:46, 20 March 2012 (UTC)

I agree that random creation of anchors by editors at arbitrary points is different than a sistematic anchoring of the lead paragraph, and that creating an automatic anchor for all the leads is a good thing. That said, this should be created by modifying the software so that all pages (or none) get this enhancement. Manually creating anchors for the particular pages you want to reference from an outside site is a terrible idea, it would require a massive clean up work when/if a better way to link to the lead is ever implemented. Your better option is to submit the feature request, maybe recruiting the help of Wikipedia talk:Semantic Wikipedia or some other interested wikiproject. Diego (talk) 16:18, 20 March 2012 (UTC)

So the situation appears to be: (1) The first sentence of an article is important enough to have very special standards applied to it by the Manual of Style. (2) Those very standards make it an attractive point of reference to other web sites, both within and without Wikipedia. (3) There is no syntactic marker which designates the first sentence. (4) Because there is no syntactic marker, there is no way for software to create an automatic anchor. (5) Software magicians might someday overcome this insuperable difficulty. Therefore (6) anchors to the first sentence won't be allowed because they might interfere with some future magic trick. It appears that the much heralded "democratization" of information that was to be the hallmark of Wikipedia has devolved into a politburo of self-appointed bureaucrats intent on vetoing proposals that they themselves don't directly benefit from. Shades of the Soviet Union! DrFree (talk) 19:05, 20 March 2012 (UTC)

Facepalm

First, you're not helping your cause by being so insulting. This isn't something to be fixed here on en.wikipedia. Manually adding html anchors to specific pages is just bad form, and would lead to frustration & confusion when someone tries to link back to a page where they're not implemented. It would require a code-change to apply to all articles, which means you should file via the bug reports & feature requests system. — The Hand That Feeds You:^Bite 20:07, 20 March 2012 (UTC)

If you want those anchors so badly, why don't you just download your own copy of Wikipedia and edit it to your heart's content? It is free content after all as long as you comply with the license (you're showing proper attribution and licensing, right?), and it occupies only about 8Gbs (much less if you trim all articles to just their lead, and a trivial weight for the few articles that you could tag by hand). Why request -no, demand- that the whole project accommodate to your needs, when you already have been given permission to do as you please - at your private space, without interfering with others? ("Soviet Union", indeed). Your proposal here looks like an over-engineered solution to a non-existent problem. Diego (talk) 21:50, 20 March 2012 (UTC)

Hey guys

After suggestions on the New Page Triage discussion page, we've opened a Request for Comment on adding the NOINDEX tag to unpatrolled articles - basically ensuring they can't be syndicated by google. If you've got an opinion or any comments, head on over there and post your two cents :). Okeyes (WMF) (talk) 13:07, 20 March 2012 (UTC)

I noticed that several pages on the List of Internet phenomena do not have links to their own articles, while others do. Now don't get me wrong, I'm not the kind of guy who would request a Wikipedia article on every single tree, root, and blade of grass, (I'm not sure if I completely know the phrase) but these pages, in my opinion, (and I think that soon we will get the opinions of other fellow Wikipedians), should be redirects to their sections in List of Internet phenomena. Anyone support me?

--Walex03. Talking, working, friending. 00:47, 21 March 2012 (UTC)

You'd have to challenge each article one by one. If a discrete phenomena article meets notability then it is legitimate for the article to remain as is. There are many list pages that shell out into discrete articles. So no, no support from me for a blanket "should redirect to the list page". --Tagishsimon (talk) 00:55, 21 March 2012 (UTC)

(edit conflict) I support the addition of any article which meets our criteria for inclusion. If the articles not linked from the article you mentioned don't exist, and they meet our criteria, then I support their creation. If someone wants to create redirects for the items in the meantime, until the articles get created (if they do), and the redirects meet our criteria, then I support that too. Anyone who doesn't want to (or can't) create the articles themselves can, of course, use Wikipedia:Articles for Creation. I don't, however, really see what the "proposal" is here. All of these actions are standard, and possible already. Sorry if you meant something else, but if so, I'm afraid I don't understand. Begoon ^talk 01:00, 21 March 2012 (UTC)

Well, no, what you should be doing (or what the community should be doing), is analysing whether that article needs to be pruned. Some phenomena come and go, others remain. It's not for Wiki to record everything that gets posted on Reddit. Frankly, making geeks feel good about themselves is not how the project should continue. I'd be happy to cull almost everything in that article; we're not supposed to be a directory service, after all. doktorb _words^deeds 02:37, 21 March 2012 (UTC)

That's also a very fair point. I was trying to avoid the details of the article and respond in general, because I don't think this is the right place to discuss a specific article, but, in the context, yes, we are not a directory of internet memes, and, while they should be subject to the same sourcing and notability requirements as any other content, there are additional considerations, obviously. There do seem to be a number of doubtful entries in that list - which are certainly not things that are "memes" as I understand the term, in the sense of their not being in any way pervasive. I'll offer one thought that may or may not be useful - when judging these items for inclusion, notability, verifiability etc. are not, in themselves enough. The criterion which are being used to define something to be a "meme" are obviously crucial, and maybe some entries have not been subjected rigorously enough to that "test" - merely being notable and verifiable isn't enough. That's a discussion for the Article talk page, though. Begoon ^talk 03:15, 21 March 2012 (UTC)

By the way, would a more appropriate place to discuss this one than here be at the the talk page of List of Internet phenomena? Incidentally, I wonder whether the phrase that the initiator of this proposal was seeking was "paraphernalia". ACEOREVIVED (talk) 09:08, 21 March 2012 (UTC)

Yes, sorry, I should have been more clear - I linked my post now. Begoon ^talk 09:25, 21 March 2012 (UTC)

Wikipedia is in danger of growing stale. We need to take it in a new direction. NUMBER ONE) I propose we redesign the Wikipeia globe logo. The new logo should be of at best questionable improvement upon the current logo but should be rendered in full 4D. A panel of international editors should be formed and each letter nominated for inclusion should undergo a thorough review process. It shall be possible to find no fewer than 10 mistakes in the final set of letters. The new logo shall be colorful because color monitors and printers have now been developed since the last logo was made. NUMBER TWO) The Vector skin has started to feel soooo 2009. I propose we create a new skin that feels more modern and relies even more heavily upon recently introduced CSS elements. Almost the entire browser market now properly supports the CSS used in Vector and interactive elements are almost acceptably fast. Clearly, we are lagging behind. It's time to push Wikipedia into the next decade. Been too long since change occurred. who's with me? Jason Quinn (talk) 03:10, 21 March 2012 (UTC)

• For one thing, I think the best replacement for Vector would be something a lot more colorful. However, I don't know if the Wikimedia Foundation can afford the server resources necessary to serve up fancy CSS, etc.Jasper Deng (talk) 03:15, 21 March 2012 (UTC)
• Not me. Perhaps you have four dimensions in your universe, but I don't in mine. Malleus Fatuorum 03:41, 21 March 2012 (UTC)
• Even though this is clearly a joke, I'm totally on board. Equazcion ^(talk) 03:46, 21 Mar 2012 (UTC)

This section contains material that is kept because it is considered humorous. Please do not take it seriously.

--Cybercobra (talk) 03:45, 21 March 2012 (UTC)

• 4D? If we're going to be making changes, I can't support anything less than 5D. 28bytes (talk) 03:51, 21 March 2012 (UTC)
• Call me a luddite, but I am a 2D man. – Allen4names 07:13, 21 March 2012 (UTC)
• Hmmm... Extra dimensions, with somewhat unsupported CSS? Sounds like a good idea to me......
  Is the original puzzle ball colorful enough? I can't imagine it would be too hard to add a couple extra dimensions to it, and more importantly, it has the advantage of having helpful mixed-Russian-Japanese redlinks. (By the way, it seems that the WMF actually does have plans to switch over to a new skin, called Athena, at some point.) --Yair rand (talk) 08:29, 21 March 2012 (UTC)

@Yair rand. Thanks for the heads up on this. Didn't know. I'm in the middle of watching the video conference about it. I was quite annoyed to hear it said that the future of the desktop is dead. So many projects seem to be taking this literally. At some level this "prophesy" will be self-fulfilling if vendors and organizations simply stop developing for the desktop and cause users to leave. This "let's bet the farm on mobile" type thinking is dangerous. Look at KDE 4 and GNOME 3, those are both projects where it is obvious that mobile and tablet-orientated thinking caused them to derail. I worry that mobile fever has infected the WMF. That said, I'm kind of liking Harris' design. I'll be anxious to see more. A good user interface tends to transfer from one platform to another with only minor tweaking. Maybe Harris' design your design (!) whoever's design will work well on the desktop too. We'll see. Jason Quinn (talk) 18:28, 21 March 2012 (UTC)

Um, what? It's not my design... --Yair rand (talk) 00:43, 22 March 2012 (UTC)

Sorry. I noticed your Athena Prototype while watching the video. I hastily edited the message thinking I had made a faux pas under the false assumption thinking you had something to do with it. I quickly realized I was in error again but got distracted and forgot to come back and fix the remark. Probably the work of many people, I guess, but maybe Harris is main designer. Don't know. Sorry for the confusion. Jason Quinn (talk) 00:50, 22 March 2012 (UTC)

The logo I can agree on, everything else no. Logos and identity have moved on a lot, things are much more streamlined and minimalist. So if there's going to be another year-long vote/debate/argument about the logo, count me in doktorb _words^deeds 18:49, 21 March 2012 (UTC)

Hi. I have been thinking of this for quite a few days. Why not maintain a shortcut for User and User talk pages? User talk pages should begin with UT:USERNAME, and user pages with UE:USERNAME. Dipankan says.. ^{("Be bold and edit!")} 05:48, 21 March 2012 (UTC)

Why UE? — Isarra (talk) 06:51, 21 March 2012 (UTC)

See also Wikipedia:Perennial proposals#Create shortcut namespace aliases for various namespaces. —  HELLKNOWZ  ▎TALK 08:51, 21 March 2012 (UTC)

UT has been proposed and shot down before. Check the archives. I too wish we had UT. --Cybercobra (talk) 08:52, 21 March 2012 (UTC)

User pages should begin with UE as US:USERNAME makes me feel of a user coming from US and such. Dipankan says.. ^{("Be bold and edit!")} 10:34, 21 March 2012 (UTC)

UT might be useful, I agree. UE only saves 2 characters, which is not worth the trouble, in my opinion - I'm still a bit confused about the 'E' too… However, as HELLKNOWZ points out, this is in the Wikipedia:Perennial proposals which means it's been proposed and discussed several times before. That doesn't mean you can't propose it again, but it does mean you should check what the previous objections were, and preferably include rebuttals for the common objections in the proposal, so that the same objections don't need to be debated again. Begoon ^talk 10:48, 21 March 2012 (UTC)

I don't know if this is the right place to submit this but I think it would be beneficial to add some way for people to submit a suggestion to change something. There is already a process for people to submit an article but not an individual change and I think this could be very useful. — Preceding unsigned comment added by 138.162.8.58 (talk) 18:59, 21 March 2012 (UTC)

You could either do it on your own; or you could suggest a change at the talk page of the article! mabdul 21:04, 21 March 2012 (UTC)

This is the encyclopedia that anyone can edit, in most cases, by clicking the "edit" tab at the top of the article or section you want to change. In some cases, however, you will find yourself unable to edit an article, since it may have been protected. In this case, do what Mabdul suggested and request a change on the article talk page, which you should be able to edit with no problem. dci | TALK 02:47, 22 March 2012 (UTC)

@138.162, You can use {{Request edit}} to request a change to an article you don't want to edit. You can use {{Edit protected}} to request a change to a protected article. Both of these are used on the article's talk page. 64.40.61.74 (talk) 10:35, 22 March 2012 (UTC)

Also, you can use the Wikipedia:Article Feedback Tool which contains the functionality requested (currently in testing, so it's not yet available at all pages). Diego (talk) 10:46, 22 March 2012 (UTC)

The user scripts listing page at Wikipedia:WikiProject User scripts/Scripts is in dire need of cleanup. To facilitate this, I created a new draft listing at Wikipedia:WikiProject User scripts/Scripts cleanup. All are invited to list scripts known to be currently working and relevant. If/when the list seems reasonably complete, we can deprecate the old listing and move this one in (though keeping and linking to the old one as a more exhaustive list of all existing scripts). Please share any thoughts on this. Thanks. Equazcion ^(talk) 00:35, 25 Mar 2012 (UTC)

Hello,

Can we create an official wikipedia skype account ?

Pro:

- audio conference

- discuss, interact

- wikiprojects coordination

- task force coordination --Tegra3 (talk) 05:36, 24 March 2012 (UTC)

Nope. Prodego ^talk 05:38, 24 March 2012 (UTC)

• Oppose - Something makes me think you proposed this before. Wikipedia won't get itself closer to being a social network. Besides, Skype does not work that way.Jasper Deng (talk) 05:40, 24 March 2012 (UTC)
• Have a look at WP:MUMBLE. Peachey88 ^{(T · C)} 06:07, 24 March 2012 (UTC)
• Wikipedia:Mumble is a much better solution for the proposed uses, and is open-source. Dcoetzee 01:17, 27 March 2012 (UTC)

When we added the "V • T • E" links to the {{navbar}} template, we broke a cardinal rule of interface design: Only show interface elements to the people who need them. For the vast majority of Wikipedia readers, the mysterious "V • T • E" letters in the corner of every navbox are nothing more than confusing clutter. Not only that, but the links also display incorrectly on some browsers and versions of MediaWiki due to how they are implemented.[11][12] We don't display such editor-centric links on other templates, so I think we can live without them in navboxes as well. What I would like to do is remove the links from the {{navbar}} template and instead create a gadget that adds the "V • T • E" links to navboxes for the people that really want them. That way editors can still have the links, but we don't have to confuse our readers with them. Thoughts? Kaldari (talk) 21:21, 24 March 2012 (UTC)

Since everybody (whether or not they have an account, or they are logged on) is a potential editor, then everybody needs to see the VTE links - otherwise, how can people edit the template or talk pages?Nigel Ish (talk) 21:43, 24 March 2012 (UTC)

The same way they edit every other template and talk page. Kaldari (talk) 22:02, 24 March 2012 (UTC)

IPs do edit navboxes, so I think there is merit for those links. It certainly is easier to get to navboxes' markup this way. —  HELLKNOWZ  ▎TALK 21:45, 24 March 2012 (UTC)

Removing the links and adding a gadget to re-add them sounds like a solution in search of a problem. The links are helpful for inexperienced editors to find and edit the templates, and the clutter is minimal. Hiding them on the mobile version might be fine (but there may be some technical hurdles that need working out first). --CapitalR (talk) 21:53, 24 March 2012 (UTC)

Sure, if they happen to guess that "E" is a link to edit the template. So maybe half of people who want to edit the template would actually use the links, and the percentage of people who want to edit the template is maybe 0.001% of the people who read the article. So for half of 0.001% of our users, it is useful, for everyone else it's just mysterious clutter. Kaldari (talk) 22:02, 24 March 2012 (UTC)

Eh, by those stats, we could also get rid of section 'edit' links and especially interwiki links. I have no idea what most of the languages are by looking at them, so perhaps we should get rid of all interwikis and use a gadget to re-add them for those who want a particular language? And very few people actually use a particular section edit link compared to how many read the article, but they're still useful to have. More seriously though, I think the benefit of the VTE links outweighs the cost (access vs. 'clutter'), and it's not hard to find out what they do (click or mouse over). And when a user does click or mouse over one, they can see how easy it is to access and edit such pages. --CapitalR (talk) 22:25, 24 March 2012 (UTC)

This is just food for thought, but maybe hide them from IP editors, and let them display by default to registered users (no gadget required)? Navboxes are UI elements, rather than article content or discussion that should be considered as part of the "anyone can edit" principle applied elsewhere. Just throwing that out there, I'd be interested to hear why or why not, though I can predict some of the responses. Equazcion ^(talk) 22:01, 24 Mar 2012 (UTC)

(Coming here from Template talk:Navbar#Getting rid of the V T E links, which has the question We don't include edit links in other templates like infoboxes, so why do we have them in navboxes?): The main reason for having v-t-e links in navboxes is because navboxes are virtually always in a separate template, and they provide the means for accessing that template's talk page or for editing it. There are rarely v-t-e links in infoboxes because the infobox is almost always in the page itself, so you use the normal edit links for the page.

Regarding if they happen to guess that "E" is a link to edit the template - the {{navbar}} template generates tooltips "View this template", "Discuss this template" and "Edit this template" shown when you mouseover the links. --Redrose64 (talk) 22:36, 24 March 2012 (UTC)

It's precisely because they aren't contained in the current page that I'm thinking there's reason to consider this (not inviting navbox edits from "just anyone"). It's relatively easy to make a mistake, intentional disruption, or controversial change affecting lots of articles. And those changes won't be detected as easily, since generally they won't be showing up in watchlists for people who edit articles where they're transcluded. Relatively few people actually have navboxes watchlisted, and the rest would need to catch errors visually. Equazcion ^(talk) 22:46, 24 Mar 2012 (UTC)

What your proposing would have the same effect as semi-protecting the whole of template space, with the downside that experienced vandals can circumvent it easily by going to the template page directly. We already protect way too many templates because they are "high risk", I would definitely oppose something like this. Yoenit (talk) 15:08, 25 March 2012 (UTC)

This proposal relies on two flawed assumptions: That all non registered people are not interested in editing, and that all non registered people don't understand how the templates work. Both are obviously incorrect. There are many non-registered editors who make use of the ability to edit templates (eg: {{Colorado Avalanche roster}}). I see this proposal as a solution that lacks a problem. Resolute 15:41, 25 March 2012 (UTC)

I concur with Resolute, this is the encyclopedia that anybody can edit. We already discriminate against anonymous users enough, no need to take it further, especially given there's no pressing reason to do so. Snowolf ^{How can I help?} 19:16, 25 March 2012 (UTC)

I likewise oppose. I occasionally edit templates when logged out (when on public computers, and I don't have the time to log into my account for use on public computers), and removing these links would make it rather inconvenient. In reality, this proposal is backward: if we remove the links from anyone, it would be better to remove them for logged-in users, since they're more likely to know how to find the template page before editing it, while non-logged-in people are more likely to be unable to find the template and consequently be confused why they see a big box when the code is simply {{template}}. Nyttend (talk) 14:43, 26 March 2012 (UTC)