Wikipedia:Village pump (proposals)/Archive 83

• Village pump
  • Policy
  • Technical
  • Proposals (persistent)
  • Idea lab
  • WMF
  • Miscellaneous

Village pump (proposals) archive  

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

---

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

"Intermediate revisions by one user not shown"

Here is a typical diff between the current revision of a page and a much older revision. In the centre there is that extra message "(33 intermediate revisions by one user not shown)".

I'd like this message to be tweaked to say either "by this user" if those revisions were by the user who made the top revision, or "by one other user" if those revisions were by someone else. The distinction is important if you are thinking of clicking one of the "rollback" links. In the first case, you are about to re-instate the revision displayed on the left; in the second, you are about to roll back just one edit and re-instate a revision that you can't see. -- John of Reading (talk) 08:37, 20 December 2011 (UTC)

• Support something along these lines. Took a while to think about this (off doing other stuff), but I think something along the lines of a list of intermediate editors in chronological order, displayed in a hidden (hover to show) drop down, would be useful. The idea of simply tweaking the message seems simple, but would require a lot of if's and else's. Simply showing the intermediate users in a list requires only knowing who they were. Then the user viewing the diff can see everything they need to, to make the right decision. Personally, I see a lot of over zealous use of rollback (example: to rollback one vandalism, where undo does the same job, whilst also allowing for some explanation in the summary), and think any user considering using rollback should be more fully versed in the editing history of the page before clicky-clicky fever takes over. If folks are not willing to spend a minute reading the history before viewing the diffs (which some are apparently not), at least this proposed extra info would perhaps save a few cock-ups. fredgandt 16:36, 22 December 2011 (UTC)
• Not possible without a major rewrite. Note that "one" is a count, and not designed to designate who made the revisions. If there were more then one, it would say "...by three users". What would have to be done then? List them all separately? That is already done on the history page. — Edokter (talk) — 17:01, 22 December 2011 (UTC)

I'm not proposing any change to "by three users", because in that case it is clear that the rollback buttons are not going to re-instate the version shown on the left. The only ambiguous case is "by one user". -- John of Reading (talk) 06:09, 23 December 2011 (UTC)

Add a 'Cleanup' tab to articles

I propose to move all templates such as those from WP:TC of an article to a new 'Cleanup' page. This page could be located in a new namespace, such as Cleanup:Tree for the article Tree. The rationale for this proposal is, that we have two main groups of people coming in touch with an article: our readers and our editors. The cleanup templates are primarily targeted at our editors, not at people who only read articles. Now obviously, we want to encourage our readers to be bold and fix things themselves when they see something needs to be fixed. However, a reader who is interested in a specific subject is likely to notice a shortcoming of the article without the extra 'hint' that something is wrong with the article. And of course our readers are already invited to do something to improve an article via the article feedback tool. The benefits of this proposal are:

• less clutter in article namespace
• more seriously looking articles
• a centralized place for the article listing what needs to be done, which might encourage boldness, since it will be more specific than generic cleanup templates

Such a new page could become a detailed 'To Do list' for an article independent of WikiProject specific lists in the WikiProject banners on the article talk page. This would also be useful, if an editor recognizes something in need of improvement in an article, but does not have the time to fix it right now. The main difference to an article talk page would be, that no signed comments should be made on that page in order to keep a clean appearance. Toshio Yamaguchi (talk) 16:08, 7 December 2011 (UTC)

Similar proposals have been rejected in the past. (See Wikipedia:Perennial proposals#Move_maintenance_tags_to_talk_pages) It is true that cleanup templates are more important to the editors than the reader. However, some cleanup templates, such as Template:Unreferenced, do serve as a warning to readers. Alpha_Quadrant ^(talk) 16:27, 7 December 2011 (UTC)

Let me say what I think about about the points at PEREN:

1. Is there statistical data providing evidence that readers motivation to become editors is ignited by the cleanup templates? I think many readers are motivated by errors or missing information in an article that interests them, regardless of whether there are cleanup templates or not.

2. Blindly believing something one reads somewhere (for example here on Wikipedia) is never a good idea. As a competent reader of Wikipedia, one should expect that there may be problems.

3. To be honest, this is one of the most nonsensical things I have ever read on Wikipedia.

4. True, but any substancial change has its 'cost'. And it is at least my personal belief (and please feel free to prove me wrong) that this 'investment' has a potential for an overall improvement of Wikipedias content. Toshio Yamaguchi (talk) 16:45, 7 December 2011 (UTC)

I do not believe any statistics have been taken on how the cleanup tags affect non-registered users. The problem I see with moving the cleanup tags to a separate page, is that it hides the problems with the article. If the readers don't know there is a problem, how will they be educated so that they know that the issue needs to be fixed. Some cleanup tags would work poorly on a separate page. For example, how would we address the section templates (i.e. "This section requires expansion") or the specific cleanup templates such as [citation needed]. Editors trying to track down and address the issues would need to jump back and forth between the pages. As pointed out by point four, there are about one million articles with some sort of cleanup tag and there are over 200 different cleanup tags. The massive amount of work that would be required to implement such a feature would be astronomical. A new namespace would need to be created. All of the cleanup bots and tools would need to be updated. We would need to alter the cleanup templates. Then we would need to actually go through and make the conversion. Even with a bot, that could take months to complete. If there is a problem with cleanup templates displaying for readers, it might be simpler to just alter the cleanup templates to only display for logged in users. There is a way to hide categories from users without the preference enabled. It shouldn't be too difficult to do the same with templates. Alpha_Quadrant ^(talk) 17:09, 7 December 2011 (UTC)

Regarding 'hiding problems with the article', we could include a link at the top of all articles (a wikilink pointing to the Cleanup page) saying something like

"Click here to check whether there are problems with this article"

Regarding the large amounts of work required to implement this, I agree. Whether that is a reason not to do it, I don't know. Regarding cleanup templates referring to a specific section: it should be no problem to provide a wikilink to the section in question on the cleanup page.

"If the readers don't know there is a problem, how will they be educated so that they know that the issue needs to be fixed."

This will be done by a link, as explained above. There should be a general notice such as

"Please note that many articles are still unfinished and there might be things needing improvement. Check the Cleanup page to see what needs to be improved in this article." Toshio Yamaguchi (talk) 17:32, 7 December 2011 (UTC)

Support with comments - As before I like the idea of this suggestion. A couple suggestions though.

• I do think that the templates should be placed on the article itself (they could be generated or not based on a setting set by the editor in the same way we do for Person data template).
• I do agree that there are certain templates such as Unref, Unref BLP and a select few others that would probably need to stay on the article but for the rest a cleanup (or other name) tab could be very useful and would make the articles much less noisy.
• I also think that we should refine the rules for the placement for some of these tags at the same time. For example, there are a lot of stubs that have templates like expand, cleanup, etc. on them and as stubs it rather goes without saying that a stub needs to be expanded. --Kumioko (talk) 16:59, 7 December 2011 (UTC)

• Oppose. I find the arguments at Wikipedia:Perennial_proposals#Move_maintenance_tags_to_talk_pages persuasive. Cleanup tags that are relegated to a separate page will be ignored, not just by readers but by most editors too. A lot of my cleanup gets done when I look up something just to read it and find things that need fixing. On pages I watch, it's a constant reminder and TODO. I find that removing tags is in itself one of my motivations for doing cleanup ("can finally get rid of that tag now"). And while people should not blindly believe anything they read on Wikipedia, I really believe it does a service to our readers to explicitly point out content that is problematic, so they can treat it with an even greater level of suspicion than usual. Dcoetzee 10:02, 8 December 2011 (UTC)
• Oppose per Dcoetzee. Sven Manguard Wha? 10:48, 8 December 2011 (UTC)
• Oppose We're having an RFC on this again? As far as I am concerned, nothing has changed since last time. It's the same old "I think they're ugly!" versus "They have the potential to convert readers into editors, and in a way that is more likely to lead to editor retention" debate, and I still support the latter. Anomie⚔ 12:08, 8 December 2011 (UTC)
• Oppose Clean-up notices fall into the same category as {{Citation needed}} (and similar) in one important respect; they inform readers as well as editors that the article is not perfect. This honesty adds to Wikipedia's trustworthiness. The public at large are now getting used to Wikipedia being reliable since it is fairly common knowledge that wherever we (editors) are not completely satisfied, we will say so, clearly. To hide that statement of dissatisfaction from passers by, could reverse the firm trend seen in the media and by ordinary folk, that Wikipedia is a great source of reliable knowledge (even the stuff that's wrong is labelled as being so). We should continue to flaunt our errors with gay abandon! "If we deny our demons, we give them power over us" (something like that anyway (Monkey (TV series)). fredgandt 22:07, 11 December 2011 (UTC)
• Oppose for the very convincing reasons put forth in previous similar proposals. There will never be 100% of people that agree with cleanup templates, but it's clear that a substantial majority - including myself - think they're appropriate.  Chzz  ►  10:18, 14 December 2011 (UTC)
• Oppose: the cleanup tag is placed in the article to draw attention of the passing by editors; the suggested alternative fails to accomplish that task. Furthermore, the overhead of a separate namespace doesn't correspond to the task of building todo lists, which can be done on the talk page. P.S.: Wikipedia doesn't make difference between editors and readers, and it's one of the reason of its growth. I wouldn't change that without very good reason. — Dmitrij D. Czarkoff (talk) 09:19, 19 December 2011 (UTC)
• Oppose. On new pages, I always place cleanup tags in hopes that the article's author will see them and learn how to improve the article's themselves. Sometimes it works.    Thorncrag  16:18, 23 December 2011 (UTC)

Change "My talk", "My preferences", etc to "Your talk", "Your preferences", etc

Reading on the direction the WMF is going in with the Athena skin as well as what is already implemented on other sites such as Flickr, I propose a change in terminology from "My talk", "My preferences", etc. to either "Your talk", "Your preferences", etc. or even simply "Talk", "Preferences", etc. Some of the reasons laid out on the MediaWiki page and other websites include the following:

• "My" is akin to labels being placed on objects. This goes against the fact that the website (i.e. Wikipedia) has provided people with a talk page, tweakable preferences, watchlist, etc.
• Something like "Your..." is more indicative of a two-way conversation and is not as asocially suggestive as "My..."
• It serves to discourage the mentality of page ownership, reenforcing a key aspect of open wikis in that there is no ownership of pages.
• As a more general corollary to the above point, it would distance us from individual-centric sites such as Myspace and bring us closer of sharing, community-centric sites such as YouTube.
• It's easier to tell someone to "Go to 'Your preferences'" instead of "Go to 'My preferences'".

Thoughts? –MuZemike 01:52, 18 December 2011 (UTC)

Any reason why there is a "My" in the first place? On GMail, I click on "account settings", not "my account settings". Why is this not the case here? p-personal is obviously a user-specific panel, so there is no need to make it more obvious through the use of pronouns, it seems to me like we could do without them (e.g. <userpage> | Messages | Preferences | Watchlist | Contributions | Log out)... In any case, to address the actual proposal, I don't really find the argument convincing. Asocial is open to interpretation (for example English is considered by some an asocial language for being individual-centric (e.g. by its extensive use of possessive pronouns), but that's true only if one accepts that individualism is a bad thing.) I'm not opposed to the proposal per se, but what's the concrete benefit of changing 'my' to 'your'? For example, re point 3, why should we discourage ownership of watchlist pages, which are private and user defined (therefore "owned"), or contribution pages, which are specific to a user? The only page affected here is "My talk", but we do (thankfully) give much leeway on how users manage their talk page, which implies some level of ownership. As for having conversations with a software, well... that's beyond me. But sure, go ahead, your, my, nothing, whatever. :-) CharlieEchoTango (contact) 06:50, 18 December 2011 (UTC)

"My" is the only way to convey that these pertain to the user who's viewing the page: "Your" is not specific (from my point of view, any other person is "you", but I'm not "you" to myself), and without any pronouns at all, the links don't convey the fact that these pertain to the individual user. Moreover, Charlie has a good point: WP:OWN doesn't affect what you set for your preferences or the content of your watchlist, "my talk" goes to the user talk page for the person who clicks it, and "my contributions" goes to the contributions for the user who has made them. Nyttend (talk) 13:06, 18 December 2011 (UTC)

I certainly think My expressions like 'I've said a bit more about this on your My Talk page but you open your My Preferences and ...' sound rather strange. I'm happy enough to go along with just keeping to the WMF My decision but I hope you excuse me making my fun of it every so often ;-) Dmcq (talk) 18:37, 18 December 2011 (UTC)

Except nobody actually says that. They say "my" when referring to their own, and "your" when referring to the other person's. By your rationale, it would sound pretty weird to say "I replied to you on my Your Talk" ;-) -MsBatfish (talk) 19:52, 21 December 2011 (UTC)

Talk about priming, I just saw a notice saying please present your myWaitrose card before payment! Dmcq (talk) 19:28, 22 December 2011 (UTC)

Seems to me to be change for the sake of change. If "My" is not considered appropriate as it implies (to heavily) ownership, surely something like "User preferences" and "User talk" would make more sense. If I give something to someone and say "This is now yours", I expect them to feel a sense of ownership of the gift. Playing with words for no practical gain is a waste of time. If this were a technical fix, I might support it. fredgandt 19:22, 18 December 2011 (UTC)

If/when Athena arrives, we can change things. Until then, as Fred Gandt says, this is change for change's sake. —Tom Morris (talk) 09:28, 20 December 2011 (UTC)

Have to agree with Tom and Fred here; this is not a needed change. I really don't think anyone has ever been confused by someone saying "Go to your preferences" only to see it's labelled as "My preferences". It would likely be more confusing the other way around, to have to say "Your talk" when referring to one's own Talk page - ie " replied to your post on your talk page" - which one am I referring to: my own, which would be labelled "Your Talk" or the other person's, which would also be labelled "Your talk"? Currently we just say "my talk" when referring to our own, and "your talk" when referring to someone else's. Having no possessive labels at all ("Talk"/"Preferences", or even "User talk" etc) would be even more confusing, especially for new users. I just don't think the current system is broken. And I really don't see how switching from "My" to "Your" would decrease the instance of WP:ownership. -MsBatfish (talk) 19:52, 21 December 2011 (UTC)

Personally what I keep wishing for is an easy way to access other editors' Contributions and Watchlist. I'm not "spying" on anyone, but if I have a question about a topic and am thinking of posting on an appropriate editor's talkpage, it's very helpful to know where that editor's interests and presumed expertise lie. My experience has usually been that hardly anyone ever looks at the talkpages for articles, and questions or comments posted there can go without any response seemingly forever. It's much more effective to post directly to a specific editor, if only one can figure out an appropriate editor to look to. Milkunderwood (talk) 03:26, 23 December 2011 (UTC)

Watchlists are protected by privacy. See Help:Watching pages#Privacy of watchlists. PrimeHunter (talk) 04:13, 23 December 2011 (UTC)

Thanks - I suspected that might be the case. However, I've occasionally been able to access another editor's contributions, but can never remember from one time to another how I managed to find them. Milkunderwood (talk) 05:08, 23 December 2011 (UTC)

All contributions are at Special:Contributions/Example. Simply replace Example with the name of the use you want the contribs of. fredgandt 05:35, 23 December 2011 (UTC)

Or if you are looking at a "User:" or "User talk:" page, there's a "User contributions" link in the toolbox at the left (at least in the default Vector skin). -- John of Reading (talk) 06:06, 23 December 2011 (UTC)

Yes, thanks very much - it's the Toolbox -> User contributions that I've been looking for. If I have a question, I first look for editors who have contributed to either an article or its talkpage, and only then want to see how interested any particular editor seems to be in the topic, so that I'm not bothering people unnecessarily. I hadn't been aware of Fred's suggestion at all, so that's also useful to know. Milkunderwood (talk) 07:43, 23 December 2011 (UTC)

Major London Underground Stations

Basically a template like Template:Major Railway Stations in Britain, only for London Underground stations. It would include Bank-Monument station as such and many other underground stations that see amazing use or hold many lines. Tez011 (talk) 17:53, 23 December 2011 (UTC)

Perhaps something that would be better brought up at Wikipedia talk:WikiProject London Transport. the wub "?!" 18:16, 23 December 2011 (UTC)

Notate file pages with they articles they have been used on

Originally titled File:DSCF1548.JPG.

There are an amazing number of pictures that get uploaded to WP, with no (or poor) descriptive text, with ambiguous names, and the uploader disappears forever. Almost every single time an image is uploaded, the uploader edits an article to add that image, often with a descriptive caption or edit summary. Years go by and somebody edits the article so the image is no longer linked, the author is gone, so we now have no idea what the image is of. Sometimes the linked article is deleted so even the edit history is useless to regular editors. These images get deleted all of the time.

I am proposing we have bots add this information to the file pages, so that even if it is not currently being used, we will at least have descriptive text and know what article someone thought it would be useful for. I recently spent several days moving hundreds of images that were in this situation. I had to go through the uploader's edit history, sometimes I would just guess (the worst guess I had to make is now called File:Possibly Ecuador.jpg). Adding this information to the file pages would save so much time and effort. Specifically I am proposing two things:

1. We run a bot that adds these tags as the file is added to the article. The information will be the User name, article and section heading the file was added to, edit summary of the addition (if one was provided), and caption (if one was provided).
2. We run a bot for existing local images (starting with orphaned images), scraping info from histories.

For free images, this will make them a lot more useful when they are moved to Commons. Also, it might be a good idea to put this info in a collapsed template, so the page won't be cluttered, but the text will still hit searches. If this idea meets approval here, I will take it to bot requests. ▫ JohnnyMrNinja 04:17, 20 December 2011 (UTC)

Update: A bot is now being worked on to complete this task, see Wikipedia:Bot requests/Archive 44#Bot to notate local file usage. ▫ JohnnyMrNinja 12:47, 24 December 2011 (UTC)

• This sounds like a good idea to me. It would be very hard to search histories for unused images. Graeme Bartlett (talk) 10:50, 20 December 2011 (UTC)
• Sounds brilliant! Sven Manguard Wha? 03:25, 21 December 2011 (UTC)
• Yes. Now! ~~Ebe123~~ → report on my contribs. 13:30, 21 December 2011 (UTC)
• Strong support! Should also include the diff in which it was inserted, because often uploaders use a descriptive caption in the article that gives more information about the image. I'd also put this on the talk page so it isn't front and center (potential vandalism etc, plus no real use having this visible to casual users who presumably won't be stumbling upon orphaned images anyways.) Calliopejen1 (talk) 18:58, 21 December 2011 (UTC)
  • As I mentioned above, I think putting the info in a collapsed template on the file page is the best idea, so casual readers wouldn't see it anyway. Most people forget that files have talk pages, because they are so rarely used. Putting this text there would also prevent the text from helping during File: namespace searches, and would also make WP:moving to Commons more complicated (the text may not even be noticed and the file page will be deleted when the file is moved). ▫ JohnnyMrNinja 22:51, 21 December 2011 (UTC)

Allow interlanguage links to Commons for non-article space pages

Interlanguage links from Commons to en: work perfectly well, yet going the other way (e.g. the link [[Commons:Commons:Village pump]]) merely produces an inline link: Commons:Commons:Village pump. Is it possible to enable this as a functionality? It wouldn't be acceptable for article pages, as the equivalent namespace in commons is reserved for galleries, and we have {{Commons}} for that, but would be useful for user pages, templates, possibly categories etc. There would be problems where these inline links already exist, but it should be possible to resolve these by getting a bot to add the necessary colon at the start of the link. Any thoughts?  An optimist on the run! 08:42, 23 December 2011 (UTC)

Support, Interlanguage links should be going both ways. However I would also allow that in the article namespace. I know we have {{Commons}} and {{Commonscat}}, however they are not always equivalent to interlanguage links, since one can add them for to individual sections of a big article or have links from photographers article to a category of photographs by a photographer, etc. Most interwikilinks from commons are from Commons categories to wikipedia articles. I do not see it as a problem to link back to the categories. --Jarekt (talk) 21:15, 23 December 2011 (UTC)

Support. I've been thinking about this lately as well. I work with categories a lot on Commons, and bi-directional linking between articles and the topic category would be quite handy. The local "Commons" and "Commons category" templates should not be affected by this proposal, as they perform a different kind of function. — Huntster (t @ c) 22:06, 23 December 2011 (UTC)

• This seems like it would cause more chaos than usefulness. Killiondude (talk) 09:35, 24 December 2011 (UTC)
• It would be awkward having Commons linked under "Other languages". Perhaps if there were another portlet called "Other pjojects", but that means having to adapt the software. — Edokter (talk) — 11:59, 24 December 2011 (UTC)
• This is an old request. See bugzilla:708 (vote for it if you have a bugzilla account). Helder 12:33, 24 December 2011 (UTC)

A writer's assistance program

There must be many people out there who have much knowledge about something but are scared away from contributing because they have problems trying to use a computer (yes these people still exist), are scared off by the wiki syntax or the many policies and guidelines. So rather than having them try and fail at creating a Wikipedia article by themselves we might have a pool of volunteers taking article suggestions by e-mail, checking them to see if they can fit in and seek reliable sources for them (this can be undertaken by yet another volunteer). I think even Articles for Creation may be too difficult, there are many pensioners who haven't gone beyond the typewriter yet have valuable knowledge to offer. So we could have a writer's assistance program rather than just sticking confusing tags on articles, which often are never fixed. S_peakF_ree ^(talk)_(contribs) 05:27, 25 December 2011 (UTC)

See Wikipedia:Adopt-a-user and Wikipedia:Article wizard and Help:Contents.

—Wavelength (talk) 05:58, 25 December 2011 (UTC)

Binding content discussions

I table a proposal to the Wikipedia community that I hope you will support. Since May, I have been rather active in attempts to reform the dispute resolution processes. Back in June, I proposed the creation of the dispute resololution noticeboard, which has been reasonably successful in its aims to provide an open style of addressing content disputes.

Since then, I have been working on a few other ideas. While I want to come up with a way to tackle POV pushing, my current proposal is Wikipedia:Binding RFCs, a method for resolving intractable content disputes. The proposal explains how the process would work, but in essence, it's a two part discussion which would be closed by three users, an admin, a user experienced in the subject area, and a user experienced in dispute resolution. I envision the discussion structure would somewhat resemble the recent RFC on the verifiability policy, but with some changes, part one of the discussion would only be to present evidence in favour of X proposal or Y proposal (policies, reliable sources, past precedent etc) and the second part being an AfD styled discussion, with comments weighed depending on strength of argument.

I'm happy to answer any questions relating to my proposal and clarify any details. I feel the proposal page itself explains how the process would work, thus I have not rehashed it here. I think that this differs as opposed to other binding content proposals because it puts the power to resolve these issues in the hands of the community. I encourage comments on this and hope this is something the community will support. Regards, Steven Zhang ^{Join the DR army!} 07:14, 21 December 2011 (UTC)

Essentially, an editorial board staffed by the DR people? That's not putting decisions in the hand of the community, that's putting them in the hand of a cabal. Now there is nothing wrong with decisions being made by cabals (every area has its regulars)... but binding ones? Dangerous stuff. Binding decisions, if they should ever be taken, should only be taken by people vetted by the community as a whole. There is already an arbitration committee for handling "binding" decision; and no, I don't think we need an editorial committee to rule over actual content. This is not the idea I have of a wiki, and definitely not the one I have of Wikipedia. CharlieEchoTango (contact) 07:34, 21 December 2011 (UTC)

I think you completely misread my proposal. At the moment, AfDs, RFCs and many other discussions are closed by admins. This proposal would not create a cabal at all. It would mean that instead that three independent users would close the discussions, as opposed to one. The suggestion of a user experienced in th area (say a WikiProject participant of the topic) may be able to add perspective, and a user experienced in DR would help ensure that other venues of DR were tried first. There could be a requirement for these users to be admins, though I note a few discussions that were closed by non-admins well (ie the Ireland article names RFC a month or so ago). But I want to emphasize this is not a creation of a new content committee, I agree that's a bad idea. Steven Zhang ^{Join the DR army!} 08:16, 21 December 2011 (UTC)

Hmm, yes I did indeed misread the proposal. Disregard, and apologies. CharlieEchoTango (contact) 16:25, 21 December 2011 (UTC)

• Comment' - While I'm very much in favor of reining in and, if necessary, eliminating POV warriors, I'm not sure that a draconian device such as this advertised on obscure noticeboards populated by certain sorts of WP volunteers is the answer. I've seen too much of the drama board lynch mob mentality around here. Ultimately this should be the function of our elected representatives, ArbCom. That they seem to have no taste for "resolving content disputes" (even though they, in practice, do exactly that) is part of their own group failing, in my view. They need to work faster, to seek less massive and often irrelevant testimony, and to be more aggressive topic-banning POV warriors off their treasured battlegrounds. I'm not saying that binding content rulings is a bad thing, I just don't trust the precise mechanism you propose to deliver fair and well-considered results. Carrite (talk) 17:09, 21 December 2011 (UTC)

• Ya know, part of th problem with many current discussions is a lack of knowledge by the community that they exist. I would think that using watchlist notices advertising the creation of a binding discussion would attract the attention of more editors than something like an AN thread. I also do think that having three closers will deliver a more balanced result as opposed to just one closer. That said, we won't know unless we try. I've in fact been discussing this with arbitrator Casliber as an alternative to Remedy 5.1 of the Abortion case, as I feel it would be a good test case, but realise this process needs to get the support of the community first. Thus, I am asking for the support of the community. If the test case goes well, then great. If it crashes and burns, then at least we know it doesn't work, but we won't know if we don't try. Steven Zhang ^{Join the DR army!} 19:44, 21 December 2011 (UTC)

• Comment: Getting warriors out would be a user issue, so Arb, right? So I would support but for content disputes, with nothing about indevidual users. ~~Ebe123~~ → report on my contribs. 21:19, 23 December 2011 (UTC)

Multilingual search results for registered Wikipedians.

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

---

RfC tag added on 23:59, 23 November 2011 (UTC).

Proposal: Enable users who have registered Wikipedia accounts to receive search results from multiple Wikipedias automatically.

Synopsis: Single language search is the wisest decision for the majority of users, but multilingual search results are incredibly useful for multilingual users, allowing them easier and more reliable access to information.

Cons against multi-language searches: Currently, there is a fairly fast and effective way to search for items in a language other than the wiki a user is visiting. By typing in the country prefix at the beginning of a search, we can navigate to a page that is not on the originating project. This is a smart balance between usability and technical performance when considering the average usage of the Wikipedias. For most users, the side language options in an article and the ability to specify a country prefix are more than enough options for effective information gathering. On top of that, it would be horribly inefficient to force the server to crawl every language whenever an anonymous user searched for something. It would also be hard on the servers to attempt to detect a language for each search call. Searching every database for a single item would be a Herculean task to perform even once, and the time it would take to do such a comprehensive search would severely detract from a usability standpoint. Although I am currently unfamiliar with Lucene, I am under the impression that a single call is made to a language's index when a search is made. The functionality of the searching and the availability of individual wikipedia language stats suggest that the articles reside on separate indexes. If this is the case, to find articles in multiple languages would require multiple searches to be made for a single request. This would also be a very large no-no from a performance standpoint if there were a large amount of languages being searched by a significant amount of active users.

Pros for multi-language searches: For articles that exist in both the language of the original search term and in the originating wikipedia's language, the user will most likely be redirected to the originating language version of the article. This is certainly a simplified explanation, as one might end up on a disambiguation page for that word. For example, if one searches for 愛 in the English Wikipedia, that user will be served with Love. Searching for Amore(Italian for love), however will redirect you to a disambiguation page for Amore. That page provides a link to the English article for love. It should be noted, however, that neither search will allow you to immediately reach the existing articles for love in the languages in which they were searched. It would be necessary to reach the article in the language of the wiki first before clicking on the language sidebar. This is acceptable, but not as user-friendly as it could be.

The above only relates to searches that involve articles that represent the concept in the searching wiki's native language. If a user creates a basic search for an article that does not exist in the language of the wiki being searched from, then the results page will display nothing. If one searches for the Japanese celebrity 温水洋一 (Yōichi Nukumizu) in the English wikipedia, it displays nothing. If you search for the romanization of his name, there is still no link to the Japanese article, but there are suggested articles that contain his name. As there is no article in English at the moment which talks about this person, there are much more limited search results on the English Wikipedia. This makes sense if the person doing the search doesn't understand Japanese, which would be understandably assumed about most users on the English Wikipedia. This isn't a valid assumption for users that explicitly specify that they would like to be unified with both the Japanese and English Wikipedias.

There will be much fewer users who unify their accounts with multiple languages. Therefore, the load would be significantly less taxing on the server to search those unified languages for a single search term.

Possible Solution: A registered Wikipedia User can specify whether or not they wish to receive search results from multiple languages. This option would be disabled by default. If this is still not a large enough limit, we could require the user account to be unified with the languages they selected.

For performance issues, I would recommend that by default when a user opts in to this functionality, all searches would be performed as they currently work. Therefore, if multiple languages have articles for the same concept, the user would be served with the page on the Wikipedia that was originally queried. Only when no result was found on that Wikipedia would there be a search for the other languages that had been opted for. If the user wishes, however, they could specify that they wish to given a choice of articles in the languages for which they opted. This would require some new functionality. The new manner of search could be done in multiple ways. If an Article exists on the language of the Wikipedia being searched, it could check for a corresponding interlanguage link and display all relevant choices from that information. This would save resources as there would be no need to search for a second time. Another option would be to run a separate search on the wikipedias opted, so that if an article exists in language, but has yet to receive an interlanguage link, the information won't be lost. Either way, I'll leave that up to people who are in charge of the technical matters and who have much more experience than myself. I'd think that it would be best to combine the two. If an interlanguage link exists, give those choices, if it doesn't exist for one of the languages opted for, make sure to search that language explicitely. This would also be a good way to find and report articles which should related via interlanguage links!

Example process flow for the various ways a search could be handled depending on the type of user:

anonymous Wikipedia user or registered user who has not opted for multilingual support:

(no change from current method)

registered Wikipedia user who has opted in for both ja.wikipedia and en.wikipedia support without specifically wishing for a choice of articles in both languages:

searches from en.wikipedia.org for “愛” -> en.wikipedia.org runs search in the current manner -> redirects user to Love. (no change from current method)

searches from ja.wikipedia.org for “愛” -> ja.wikipedia.org runs search in the current manner -> redirects user to 愛. (no change from current method)

searches from en.wikipedia.org for “温水洋一” -> en.wikipedia.org runs search in the current manner -> no results found -> runs a search for “ja: 温水洋一” -> redirects user to 温水洋一

registered Wikipedia user who has opted in for both ja.wikipedia and en.wikipedia support and specifically wishes for a choice of articles in both languages:

searches from en.wikipedia.org for “愛” -> en.wikipedia.org runs search in a new manner -> gives choice of both 愛 and love

searches from ja.wikipedia.org for “愛” -> ja.wikipedia.org runs search in a new manner -> gives choice of both 愛 and love

searches from en.wikipedia.org for “温水洋一” -> en.wikipedia.org runs search in the new manner -> no results found. runs a search for “ja: 温水洋一” -> redirects user to 温水洋一

Thanks for reading! I hope you think this is a worthwhile idea and look forward to your ideas. Also, I apologize for the informal nature of this proposal. It's my first wikipedia page and I'm just a dumb art student. Subcogitate

• Oppose: We've considered it before, but most people don't know all the 20+ languages Wikipedia uses. One word in one language can mean something else in another, so users could get misinformed. I don't think it's worth the increased server latency. By the way, this is not a unique page - see Wikipedia:Your first article.Jasper Deng (talk) 23:42, 19 November 2011 (UTC)
• ---Thanks for the feedback! If you notice, however... My proposal doesn't say anything about searching all the languages. Just ones that the users select. You might want to reread the entire article and gain a better understanding of what I am suggesting. Also, you are right about this not being a unique page, so thanks! :) Subcogitate
  • I like the idea, but there are a few things that need to be sorted out (logistics).Jasper Deng (talk) 04:04, 21 November 2011 (UTC)
• Nice idea. Well considered and presented. I'll think about it a bit before deciding one way or another though. First impression is that it could be a boon for those who speak multiple language to more quickly find matches across all Wikipedias. fg 01:43, 20 November 2011 (UTC)

• Previously proposed umpteen times, it is languishing at Bugzilla unloved and uncared for at https://bugzilla.wikimedia.org/show_bug.cgi?id=1837. Fences&Windows 00:59, 22 November 2011 (UTC)

• -- It's nice to see people hoping for the same thing. The title of that bug is "search all languages" which is a bit different from what I'm suggesting... If that's not what the bugfix is supposed to do, then maybe it needs to be re-written to be more specific :) Thanks for the tip! I'll look into bugzilla from this point forward! Subcogitate

Personally, I think this could be quite a good idea. ACEOREVIVED (talk) 20:55, 23 November 2011 (UTC)

You might want to use http://www.qwika.com/, but I am not sure how relevant or how useful it is.

—Wavelength (talk) 21:29, 23 November 2011 (UTC)

• Support Can't think of any down sides. I don't speak or read any other languages but English (except programming and scripting languages but that's different) so would not get the benefit but, I can see how useful it would be to a user who is multilingual. I can well imagine it being a boon for Wikipedia too since it would encourage cross language Wikiknomery etc. I also imagine it would be quite simple to implement. A quick extension to some php and a couple of tweaks to related UI and Bob's your uncle (as we say in blighty). fredgandt 23:53, 23 November 2011 (UTC)

• Comment: I have listed this proposal at Template:Centralized discussion to canvass wider input. Cunard (talk) 00:01, 24 November 2011 (UTC)

• I'd love to be able to search the French and German Wikipedias at the same time as I search the English one. We'd need to think about how the results were displayed, because with many things -- biographies, geographical locations, the sort of thing you'd actually want to use a foreign-language Wikipedia for -- the articles will have the same titles. I suggest using the standard Wikipedian prefixes, if this is technically possible, so if I used the search term "Goethe" the results would be listed as en:Goethe, de:Goethe and fr:Goethe.—S Marshall T/C 12:18, 24 November 2011 (UTC)
• Support. As I'm regularly using the English, the French, the German and the Slovene Wikipedia, I find it a great idea to have the results for all of them listed in one place. This makes finding the relevant information easier, simplifies the comparison between the different versions and cross-checking and also allows for easier building of articles using information and references from different language versions. I'm really looking forward to have this enabled. --Eleassar ^{my talk} 12:50, 24 November 2011 (UTC)
• I'm doing some translation right now, and this would certainly be helpful, especially as a little option on the search page. What would be cool would be having the interwiki result(s) pop up next to each search result so people can also see which languages have an equivalent article to what they're looking for. /ƒETCHCOMMS/ 19:01, 24 November 2011 (UTC)
• Comment Don't forget Google "goethe site:wikipedia.org" - not great but better than nothing. Rich Farmbrough, 17:38, 25 November 2011 (UTC).
  
• Support Sounds like a good idea. Dusty777 (talk) 23:56, 25 November 2011 (UTC)
• Comment Could this somehow be linked to the Babel userboxes on user pages? So, when enabling the feature, you won't need to select languages you're interested in. Bazonka (talk) 09:48, 26 November 2011 (UTC)
• Support as a checkbox option, disabled by default. It will clutter results (the same sequence of chars can bear different meanings in different languages), so using it by default is not a good idea. P.S.: the Babel comment right above mine makes some sense: it would be nice if language skills would influence sorting. — Dmitrij D. Czarkoff (talk) 17:33, 28 November 2011 (UTC)
• Restored for further discussion before it is closed by an uninvolved admin. Cunard (talk) 06:18, 13 December 2011 (UTC)

• One month timestamp after the RfC tag was added to prevent archiving: 23:59, 24 December 2011 (UTC)
• Cunard (talk) 06:18, 13 December 2011 (UTC)

• Support As long as it's optional.Zlqchn (talk) 12:04, 15 December 2011 (UTC)
• Support as an opt-in, not appropriate as a default. Could also fuel further quality improvements in other wikipedias which are at an earlier stage in their lifecycle compared to en.wikipedia.... bobrayner (talk) 19:56, 15 December 2011 (UTC)
• Support As long as this doesn't put some huge strain on the backend somehow. That reminds me that I could edit something on es.wp... —Justin (koavf)❤T☮C☺M☯ 04:44, 21 December 2011 (UTC)

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

Add link to sandbox on the top right corner

hello,

can't we add a link to the user sandbox somewhere in the top left? I mean ahead "my talk", "my preferences", etc? "My sandbox" would be nice; the user can rename the {User Name}/Sandbox page anytime.--♫GoP♫_T^C_N 18:35, 7 December 2011 (UTC)

• Strong support I actually added this a while back via user script (along with all kinds of other changes). I think having an immediate link to a user sandbox in the p-personal navigation menu for all logged in users would be a fantastic and simple way to encourage the use thereof. When users first create an account, both their user page and user talk page are red-links in the navigation menu, so what harm could there be to add another? Whole hearted support! fredgandt 08:58, 8 December 2011 (UTC)
• Support great idea. Yoenit (talk) 09:49, 8 December 2011 (UTC)
• Support, but it would be nice if the page contains an informational message explaining what their sandbox is for. It'd mystify me as a new user to click on a link and see a new page and then wonder "okay what is this for?" Commons recently added "My uploads" to the upper right and there was no real concern about the space it occupied. Dcoetzee 09:56, 8 December 2011 (UTC)
  • this link preloads a users sandbox with a template. That is the sort of simple solution that could be employed to address your wise concern. fredgandt 10:12, 8 December 2011 (UTC)
• Support I think that is a good idea and would be especially useful for new editors. Toshio Yamaguchi (talk) 10:00, 8 December 2011 (UTC)
• Support only if it can be turned off in a "My preferences" setting - I have four sandboxes and their talk pages, I very much like having sandboxes, but I'd rather not have the tab. Many other users also would probably not like it. If you want to have it opt-out (and a large enough consensus emerges as to allow for opt-out) that's fine, but if there's no opt out, I'd be rather miffed. Sven Manguard Wha? 10:46, 8 December 2011 (UTC)
  • Although I'm not going to oppose an opt-out, note that you could make your sandbox page into an index/list of your sandbox pages, so they'd always be two clicks away, which is nice. Dcoetzee 11:56, 8 December 2011 (UTC)

It already is: User:Nabla#Sub (Ok, 2 clicks and a scroll :-). Not against it, though it will force all of us to have a needless link in order to patronise new users. - Nabla (talk) 23:20, 9 December 2011 (UTC)

• Support only if it can be turned off Per Sven Manguard. I think I have 12 sandboxes now, and I have no need to index them. When I want one, I just type e.g. "User:Anomie/Sandbox6" into my browser's search box. As for the technical implementation, should this find consensus it could be made an "enabled by default" gadget. Anomie⚔ 12:04, 8 December 2011 (UTC)
• Support if turned off by default Most new users won't know what it is for, or will use it inappropriately, filling the Wikipedia servers with unnecessary rubbish. But for more advanced users who want and will use this sort of functionality, it should be easily available. Bazonka (talk) 12:35, 8 December 2011 (UTC)
  • The whole point of sandboxes is that nobody cares if they are filled with rubbish. The alternative if to have the confused users post their rubbish elsewhere, most likely in mainspace. The concern that users don't understand what it is for could be solved with a simple editnotice. Yoenit (talk) 13:11, 8 December 2011 (UTC)

That's not quite what I meant. I was referring to server capacity, not content. Perhaps it's not such a problem though. Bazonka (talk) 20:29, 8 December 2011 (UTC)

I concur. Something like User:Toshio Yamaguchi/Template:User sandbox notice should work. Toshio Yamaguchi (talk) 16:38, 8 December 2011 (UTC)

• Support I can't add much more than the support already given. doktorb _words^deeds 16:45, 8 December 2011 (UTC)
• Support with opt-out. CharlieEchoTango (contact) 16:48, 8 December 2011 (UTC)
• Comment: I just wanted to say that from a Wikimedia Foundation/new editor retention perspective, this is a really great idea. I would propose that if we try this, we make an effort to see how many new editors create/use their sandbox, and how they do so. Steven Walling (WMF) • talk 22:26, 9 December 2011 (UTC)
  • Perhaps the foundation could set up a test that creates the proposed tab for 10 or 20 percent of all not yet autoconfirmed new users. You could then study the use/misuse/disuse/strawberry-mouse of it and see if it could be considered a worthy new feature to roll out for all new users. If then after further study it was found to be the best thing ever!, it could be added to the UI as a simply toggleable option (via prefs) (suggest if tests results prove sandbox tag favourable that it is enabled by default with opt-out toggle). Something along those lines anyway (I know you like testing things Steven ) fredgandt 01:07, 10 December 2011 (UTC)
• Support - great idea. I use custom-js to add a couple of buttons to "my test page", and a "notes" page; they're invaluable to me. If all users had one easy-to-access 'Sandbox' of their own, that'd be a massive improvement. I support it being on by default (because it is of most benefit to new users), with an option to turn it off. Shouldn't we 'pre-populate' it with a header, similar to {{userspacedraft}}, if it does not exist yet?  Chzz  ►  00:56, 11 December 2011 (UTC)
  • Agreed on prepopulating with some useful links etc. Steven Walling (WMF) • talk 18:01, 12 December 2011 (UTC)
• Support this proposal. More generally, I think the "personal toolbar" needs a bit of work to make it more discoverable - maybe some Tipsy tips on newbies' (red) user page and talk page links? — This, that, and the other (talk) 01:18, 11 December 2011 (UTC)
• Support if opt-out is available I'm all for additional features if people find them useful, but I don't want to be forced to have it. Nyttend (talk) 21:49, 11 December 2011 (UTC)
• Conditional support - I would welcome this as an opt-in, but I would oppose having users have to opt-out. – Allen4names 22:14, 11 December 2011 (UTC)
• Conditional support if we can opt out of it. I personally use a user script to include links in the "p-personal" space, but this is better.~ Matthewrbowker ^{Say hi!} 06:36, 13 December 2011 (UTC)
• Oppose the already available buttons Edit and Preview do the trick. Don't think sandbox is needed at all. — Dmitrij D. Czarkoff (talk) 07:31, 14 December 2011 (UTC)

I disagree with this. A preview does for example not produce a diff that is visible to others. If a newbie makes actual edits in their sandbox, this allows for others to give feedback and advice on eventual problems with the newbies editing behavior. Toshio Yamaguchi (talk) 09:45, 14 December 2011 (UTC)

• Support with opt-out and expand to IPs: I like the idea, new users would find it quite helpful, but users who are experienced enough to go to preferences and remove it deserve not to have a clutter if they don't want it. On a sidenote who says users will use the sandbox link instead of testing it out in the main since they can already test in their user-space but no, they test it out there. And wait, what about IPs? How about putting up the WP:SANDBOX as a link in the tab for them? After all they do most of the 'tests'. Something like adding a sandbox tab along with the "login/create account" option that would read "Test edits here" on mouse hover. That might reduce random text entries by IPs who are merely checking out. --lTopGunl (talk) 22:17, 14 December 2011 (UTC)
• Question: Do you mean like what's on pt:? Anyways, support as opt-out. ~~Ebe123~~ → report on my contribs. 15:49, 21 December 2011 (UTC)
• Support per Chzz. As a new user it took me a while to figure out how to create a sandbox. Milkunderwood (talk) 00:45, 23 December 2011 (UTC)
• Strong support - oh man, this would be helpful over at the Ambassador program. Ed ^{[talk] [majestic titan]} 00:40, 25 December 2011 (UTC)
• Support with opt-out. What if we have more than one sandbox? Would we be able to choose which one is linked? –Fredddie™ 06:27, 26 December 2011 (UTC)

User:Δ/Typos

I've started playing around with database dumps and I have had an idea, however I will need more eyes/hands to get this idea off the ground. I am going to be running regular scans of database dumps for typos, see User:Δ/Typos for the first report that I have generated there are 388 pages with "the the". A few of them are valid uses but most are just typos. If I could get some interested users to lend a hand with creating the list of typos and fixing the located typos we could do a lot for the project. ΔT _{^{The only constant}} 20:42, 13 December 2011 (UTC)

Is there any way your search could exclude everything except for "the the"? Although this is useful, I do see a lot of "the then", "then the", and things like "the theory". Could that be narrowed? Nolelover ^{Talk·Contribs} 21:02, 13 December 2011 (UTC)

Yeah, that's fairly simple, must have forgotten about those. Ill adjust the regex and update the list. ΔT _{^{The only constant}} 21:04, 13 December 2011 (UTC)

Actually that wasn't an error with the regex, there is a user already working on the list :) ΔT _{^{The only constant}} 21:07, 13 December 2011 (UTC)

Need to exclude The The as well. -- WOSlinker (talk) 21:20, 13 December 2011 (UTC)

Already done. (for some reason my IRC bot posted this edit twice, once now with your current timestamp the other 9 minutes before.) ΔT _{^{The only constant}} 21:22, 13 December 2011 (UTC)

The lists would be more useful if they included a timestamp, or were held on-wiki so that they could be watchlisted. -- John of Reading (talk) 08:10, 14 December 2011 (UTC)

(←) I love this idea! I am watching that page :) and I'll be going through some if not all of them using AWB. How often will they be updated?  Hazard-SJ  ㋡  00:01, 18 December 2011 (UTC)

Right now Im trying to get the logistics worked out. But my plans are to update the list regularly, and upon each database dump release. ΔT _{^{The only constant}} 03:23, 18 December 2011 (UTC)

Now that's a massively helpful use of automated technology. Running through with a few other perennials ("diety" - the slimming god, "and and" - the overexcited conjunction, the well known online encyclopaedia "Wikipeida" and so forth) to create specific lists, so editors are not distracted would be a cool resource. Elen of the Roads (talk) 16:37, 18 December 2011 (UTC)

As soon as the current dramafest that is my arbcom case is over Im going to move this into full throttle. ΔT _{^{The only constant}} 16:42, 18 December 2011 (UTC)

• Are you reviewing each individual AWB edit manually for proper grammar following your change? "... the The ..." should not necessarily become "... The ..."; it might need to be "the" (e.g. [1] [2] [3] [4]). –xeno^talk 16:20, 19 December 2011 (UTC)

• Yes, in that case I defaulted to assuming that in those cases The was part of the proper noun and edged on the side of caution to leave it capitalized. As for correct grammar, I am not a specialist in English grammar, but it does look correct to me. ΔT _{^{The only constant}} 16:26, 19 December 2011 (UTC)

• This is not a safe assumption, and in at least one of the linked examples resulted in inconsistent article usage [5]. –xeno^talk 16:31, 19 December 2011 (UTC)

I'm interested in helping to cleanup typos, since it seems like an easy way for a new editor to make contributions. I also found List of common misspellings. How will your project interact with that? RudolfRed (talk) 23:12, 26 December 2011 (UTC)

Aimed donations

As proposal for the future, I would like to make donations to aimed branch of wikimedia. I guess a very simple "paypal donation link" in each article and if that article is, for instance, about science, then the most part of the donation will go to the scientific branch of wikimedia (which I guess don't exist at all today).
More specifically, I'm thinking also to to the copyright of a work: particularly when someone edit a page about a literary/musical work, I guess he would be happy to donate 1 cent to its author (so not just only to the authour of the wikipedia page, but to the author of the work too, like I would do e.g. for an article about Roger Waters, paying Roger Waters, although he has already much money, because I like that his work and I'm happy to edit it: in the way I'm proposing I would be a bit more motivated to edit the article). As well as if one edit the LHC article, he would be happy to donate 1 cent to CERN.

Reply from Wikipedia information team (info-en@wikimedia.org)
Thank you for your email. Our response follows your message.

_{> As proposal for the future, I would like to make donations to aimed branch of wikimedia. I guess a very simple "paypal donation link" in each article and if that article is, for instance, about science, then the most part of the donation will go to the scientific branch of wikimedia (which I guess don't exist at all today).}
Donations to Wikimedia go to fund the operation of the site rather than any particular "branch". The Wikimedia Foundation maintains the servers and builds software that enables the editing community to work on the project. The process of article development and maintenance is something done by volunteer editors. There is no way to specifically target funding on just some topics and not others because the bulk of the work that the Foundation does isn't editorial but primarily technical.

That said, in some countries, there is outreach done to different groups, specifically the work done with cultural and educational bodies. It is up to chapters to try and find the best partnerships they can pursue, and those decisions are usually done on what can bring the most amount of benefit to the overall goal of letting every single human being freely share in the sum of all human knowledge.

_{> More specifically, I'm thinking also to to the copyright of a work: particularly when someone edit a page about a literary/musical work, I guess he would be happy to donate 1 cent to its author (so not just only to the authour of the wikipedia page, but to the author of the work too, like I would do e.g. for an article about Roger Waters, paying Roger Waters, although he has already much money, because I like that his work and I'm happy to edit it: in the way I'm proposing I would be a bit more motivated to edit the article). As well as if one edit the LHC article, he would be happy to donate 1 cent to CERN.}
The problem with this proposal is not everyone is interested in supporting the subject of the article. I expect the people who edit the articles on Roger Waters or the Large Hadron Collider would be fine with a small fraction of money going to Waters or CERN, but having an article isn't an endorsement. If I knew that a cent was going to some terrorist or neo-nazi group every time I improved the article about them, that'd not be a good thing. There are also massive accounting headaches with this, and it would leave the underlying issue there. The point of the fundraising is to raise money to support the Wikimedia projects, not to support the subjects of articles. If we started giving money to the subjects of articles, the money lost would have to be made up for by increasing the amount of money raised.

That said, if you wish to support other groups, we actively encourage doing so. We have had lots of e-mails saying things like "how dare you ask for money while cancer still exists?" and things along those lines, and our answer is always the same: donate to those charities too!

I hope I've answered your questions: thanks for your ideas, and I don't want to dampen your enthusiasm in coming up with ideas. We have a whole page on Wikipedia called the Village Pump (idea lab) where people come up with ideas on how to improve Wikipedia - see <http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28idea_lab%29>

Yours sincerely.

• I assume this email response from an wp:OTRS volunteer was posted here with the idea of sparking further discussion. However, the the volunteer who replied to your email already identified the fundamental flaws in your idea. Unless you have more to add with regards to your idea, this will be archived in a few days as yet another quite interesting but completely unrealistic idea. Yoenit (talk) 00:30, 27 December 2011 (UTC)

• WP:BOUNTY. Prodego ^talk 00:34, 27 December 2011 (UTC)

Be able to watch talk and main pages separately

This has been brought up before, but has not got much attention. See #Watch_talk_pages (2005) and #Watchlist_without_talk_pages (2008)

It would be nice on occasions to watch a talk page without watching its main page or vice versa. The default behaviour should stay as it is insofar that any watched page automatically has its associated page also watched, but if we chose, we should be able to watch un-watch just one or the other. fredgandt 02:00, 30 November 2011 (UTC)

It's been brought up before at least a couple times, but I agree, I'd love this. ♫ Melodia Chaconne ♫ (talk) 03:07, 30 November 2011 (UTC)

• Support. But this is the programmers', not our, problem.Jasper Deng (talk) 03:37, 30 November 2011 (UTC)
  • • Comment There may be performance implications, but I guess it's possible to implement this (if there was concensus for that). Petrb (talk) 07:55, 30 November 2011 (UTC)
• Support. When brought up before, was there a technical reason this wasn't possible or did we just decide not to implement it? --Philosopher ^{Let us reason together.} 04:02, 30 November 2011 (UTC)
• Support This option may be useful for some editors. Don't see a downside.--JayJasper (talk) 05:48, 30 November 2011 (UTC)
• Weak oppose, as it will lead to increased amount of out-of-context edits. — Dmitrij D. Czarkoff (talk) 09:20, 30 November 2011 (UTC)
• Oppose. This would have negative consequences on editor interaction. Edit warriors could simply claim that they were not aware something was discussed on the talk page because they 'forgot' to watch it. Sometimes absence of a feature is a big advantage. Hans Adler 13:12, 30 November 2011 (UTC)
  • Anyone wishing to claim ignorance can already do so. I proposed that this would not be a change to the norm but an addition to it. An extra feature that would allow the un-watching of one or the other page, without un-watching both. There could be no forgetting as they would have to actively undo default behaviour. fredgandt 13:23, 30 November 2011 (UTC)
    • I still think this would cause confusion, plausible deniability and disruption. However, we can already restrict display of changes to just one namespace. It should be easy to write a JavaScript tool that you can install yourself and which just displays several namespaces and filters out certain others, or which sorts changes according to namespace. Hans Adler 17:08, 30 November 2011 (UTC)
      • Well, being able to watch talk pages but not the article pages shouldn't be a problem, at least. I often don't care about the changes on the 'article' page (such as with Wikiprojects) or am curious about the talk page temporarily on a heavy-watched page (like the FA of the day). ♫ Melodia Chaconne ♫ (talk) 19:16, 30 November 2011 (UTC)
• Weak oppose. My guess without looking at the software is that this is a Mediawiki matter not a WP matter. IMHO, the diversion of scarce resources from other matters isn't justifiable. Wtmitchell (talk) (earlier Boracay Bill) 14:10, 30 November 2011 (UTC)

T25014 "There is no user preference to automatically watch talk pages edited" seem pretty close the proposal. ---— Gadget850 (Ed) ^talk 18:03, 30 November 2011 (UTC)

• Not quite related. Anyway, watchlist entries are bound to the article's titles in the database, which encompas both the atricle and it's talk page. They are unseperable in that respect, so this would require rewrite in the software (and possibly restructering of the database). — Edokter (talk) — 18:11, 30 November 2011 (UTC)

I would imagine (I know a bit about PHP and MySql) it would be quite simple to split them up at one level or another. I would look at the last script to handle the providence of Special:Watchlist and flag those tagged. The tagging could also be easily appended to the database. Bitfileds come in handy for this sort of thing. Just create two new values and carry on camping! fredgandt 21:13, 30 November 2011 (UTC)

FWIW, Wikipedia:Hide Pages in Watchlist shows that it should be possible to write a user script to do this. Rd232 ^talk 19:24, 30 November 2011 (UTC)

User scripts can change the display in almost unlimited ways. So yes it could be done that way. the question would be whether enough people would like it to make it more practical and/or desirable to add it to the software. fredgandt 21:13, 30 November 2011 (UTC)

• Support as opt-in. I would find this practical. ~~Ebe123~~ → report on my contribs. 22:58, 1 December 2011 (UTC)
• Comment I don't understand when this would be useful and would like to see clear examples. Dcoetzee 09:38, 4 December 2011 (UTC)

• Now and then and here and there!  fredgandt 10:00, 4 December 2011 (UTC)

• Support CharlieEchoTango (contact) 08:23, 6 December 2011 (UTC)
• Oppose - I can't see the value in this. Why would you want to watch one and not the other? Major changes to an article are discussed on the talk page and if I had forgotten to add the talk page to my watchlist, by the time I saw those changes, it might be too late to do anything about them. I would support a 'Hide Talk Page' option such as the 'Hide bots' option we currently have but the default should be to watch both pages.--Ykraps (talk) 08:53, 6 December 2011 (UTC)

You could not forget to watch one or the other as the default behaviour would not change. This is a proposal to allow the un-watching of the pages separately as a special option. As for when or how it might be useful, it might be (personally has been). I just like options!  fredgandt 09:13, 6 December 2011 (UTC)

That doesn't sound so bad but it still seems a lot of work for very little benefit that I can see.--Ykraps (talk) 08:07, 7 December 2011 (UTC)

• Support. - Dank (push to talk) 18:57, 6 December 2011 (UTC)
• Oppose Increases user interface complexity without any clear benefit. (If this "feature" is thoroughly hidden then okay, but I'd rather see the MediaWiki developers spend their time on developing more useful features.) —Ruud 21:53, 6 December 2011 (UTC)

  Personally, I'd rather be certain that I always have both the page and the talk page watched. I absolutely do not want to see the behaviour of unwatching be changed (by default), nor would support adding any additional user interface elements (confirmation dialogs, tab or menu items) be added (without enabling this feature in your preferences.) Some additional checkboxes etc. on the watchlist would be fine. —Ruud 12:43, 7 December 2011 (UTC)

• Oppose - What's the point? Why can't you just ignore the extra watchlist entry? What if you're watching the talk page of a low-traffic article without watching the article itself, and it gets vandalised? →Στc. 23:09, 6 December 2011 (UTC)

  And since when is it anyone's obligation to revert vandalism? And if you're going to say "why not ignore that page" than it wouldn't get reverted ANYWAY now would it? ♫ Melodia Chaconne ♫ (talk) 01:16, 7 December 2011 (UTC)

  I would like to watch WT:AIV but not WP:AIV.Jasper Deng (talk) 23:45, 6 December 2011 (UTC)

  What's stopping you from simply ignoring the edits made to WP:AIV? →Στc. 00:31, 7 December 2011 (UTC)

  • AIV gets many edits each day that I don't want to watch. It's the talk page I want to watch.Jasper Deng (talk) 01:56, 7 December 2011 (UTC)
    • It was actually AIV that inspired this proposal. I wanted to keep an eye on discussions there but didn't want to be pointlessly flooded with the constant stream of edits to the main page. If I were an admin, it would be important for me to watch the page. I'm not though. And watching the bot tidy up the reports 1000 times a day was more than I could stand. fredgandt 22:38, 11 December 2011 (UTC)
• Support, no good reason not to do this. There are plenty of circumstances where a user might want to follow changes to an article and not its talk page, or vice versa, and why shouldn't they be able to do so? Robofish (talk) 12:45, 7 December 2011 (UTC)
• Oppose only a small benefit, at the risk of considerably more complexity and potential for things to go wrong - such as you think you're watching an article, but you aren't. Grandiose (me, talk, contribs) 13:58, 7 December 2011 (UTC)
• Oppose It might lead to a user not seeing a question raised on a talk page about an article that is pertinent to them. If someone doesn't want to look at the talk pages (or vice versa) in their watchlist then they can just filter the Namespace themselves. Zangar (talk) 19:19, 7 December 2011 (UTC)
  • If I just wanted to not watch one particular talk page, how could i do that by use of the current filters? That could only be done with a user script. This proposal is to add functionality for all users, not just those who manage to think of the idea, then find or write the script to allow it, fredgandt 22:45, 11 December 2011 (UTC)
• Oppose: would be too complex. Try to envision how "EditWatchlist" would look, and then think about Special:EditWatchlist/raw: do you want to have 3 separate textboxes: watching_main / watching_ talk / watching_both ? — AlexSm 19:52, 7 December 2011 (UTC)
• Support There are numerous pages where I want to be aware of changes to the text, but not participate in the voluminous discussions (much of the MOS, for example). DGG ( talk ) 04:04, 8 December 2011 (UTC)
• Oppose in principle. This will almost certainly result in even less discussion and collaboration. —Justin (koavf)❤T☮C☺M☯ 10:20, 8 December 2011 (UTC)
• Support, but it needs to go farther. We don't just need the ability to watch just the talk page or just the main page, but to watch just one section. Many times I have tried to watch one particular low-activity noticeboard case only to end up drinking out of a firehose as some unrelated case gets a large number of comments. --Guy Macon (talk) 18:55, 8 December 2011 (UTC)\

• Indeed, I'd love to be able to watch just one section of CFD, or ANI for instance. ♫ Melodia Chaconne ♫ (talk) 19:11, 8 December 2011 (UTC)
• Awesome idea! Maybe too far reaching for the tiny step society, but great if it could be added. Options are great if they don't actually do any harm. I fail to see how this could. fredgandt 22:32, 11 December 2011 (UTC)
• Support this, but not the main: Watching only a section of a talkpage would be great. You are right, this happens so many times. However watching either talkpage or the main page separately would be confusing. This specific suggestion should be applied as an opt-in (from preferences) as well. --lTopGunl (talk) 18:40, 13 December 2011 (UTC)

• Oppose Increases user interface complexity for no apparent reason and proposer gives no rationale for this change other than "It would be nice on occasions". Switched to Neutral below. Toshio Yamaguchi (talk) 19:03, 8 December 2011 (UTC)
  • Why must I give a rationale? If you can see any value in the idea, support it. If you think it is harmful, oppose it. If you don't care one way or the other, don't comment. Why must people have to work so hard to impose thoughts on to other editors here? I propose an idea. How it sits in your head is your business. fredgandt 22:28, 11 December 2011 (UTC)
    • You don't have to give a rationale. I don't think it is harmful, but I also think it is not useful, since I can think of no situation where I would ever want to watch only one of the two pages. Thus my 'Oppose'. If you have an example of such a situation, however, by all means feel free to present it and convince me otherwise. I just say that my oppose is rather weak. Some proposals might have a negative effect on the encyclopedia but I don't think that's the case here. I just wanted to make transparent why I oppose this proposal. Toshio Yamaguchi (talk) 22:56, 11 December 2011 (UTC)
      • Plenty of examples have already been given, but I'll repeat a very obvious one I mentioned above -- Wikiprojects. I know I'm hardly the only one who never pays attention to what's on the 'project' page but is quite involved in the discussions in them. The other case, as I said above, is FA of the day; perhaps a better example, even, as on the day they are featured they get tons of edits, and I for one an often only interested in the talk page. ♫ Melodia Chaconne ♫ (talk) 04:52, 12 December 2011 (UTC)
      • Personally not liking something does not strike me as fair grounds to oppose something. I am not Christian, but do not oppose others being Christian. If that's what they want to do, good luck to them! If however, I thought Christianity was dangerous or harmful (wow, that's a contentious subject right there), I would oppose it on the grounds that it would do that harm to others and future others. Analogy aside, if you see no harm in this, please don't oppose it. Just state your neutrality if you have to state anything at all. fredgandt 07:27, 12 December 2011 (UTC)
• Neutral Proposal says default will be watching both pages (which I wouldn't like to see changed) and one of the pages will not be watched only if the editor chooses to do, thus neutral, as some people seem to find it useful. Toshio Yamaguchi (talk) 08:00, 12 December 2011 (UTC)
  • Absolutely. I wouldn't want the default to change either; that would get terribly confusing. This is just an available option to un-watch a page without un-watching its partner. I envisage a drop-down (open to ideas) like the "move" drop-down, that shows when hovering over the "this page is watched" icon (not when hovering over the "watch this page" icon) that gives the choice to un-watch the page without un-watching the other. If we were to click on the star as normal, the normal behaviour is carried out (both are un-watched). On a personal note Toshio, thanks for being such a good sport. fredgandt 10:03, 12 December 2011 (UTC)
• Support (Sort of) Wasn't there some talk of making it possible for a user to have a hotlist of pages that are really important to them? I for one would like to have pages I created appear bolded in my watchlist, rather like pages in my watchlist appear bolded in Recent changes. Perhaps a system could be developed along those lines? Speciate (talk) 05:19, 12 December 2011 (UTC)
  • Although bolding preferred pages would conflict with other highlighting (proposed and presently implemented), I'd support a weakening (by fading to grey or reducing font size) of those pages we chose to un-watch as a compromise. I think though if the scripting was in place to allow that kind of marking (application of a class probably), it would make more sense to go the whole hog and not show those pages marked. fredgandt 07:27, 12 December 2011 (UTC)
• Neutral - I don't see any purpose in this, but, if other people want it, and it can be done, then fine. It doesn't matter that much.--Unionhawk ^{Talk E-mail} 13:10, 20 December 2011 (UTC)
• Oppose again - [6] →Στc. 02:02, 23 December 2011 (UTC)
  • Just to be clear: you're opposing this because a more complex way of accomplishing effectively the same thing already exists? How about instead, support this way of making it easier for people? fredgandt 02:24, 23 December 2011 (UTC)

• Complex? I think display:none; is self-explanatory. →Στc. 05:58, 23 December 2011 (UTC)

• Support. Rcsprinter (whisper) 16:36, 28 December 2011 (UTC)

Bald proposal - we should ask newspapers to provide links in Wiki format

I know this proposal is very bald, but we have to do it one day: Wikipedia is very big and many people are spending their time to edit it. Editors can use some help to make their editing work faster, by focusing on essentials, on doing intelligent edits, and wasting less time with routines. I waste lots of my time just formatting references. Take for example this link: [7]. If I want to reference it, then I have to copy: the link, the name of the article, the date it was added, the name of the author and the name of the newspaper, to make it look like this:

<ref>[http://www.economist.com/blogs/freeexchange/2011/12/euro-crisis-3 The euro crisis - Is everything fixed?], Dec 16th 2011, R.A., ''The Economist''</ref>

I have to bounce like five times from one window to another just to copy all the data required. It should be done automatically. We should try to talk with the newspapers and ask them to help us, by allowing their readers to copy the links to their articles in a custom-format. This can be done if the newspapers implement a JavaScript for formatting URL's, or maybe by creating some Firefox extension that grabs the required data and process it to make it usable for the user - this option would require an extra HTML tags in the newspaper articles that the addon can look for. I know this is not easy to do, but if you add all the time the Wikipedia editors waste on formatting references, it would result in an enormous amount of time wasted. If some newspapers would implement this feature, then other newspapers will be encouraged to do it too. Not only Wikipedia editors can use such a feature. Every day there are new Wikis on the internet, and their editors can use the feature too. Sometimes the Wikipedia editors are referencing data from well-established blogs, so it might be a good idea to try to convince the programmers of Wordpress and Livejournal to implement the feature too. The knowledge on Wikipedia articles is helping all the humanity, including the journalists. But we also need some help from journalists too, in order to make our work better, for the benefit of everyone. —  Ark25  (talk) 04:05, 24 December 2011 (UTC)

Web pages can already set various Meta elements. I don't know how standardized and widespread they are. PrimeHunter (talk) 04:48, 24 December 2011 (UTC)

Ever tried using ProveIt? The Blade of the Northern Lights (話して下さい) 04:59, 24 December 2011 (UTC)

(edit conflict)Have you tried Wikipedia:RefToolbar? --Jayron32 05:01, 24 December 2011 (UTC)

Thanks. I will try to use those tools and I will come back ASAP. —  Ark25  (talk) 07:36, 24 December 2011 (UTC)

Well, with the [ProveIt] addon I will still have to go back and forth between Firefox windows to copy all the elements: URL, name of article, date, etc. I don't really understand how to use the RefToolbar, can you help me to understand how it works? Do you have some examples of specific DOI references? like for example of a doi: that references a newspaper article. —  Ark25  (talk) 19:47, 24 December 2011 (UTC)

If you're using Firefox, WP:Cite4Wiki is a great add-on which does actually automate it fairly well. sonia♫ 04:39, 27 December 2011 (UTC)

• Oppose: firstly, we have different citation formats, so the housekeeping will still apply in any case. Next, I see no actual problem in copying the needed data. Finally, why should some newspaper provide a specific format for the single user? — Dmitrij D. Czarkoff (talk) 07:31, 25 December 2011 (UTC)

It's not for a single user - most of the Wikipedia editors can use that. It should offer you the opportunity to customize the way it copies all those fields: URL + name of article + "]" + author OR URL + name of article + "]" + author + date + accesed date. That way you can copy the data in a format that meets your requirements for using the citation format you like. If you have no problem in going back and forth between 2 windows for 5-6 times to copy all the required data and wasting 30-60 seconds just to make a reference instead of pushing a single button then... you don't really think in terms of efficiency. Wikipedia editors are wasting enormous amounts of time just to create the references, while that kind of action can be done much faster and efficient. —  Ark25  (talk) 22:47, 26 December 2011 (UTC)

• Support: Another advantage is that the newspapers can make sure that we get the correct information. Often it's easy to mistake who the real author is (for example, with a guest writer of a column with an established author) or what the actual published on date (vs last updated or in the case of articles that are recycled onto the front page). Also, often sites have their own permalink format that is not apparent from looking at the article as published in a particular section of the site (it may only be visible through invisible meta info). I would encourage taking this up with either/both W3C [8] and/or WHATWG [9] - I might do so myself, but I must admit I am somewhat unreliable for things like these. Jztinfinity (talk) 04:30, 27 December 2011 (UTC)

Well I am not reliable for things like these either but I feel like I really have to do it. It's in the interest of everyone to solve this issue. Wikipedia editors would be more efficient, the newspapers who implement the feature will preferred by the editors (so they will be promoted), all that in the benefit of the Wikipedia readers. It can be implemented either by creating/implementing a W3C standard and ask the newspapers to implement it (will take time but it's the best solution and worth the effort) or, at first, a Firefox extension can help, by doing the job for a limited number of newspapers. The extension should be modular, allowing people to add "plugins" for more newspapers. The extension can learn the specifics of each newspaper web site, reverse engineering them a bit, in order to create the wiki-links. Right after this proposal there is another interesting one - aimed donations. I think its worth to explore the idea of donating money specifically for developing software that helps Wikipedia editors. Some people might be interested to donate for developing AWB, especially as it's not only useful for wikipedians, therefore people who don't want to donate for Wikipedia might be interested to donate for the software. There are sites like oDesk or donationcoder where the money can be used to accelerate the development of the software. I would be happy to donate even amounts like 300 $ just for fixing this issue - it's wasting an enormous chunk of my wikipedian life (which in turn it's like 30-40% of my entire life). So 300 $ for me is quite very cheap. —  Ark25  (talk) 23:48, 27 December 2011 (UTC)

• Oppose. Sorry, but we'd be asking the newspapers to solve our problem, and they'd do it with their priorities. For example, the link would likely come loaded with all the extraneous spammage after the "?" in the URL which identifies the user who accessed the article, which I make a point to trim off; they might even link to special ad pages that luckless readers have to navigate through; the titles might come with their own capitalization scheme, subtitles, etc. that editors would then want to fiddle around with and so on. Sure, I'd like us to have a fast, very flexible, and easy to use WYSIWYG format where we can drag-and-drop references; but it should be our script set to work our way. Wnt (talk) 02:21, 28 December 2011 (UTC)

Sorry but I think you didn't understand what I said. First, the problem can be solved with a Firefox extension, that would not imply newspapers to implement anything. Not sure how many people log in to read newspapers articles, because using such links prevents other readers of the Wikipedia article to check if the data is correct or not (verifiability). I think most of the editors prefer to add links to articles that don't require accounts to read. Also, if this kind of issue would be addressed, then the script will allow the reader to customize the way the data is copied, including trimming of the things you mention. The script should provide you the option to include or not the subtitle, to transform the title in uppercase/lowercase, etc. Also, most of the Wikipedia editors would be very happy to do the job faster, saving the time to fiddle with details like capitalization, subtitles, bold, italic, superscript, subscript, underline, etc. Yes, it can be done by making our own script. Either we create a Firefox extension that learns newspaper sites and use the tags in their webpages to create the reference. Or, the long term solution is to develop a new W3C standard for this issue (which implies using certain tags for title, subtitle, URL, author, date, etc), and then to encourage the newspapers to implement them. Then, a browser extension can take all that data in the tags, and arrange it the way the user wants it. That way, the extension will work without having to make it learn the particulars of each website. I am not good in programming, but at least I can contribute with some money. —  Ark25  (talk) 06:21, 28 December 2011 (UTC)

Comment - it is possible, maybe not by a commercial media provider, but it is already being done by the National Library of Australia. They have digitised thousands of old newspapers up to about 1956 and have conveniently provided a "cite" button that automatically produces a wikipedia (or Harvard/APA/MLA) formatted citation. See this article (the earliest mention of Don Bradman) for an example of how easy it is to use. The-Pope (talk) 14:51, 28 December 2011 (UTC)

Thanks a lot for showing that nice example, The-Pope ! Yes that's a good step forward. I think that, in time, other libraries and even newspapers will do something similar. The solution is to implement a standard, to make it compatible between sites. It will even make the website's job easier. Because the National Library of Australia created a script to provide that cite button. With an established W3C standard, they will only have to maintain the fields into certain tags (like for example class='box title'>The Sydney Morning Herald (NSW : 1842 - 1954)) and a browser extension can handle the script to use those tags in order to create the cite. A browser extension can be made much more versatile, creating custom profiles, for various arrangements of the citation and language-specific version. For example, when I create a reference for ro.wp, I need 29 decembrie 2011 instead of 29 December 2011. The browser extension can directly copy into your clipboard the desired citation, at a click of a button. Also, a browser extension might work faster than a javascript implemented on the website. —  Ark25  (talk)

the highlighted links to other pages should have a preview box

the highlighted link should have a preview box, esp if the link is to a page that is a definition of the linked word, it would make wikipedia more convenient, instead of leaving the current article being reviewed to get the definition of an unfamiliar word or a description of an event, you could have a highlight box that comes up by hovering the mouse cursor over the link, and in this box it would include the information necessary to get the jist of the linked article and have it disappear when you remove the cursor from the highlighted link — Preceding unsigned comment added by Which damn name is available? (talk • contribs) 03:10, 28 December 2011 (UTC)

Go to your preferences, select Gadgets and then enable Navigation Popups. This adds preview boxes when hovering on internal links. CIreland (talk) 03:15, 28 December 2011 (UTC)

New Essay

I've read a few blogs and also some feedback on the dashboard and it appears to me that one of the reasons folks find Wikipedia confusing is that all of our policies "link" to more policies. So someone trying to get an understanding of Wikipedia would continually be reading a new policy, guidelines, or essay and never find "the end". I think we need an essay that does two things: 1) It explains why there is no "end" in the circular format of our policies, and 2) It explains why our policies are circular and sometimes contradictory. I think this essay needs to contain absolutely zero wiki-links except for a "see also" section at the bottom or some citations. It should explain that one does not need to know all the finer points of Wikipedia, give a brief explanation of the more major points, and suggest that a reader take each policy one at a time in full before trying to tackle another. It needs to explain why this all seems insurmountable and confusing and how to contextualize each part individually and collectively. The bottom line is: It needs to offer a "Be bold" message that suggests the reader be patient with themselves and Wikipedia but to give it a shot and be open to learning. WP:INSURMOUNTABLE with WP:THEEND and WP:CROSS LINKED as shortcuts? Thoughts?--v/r - TP 16:24, 20 December 2011 (UTC)

• Broadly support, but note that WP:IAR was the first policy anyway, introduced by Larry Sanger. The essay you suggest should at least mention this somewhere, as well as emphasising collaboration, consensus, and iterative solutions to problems (ie. don't try to do too much at once). IBE (talk) 19:48, 20 December 2011 (UTC)
  • Larry was actually later a registered opponent of this policy.Sanger on the origins of this rule Rmhermen (talk) 01:47, 21 December 2011 (UTC)
• Support along with IBE's recommendations above. Such an essay would be immensely helpful to newbies and semi-active editors who get discouraged at times because they feel as though they are immersed in a bottomless pit of countless policies and guidelines. For that matter, it would probably be helpful to seasoned, established editors as well. Support the suggested shortcuts as well, and would add WP:PATIENCE, and maybe WP:HANGINTHERE.--JayJasper (talk) 20:59, 20 December 2011 (UTC)

WP:RUNFORYOURLIFEWHILEYOUHAVETHECHANCE! fredgandt 05:32, 21 December 2011 (UTC)

Wow, Air Force. That is actually a really good essay to write. Mean it. Thought the adminship was rotting your brain, but it appears not (yet).  ;-) In all seriousness, I think a heartfelt man-to-man essay of the sort you propose is exactly on target. Maybe make the point that users can learn by trying things and do the things that come easy first and work their way up. More of an apprenticehip model. I still don't understand all our Wikicrap policies and get by pretty good without doing so...TCO (talk) 17:28, 21 December 2011 (UTC)

I admit to some degree the nature of Wikipedia makes interwoven policy pages inevitable, however, I do wish when someone has a simple point to make they would spell it out in a sentence rather than a policy page link. Or maybe when you use a policy page link, spell out what you're trying to say, then do something like ("for more information, see WP:Link"). Jztinfinity (talk) 15:17, 25 December 2011 (UTC)

• Support Our documentation is so dreadful - full of Wikispeak that new users (and even old users!) dread! I'd love to read this essay, thanks for considering developing it! SarahStierch (talk) 19:39, 29 December 2011 (UTC)

Wikipedia Transparency

In the interest of avoiding a bias or any special interest agenda on Wikipedia, I propose that Wiki provide a list of who donated how much money to Wikipedia. Amusedspaceman (talk) 21:14, 23 December 2011 (UTC)Dec. 23, 2011

Why? To thank people who thought they were giving anonymously, or to name and shame users who haven't given?  An optimist on the run! 21:22, 23 December 2011 (UTC)

The Wikimedia Foundation annual report lists all donations of more than $1000 dollars I Believe, I dont think you really want a list of all 573,568 contributors. I am sure if you cant find the report somebody will provide a link in a moment. MilborneOne (talk) 21:25, 23 December 2011 (UTC)

As a regular editor, I do not know, nor do I want to know, who Wikipedia's largest donors are specifically for that reason. By not knowing who our donors are, I am less inclined to give any thought to their concerns. If Jimmy Joe Bob's Pulled Pork, Inc. donates $5 bazillion, I have no idea. When I edit [[Jimmy Joe Bob's Pulled Pork, I give it the same attention I would give to Crazy Jane's Pulled Pork, even though Crazy Jane repeatedly says on her menus that Wikipedia is a communist conspiracy aimed at controlling our minds by adding fluoride to our drinking water. - SummerPhD (talk) 13:30, 24 December 2011 (UTC)

The best way to ensure a lack of bias is to uniformly insist that all pages be based on reliable sources in proportion to their respectability and impact. This puts all editors on an equal footing since any editor can, in principle, acquire and summarize any source within the limitations of policy. Since the WMF has a very, very light hand regarding content disputes (notable exceptions being child pornography and copyright issues), this suggestion would have essentially zero impact on the content of most pages. WLU (t) (c) Wikipedia's rules:^simple/_complex 17:03, 24 December 2011 (UTC)

With small donations this isn't a matter of transparency, more an issue of data privacy. There are plenty of Direct marketing companies who would love to get hold of our donors list, as lots of organisations especially charities would pay to use it for marketing. Off hand I can't think how anyone else would use it if we published it, except perhaps a few image conscious organisations threatening editors with writs if they were able to use this to identify the the Wikipedians who edit the articles on them.. Personally I'd rather it wasn't available for either of those purposes, and if we were to release it my prediction would be that the revenue from renting out our donor list might not cover the reduced donations from our existing supporters. ϢereSpielChequers 17:32, 29 December 2011 (UTC)

Log out confirmation

Twice in the last couple of days I've accidentally clicked "Log out" while trying to click on the search box (they're adjacent in Classic skin). This is annoying, as it means having to log back in again, and for some reason it doesn't log me back into Commons. Is it possible to introduce a confirmation dialogue (possibly opt-in or opt-out through preferences) saying "Are you sure you want to log out?" when this occurs?  An optimist on the run! 10:14, 29 December 2011 (UTC)

I made you a script to solve your immediate dilemma. Add

importScript("User:Fred_Gandt/classicLogoutConfirm.js");

to your classic skin JavaScript page. Bypass you cache etc. and when the script runs it will add the confirmation popup you desire. fredgandt 11:05, 29 December 2011 (UTC)

Excellent - just what I wanted! Thanks!  An optimist on the run! 11:16, 29 December 2011 (UTC)

You're welcome. let me know if there are any problems with it. fredgandt 13:17, 29 December 2011 (UTC)

Your 20+ lines script could look like this below (again, Classic skin only). — AlexSm 19:23, 29 December 2011 (UTC)

$('a[title="Special:UserLogout"]').click( function(){
  return confirm("Are you sure you want to log out?");
})

That appears to work too - I've just added it to my Commons js script. Again, many thanks.  An optimist on the run! 23:06, 29 December 2011 (UTC)

Cool! I've never used a confirm (or any other prompt) before. I didn't know it would pick up the address automatically. Very useful. JavaScript is very clever! One learns something new every day.  fredgandt 01:26, 30 December 2011 (UTC)

Enable "Show changes since last visit" on watchlist

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

The community is in support of this proposal. -- DQ (t) (e) 16:08, 30 December 2011 (UTC)

A Bugzilla report was filed at bugzilla:33123; after the proposal was implemented, discussion occurred at Wikipedia:Requests for comment/Watchlist survey. Cunard (talk) 19:17, 21 June 2012 (UTC)

---

I propose that the option $wgShowUpdatedMarker be enable on the English language Wikipedia, as seems to be the default on many other projects. This will enable users to see which pages on their watchlist have been updated in a single glance. The default styling is to bold the page title, but we could style it any way we want, e.g. with a subtle background color instead. — Edokter (talk) — 14:10, 2 December 2011 (UTC)

• Support This feature is especially good for those who (like me) show all changes instead of just recent changes. And since it's just a matter of switching it on, there's no big fuss about how we go about doing it. A nice simple upgrade with the flick of a switch (kinda). fredgandt 19:16, 2 December 2011 (UTC)
• Comment This would be toggle-able yes? If so, there's no reason not to. If not, however, I would oppose on the grounds of stuff like that being annoying. ♫ Melodia Chaconne ♫ (talk) 20:48, 2 December 2011 (UTC)
  • As the function almost only adds a class wrapper to certain entries in your watchlist, even if it weren't togglable, one line of css could override (I'm fairly sure but Edokter can confirm) the effects. So one way or another, yes. fredgandt 20:52, 2 December 2011 (UTC)
    • Correct. There is no user option, but it can be overridden with CSS. I don't like the bold either so I would opt for a less-annoying appearence. — Edokter (talk) — 21:00, 2 December 2011 (UTC)
• Support I like this feature on other projects. I find it particularly useful when looking at history pages for active discussions, because I can't always remember how many of the recent comments I've already read. I've been wondering recently why it wasn't enabled on en.wiki. Are we too big, perhaps? WhatamIdoing (talk) 21:33, 2 December 2011 (UTC)
• Weak oppose - I know what's been different when I see my watchlist, and I don't need to be reminded. But I would support as an opt-in.Jasper Deng (talk) 23:41, 2 December 2011 (UTC)
  • There's no opt-in, but as I said above, it's overridable. — Edokter (talk) — 00:15, 3 December 2011 (UTC)
    • Not in a way that I could simply go to Preferences with. Not every user knows CSS.Jasper Deng (talk) 00:17, 3 December 2011 (UTC)
• The change could be opt-in. Nothing would change unless the class was given special treatment. If it was ignored there would be no visual change at all. If users then wanted to, they could use css to show the new feature, instead of css to override it. This is an option. Keep the ball rolling. fredgandt 00:38, 3 December 2011 (UTC)
  • I think this would be very useful as a gadget (I'm sure no sysadmin intervention is needed for that, eh?). In that case I would support it.Jasper Deng (talk) 00:40, 3 December 2011 (UTC)
    • Actually it is. That's why the proposal. In order for the correct class to be applied to the appropriate titles in our watchlist, we need part of the Mediawiki software to be switched on. It will then apply a span wrapper with a class attribute to all appropriate titles and we then use css to style that class. None of this can be done without the support in the PHP connection between us and the database. fredgandt 00:47, 3 December 2011 (UTC)
      • The opt-out was what I was talking about here. Jasper Deng (talk) 00:50, 3 December 2011 (UTC)
        • No, the opt-out can be done locally. But let's first focus on the general proposal. Styling (or opt-out) is always an option. — Edokter (talk) — 01:33, 3 December 2011 (UTC)
          • I don't think it's a good idea but am not opposed to allowing other users have it, provided that I don't.Jasper Deng (talk) 02:15, 3 December 2011 (UTC)
            • Jasper: Would you be opposed to <s>...</s>ing out your "weak oppose" and replacing it with "neutral" per your last statement? fredgandt 21:13, 3 December 2011 (UTC)
              • I cannot support this proposal if there won't be an opt-out.Jasper Deng (talk) 23:33, 3 December 2011 (UTC)
                • Fair enough Jasper. Thanks for responding. Although, bare in mind (as discussed) there is a very simple way to override the effect even if it were installed without an opt-in. So opting out would be a doddle. fredgandt 23:45, 3 December 2011 (UTC)
• Strong support, this is the bare minimum of Watchlist usability, which is still not met. — Dmitrij D. Czarkoff (talk) 15:05, 3 December 2011 (UTC)
• Strong support, Kudpung กุดผึ้ง (talk) 16:34, 3 December 2011 (UTC)
• Strong support the minimal inconvenience of not retaining the status quo isn't a good reason for impeding progress which helps make editors more productive in their daily (or several times daily) routines. - ʄɭoʏɗiaɲ ^τ _¢ 19:15, 3 December 2011 (UTC)
• Support Armbrust ^{Talk to me about my edits}_review 21:42, 3 December 2011 (UTC)
• Support Helder 21:54, 3 December 2011 (UTC)
• Question. Some people seem to understand what this is supposed to do, but I don't. The description sounds as if it would make every line of the watchlist bold. What am I missing? On which other project(s) is this activated? Hans Adler 22:13, 3 December 2011 (UTC)

• When we visit our watchlist we see either the last changes to the pages we watch or (if chosen) all changes in chronological order that have been applied to those pages. With this functionality applied, what we see are all the same entries, but with some page title links highlighted (the style of highlight can be changed by CSS). Those that are highlighted are those pages we have not visited since the change indicated/reported. So, we view our watchlist changes at 1pm and see that we were the last person to edit Example. We then do some other stuff and come back at 2pm and see that someone has edited the page. Because we haven't yet revisited Example, it is shown highlighted. We then visit Example to see what has changed, and do some other stuff. We revisit our watchlist at 3pm and see that no one has edited Example since we visited it and there is no highlighting. So the highlighting is to let us more easily see those entries on our watchlist, that we have not visited since the last changes were made. A way therefore to keep track of which changes we have patrolled and which we have yet to.

This functionality is being used on Mediawiki for example (and many others including commercial Wikis such as The Second Life Wiki).

With this change to the watchlist there is also a new button. It is featured in the watchlist controls section above the entries. It (when clicked) allows that we can "Mark all entries as visited".

We have yet to discuss what the style of hghlighting would be, but we should first discuss whether or not we want it. The class is already in use here, and can be seen highlighting (in bold) pages that we are watching, when we see those entries in Special:RecentChanges fredgandt 23:19, 3 December 2011 (UTC)

Thanks for the explanation, and thanks Edokter for the pointer to Commons. I have tried it out now. I think if this were used here it would fundamentally change the way I am using my watchlist. At the moment, I load it once and then go throught it chronologically. With the new feature, I would probably go through my watchlist thematically and reload it all the time in order to see the markup change. If it's the same for others, this could increase server load. Maybe that's why it's currently turned off. Hans Adler 00:03, 4 December 2011 (UTC)

I use JavaScript to update my Wacthlist every 60 seconds while I'm on that page. It also checks my Watchlist every 60 seconds while I'm not viewing it and shows me if it has changed by making a little box turn green (then it stops checking until I've looked at my Watchlist). I was unsure if this would be considered inappropriate use of the servers and asked Wikimedias top programmer guy what he thought. He said "Be bold! If there are any problems someone will let you [me] know.". fredgandt 00:11, 4 December 2011 (UTC)

• The option is enabled on Commons, Meta and MediaWiki, to name but a few. (BTW. Funny to see the class applied in RecentChanges.) — Edokter (talk) — 23:31, 3 December 2011 (UTC)

• I already checked, and the <strong>...</strong> tag carrying the "mw-watched" class can have its strength (boldness) overriden. The body of the "Special" pages each has their own class, so a change to how "mw-watched" is treated on Special:Watchlist does not have to apply to other uses of "mw-watched". I'm sure you (Edokter) already knew this but others reading this may not have. fredgandt 23:45, 3 December 2011 (UTC)

• What I find 'funny' is that <strong> and #mw-watched are applied in RecentChanges even when they shouldn't, since $wgShowUpdatedMarker is turned off here. — Edokter (talk) — 23:51, 3 December 2011 (UTC)

• O.o good point. lol? fredgandt 23:53, 3 December 2011 (UTC)

• Support - overwhelmingly sensible. Pesky (talk …stalk!) 07:19, 4 December 2011 (UTC)
• I have listed this proposal at Template:Centralized discussion. Cunard (talk) 09:01, 4 December 2011 (UTC)
• Support This feature is enabled on Commons and I love it and find it extremely useful. On enwiki the only way I can be sure all the edits on my watchlist are new is to wait a few days :-P Dcoetzee 09:33, 4 December 2011 (UTC)

Really? Do visited and unvisited links not show in different colors for you? ♫ Melodia Chaconne ♫ (talk) 14:56, 4 December 2011 (UTC)

All the links are visited, because all pages on my watchlist are already in my history (because I've viewed them before). Dcoetzee 04:51, 6 December 2011 (UTC)

• support, would be useful. sonia♫ 09:49, 4 December 2011 (UTC)
• Question One thing I was curious of -- is this a real 'last visited' type of tracking, where it actually resets if you aren't on WP for a couple hours, or does it only track what you actually visit (or use the 'mark as visited' button)? The later I can get behind much more, ESPECIALLY if it simply tracks if you've visited WP or not. I utterly HATE when the 'visited' flag is raised anytime you even step onto a website, but as my WP Watchlist is my home page, it often gets refreshed when I have to reset the browser because of an error, or have been streaming lots of videos, etc. Of course as I said above, it NEEDS to be a tolerable option rather than forcing it on everyone. ♫ Melodia Chaconne ♫ (talk) 14:56, 4 December 2011 (UTC)

• It is the latter. The page link turns bold if the page is edited after you have last loaded it. — Edokter (talk) — 16:58, 4 December 2011 (UTC)

• Yes please --Guerillero | My Talk 21:56, 4 December 2011 (UTC)
• I think that I support this proposal, although I find the explanation rather unclear and I'm not sure that I really understand it. At present, I keep track of what I've looked at on my watchlist by seeing the blue links turn that purplish color they turn when the browser (Firefox, in my case) has put the URL into history. If I understand correctly, this proposal would make that functionality more robust, which I would like, and there would be ways to opt out of it if I turn out not to like it. --Tryptofish (talk) 20:01, 5 December 2011 (UTC)
  • There are only two ways you could have page title links change colour that way in your watchlist: 1) If you regularly clear your browsing history 2) If you add pages to your watchlist without ever actually visiting the page (possible by adding the titles to Special:EditWatchlist/Raw). This proposal is not to highlight what pages you have visted, but what pages have changed since you last visited them. Please see my explanation above. fredgandt 20:15, 5 December 2011 (UTC)
    • I've read your explanation numerous times, and, well, I guess I support this proposal anyway. --Tryptofish (talk) 21:01, 5 December 2011 (UTC)
• Oppose Support - I want to oppose just to make a WP:POINTy edit to show that consensus doesn't have to be unanimous (as it almost is here), but I actually like this idea. Ian.thomson (talk) 20:10, 5 December 2011 (UTC)
• Strong support A useful function, especially for those of us with longer watchlists. --Philosopher ^{Let us reason together.} 20:20, 5 December 2011 (UTC)
• Support, this would save me a lot of time, I am often unsure of what I have already checked on active pages. Peter (Southwood) ^(talk): 05:24, 6 December 2011 (UTC)
• Support. I love it in Commons and can't understand why it's not allowed here. Jim.henderson (talk) 19:31, 6 December 2011 (UTC)
• Comment. It seems that the majority of people want this enabled so I'd feel like a bit of a dick if I opposed. But if it is implemented, can it please be made opt-in? (Or, at the very least, make an easy way to opt-out – and by easy I mean something that doesn't require me to learn CSS). Jenks24 (talk) 00:42, 7 December 2011 (UTC)
• Support. I've found it extremely useful at Commons, and I've wished for a long time that we had it here. I'm not sure if it can be made optional, but I'd support making it so if it can be (why force something on Jenks24 that he doesn't want?), although the best situation in my mind would be to make it default with opt-out being a simple option in the Gadgets part of Preferences. Nyttend (talk) 03:35, 7 December 2011 (UTC)
• Support. I find it very handy on Commons. —Bruce1ee^talk 06:07, 7 December 2011 (UTC)
• Support, but only if there is an easy option to toggle this either within Preferences, or on the Watchlist page itself, so users don't need an understanding of CSS to opt-in/out. But I've always wanted something like this. Zangar (talk) 09:34, 8 December 2011 (UTC)
  • For those who don't like or want this, the css required to override the effect is minimal and will be made easily available by myself and others (should we have this feature enabled). For those who do not want to mess about with css, there will be a clearly labelled button on Special:Watchlist to "Marked all pages visited". One click of this and the stylistic change is immediately undone. So in effect there is a toggle to switch the effect off. If the feature is enabled, I would imagine the conversation would move to MediaWiki talk:Common.css‎, where the preferred default styling can be discussed along with other options. For example: If enabled, I will choose to set the style in my common.css. Some may prefer not to bother and use the default. Others may like neither the default or my style and want a particular style or have it overridden completely. I (and I imagine others) would be pleased to provide code for specific styles including full overriding. So all in all, if it is enabled, no one will have to put up with it if they don't want to. fredgandt 10:02, 8 December 2011 (UTC)
• Strong support - very useful for people with long watchlists, like myself. And can we make it optional? Sure. I suppose. And I think it'd be most useful for the savvy wikipedians, so I wouldn't be opposed to an opt-in.--Unionhawk ^{Talk E-mail} 19:39, 9 December 2011 (UTC)
• Support as a preference option - I think its more useful to more serious members. -- Eraserhead1 <talk> 22:01, 11 December 2011 (UTC)
• Strong support: I'm sure editors have better things to do than repeatedly check their watchlist timestamps and remember the last timestamp so as not to miss anything on their next login. Hope this highlighting won't require the watchlist to remain open and rather still show the highlightings that were supposed to be bold when signed in from a different terminal. I was wondering why wikipedia didn't have this feature! --lTopGunl (talk) 18:56, 12 December 2011 (UTC)
  • Log in on computer A and check watchlist. See highlight that Example has changed since you last visited it. Visit it. Close page. Login on Computer B. Check watchlist. See no highlight since Example hasn't changed since you last visited it. fredgandt 20:08, 12 December 2011 (UTC)

Precisely what I meant since current scripts would require the watchlist to stay open. --lTopGunl (talk) 06:41, 13 December 2011 (UTC)

Comments have slowed. With almost unanimous support, could we do the next step now? Who says what to whom about switching it on? fredgandt 18:09, 14 December 2011 (UTC)

Indeed. No need to wait the full 30 days. I'll post a request at Bugzilla. — Edokter (talk) — 18:48, 14 December 2011 (UTC)

Request has been filed. — Edokter (talk) — 18:54, 14 December 2011 (UTC)

Awesome. Do we sit and wait, or is it a good idea to support it at bugzilla too? fredgandt 19:54, 14 December 2011 (UTC)

This discussion is linked from there, so no need to spam the bug report. — Edokter (talk) — 19:57, 14 December 2011 (UTC)

• Good to see the gears are turning already. I would strongly support this too; it would help the watchlist do what I really use it for (all too often I look at the last diff, then click through to the history to look at changes since I was last there...). bobrayner (talk) 19:53, 15 December 2011 (UTC)

How much time is expected for this to get implemented? --lTopGunl (talk) 21:56, 19 December 2011 (UTC)

It is already implemented, it only needs to be enabled. — Dmitrij D. Czarkoff (talk) 09:34, 21 December 2011 (UTC)

And that would take? --lTopGunl (talk) 11:14, 27 December 2011 (UTC)

The enabling itself is only adding/modifying one line of code on the servers. I don't know how long it would take to update the code on all server, but I would guess no more than a few minutes. Rabbitfang 07:27, 28 December 2011 (UTC)

It appears (from reading the conversation at bugzilla) that there are concerns about the number of extra database reads and writes this might cause. Due to the extremely high traffic here, I'm not surprised there are concerns. The shame is, that rather than seeing a problem and fixing it, my guess is that the problem will more likely be shoved under the rug and forgotten. Fingers crossed though. fredgandt 08:05, 28 December 2011 (UTC)

Right. No wonder it was not enabled yet. --lTopGunl (talk) 11:04, 28 December 2011 (UTC)

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

Wiki-center where people can "work" 5-25h/week against hourly wage

The model I think could work, in Sweden as well as in other countries, is this. The city/commune (or the state) put in some money, for example by transferring money from the unemployment benefits to this sector (less people would be full time unemployed and the students wouldn´t have to borrow as much). Then wiki-centers, or perhaps first wiki-associations, will be founded. Students who have spare time, or anyone who wants to work with wikipedia (or wiki-work in general), will be allowed to apply for work in these centers. I don´t think full time is good, but maybe 5-25 hours a week and with some time limits (one, two or three years) so that many people get the chance, not just a few. One could arrange this in several ways. One way could be to arrange it like a paid course (which means that there has to be teachers as well, who obviously have to get some kind of wiki-teaching degree first). And if it´s arranged like a course one could have several levels, the first levels are general (understanding the concept and how to search information), then some levels where editing is practised (writing articles, translating articles, cleaning articles, engaging in debates and so forth), and last but not least - to go to schools, libraries and universities to hold lessons, and the same for newcomers. Many people will probably instinctively say no, because it feels like the neutrality will be lost in some way (bias). But with this concept I don´t see this as a major problem. If, for example, the city of London finance some wiki-centers in London and then the people who get part time work there can write whatever they want, or do whatever wiki-work they want, no matter if they produce one or one million articles, the payment is the same (hourly payment for example) - then it is hard to tell how this could be judged as a biased-wiki-work. I especially think that wiki-centers like this should be established in Africa, the best locations would be close to universities. The main reasons are 1. People there need employment, and students needs money to finance their studies. 2. It would be good for the democracy and general knowledge. 3. It would be good for Wikipedia at large because Africans will probably write about Africa quite a lot, and Africa is not covered so much. But I can also think of good arguments for similar arrangements in Europe and other "rich" regions. Employment/income/democracy/inclusion/youth and student politics/good for the development of Wikipedia (new groups will join) and so forth. --Mats33 (talk) 15:48, 22 December 2011 (UTC)

• I don't see neutrality being a problem. However, this is far beyond the reach of Wikipedia or the WikiMedia foundation. To organize anything along these lines would require the involvement of multiple institutions and organizations under the governance of a global administration. It might be possible to convince local governments/councils to organize local funds for educational projects, but for those projects to be so firmly linked to Wikipedia, is likely to be any such suggestions death-nail. For local governments to direct funds away from any other sector (benefits or otherwise), would not be done lightly. I strongly doubt any local government/council would consider wiki-centres a worthy use of their limited funds. Perhaps schools and/or collages/universities at a local level could be convinced to do more work with Wikipedia, but there are already projects like that under way (so I believe). I'm sorry, but the grand scope of this idea would require some sort of new world order or the backing of some private philanthropist (you could ask Sting). fredgandt 16:13, 22 December 2011 (UTC)

I've always said that if some Bill Gates character came along and decided to chuck a few billion towards Wikipedia, and chose to pay to have some kind of hermetic community of editors spend their days editing Wikipedia, that would be fine by me. The issue with "paid editing" as we call it is the fact that it almost always brings with it a WP:COI. If BigCorp Inc. paid for you to write about BigCorp Inc., that's a COI issue. If some mad millionaire wanted to pay someone a living wage to churn out articles on obscure philosophers, I don't see what the issue would be. Of course, I don't see anybody really wanting to pay people to write the sort of stuff we'd want, so it's all a bit hypothetical at the moment. —Tom Morris (talk) 17:36, 23 December 2011 (UTC)

The Google Foundation did at one point. See Wikipedia:WikiProject Medicine/Google Project. We got some very good reviews of articles from professional medical writers as a result. WhatamIdoing (talk) 02:20, 24 December 2011 (UTC)

• I think this is definitely desirable. Though it is beyond the power of Wikipedia, we are currently facing the prospect of severe damage from the copyright model of rewarding authors (see Wikipedia:SOPA initiative). At some point we need to go from defending ourselves tactically, opposing this and that vote and defending a status quo in which it may indeed become harder for authors to receive compensation, and boldly propose a system whereby individual taxpayers are required to pay a certain amount to funding organizations for the arts, individually choosing which organizations, so that artists are rewarded without any copyright limitation on the distribution of creative works. One consequence of this system would be that an organization to reward productive Wikipedia editors would be just as feasible as one to reward Oscar-winning actors - non-copyrighted authorship would no longer go unrewarded. Wnt (talk) 05:43, 31 December 2011 (UTC)

Proposal: Message to the Foundation r.e. GoDaddy

Recently is has emerged that GoDaddy, a domain name registrar that the Wikimedia Foundation use, have come out in strong support of SOPA. It has made big news and there is a movement by lots of companies and individuals to move all service away from GoDaddy. (see http://www.reddit.com/r/politics/comments/nmnie/godaddy_supports_sopa_im_transferring_51_domains/) Obviously there is no fault in the Foundation here - but it would be nice to see them take the same action. I propose that the community supports a message to the foundation (as obviously this is not a decision we can make ourselves) to move away from GoDaddy. Something like:

The English Wikipedia community, in light of GoDaddy's support of SOPA, believe that the Wikimedia Foundation should move any services away from that company in protest at their position.

Obviously actually doing so will be a pain in the neck. But it would be nice to show the Foundation we support such an action. --Errant ^(chat!) 15:51, 23 December 2011 (UTC)

• Support as proposer --'Errant ^(chat!) 15:51, 23 December 2011 (UTC)
• Support This could make a nice big splash and would be a relatively harmless way to show solidarity with the anti-SOPA movement. The actual implementation by the Foundation might take a bit of time and planning to do, but the point would be that simply announcing that they are going to move would be an important way to signal opposition to SOPA, and solidarity with all those who are against it. —Tom Morris (talk) 16:09, 23 December 2011 (UTC)

  I'd also like to note that in the Reddit threads, there are a LOT of people who have said that if the Foundation do this, they'll donate. Even if not everyone who has said they will donate actually go through with it, there's probably a couple thousand dollars. That's a pretty damn good reason to move. —Tom Morris (talk) 16:58, 23 December 2011 (UTC)

• Support. Great idea. Choyoołʼįįhí:Seb az86556 ^{> haneʼ} 16:24, 23 December 2011 (UTC)
• Support. Individuals could go further and send discard notices to correspondents who's email domain is registered through GoDaddy. Jc3s5h (talk) 16:34, 23 December 2011 (UTC)
• Support. --SarekOfVulcan (talk) 16:45, 23 December 2011 (UTC)
• Support just another reason to why we should not use godaddy --Guerillero | My Talk 16:55, 23 December 2011 (UTC)
• Support. I have no idea how much of a nightmare it would be for an organization the size of Wikimedia to change registrars, but if it is feasible, it would be the right thing to do. Resolute 17:01, 23 December 2011 (UTC)
• Support. Wikipedia is directly funding a company that, in turn, makes significant payments to the politicians driving this bill. For the 2012 election cycle, GoDaddy's PAC has so far made contributions to 13 candidates for the House of Representatives ([10]). Six of those donations went to co-sponsors of the original SOPA bill (including the Representative who introduced the bill, Lamar Smith). In other words, the Foundation's dollars are being used to influence politicians to act directly against this project's interests. Note that there is additional community discussion at WP:SOPA to determine what actions (if any) Wikipedia should consider in response to SOPA. TenOfAllTrades(talk) 17:03, 23 December 2011 (UTC)
• Support CharlieEchoTango (contact) 17:03, 23 December 2011 (UTC)
• Oppose The "English Wikipedia community" is not organized to make politicized statements like this. Townlake (talk) 17:05, 23 December 2011 (UTC)
• Oppose - another "We must do something - now!" response.  An optimist on the run! 17:14, 23 December 2011 (UTC)

  Actually, no, it isn't. The only thing that would be done would be telling the Foundation that the consensus of the community is that it'd be nice if they could stop using GoDaddy. The Foundation could then, if they agreed, make an announcement that they intend to stop using GoDaddy as soon as is practical, and ask the tech staff to do so. It'd be nice to signal the community's intentions (if indeed they have an interest in doing this) sooner rather than later, and it'd be great if the Foundation could strike while the iron is hot, but this doesn't commit the Foundation to doing it in any particular timeframe. —Tom Morris (talk) 17:21, 23 December 2011 (UTC)

  Just a thought - is there any verified evidence that this is GoDaddy's stance?  An optimist on the run! 17:24, 23 December 2011 (UTC)

  Yes. —Tom Morris (talk) 17:28, 23 December 2011 (UTC)

  In addition to their statements, GoDaddy's PAC (funded primarily by GoDaddy's senior management) contributes to the campaigns of politicians who introduced and cosponsored the bill. TenOfAllTrades(talk) 17:34, 23 December 2011 (UTC)

• Oppose as yet more political propaganda creeping its way onto a "neutral and balanced" site. — Joseph Fox 17:32, 23 December 2011 (UTC)

  Sorry, but how would it do that? The Foundation agree that SOPA is bad, all this is about is nudging the Foundation to switch away from buying services from a company who act in opposition to the intentions of the Foundation. If it were to happen, there would actually be no change to Wikipedia or any WMF sites, just to their DNS entries. It'd be a good way to express solidarity with opposition to something the Foundation have already agreed goes against the best interests of the site. —Tom Morris (talk) 17:41, 23 December 2011 (UTC)

  It is therefore not a neutral route, of course. And I'm pretty sure Go Daddy aren't going to lose sleep over a client switching away from them, really. — Joseph Fox 17:44, 23 December 2011 (UTC)

  Not one, no, but many many multiple ones, as inspired by the reddit post that discovered this information. --MASEM (t) 17:58, 23 December 2011 (UTC)

  Also, considering the bandwidth and number of domains used by the foundation, this will be a helluva scratch in their paint. - ʄɭoʏɗiaɲ ^τ _¢ 18:00, 23 December 2011 (UTC)

  The Foundation don't use GoDaddy for hosting, just for domain registration. That is still probably a couple hundred dollars a year. The symbolic value is more important: when people see the Foundation changing supplier, that'll prompt others to do likewise, and it'll show solidarity with people who are opposed to SOPA. Supporting companies who act against the best interests of the projects (which is something the Foundation have accepted, see Geoff's blog post). —Tom Morris (talk) 18:15, 23 December 2011 (UTC)

• Support. Salvio ^{Let's talk about it!} 17:36, 23 December 2011 (UTC)
• Comment While they're at it, why don't we transfer wikimedia servers outside of the United States. The united states, as much as it likes to believe it does, does not control the internet at all. I can see the .com and .net domains fading into second-class usage if SOPA is passed, as another non-censored domain takes their place... Either that or this will turn into something like International Draw Mohammad Day, where EVERYONE posts a copyright link to the whitehouse website then submits a piracy notice to the US government ordering their website be removed or face legal action under their own bill. - ʄɭoʏɗiaɲ ^τ _¢ 18:00, 23 December 2011 (UTC)
  • OT comment Well, that's a bit of a mixed bag. The US by and large still has the best protections for freedom of speech of any plausible location. We wouldn't want to put them in Germany where we might not be able to cover the Horst Wessel Lied, or the United Kingdom, where defamation law is notoriously plaintiff-friendly and truth is a somewhat unreliable defense. On the other hand it would be nice to have freedom of panorama, which we don't in the States. --Trovatore (talk) 21:40, 23 December 2011 (UTC)
• Question Is DNS registration the only service that WMF gets from GoDaddy? If so, the bandwidth issue is trivial, as most (and all serious) ISPs would already cache the major project sites' DNS results. LeadSongDog come howl! 18:15, 23 December 2011 (UTC)
• Support. The WMF has already expressed its opposition to SOPA, with good reasons. It should not continue spending donors money on a company that has been so outspoken in supporting the act. the wub "?!" 18:24, 23 December 2011 (UTC)
• Strong support – Stop supporting your own destroyers. We shouldn't fund those who would rather see our work destroyed or compromised. Perhaps we can even convince GoDaddy and others that continuing to support SOPA will harm their reputations and revenues. --Michaeldsuarez (talk) 18:31, 23 December 2011 (UTC)
• Oppose Ill advised for the reasons stated by the other opposers and by myself in previous posts. SOPA is inapplicable to Wikipedia. We are now setting the bar for political activisim somewhat low.--Wehwalt (talk) 18:37, 23 December 2011 (UTC)
• Comments Here is a cached copy of GoDaddy's blog post on their position (the page seems to have been moved or blanked (no surprise considering the battering they are getting in the press)). They make some interesting points, well worth reading.
  • The media have jumped on this, and GoDaddy is being dragged through the mud. Consider how Wikipedia would also be dragged through the mud if it chose to get dramatically involved in large scale public protest or (not that it is suggested) support. The media are not moral; they sell news. Any news they can make sensational sells copies of their stink. Support, oppose, or remain neutral; whatever Wikipedia does that is seen clearly as a public demonstration, will give the media a chance to spin it any way they can to sell more stink.
  • Whether Wikimedia support or opposes SOPA should be done relatively quietly, since Wikipedia is their baby and the world at large knows it. Whatever WMF do loud and in public will effect Wikipedia directly. fredgandt 19:10, 23 December 2011 (UTC)
• Wow! In the time it took to type the above, GoDaddy killed the cached page and replaced it with a statement, that they are no longer supporting SOPA. fredgandt
  • FYI I saved a plain text copy of GoDaddy's statement about their retracted support. I've dumped it on my sandbox. It's not formatted, but all the original text is there. See User:Fred_Gandt/sandbox#GoDaddy_statement_in_support_of_SOPA (removed by me) if you're interested. fredgandt 19:57, 23 December 2011 (UTC)

I'm gonna suggest we close this now: Jimmy has weighed in on User talk:Jimbo Wales and on Twitter, saying that the Foundation have agreed to move away from GoDaddy. Seems like there's not much point in continuing with this proposal. —Tom Morris (talk) 19:12, 23 December 2011 (UTC)

• Info GoDaddy's withdrawl of support for SOPA. LeadSongDog come howl! 19:47, 23 December 2011 (UTC)

Bogus withdrawal of support. The only message they got was that they were losing money. "Fighting online piracy is of the utmost importance, which is why Go Daddy has been working to help craft revisions to this legislation" Now they support some minor unspecified revision to this turd. "It's very important that all Internet stakeholders work together on this" They still support the goddamn thing, and they say it's important that we support it too. "Go Daddy will support it when and if the Internet community supports it." Their withdrawal of support is temporary! LOLZ. I wish I had an account with them just so I could move it away. Alsee (talk) 17:14, 24 December 2011 (UTC)

• Support. See [11]. There is real reason to worry that a company supporting SOPA would be more prone to abuse its discretion to suspend domain information on its own initiative, for example if we got into a dispute with some third party about the Commons PD-Art tag. Choosing a more like-minded registrar potentially shields Wikipedia from some unexpected dispute, preventing foes of free content from hitting us by surprise with a newsworthy controversy despite the lack of any legal leg to stand on. Wnt (talk) 05:47, 31 December 2011 (UTC)

Keep record of deleted image revisions

For an NFCC image like File:Cape Air logo.svg, previous revisions get deleted by a bot when the image is modified, to meet the fair use criteria. I know it's technically messy, but it seems it would make sense to leave a record of the original versions in an altered form like

13:11, 20 March 2009		SomeUser
05:53, 19 March 2009		OtherUser
05:51, 19 March 2009		SomeUser

just a thought. —Designate (talk) 23:26, 23 December 2011 (UTC)

• Why? fredgandt 00:41, 24 December 2011 (UTC)

Here is a real example; a user uploads a high resolution scan of magazine cover. After a while someone else tags it as NFCC, resizes the image and writes a Non-free use rationale. A year or so later another user finds the copyright was not renewed and changes it to a free image. Does this third user know there was a high resolution scan? And in this case the original uploader had retired from Wikipedia. It is nice that non-admins know the history. -- SWTPC6800 (talk) 03:58, 24 December 2011 (UTC)

This is standard practice on Commons and I would Support modifying bots to do the same here. Dcoetzee 21:14, 25 December 2011 (UTC)

A standard practice on Commons is to... what exactly? This seems to involve fair use which isn't a part of Commons' scope. Killiondude (talk) 03:53, 27 December 2011 (UTC)

Sorry for being unclear. Frequently, photos of paintings including frames are uploaded under the "PD-Art" license tag on Commons. This tag forbids the inclusion of three-dimensional frames for legal reasons. After the frame is removed by cropping, the old version of the image (which is not legal to distribute) is routinely revdel'ed, while leaving the uploader username and upload date intact. Dcoetzee 04:36, 27 December 2011 (UTC)

• The history is still accessible in the "View History" tab, so this is more a kindness to people that don't think to check there. That being said, I've seen admins preform revision deletions where the old thumbnail is gone but the uploader and description remain, however I've been told that it's longer and more complicated to do it that way. I would be against forcing admins to use this method, mostly because the uploader history is still available, and there aren't that many admins willing to work in files as it is; however there are a few things we could do:
  • Create a bot that adds a template to all files resized by DASHBot - that template would mention that the file has been reduced in size per the NFCC, and that a history of previous uploaders can be found in the page's history.
  • Modify DASHBot (with the author's permission) to add the upload history, in text, to the file description page when it works (718 bot did this)
  • Encourage (but not mandate) admins to use the method that only disables the thumbnail, not the rest of the information. Sven Manguard Wha? 21:13, 30 December 2011 (UTC)

Wikimail public email service

Hi there! First I want to say it is wonderful that few people could achieve the web rank 5 with much humility compared to the big corporations leading the internet. We definitely need people like you all, full congratulations!!

Second, I woke up this morning, went on my yahoo account and thought : 'I'm really bored to have no choice seeing all the very uninteresting and brainwashing advertisement we don't have choice to see if we want to access our inbox. Google is probably better on that issue, but yahoo is definitely terrible. I think Google is also not so interesting because I don't actually want an email service to analyse what I write in my emails so the robot than pushes in some publicity in accordance with my interests. And about hotmail, well I just don't want to use it, too risky for privacy violation.

So this morning when I woke up, I just thought : 'Why is there no public email service with Wiki?' I've seen a website named www.wikimail.org, but it looks nothing like a public email service. Are you developing a public email service?

I thought if this happens, you would reach more people on an everyday basis because probably the majority of Wiki users, readers, etc will go on their emails more often then on Wikipedia. You could touch more donators because you could insert a button on the "Wikimail' Homepage that says "Donate" with a nice picture of Jimmy Wales for example. Their could also be a search engine directly embedded into the email accounts so the Wikimail users don't have to quit their inbox to search into Wikipedia. I'm sure there's a lot more to develop, but the main idea is that at last we could access a public email provider who respect the fact that a lot of people don't want to feel obligatory to see those "news" for example on yahoo homepage that seems only to serve the purpose of flashing out rather than inform the readers. And our writing hopefully would not be analysed by a robot that than send us aimed publicity for "our own good", or "for a more personalized experience" which is actually not true. It serves only the purpose of big corporations, not ours...

Wikimail could have a homepage with newly posted articles on Wikipedia for example, but at least it would be genuine information, something that makes you grow and when the people feel they are treated with integrity, they will donate. You will definitely get more donations. The question is, will these donations make a difference in your fundraising given that an email service needs also money to run. Well only you can tell. But at least, I can tell myself I had a nice idea when I woke up this morning!! I thought important to share it with you guys. Long life to Wiki!!!

Charles P.

Montreal, Quebec — Preceding unsigned comment added by Charlpelti (talk • contribs) 17:21, 28 December 2011 (UTC)

• Oppose - Thanks for the nice words, Charles. We're most all part-time volunteers here, so in a way nobody is "Wikipedia" and everybody is "Wikipedia" — but we all do appreciate compliments from those who don't dwell in the labyrinth of seldom-seen "backstage" pages like this one. Wikipedia volunteers spend a huge amount of time each year fighting vandalism and assorted nonsense. I'm afraid that public email would be a vast new playpen for such miscreants. While it would be nice to advance the noble cause of non-commercialism one more baby step, the cost of the program in terms of volunteer time would far exceed the potential gain to society. In my opinion we need to keep things focused on writing and maintaining a better encyclopedia. Best regards, —Tim Davenport, Corvallis, OR //// Carrite (talk) 17:56, 28 December 2011 (UTC)

• Understood - Hi Tim! Thanks for your reply. I do understand more now the work all you are doing. I do see myself that email services always fight tremedously against Spams, etc. This is actually so unfortunate... Of course I dream of a world in which everyone respects the work of each other, but obviously we don't live in such a world now. So I fully understand your point. Maybe one day... Best to you, Charlpelti (talk) 13:04, 30 December 2011 (UTC)

• Interesting. Wikipedia already does much of the functionality of e-mail with the "email this user" feature, but because you can't access it directly via a web or mail reader interface, it depends on another account to receive the messages. I should note that there are far better options than hotmail - there's a free site cooltoad.com where you can type in your data and you're good to go, no paper chase for another address, password you can remember, more than one address if you want it, no ads, no spam ... I wonder how they even manage to offer the service at all without getting stomped by the NWO, let alone what their motivation is for doing so, but it is indeed a better option. In any case WMF should consider the idea: look at the costs, evaluate the value of the outreach it could obtain. Wnt (talk) 05:35, 31 December 2011 (UTC)

Watch the sections (as opposed to watch the whole page)

• Note: this topic originally referred to "threads" instead of "sections". ▫ JohnnyMrNinja 08:38, 23 December 2011 (UTC)

I would propose a feature for a Wikipedia: namespace to watch only specific threads. On big pages like this one or noticeboards the editor can be interested in a particular thread, but watching it becomes more difficult when there are many threads and some of them are buzzy. — Dmitrij D. Czarkoff (talk) 09:29, 19 December 2011 (UTC)

• Support with opt-in or opt-out: this would be useful as suggested in a thread above as well. --lTopGunl (talk) 09:34, 19 December 2011 (UTC)
• Support, but see Wikipedia:Perennial proposals#Allow watchlisting individual sections of a page.  An optimist on the run! 09:35, 19 December 2011 (UTC)
• Support, though what we should be voting for is an opt-in beta of Wikipedia:LiquidThreads. They keep testing it out on other wikis, though things would move a lot faster if they allowed approved enWP users to try it out on their talk pages (or on a special beta page in their userspace). Liquid Threads is currently the only tech capable of making this happen on WP, and it was started in 2006! ▫ JohnnyMrNinja 09:49, 19 December 2011 (UTC)
• Suggest Unless you really meant threads, I recommend changing the proposal to "Watch sections (as opposed to watch the whole page)". I'd support that for sure. Saves doing it all by user script. And I imagine quite trivial to create and install. fredgandt 11:40, 19 December 2011 (UTC)
• Support as an "opt-in or opt-out" feature, providing it is not overly difficult to implement. Would be highly useful and convenient for editors interested in watching only a particular discussion.--JayJasper (talk) 22:57, 19 December 2011 (UTC)
• Support this idea, but acknowledge the complexity (and current impossibility) of implementing this. See bugzilla 738. Steven Zhang ^{Join the DR army!} 23:08, 19 December 2011 (UTC)
• Support the idea. On Portuguese Wikipedia/Wikisource Village pumps (example) it is used a system of subpages transcluded into the main page, so that people can (un)watch individual topics. There is also a proposal here for using a script to make the system a little more user friendly. Helder 00:18, 20 December 2011 (UTC)
• Comment We can all jump up and down and support this in principle, but unless there is consensus to install LiquidThreads, I'm not sure what we are going to achieve by writing comments and putting words in bold before them. And, trust me, to install LQT, we're gonna need a lot more consensus than this. —Tom Morris (talk) 09:09, 20 December 2011 (UTC)
• Support. I don't know which is the issue with liquid threads, but that was not the original proposal, nor it is unavoidable to achieve the desired result. See Template talk:Did you know, Wikipedia:Peer review, or Wikipedia:Featured article candidates (see their structure, not their specific purpose). They have individual pages for each nomination, transcluded into the main nominations page. So just change "nominations" with "discussions", and the system can work equally well for plain discussions. Cambalachero (talk) 13:15, 20 December 2011 (UTC)
• Comment it's very complicated to implement this and there is already LQT extension which support this and works great, so I don't believe anyone would be interested in integrating this feature. So even if this reach support I doubt it change anything. You should consider a proposal of installation of liquid threads instead. Petrb (talk) 14:09, 20 December 2011 (UTC)
• Comment AFAIK, all requests to enable LQT on new wikis are marked as LATER until the extension is completely rewritten (see mw:LiquidThreads 3.0 and the recent status updates). Helder 15:18, 20 December 2011 (UTC)
• Oppose While it would be useful to be able to watch a specific discussion, if the intent is to use LiquidThreads, this is a very bad idea. Liquid Threads adds unnecessary complexity to talk pages and gives talk pages an appearance similar to a forum. Alpha_Quadrant ^(talk) 15:42, 20 December 2011 (UTC)
  • Not "my" proposal, but it isn't to install LiquidThreads; it's to enable watching sections (as I read it (see my suggestion above)). You're opposing comments made by others. fredgandt 18:20, 20 December 2011 (UTC)
    • The exact wording of the proposal is threads. Current Wikipedia talk pages do not have threads, they have sections. I would support the implementation of section watching, providing it does not come in the form of liquid threads. Currently, LiquidThreads is the only technical way to implement this proposal. Until that changes, I am opposed. Alpha_Quadrant ^(talk) 18:24, 20 December 2011 (UTC)
      • It was my assumption that the use of the word "threads" was just semantics and did not refer to technical threads, just any way to watch part of a page as opposed to the entire thing. I thought it was quite obvious from the post that the poster was talking about the "sections" on a page. I'm sure it is enough to put a qualified "support" if you oppose the use of LiquidThreads. -MsBatfish (talk) 20:38, 21 December 2011 (UTC)
      • Indeed I used the word threads to refer to what technically appears to be a section. I didn't actually know about the LiquidThreads by then. Though I support the LiquidThreads, if there was any implementation that only allowed watching the specific sections, didn't change anything else and could be used right now, I would support it. This thread is not about LiquidThreads. — Dmitrij D. Czarkoff (talk) 07:20, 23 December 2011 (UTC)
• Oppose Mugginsx (talk) 19:38, 21 December 2011 (UTC)
• Support: I myself have thought numerous times that some sort of section-specific watch would be very useful on large, frequently-edited discussion pages (like this one). Unfortunately, it is my understanding that this has been brought up before but turned down with the rationale that the developers are already working on implementing LiquidThreads in the future, which will make Wikipedia discussion pages like the ones on forums or bulletin boards. Not sure if I fully like that idea. Why can't we support the idea of watching sections without supporting the idea of LiquidThreads? It seems unproductive for people to say we have to either implement LiquidThreads or leave it exactly the way it is. Surely (as mentioned above) there are other ways to implement something like this? -MsBatfish (talk) 20:38, 21 December 2011 (UTC)
• Comment: I could very much support the OP assuming "sections" is intended, and only if it's technically feasible to integrate it without having to use scripts or add-ons. But I've run into liquid threads at Wiktionary, and there's no way on God's green earth I'm going to fart around with those. That's equivalent to a slammed door in my face. Milkunderwood (talk) 08:27, 23 December 2011 (UTC)
• Support watched sections However, there is a technical issue or two that would make this less than straightforward to implement (though far from impossible). The major issue is that section titles can change (at any time (as this section title did just recently) and very easily (no consensus or admin needed)). So each would need to be tagged (on creation) in such a way that it could be tracked, even if its name changed. A UUID of some kind would solve the problem, but would require programming to be written that currently either doesn't exist (in MediaWiki) or would need tweaking from code not specifically designed to do this job. The current software will automatically pick up a page name change and switch our gaze to watch the new title, whilst keeping (dependent on settings I think) an eye on the original title too (redirects are italic for me). Also, the current software deals with deleted titles ok. We just end up watching a red link. So it seems to me, MediaWiki already has a basic blueprint for new programming to implement this (although not straightforward). fredgandt 00:38, 24 December 2011 (UTC)
• Comment I believe that this might lead to inaccuracies with editing the section via the editsection link versus editing via the edit page link. Also, if multiple sections are changed at once there may be an inaccuracy problem as well.  Hazard-SJ  ㋡  00:19, 28 December 2011 (UTC)
• Oppose This is technically impossible given the current structure of Mediawiki without the use of Liquid Threads (Which I also don't support) due to the following facts:
  • Scanning the entire page edits for sections and then doing detailed comparisons to the previous text would introduce further and unacceptable server load due due to the fact that revision text is stored as a whole without any care regarding sections on the page and it would add a *stack* of SQL queries and processing to achieve what you desire.
  • Watching a section doesn't take into account sections before or after the one you are watching, hence, in the case of article pages I could put a comment tag at the end of the section above and a comment tag in the start section below to remove a section without triggering a watchlist notification (just an example).
  • There is no way to uniquely identify sections on a page. For instance, if you watch a thread called "Sock Puppets" on ANI and someone adds another thread later down the page with the same section title, both sections match the watch list condition and you'd get mixed messages from both. Furthermore When a section is removed the watch would need to also be removed to prevent buildup in the watchlist table, this means every time an identical named section is added and then removed you would loose your watchlist entry all together.  «l| Promethean ™|l»  (talk) 01:09, 31 December 2011 (UTC)
• Oppose I was about to list out some reasons why using the current software makes this a WONTFIX, but I see Promethean has just done a pretty good job (though I haven't really looked at LT, so can't offer an opinion on that). The workaround for this project is to use an automatic page-maker so that individual sections are contained on separate pages and the overlying page transcludes the sub-pages. User:Coren wrote a bot a few years ago that would automatically sub-page new sections and tested it briefly on a noticeboard (I think that's where it trialled). It seemed to work OK but never went anywhere, maybe someone should ask Coren for the code. Franamax (talk) 23:19, 31 December 2011 (UTC)
  • There were no technical problems with the system, really, but I've never managed to raise sufficient consensus to deploy it anywhere (there was an open question about whether the subpage should be named for the section or by some sequence number that never got resolved because it was moot). It was fairly robust, and I could probably dust the code off and redeploy it if there is consensus that it could be useful. Certainly, I liked how it did thing – but I'd be really odd if I took the time to code a bot that did something I didn't like.  :-) — Coren ^(talk) 23:52, 31 December 2011 (UTC)

Provide options for login cookie expiration times

When we log in to Wikipedia, we are asked (checkbox) if "Remember me (up to 30 days)". I'd like to be able to select the length of time from a list of options. Would you?

I suggest: Adjusted per User:Optimist on the run's suggestion

<select>
	<option>1 day</option>
	<option>1 month</option>
	<option>Indefinitely</option>
</select>

The preselected option could remain 30 days (1 month) and "indefinitely" could be undone any time the user logs out (obviously cookies are computer specific). fredgandt 08:57, 30 December 2011 (UTC)

Seems a reasonable idea, provided we're happy for users to take responsibility for their own security, though I don't think there's a need for so many options. 1 day, 1 month or indedfinite would be sufficient IMO. How would this work if users logged on to different machines? I'd want a shorter cookie for my office computer than for my home one.  An optimist on the run! 12:01, 31 December 2011 (UTC)

That would be exactly how it works. Each computer stores its own cookie, and as far as I know, there is no record made on the database regarding our selection (at present or required by this proposal).

Fewer options would be fine by me. Perhaps a compromise between my and your suggestions? 1 day, 1 month, 3 months, indefinite? No actually, I think you're right. I just thought, "if we're going to have options, have options". but the three you suggest would be quite adequate. fredgandt 12:10, 31 December 2011 (UTC)

• I have edited my cookie once... I don't need to login any more. (except on new computers, after cleaning it up). Regards, mabdul 14:38, 31 December 2011 (UTC)

Not so simple for the average user. This would be a clicky solution to a problem your actions have highlighted. If there wasn't a need for this, you'd not have had to edit your cookie. fredgandt 20:08, 31 December 2011 (UTC)

Mirror deletion nomination from commons

What about using bot to

• insert something like this on description pages of files nominated for deletion on commons
• notify enwiki uploaders.

It may rescue part of files (as more people interested in keeping useful files will know about deletion notification) and reduce need for things like Template:Keep local (it is impossible to use enwiki watchlist to watch file on the commons but it is possible to watchlist local page). Bulwersator (talk) 15:58, 31 December 2011 (UTC)

• • If files are on Commons, they typically have no file information pages here. Besides, if file information pages were to be created here each time a file is proposed for deletion on Commons, admins of English Wikipedia would have to delete lots of file information pages once the deletion requests finish on Commons. Better options:
    • When tagging as {{NowCommons}}, also notify the uploader(s) on their talk pages (Japanese Wikipedia already requires this, and tools such as For the Common Good or Commons Helper could do this automatically if you ask them to tag with {{NowCommons}}. This way, English Wikipedia users notice the move, so they can watch the Commons file instead.
    • Add an option to receive an e-mail whenever a page on your watchlist is changed. Commons, Meta and other projects already offer this, and I think that this option is very useful on those projects. I'd want to receive those messages here too. --Stefan2 (talk) 21:02, 31 December 2011 (UTC)

Assigning editors in chief

After several attemps of revising and adding references to some Wiki articles, I realized that Wiki's editing policies only encourage jobless Wiki bullies, who pride themselves in undoing other people's nice editing. One of such person is "(Redacted)" (a 'Wikipedian'), who is notoriously busy with deleting.

I let my student understand this phenomenon by giving an editing example in class to see how such Wiki bullies react in a flash of light. It is my opinion, and many people's, that if Wiki wants to grow stronger and receive donations, Wiki should maintain good characters by assigning responsible experts for each pages (editors in chief). — Preceding unsigned comment added by 220.128.221.59 (talk • contribs) 05:22, 31 December 2011‎

How would you suggest this be done? There are nearly four million articles. No one can be "assigned" since we're all volunteers, and a true expert likely has better things to do than babysit a few thousand articles for free. — Huntster (t @ c) 11:29, 31 December 2011 (UTC)

Oppose Per WP:SNOW Pol430 talk to me 12:25, 31 December 2011 (UTC)

• Suggest proposer examine Citizendium to see how his suggestion works in practice. --Allen3 ^talk 12:35, 31 December 2011 (UTC)
• problem: "jobless Wiki bullies" solution: "editors in chief" - seriously? Bulwersator (talk) 12:40, 31 December 2011 (UTC)
• @IP - please, read Wikipedia:No personal attacks Bulwersator (talk) 12:42, 31 December 2011 (UTC)

No point in this discussion. This IP is complaining because his self-promotional external link additions have been reverted. Nageh (talk) 12:51, 31 December 2011 (UTC)

Don't be silly. And don't be rude. Also, don't walk around with a chip on your shoulder about "Wiki bullies", especially if you're a teacher. And if you're a teacher, please don't refer to Wikipedia as "Wiki". There are other wikis in the world. — JohnFromPinckney (talk) 13:23, 31 December 2011 (UTC)

Oppose Per Citizendium - it simply doesn't work! (see also the bottom of the talkpage!) mabdul 14:45, 31 December 2011 (UTC)

• Heh, Citizendium lives again. Because, at Citizendium, formalizing the informal power held by editors caused absolutely no problems. I mean, it's not like they appointed a dishonest promoter of fringe theories to guard over the Homeopathy articles... oh, wait. —Tom Morris (talk) 15:19, 31 December 2011 (UTC)
• Redacted username. Also Oppose, as what would be the distinsion? them being able to delete but the rest no? It just doesn't work. ~~Ebe123~~ → report on my contribs. 15:41, 31 December 2011 (UTC)

This controversy appears to concern Talk:Arbitrary-precision_arithmetic#Link_to_article_about_undergrad_project. Though I like to think of myself as scientifically literate, I have absolutely no idea whether this external link contributes significantly to the article or not. I think an "editor in chief" would be as clueless as I am. The right way to deal with these things is to seek third opinions from experts who can look at the situation impartially. There is a Wikipedia:Third opinion process, though WikiProjects such as the WP:WikiProject Mathematics and WP:WikiProject Computing linked at the top of the talk pages have their own talk pages for recruiting experts. None of these processes work very well - Wikipedia does have real problems with deletionism, which since the aggressive BLP policies of 2007 has halted its expansion and left everything here undermanned. But editors in chief would not work well either, and the problems they would cause would be worse. Wnt (talk) 17:37, 31 December 2011 (UTC)

Why do Wikipedians always generalize when they say that we don't have the expertise to understand something? How do they think all our expert articles are being created? By outside exerts? With all respect, the paper that was linked is trivial enough, in fact to a level that amazes me of being published in a journal. While being on-topic (WP:EL), it does not contain any further research to the article (WP:EL), and rather discusses a straightforward implementation of arbitrary-precision floating point numbers using Fortran. Really nothing new in there. While it could be added if other editors think it is appropriate, the principal problem that has been correctly identified is that the IP has a COI with adding his paper to various of our articles. Nageh (talk) 18:21, 31 December 2011 (UTC) PS: Happy New Year everyone! Nageh (talk) 18:22, 31 December 2011 (UTC)

• Oppose and not just per Citizendium though that alone is reason enough. We have many experts, but today's expert is next generation's old fogey so if we were to try this route we would need an ongoing process of retiring "expert" editors who can't keep up with scientific progress. We'd also need a process whereby new editors could supplant a less expert editor in their field and active editors could supplant an inactive but more highly credentialled editor. None of those would be simple, easy or pleasant processes and that's all before you get into the business of whether a professor at one university is the equivalent of a professor at another less prestigious university; Let alone what power over content you entrust to such custodians. ϢereSpielChequers 15:24, 1 January 2012 (UTC)
• Oppose The premise is blatantly untrue. If our policies only encourage people that want to delete stuff, how come we have millions of articles that are of sufficient quality for half a billion people to read them each month? --Tango (talk) 15:32, 1 January 2012 (UTC)

Feature request: displaying mathematical equations as png images with solid background

I would like to request the feature that mathematical equations be stored as png files with a solid white background.

Currently, equations in Wikipedia are already stored as png files, but the images have no background.

The Stylish plugin for Firefox allows one to customize themes with user-defined-css.

While browsing with a dark theme, equations in Wikipedia are essentially invisible, as they display with black text on a black background.

For example, while browsing with a dark theme, equations are visible here ...

http://plus.maths.org/content/chaos-numberland-secret-life-continued-fractions

With a dark theme, equations are almost invisible here ...

http://en.wikipedia.org/wiki/Continued_fraction

The invisible equations look like this ...

http://en.wikipedia.org/wiki/File:Wikipedia_accessibility_of_formula.PNG

I'm am not suggesting to use MathML or to change how images of equations are generated with Tex.

I simply request that the generated images of equations have a solid white background.

Leonardnemoi (talk) 01:57, 2 January 2012 (UTC)

• 

The images are transparent to match the background of whatever skin your are using. That's why the skins aren't black. I imagine you could add a bit of CSS to those skins to make the backgrounds of images white, which would solve your problem more cleanly. Prodego ^talk 06:23, 2 January 2012 (UTC)

That CSS would be img.tex { background-color:white; } or the like. But since you'll have the same problem with other (manually-created) images that use a transparent background with the expectation that it will be overlaid on something light-colored, you might want to apply that to all images instead of just those with the tex class. Anomie⚔ 17:42, 2 January 2012 (UTC)

That's right. A transparent background allows background images that look like paper or something like that. -- NetAction (talk) 22:15, 2 January 2012 (UTC)

Or, in the case of Wikipedia, allows it to look decent on article pages (white background), non-article pages (very pale blue, at least on Monobook), infoboxes (light grey), tables (various colors, often a light grey), template documentation (light blueish), and so on. Anomie⚔ 22:53, 2 January 2012 (UTC)

Awarding new users for trivial behavior

Hello. I was wondering how everyone would feel about giving new users encouragement for doing fairly trivial things. My suggestion comes from experience at Stack Exchange, where new users are bombarded with reputation increases and badges for every little new feature of the website they use. It was definitely more welcoming than annoying for me. It also gave me a little push to explore the different features of the site. So on Wikipedia, I was wondering if we could have appreciation notes or even mini-barnstars with messages like "Congratulations! You just

• made your first edit!
• reached 30 edits!
• started your first discussion thread!
• replied to someone on a talk page!
• made your first new article!
• created your first new section in an article!
• fixed a grammatical error!
• watched a page for the first time!
• visited the MOS for the first time!
• visited the Community portal for the first time!

We hope you continue to contribute." I know it may seem too much like a silly game or something. But I would point again to Stack Exchange, which is a pretty serious and heavily moderated website that's very content-focused. I don't think the badges and reputation on Stack Exchange distract from the high-quality posts there.

I anticipate a few tricky issues and objections. I can see how we wouldn't want to encourage spammers with this kind of message. Perhaps the award would only be given afterwards: "Congratulations! You just made 10 edits that weren't reverted for 24 hours!" Another issue is whether these messages would be given automatically, perhaps by a bot, or by other users. I think these details could be worked out. What do you think? Leonxlin (talk) 20:08, 31 December 2011 (UTC)

• We already have the incredibly obnoxious wikilove option on every user talk page. Frankly, I hate this idea. Beeblebrox (talk) 20:47, 31 December 2011 (UTC)

Why do you find wikilove obnoxious? Leonxlin (talk) 00:12, 1 January 2012 (UTC)

• Wikipedia:Welcoming_committee combined with the will to enact the principle should be enough. I personally find Stack Overflow's use of this system rather frustrating. I feel like a second class pleb when trying to get involve since my street cred isn't up to par. Better (I believe) to personally welcome and thank new users for their work (where good). Automation is useful (there are plenty of templates we can use to welcome and advise), but a fully automated scoring system would (again, I believe) be somewhat tacky and potentially used against users (e.g. "Your edits have no value here because you haven't earned your 'Look what I did!' badge yet!"). fredgandt 21:14, 31 December 2011 (UTC)

I'm sorry that that's been your experience at Stack Overflow, which I find to have an incredibly well-designed system. I myself barely notice anyone else's reputation, which I guess is curious since it makes me so happy to receive badges and earn more reputation for myself... For me at least it has been a great incentive to contribute, and doesn't make Stack Exchange "tacky" at all. I have not witnesses user ratings being used against people on Stack Exchange. Similarly with reddit. While everyone obsesses over karma, at least I almost never find myself clicking on a username to find out how much karma they have. The claim that these badges would cause users to think each other superior or inferior is an empirical claim, one that is simply not true, I feel. Does anyone currently boast about how many barnstars they have in discussions, or look down on anyone else for not having such-and-such barnstar? No. I don't know how many barnstars you have, and I would highly doubt that you've taken the trouble to find out how many I have before reading this reply. However, I was quite excited to receive my first and only barnstar, which is why I think having more such things would be a good thing. Leonxlin (talk) 00:12, 1 January 2012 (UTC)

There are Service Awards that users can award to themselves, starting with their first edit. Maybe those (and the other awards) just need to be more widely publicized. I only found them by accident. RudolfRed (talk) 06:44, 1 January 2012 (UTC)

Pretty cool. If only they were better known, or automated... Leonxlin (talk) 00:16, 2 January 2012 (UTC)

• While I'm no fan of things like wikilove I am not driven away by things like that, they just inspire a groan like a Christmas cracker joke. The real question is do things like this keep more people than they drive away?, and I'd guess yes they probably do so I'm for ratings like slashdot or mathoverflow or whatever. We should try copying the bits that make other systems popular. Dmcq (talk) 11:56, 1 January 2012 (UTC)

In other words, you would like to get something like "Achievements" in Wikia ([12])? Well, yes, it has been tried there. My impression is that it creates an impression "This wiki is meant to be fun and not serious". That's OK, if this impression is correct (I guess it is the case in some of their wikis). But Wikipedia is meant to be serious (even if it means it is going to be less fun for some users). Thus, in a sense, we would be tricking users into editing - and I don't think we should. --Martynas Patasius (talk) 16:06, 1 January 2012 (UTC)

Just because something is serious doesn't mean it can't be fun or pleasant. I know there are some people who think that 'work is not meant to be fun' and so make it distinctly unfun and cause people to become old before their time, but is that really what you want? People who are uninterested in all that sort of stuff can just ignore it, but there's plenty of potential good contributors who like a pat on the back every so often even if a bit automated. Dmcq (talk) 16:11, 1 January 2012 (UTC)

True, things can be both serious and fun (and often are). But "primarily meant to be serious" and "primarily meant to be fun" overlap much less than "serious" and "fun". --Martynas Patasius (talk) 16:22, 1 January 2012 (UTC)

Also, there isn't much wrong with "potential good contributors who like a pat on the back every so often", but sometimes that comes with, er, decreased enthusiasm for being criticised. And I'd say that taking criticism well (enthusiastically, or at least indifferently) is one of the most important "features" of a good contributor. "Achievements" just might create a false impression that this is a "fun first" wiki where criticism is not very likely - while the contrary is the case. --Martynas Patasius (talk) 16:38, 1 January 2012 (UTC)

• Oppose introducing achievements on Wikipedia. Barnstars is enough and the right kind of motivation (from peers), not self-awarded. —  HELLKNOWZ  ▎TALK 16:28, 1 January 2012 (UTC)

I'm not sure I understand. The only mention of self-awarded achievements in this in this section was by RudolfRed, who talked about Service awards, which already exist. My proposal is to automate such awards (preferred), or else make them well-known enough that anyone who qualifies for them will be given the appropriate awards by another user.

I would like to know, is your opposition based on an opinion about the kind of awards or the extent/amount they should be used? In my opinion, barnstars are pretty hard to earn and too rare alone to provide the optimum amount of motivation from awards. Perhaps I'm just lazy and have a short attention span, though. Leonxlin (talk) 00:16, 2 January 2012 (UTC)

What editors should be encouraged to earn is a better Wikipedia, not a collection of gold stars. Encouragement should come in the form of seeing one's edits kept and built on (as things presently are). Most editors are fairly interactive here, insofar that they (mostly) use edit summaries to convey to other editors what they've both done, and (often) think about other editors work. There are talk pages galore, and they are used a lot. I actually got my first barnstar today, and am far from jumping for joy about it. I know that sounds mean spirited, but that simply isn't why I am here. Congratulating people for "visiting a community portal for the first time!" makes a mockery of everything we are supposed to be doing. I started (and intend to continue) writing an anti-policy page that actually touches on the point I am trying to make here. See Wikipedia:Play the game. fredgandt 01:01, 2 January 2012 (UTC)

• Totally agree, since it can be a while before you get many barnstars. A lot of new users will be like me, with very small talk pages, and no barnstars (and I've only ever given one out, and I don't even know if I was allowed to, or if there are credentials required). I strongly support starting it incrementally, and aiming to "think smarter, not harder" - if you come up with just one good thing to reward people for (and one that is easy to implement), that will be so much better than 300 things that are of no use whatsoever to the project or the individual. "Good" would be, eg. "You have made 10 edits to mainspace pages", which could link to the explanation of what mainspace means, so they start learning the ropes in a context that is relevant to their achievements. I suggest definitely not mentioning in the award itself that they "weren't reverted within 24 hours" which can sound like faint praise - as if most of their other edits were reverted. I would suggest having a link in the award to a brief description of the conditions of the award, stating whether it was given by a bot or a human etc, as well as the said conditions about the edits not being reverted. Another good award might be for the first time they use an edit summary. An example of a bad sort of award would be, say, "Congratulations, you just fixed a grammatical error!" This would take a human to judge, and be a bad use of people's time. I think a small selection of carefully targeted awards, designed to enhance people's appreciation of what is considered good work, and linked to relevant policies or explanations of how Wikipedia works, timed to be approximately right for their level of experience, would help them to enjoy their time here. If it is educational and selective, not a wild frenzy, I do not see anything gimmicky or fun-laden, just interesting. I worry that barnstars are gimmicky - generally, being an experienced editor, I much prefer feedback showing me that my work is appreciated. One intelligent comment that tells me something I didn't already know, that helps me to contribute better and further the goals of Wikipedia, is worth more than 1000 barnstars and other such like. Early simple rewards that introduce people to the way the community works are a good way to get people started. They should be limited to a small number, and we can tell people when they've got them all. IBE (talk) 06:15, 2 January 2012 (UTC)

Also, just wanted to add something. Style and tone are important here: if we put exclamation marks after each statement ("You have just made 30 edits!") that is going to suck. Better to leave punctuation off, and put a nice smiley face, or three. IBE (talk) 06:18, 2 January 2012 (UTC)

• • Just to clarify one further point: barnstars are still great, so don't think I don't appreciate them. Thanks to User:Prodego for my first one :):) IBE (talk) 06:24, 2 January 2012 (UTC)

You might like to read Wikipedia:Perennial proposals#Use_a_bot_to_welcome_new_users, which is a similar idea.

An automatic system is not likely to get support. You'd end up saying "Congratulations on your first edit" to vandals. An opt-in system, on the other hand, might be accepted. The problem is how to make it sufficiently well-known that interested people find out about it. WhatamIdoing (talk) 22:54, 2 January 2012 (UTC)

I think this is a great refinement, because if it was good, more people would find out about it anyway. It could then be added to the Welcome template if it was clearly proving popular. The way to make it better, as I suggested, is to make sure it helps with actually learning how to use Wikipedia - mere rewards given by bots will wash out all interest in the system, but links to relevant parts of the project, such as the manual of style for people who have made 100 edits (that might be too late, not sure), and links to the relevant project for people who have made a dozen edits to articles of interest to a given project might help. Of course they can look up these things anyway, but bots might manage the learning curve. If it proves really popular it could be made automatic after a welcome notice is posted, with an opt-out, but I agree with starting at the opt-in level - then people are challenged to make it useful. IBE (talk) 12:07, 3 January 2012 (UTC)

Speedy deletion tags: Time last edited (db-meta)

(Cross-posted from Template talk:Db-meta)

Frequently I come across speedy deletions with the message "This page was last edited by ... 1 second ago" (or occasionally even "... in 1 seconds time"), i.e. the page hasn't been purged since it was tagged. Yes, it's easy to click the time to purge it, but with a slow connection it does take a few moments. I propose this is changed to (e.g.) "This page was last edited by ... at 07:59 UTC (xx minutes ago)", with the purge link still retained. Purging the page will update the "xx minutes ago", but the time of last editing will be unaltered. If there's consensus for this change, I'm happy to try to work out the necessary code. Any thoughts?  An optimist on the run! 09:45, 3 January 2012 (UTC)

I don't know about all the ramifications and side effects this might have, but as described, I think it's a great idea. I just stumbled across two templates in the last week where I was scratching my head for far too long before I realized what was really going on. Count me as a supporter. — JohnFromPinckney (talk) 14:26, 3 January 2012 (UTC)

Reflist should be shown when previewing a section edit

Because of issues discussed below, the exact proposal isn't clear in one important respect; whether or not the reflist should be shown for the whole page or just the section we are editing. Please be clear when stating your preference in this respect. Thanks. fredgandt

When previewing a section, a presentation of a the reflist should show beneath the preview (anywhere on the page is better than nowhere), containing all references (as they would normally be displayed). from the section being edited. fredgandt 02:32, 19 December 2011 (UTC)

• Agreed. I would find it pretty useful, as it's time consuming to manually add a reflist to the section, preview, then remove the reflist before saving. CharlieEchoTango (contact) 07:04, 19 December 2011 (UTC)
• (ec)Great idea. I often manually add one my self and occasionally forget to remove it before saving... Mark Hurd (talk) 07:06, 19 December 2011 (UTC)
• Support. Would make adding refs to long articles so much easier. Can't see any downside, other than the opportunity cost of diverting WP programmers from other worthy projects. --Hobbes Goodyear (talk) 07:15, 19 December 2011 (UTC)
• Comment Note that you would have major issues with references defined elsewhere in the page and just referenced from your section (including all uses of WP:LDR). Anomie⚔ 12:21, 19 December 2011 (UTC)
  • Could that be prohibitively major? Is the tech too tetchy? fredgandt 12:24, 19 December 2011 (UTC)
• Comment According to Help:Footnotes#Previewing edits you can work round this by using wikEd. -- John of Reading (talk) 12:46, 19 December 2011 (UTC)
  • Seeing as that's a gadget, I would assume this can die peacefully. Right? fredgandt 12:49, 19 December 2011 (UTC)
• comment I'd recommend using user:js/ajaxPreview which does display the references. It's faster than regular preview, for me. Anomie is correct that there would be (and is with this method) a problem with elsewhere-defined refs, which are very common. sonia♫ 01:33, 21 December 2011 (UTC)
• If memory serves, someone filed a bug at Bugzilla on this years ago. WhatamIdoing (talk) 21:51, 21 December 2011 (UTC)

• I believe it's T7984; the discussion there doesn't seem to suggest it's impossible to code, but as there's javascript workarounds it's probably not a high priority for any particular person. Shimgray | talk | 21:59, 21 December 2011 (UTC)

• I have WikEd but I haven't seen any option to do a reflist, is there one instead of sticking in reflist and then forgetting to take it out and then doing a second edit to correct my error. Dmcq (talk) 23:04, 21 December 2011 (UTC)
• Per Anomie's comments, proposal update Instead of showing a reflist for the section being edited, the reflist for the whole page (calculated to include your previewed edits) should be shown. I think that would be simpler to code and would circum...get around... the issues Anomie raised. I've adjusted the proposal lead. fredgandt 00:03, 22 December 2011 (UTC)
  • Which means the parser has to process the entire page, which could get messy and slow on pages with 100s of references. I could see this as an opt-in tick-box or preference option though. It would remove the danger of me forgetting to take out the {{reflist}}. What I would like to see is the exact same output that putting in the {reflist} does, I can live with the named refs showing as errors, as I can assume they were already properly formatted. Franamax (talk) 01:12, 22 December 2011 (UTC)

See top comment and my last at the bottom of the thread (at time of posting). fredgandt 08:13, 2 January 2012 (UTC)

• Comment I have not done the research but I would be surprised if this is not a perennial proposal. I've reviewed the code in Cite and it's intertwined with how our parser works currently. Anyway, this is not impossible to fix with our current technology, but at this point I don't see an easy fix. Personally I'd rather wait until the new parser is done, and we will not only be able to preview cites but probably show them in WYSIWYG. Unfortunately that is more than a year away. NeilK (talk) 02:09, 22 December 2011 (UTC)
  • That's a very positive comment. I firmly believe, if something is worth doing, it's worth doing properly. Sometimes, that means waiting. Quick fixes are often unsatisfactory. I'd love to see this incorporated in the next generation of software. Nicely plugged in rather than glued on the side. fredgandt 02:45, 22 December 2011 (UTC)
• Support this would be the third time I have seen this proposed. Support-support-support - so to to be clear I mean strong support. I cant tell you how many time I have forgotten to remove the {{relist}} when just editing a section after having to add it because I want to see how the refs appear. Moxy (talk) 02:52, 22 December 2011 (UTC)
• Support - this is a feature I have been missing for years. Ajax gadgets are often to slow to load. --Kudpung กุดผึ้ง (talk) 03:04, 22 December 2011 (UTC)
• Comment This issue requires an update to the Cite software extension. It is logged as T7984. To support this, create a Bugzilla account and vote.

There are three current solutions, which I have not compared:

• User:js/ajaxPreview
• User:Anomie/ajaxpreview.js
• WP:WikEd

---— Gadget850 (Ed) ^talk 03:20, 22 December 2011 (UTC)

Thanks Gadget850. Voted. fredgandt 03:47, 22 December 2011 (UTC)

• Question Wouldn't displaying all the refs (from the whole article) take a significant time (slowing down previews), and wouldn't it make the preview display quite cumbersome/confusing (in articles with many refs)? Johnuniq (talk) 11:31, 22 December 2011 (UTC)
• Support - I hate adding in an extra reflist for preview purposes because it's embarassing when I forget to take it out.--SarekOfVulcan (talk) 21:43, 22 December 2011 (UTC)
• Support: I'm nearly always adding {{Reflist}} while editing section and remove it after preview. Don't think this should be that cumbersome. — Dmitrij D. Czarkoff (talk) 07:09, 23 December 2011 (UTC)
• Support - I'm usually nearly finished editing a section before I even realize I can't see my references. I had been thinking that WP ought to automatically display just refs for that one section, but probably all refs for the entire article would make more sense. Milkunderwood (talk) 08:11, 23 December 2011 (UTC)
• Support. If WMF wants to spend some money on new software features, this should be among their top priorities. ASCIIn2Bme (talk) 22:50, 23 December 2011 (UTC)
• Support - this is one of the more annoying glitches with editing Wikipedia. Now I think about it, the reference section should really be a separate page element from the article content entirely, similar to the article title, but I guess it's a bit late to change that now. Robofish (talk) 23:38, 29 December 2011 (UTC)
• Oh hell - yes please! (Support) - I'm waiting for that so long. That helps editors for improving the encyclopedia! (And not such features like wikilove, dashboard, etc...) mabdul 14:28, 31 December 2011 (UTC)
• + - something useful and easy compared to WYSIWYG. Bulwersator (talk) 14:36, 31 December 2011 (UTC)
• Oppose as written/modified. This would force the parser to process the whole page, which will dramatically slow down previewing sections on large pages. Support a "Preview refs" tick-box which would exactly duplicate the effect of putting {{reflist}} into the previewed text, as that would be dead-simple to code up (add one interface element, call Cite.php if selected) and could be implemented in a matter of days, incl;uding all the language variants of "Preview refs". Iffy on an additional tick-box to parse the whole page, would be nice to have but less chance of someone actually doing the more complex PHP coding. Just duplicating {reflist} though, that's eminently achievable. Franamax (talk) 21:51, 31 December 2011 (UTC)
  • I thank you for your thoughtful comments. The reason I edited the proposal was due to the issue(s) Anomie pointed out (above). I originally thought the section related refs would be enough, but some may malfunction without their brethren. If a simple way to provide just the refs for the section, without getting any errors could be constructed, I also think section only refs would be better. Generally/summarily, I would like to see almost any improvement in this regard, however it was fashioned. fredgandt 22:08, 31 December 2011 (UTC)
    • Unfortunately, section editing works by only feeding the section text to the pre-processor, parser and renderer - but that's the intent, it's much faster. My understanding of the software structure is that if you want all the refs to render correctly, you pretty much have to feed the entire (new) page through the PP (which expands templates) and parser. Pick an FA with over 120 or so references and try previewing a section, it will come up pretty fast. Then try saving a change and time how long it takes until the entire page shows up. I predict you will have time to make a coffee. Some of that time will have been spent parsing other templates ({{convert}} is fairly intensive too) and rendering the full page, but a lot of it is spent on nested {{cite}}s. That's party anecdotal, but when I've seen FA types complaining about lag times it's always been associated with pages containing more than about 120 refs. So from my viewpoint, making this an automatic function breaks the functionality of section editing. I'd much sooner live with the errors in named refs that Anomie pointed out, I'm already used to them from using temporary {reflist}s (which many people above evidently use too), I would expect them having ticked on "Preview refs", and it's a simple enough change that we could actually get a coder to bite. That bugzilla has been around for a lo-o-ong time. :) Franamax (talk) 22:47, 31 December 2011 (UTC)

• Support Previewing refs per section as a tick box option.

Oppose previewing refs for whole page, for performance reasons.

I pretty much agree with Franamax's logic from above, except that I'm not stating a position on the "whole page reflist option checkbox". My first thought was that there was no real point in opposing it, since it's proposed as optional, so why would I oppose other users having the option, but then I moved to concern about server load and the user experience waiting for the "full" reflist on big pages - so I can't get off the fence on that part of it. Begoon ^talk 07:55, 2 January 2012 (UTC)

• Looks as if the general idea has good support, but for a couple of concerns.
  • If we have a reflist for the whole page, it will take too long to parse and put an unnecessary strain on the servers etc. etc. (although be bold does extend to use of the servers).
  • If we have a reflist for just the section we are editing, parts of it may get messed up on being parsed, and display incorrectly.

Since the lesser of two evils would be the few broken refs (by the looks of the above comments), and at present people appear quite used to it, I think that might be the preferred way to go (the original proposed "refs for the section we are editing"). I'm not going to mess about with the lead again, but instead ask that when/if it comes time to count the votes, the counter reads carefully. And also ask that any more comments of opposition or support be made clear with the counting in mind. Awesome! fredgandt 08:07, 2 January 2012 (UTC)

OTOH, keep in mind that creating a button for it will expose many more people to these errors, including many who won't know that that's "normal". Anomie⚔ 17:51, 2 January 2012 (UTC)

Could any error results be simply hidden, thus giving the unaware no indication that "something went wrong!"? Or at least something along those lines. Perhaps having error messages replaced by a friendly green message, stating that "for reason this is this. see link"? fredgandt 18:02, 2 January 2012 (UTC)

Good point that if it's visible, people will try it and find themselves confused at times, in the same process of discovery of everyone who's tried the temporary-{reflist} trick. The tick box would definitely need a "what's this?" link beside it, similar to "This is a minor edit". As far as hiding errors (in re Fred), errors generated within the section itself would presumably need to be shown, as that is what the final output would show. The one "external" error we are aware of is invoking a named reference. This is the MediaWiki "cite_error_references_no_text" message [13], generated by the referenceText() function in Cite_body.php. I'm not a MediaWiki dev, but it does look to me like adding a "friendly" mode to emit "cite_preview_references_no_text" instead would be a fairly lightweight code change, and each project could write it's own message and help page. The help info would explain that if you are trying to reuse a named ref defined within the section, you've done something wrong, but if it's a named ref defined elsewhere you will still need to check the final output. This more limited proposal still looks quite doable. Franamax (talk) 00:45, 5 January 2012 (UTC)

Magic infoboxes

So most articles we host have an infobox of some kind in the top-right corner. They look great and add huge consistency to articles across WP, but they are also trouble-makers. Most other templates are simple transclusions, people see {{unreferenced}} and get the idea of what it is, and probably just ignore it. Infoboxes, however, require a litany of information in a very specific format, a format that can only be learned by reading the list of parameters and possible values on the template itself. So new editors open a page to change "there" to "their", and are immediately lost in the obscure jumble before them.

What I am proposing is that we take the code for those infoboxes from the first section. We can put it anywhere else, just take it out of the intro. There are couple ways this can happen, but mostly it is the idea I am proposing (we can hammer out the actual application afterward). Two different ideas that I've had that I think would work:

1. Allow standardized subpages for articles for infoboxes (something like Solanaceae/Infobox) that are automagically transcluded on the article in the top-right position.
2. Move all infoboxes to the bottom of the page, with code that renders them at the top.

There are probably several more ways to do this, and with any method we should add an [edit] somewhere in the infobox itself, so nobody gets confused. I don't think its a huge leap to think more than a few new editors have been turned off by the infobox in the intro, and I'm sure that even established editors would like to have it out of the way when trying to improve an article. Certainly infoboxes are different to any other template, so we should treat them differently. ▫ JohnnyMrNinja 23:32, 29 December 2011 (UTC)

As an example, take the article Final Fantasy (video game). It very well formatted, clear and articulate. Now look at the code for the intro and you see a different picture. If that is the first wiki-markup a new editor ever sees, they will think that is how the entire site is coded. ▫ JohnnyMrNinja 23:41, 29 December 2011 (UTC)

Funnily enough I was just thinking along these lines. All the rest of the "mess" in markup is either controllable or movable. The cruft at the top, smacks users in the face. Rich Farmbrough, 23:53, 29 December 2011 (UTC).

User:Rich_Farmbrough/Final_Fantasy_(video_game) is a simple solution, along those lines, but it does make editing the infobox harder. Rich Farmbrough, 23:57, 29 December 2011 (UTC).

This is sort-of what I had in mind with infobox subpage. The problem is that articles can't have subpages right now, so we would have to make a special exception (and by we, I mean the devs). It needn't be any more difficult to edit, if we place an [edit] link in the top-right of every infobox that would lead the editor to the subpage. ▫ JohnnyMrNinja 00:13, 30 December 2011 (UTC)

If this were to happen, it's probably be best placed at Template:Infoboxes/Final Fantasy (video game) or Template:Infobox video game/Final Fantasy (video game) (depending on whether consensus decides one location for all these infobox pages or organization under the specific infobox template is preferable), rather than in article space. OTOH, the visual editor will probably have a better solution for templates anyway. Anomie⚔ 01:32, 30 December 2011 (UTC)

Hmmm, how about implementing a feature in the edit box where it can automatically detect templates that are being supplied with more than a certain number of parameters (such as infoboxes) and automatically collapse those templates' code? I am not sure if such a feature would be possible with the current edit box, though. I have heard that there is a WYSIWYG editor for Wikipedia in development; perhaps such a feature could at least be implemented in that if the current edit box would not support it? Just a thought. Regards, —{|Retro00064|☎talk|✍contribs|} 00:41, 30 December 2011 (UTC).

I, too, think that this is more sensibly implemented in the visual editor to come. I certainly am not bothered at all by the template code. Nageh (talk) 00:44, 30 December 2011 (UTC)

I fully agree with Johnny - this is something I've thought for some time. I don't think creating a subpage to hold the infobox would be a workable solution, as the software would struggle to work out whether it was a subpage, or a separate page in it's own right (e.g. AC/DC). Having a separate template for the infobox would be the simplest idea - I'm just trialling this with Talyllyn Railway.  An optimist on the run! 08:52, 30 December 2011 (UTC)

Seems to be working, though a slight change to the relevant infobox template was required.  An optimist on the run! 09:23, 30 December 2011 (UTC)

This is also a workable solution. The reason I'm favoring the subpage idea is that A) there may be articles called AC/DC, but there shouldn't be any articles called AC/Infobox, and it should be easy enough for MediaWiki to tell the difference, and B) I was hoping that the software would automatically recognize that there is a /Infobox, and automatically put it in the top-right of the article, so there is no chance of anyone misplacing it. ▫ JohnnyMrNinja 11:36, 30 December 2011 (UTC)

Unless you need more than one infobox in the same article, e.g., both Drugbox and Chembox. WhatamIdoing (talk) 20:12, 2 January 2012 (UTC)

This sounds similar to the rejected proposal for a table namespace. But you may just want to wait and see what changes the WYSIWYG editor brings. Rmhermen (talk) 17:18, 30 December 2011 (UTC)

• Interesting... The problem with a code subpage as described is that you can't specify where in the text the code appears, so it's only useful for something at the top. And while splitting pages in two might occasionally make the top of the article look cleaner, it doesn't change how the rest looks, which doesn't justify the added confusion. To specify where template boxes come out, you'd need some kind of named anchors in the text. These would then transclude in the material you want. This could be done right now if we make the policy decision to allow a massive proliferation of article subpages - you simply put {{MyArticle/Infobox1}} at the top of your article, and all the infobox stuff goes in Template:MyArticle/Infobox. Right now this is discouraged because these one-off template subpages would get unmanageable; it would be nice to have just one code subpage in a fixed location as you say. Now there is a mw:Extension:Labeled_Section_Transclusion (not currently installed) that can do this; you put {{#lst:MyArticle/Code|Infobox1}} at the top of your page, and then this template would be interpreted to transclude the section into the article. That code can of course be simplified a little more with an ordinary template so you don't have to specify the name of the article you're working on or the /Code and it stays the same during page moves - however, the page move for the /Code page would need to be done manually every time, until this was made automatically a part of normal page moves. Maybe a Code: namespace would be better while we're at it. Installing the LST extension would definitely be the first step toward any trial scheme to make a code page work. Wnt (talk) 18:03, 31 December 2011 (UTC)

Isn't this going to be solved with the new editor interface (collapsible syntax, etc)? emijrp (talk) 18:15, 31 December 2011 (UTC)

Somehow it's more appealing to have a feature we can install now than one we can install ... eventually. Wnt (talk) 16:47, 1 January 2012 (UTC)

I don't like the idea of the transclusion being magic...the same boxes that are used as top-right infoboxes on many pages are also used in other places on some pages. For example, a page about a general type or set of chemicals may have (also or only) several infoboxes, each in a section devoted to one specific entity in the class. Having the box offloaded to a separate page that is explicitly/manually transcluded where desired would solve that problem. The pages about chemical elements do that already, for example, Helium has {{Infobox helium}}. Having explicit transclusions would also allow use of multiple boxes on a page.

On the other hand, a few years ago, a discussion about doing that in general for chemicals (offloading {{chembox}}) did not get consensus support. The two reasons I vaguely remember (and current agree with) are that it puts actual article content in a namespace other than mainspace and it requires keeping more page-names in sync. It becomes harder to watch for changes (have to adjust my watchlist every time a box is offloaded) and harder to link to a specific revision for purposes of off-site content reuse and citing (link to old revision might not have the same vintage infobox transcluded). It also bloats the heck out of the template namespace, making it harder to find actual templates whose names are similar to those of articles. Having subpages (even if only in concept, as a formal convention among first-class actual-page namespace) would solve that last issue (and articles in namespaces other than Template: are easily transcludable already). However, talk-pages for article-names with slashes have always been broken (Talk:AC/DC is a subpage of Talk:AC associated with AC not with AC/DC), and I don't support making more widespread use of them unless that gets fixed. DMacks (talk) 21:53, 1 January 2012 (UTC)

There would be no issue with articles that have multiple infoboxes, as the additional boxes could be placed normally. The vast majority of pages that have infoboxes have only one, and that is always (or should be) in the top right. And as far as an infobox talkpage being a subpage of the article talk page, I don't see how that's a problem. While that doesn't make sense for AC/DC, it wouldn't cause issue here. ▫ JohnnyMrNinja 08:36, 5 January 2012 (UTC)

WikiTrust UserScript

WikiTrust UserScript

The WikiTrust UserScript highlights the words written in one revision if you click in the text. A box shows the author's name and the date. There are some extra features like a list of authors. The script will become free software as soon as it is ready.

I would be happy if you could do a five minutes test and write your oppinion here or on the talk page. The installation is very easy. Just copy and paste two lines into your common.js page. Please excuse the slowness because of the broken Toolserver. -- NetAction (talk) 10:00, 3 January 2012 (UTC)

Installed very easily, obviously.

• Tested it first on a big article - Malaysia - toolserver lag enormous - gave up waiting.
• Tried next on a smaller page - JP1 remote - worked perfectly - excellent.
• Went back to Malaysia - now works perfectly - assume due to earlier caching.
• Went to United States - same behaviour as first Malaysia visit - gave up waiting.
• This behaviour persisted - going away from United States and back again fixes the lag.

Thoughts

• Love the tool - very useful.
• The banner under the Article heading saying "You are using WikiTrust" went away after a few clicks. If that's by design, it's by good design - I would hide it with css otherwise.
• Some way to deactivate/reactivate without editing User JS would be nice (I realise that reactivating may be a problem if deactivating hides the "interface" box for the gadget). I wouldn't personally want the feature "always on" - but always available would be cool.

OS - WinXP SP3 / Browser Chrome 17.0.963.12

Apart from the slowness which was always caused by slow requests to toolserver.org (I could see those requests waiting to complete) - I had no problems at all. Great addition to my box of tricks, thanks for sharing it. Begoon ^talk 12:58, 3 January 2012 (UTC)

Thanks for testing. Please re-visit the pages after waiting a minute. They will be in the server's cache. The banner goes away after a few clicks by design, yes. Why wouldn't you want WikiTrust to be always on? -- NetAction (talk) 13:25, 3 January 2012 (UTC)

Well, after some thought, maybe I would leave it always on - I use NavPops too, and occasionally I disable that from its own interface if it's popping up in annoying places, so that influenced my thinking, but actually that isn't really comparable. There were a couple of reasons I might not want to. First of all, I'm a clumsy clicker on some touch screens or touchpads, so I don't want to generate lots of unnecessary toolserver requests if I click in the text. Apart from that, the lag was annoying, with every page "waiting for toolserver", and I like to see page loads finish so that I know all scripts etc have run. A final reason, maybe even the best one, is that you were looking for feedback, and user configurable options like that are something I always like in tools - even seemingly redundant flexibility isn't always as redundant as the programmer thinks. I know, because I program, and I'm usually on the other side of that discussion. Those are personal things for me, though - so please don't take them as criticisms of a great tool. Begoon ^talk 14:46, 3 January 2012 (UTC)

Thank you very much. I thought about the touch screen thing as I have a tablet pc myself. I'll think about it. (By the way: The userscript does not do any ajax requests after loading.) Of course the slow requests are an issue. Hope I can fix it soon. -- NetAction (talk) 14:57, 3 January 2012 (UTC)

OK I tested with my tablet pc. It did not fire a click event while scrolling. There was no problem with WikiTrust. I think this behavior will be similar on other tablets. -- NetAction (talk) 20:36, 3 January 2012 (UTC)

Thanks for that. I have access to a touch-screen today (was away yesterday) - and you are correct, I just did a quick test and can confirm that even my legendary clumsiness on a touch screen doesn't seem to trigger it. Seems I was overly concerned about that point, so, really, other than just to add a "new bell or whistle", the feature to disable from within itself might be unnecessary, and too much trouble to be worth it. I'll leave the script enabled for the next few days and let you know if any other problems occur (I promise not to mention toolserver being slow again - that's a given :-)). Begoon ^talk 04:13, 4 January 2012 (UTC)

Addendum: I lied - I'm going to mention lag again. In general use over several hours, the lag is nowhere near as noticeable as it was in the "5 minute" test. This is because, even if you load a large page, it is generally a minute or so before you read a bit and decide you want to click some text to see details. By this time, the caching has happened, and all is well. I should have done a longer test initially with less "jumping around". In a real usage scenario, it's working very well indeed. Begoon ^talk 08:43, 4 January 2012 (UTC)

I switched from Toolserver to my private server as it is 20 times faster. There should be nearly no lag now. -- NetAction (talk) 15:38, 5 January 2012 (UTC)

Yup - less than 3 seconds on Brazil. Nothing at all on normal size/small articles. If I wasn't looking for lag, I wouldn't even have noticed the Brazil. That's perfect. Begoon ^talk 15:47, 5 January 2012 (UTC)

Great! -- NetAction (talk) 16:43, 5 January 2012 (UTC)

Wiktionary hits on Wikipedia.com

There should be a set of Wiktionary result(s) on the Wikipedia.com website so that people can use wikis pages AS A DICTIONARY. :D This increases the value (usefulness) of Wiki & beats out dictionary.com by a kilomile. — Preceding unsigned comment added by 72.162.229.254 (talk) 16:22, 5 January 2012 (UTC)

If you'd like to search wiktionary, you can do so at wiktionary.org. For common words with only a dictionary definition, we often have a soft redirect to the wiktionary page. See Tough for an example. Night Gyr (talk/Oy) 16:56, 5 January 2012 (UTC)

I think this is covered in WP:NOT. BTW, you should use "[[wikt:tough|]]" to link to the Wiktionary article tough. – Allen4names 18:24, 5 January 2012 (UTC)

The majority of article titles on Wikipedia are either proper nouns, or multi-word phrases, so a wiktionary definition wouldn't be applicable anyway. For the rest, {{Wiktionary}} is available, and frequently already in use.  An optimist on the run! 20:20, 5 January 2012 (UTC)

Idea for of Increase in Donations

Hello!!! Hello!!!

I have an idea for of Increase in Donations

There is a category of people who donate money, but there is a category of people who donate money for that would show it to others. You can create a bracelet made of silicone with the logo "wikipedia" (it can be ordered in China. Price if you order a large quantity will be 1 cent) and send it to everyone who donates a minima 10-20 dollar ... (it's you decide, it depends on how much will cost to send the bracelet)

This idea can be improved.

So you will attract a lot of people who donate money in order to indicate that they have donated money

If you implement my idea. just tell me as the author of the idea.— Preceding unsigned comment added by 7SkyFree (talk • contribs)

See Wikipedia:Merchandise. ---— Gadget850 (Ed) ^talk 23:01, 6 January 2012 (UTC)

That eventually leads to meta:Fundraising ideas/Cafe Press. To be blunt, I think they could really use some better ideas... As for your idea, it's a good one, but you should develop it further and come up with an actual pattern. Note that the production of such wristbands has grown much more sophisticated (see [14] for lots of companies) -- even for just $2 or so each for a modest-sized run, these can be done in the U.S. and it can be done not just with an indistinct indented text but with a smooth surface and two or more different highly contrasting colors, or even with a photographic finish; you also have a choice of widths, even irregular shapes (if desired). So it's reached the point where creativity seriously applies. Take a shot at it! Wnt (talk) 17:45, 7 January 2012 (UTC)

Proposed new project

It's not exactly a policy proposal, but it is a proposed Wikiproject with probably some policy implications, so I thought it'd be good to make note of it here: User:Herostratus/Wikiproject Paid Editing Watch. Members welcome. Herostratus (talk) 21:20, 6 January 2012 (UTC)

This should go to Wikipedia:WikiProject Council/Proposals. ---— Gadget850 (Ed) ^talk 22:57, 6 January 2012 (UTC)

Rfc - "Automatically updated cited information" - at (idea lab)

Request for comment on technical feasibility and desire/horror etc. of idea in development. fredgandt 13:58, 8 January 2012 (UTC)

"SubsterBot" for automatic inclusion of external sources

Hello all!

According to the approved request and a hint by Chris (thanks for this) I will propose the services provided by User:DrTrigonBot here somehow in detail. I think this could be of interesst for some of you. The bot is already running on dewiki (German Wiki), frrwiki (Nordfriisk Wiki) and here with quite some success, e.g. on following pages:

Here on enwiki for following page:

• world rankings
  • Template:Elo rating: Elo rating system
  • (w:de:Vorlage:ITTF-Weltranglistendaten: International Table Tennis Federation - upcoming...)
• a.o. ...

On dewiki this bot is used e.g. for following pages:

• blog from RSS to watchlist
  • w:de:Wikipedia:Wikimedia Deutschland e. V./Blog
• Exchange rates
  • w:de:Vorlage:Wechselkursdaten/EZB: European Central Bank
• Bank code (and other info)
  • w:de:Vorlage:Infobox Kreditinstitut/DatenDE
  • w:de:Vorlage:Infobox Kreditinstitut/DatenAT
  • w:de:Vorlage:Infobox Kreditinstitut/DatenCH
  • w:de:Vorlage:Infobox Kreditinstitut/DatenDE/Quelle
• a.o. ...

...the possible usages of the bot are converging against infinite - depending on the creativity of users.

The bot provides a simple and programmable interface to automatic data substitution (or synchronization) from arbitrary external sources (webpages, thus by URL - or mail) to wiki pages (mostly meta templates; containing data like e.g. world rankings or else) in a format suitable to store and process further here in wikipedia. The basic idea is to have a generic system, quite similar to and well behaving/interacting with the Help:Magic words#Parser functions in order to be able to adopt it to specific cases instead of writing a special (new) bot all the times. In it's current state the bot works well toghether with the Help:Magic words#Parser functions and delivers data to meta templates which can be used further in the wiki (look at the examples also). Even though there is still a lot of fine tuning to do, the current state (actual bot code) can be considered as productive and stable thus I would like to make this public. Some of the docs should be enhanced also (any help is welcome ;) and some are existing at the bot template User:DrTrigonBot/Subster already.

May be I should also mention the relation to another current (or future) project, namely meta:WikiData WMDE in which the bot should also fit very well. As far as I can see it should even emphasize the need of the bot... ;)

I am available for questions, ideas and help but do not have that much time - please be patient. The best would be to contact me on dewiki (German wiki) but I will drop in here frequently too. So it would be a nice thing if we could slowly migrate list und data templates to use the bot - wherever useful... Thanks and greetings --DrTrigon (talk) 14:06, 8 January 2012 (UTC)

Perhaps should be re-posted at Wikipedia:Bots/Requests for approval. Perhaps (instead) I am too tired to be reading and typing. fredgandt 14:17, 8 January 2012 (UTC)

This is not a BRFA, rather an announcement that the bot can handle stuff that may be useful to a wide variety of projects, so VP seems like the exact place to post this. —  HELLKNOWZ  ▎TALK 14:20, 8 January 2012 (UTC)

flickrreview for en.wiki?

I would like to propose a flickrreview template for en.wiki to match Commons' flickrreview template. Is there a reason not to have something comparable here? (I ask this because I came across File:Weeping statue.jpg which is from flickr and back in 2006, but now that flickr user has disappeared and we can't verify its copyright status)--GrapedApe (talk) 03:21, 4 January 2012 (UTC)

The reason that the template does not exist locally is that free use files from Flickr should not be uploaded here, they should be uploaded at Commons. In the rare event that a non-free file from Flickr is desired, it should be uploaded manually, with a manually generated FUR, and would not require this template anyways. Sven Manguard Wha? 03:14, 5 January 2012 (UTC)

I understand that's the idea: everyone go to commons. But that doesn't always happen and when there's a lag time between the uploading and the move to commons, we lose confirmation of free status. Like at Wikipedia:Files_for_deletion/2012_January_2#File:Weeping_statue.jpg.--GrapedApe (talk) 15:25, 7 January 2012 (UTC)

You can help and join Wikipedia:WikiProject Images and Media/Commons/Drives/Jan 2012 Bulwersator (talk) 19:44, 12 January 2012 (UTC)

Notification to the Editor

WP can (if possible) field a FB like notifying system.
It works thus. As I am writing here, and if you comment in this subject, I get notified. or you can refer the person as @example... or some other markup... and can you tell me if there is a need for improving the visuals of templates... (I can :-)) If yes can you please give a list so that i can edit and put up to get it approved by consensus.... I can not find the list. Thanks, RaunakR (talk) 15:21, 11 January 2012 (UTC)

We already have several methods for keeping track of conversations:

• Watching pages for changes. The settings for this functionality are found in your preferences.
• Email notification when changes are made to certain pages. Again the settings for this functionality are found in your prefs.
• Notification if another editor edits your talk page. A banner will show at the top of any freshly loaded Wikipedia page, when loaded after the edit was made.
• The {{Talkback}} template. Used on editors talk pages to let them know (just in case they didn't already) if someone has responded to a comment of theirs. Particularly useful if responding on an older topic that may no longer be watched by the editor.

As such, I don't think we need any more ways to notify users of changes. fredgandt 17:21, 11 January 2012 (UTC)

Or {{talkbacktiny}} for those of us who think talkback's footprint is a tad humongous.--Fuhghettaboutit (talk) 23:09, 11 January 2012 (UTC)

OK Got it... RaunakR (talk) 09:11, 12 January 2012 (UTC)

Justice to good-faith edits

And the third thing is (uder a new headline) If a person wants to create something on wikipedia, can he use the sandbox/<name of the page>? If other editors like it then we move it to mainstream... New articles need wikified things which new editors usually lack. It may require resources but will benefit good-faith edits who really want to contribute but can not follow up to the expectations of RC Patrollers and others who are experienced editors. Every article be it a stud really counts. As of now Court Martial is meted out to any bad edits (be it of good faith or vagabond). Its true that amidst such traffic, its impossible to judge, why not make initatives in place of the banner (charity) listing out the benefits of wikipedia (many will feel like joining) and simplifying edits by removing the compulsory 'wikifing' of articles... we really dont want the editor to be a computer jack. Anyone can edit.

OR

If its sucking too much resources (patrolmen can contribute instead of the rcp) why not make it mandatory to have an account to edit? (many article have it but in general) according to a persons psychology, if he doesn't spare a minute for creating a username, will he spare another minute to edit wiki? Now don't say he has 1 minute rather than 2.
Do not feel hard over me. This was just a proposal from a fellow voice RaunakR (talk) 15:43, 11 January 2012 (UTC)

• "Before making a new proposal here, please review Wikipedia:Perennial proposals to see if it has already been suggested.": Wikipedia:Perennial_proposals#Prohibit_anonymous_users_from_editing Bulwersator (talk) 16:03, 11 January 2012 (UTC)

OK..RaunakR (talk) 16:52, 11 January 2012 (UTC)

The 'sandbox/<name of the page>' already exists. CharlieEchoTango (contact) 06:29, 12 January 2012 (UTC)

Template:nn-warn-deletion should have recovery instructions

If only 10% of the editors who create articles on apparently non-notable topics were willing and able to try to improve their work instead of being bitten by having it deleted, that is a potentially huge source of new contributors. Speedy deletion is like a word processor which deletes your files because of bad grammar. Currently, the Category:CSD_warning_templates do not give newbies any clue about how to get their work back, so even those willing and able to improve it are faced with the prospect of starting over from scratch, which is a terribly discouraging experience for someone new to editing. Most admins don't perform a thorough secondary source check before deleting articles without an assertion of notability.

Therefore, Template:nn-warn-deletion needs a sentence to instruct those (usually very new) editors who are willing to try to improve the sourcing of their WP:CORP or garage band etc. article to either WP:USERFY it or put it in the WP:INCUBATOR. Which of those possibilities would be best? Would both? Which of the other CSD templates would benefit from such instructions? Selery (talk) 11:48, 11 January 2012 (UTC)

The problem is that the CSD templates are not properly standardized. Most of them work by substituting Template:Db-notice, which contains basic instructions such as requestion userfication, with some additional text specific to the reason for deletion. There are alternative templates of which Template:nn-warn-deletion (and its parent template template:Nn-warn is one). I see no reason to have duplicate templates for this though, as Template:Db-notability-notice has the same functionality and is properly updated. Yoenit (talk) 16:48, 12 January 2012 (UTC)

I see. I think I will request protected template edits to expand the userfication instructions slightly and also mention the incubator, unless someone has a better idea. Selery (talk) 15:49, 13 January 2012 (UTC)

facebook button

WP:PEREN
The following discussion has been closed. Please do not modify it.
Considering the vast amount of content available on Wikipedia & millions of users, why can't wikipedia have share on facebook,twitter (& any other social networking sites) button. it is very simple to embed,requires very little server resources & would be used by billions of commen users of wikipedia & facebook. This could alter the way information is shared in the world. Well I was thinking of this RaunakR (talk) 16:53, 11 January 2012 (UTC) Again? Please, use search Bulwersator (talk) 16:59, 11 January 2012 (UTC) Sharebox is a script that reorders your toolbox. It adds new buttons that make it easier to mail, print or share an article on Facebook or another linksharing service. You must have an account to add Sharebox to the sidebar. See User:TheDJ/Sharebox for more information. ---— Gadget850 (Ed) talk 18:04, 11 January 2012 (UTC) This is a perennial proposal. Short version is, this will not happen. — The Hand That Feeds You:Bite 23:30, 11 January 2012 (UTC) Like --Born2cycle (talk) 05:42, 12 January 2012 (UTC) Every time I see that template, I want to bang my head on my desk. Gah.... Reaper Eternal (talk) 20:04, 12 January 2012 (UTC) WP:PEREN. This is ridiculous, the last discussion closed barely a moth ago. Kudpung กุดผึ้ง (talk) 05:57, 12 January 2012 (UTC) Oddly, it's not listed at that page (don't have the time to add it right now). MER-C 06:32, 12 January 2012 (UTC) This is being worked on, so I suspect we will get social sharing features on enwiki in the not too distant future. Prodego talk 21:03, 12 January 2012 (UTC) It will serve as an utility to share the knowledge. RaunakR (talk) 09:36, 13 January 2012 (UTC)

Fund Development on Gun.io

(Full disclaimer: I operate the service I am recommending we use. I was referred to VP by the Sarah Stierch of the information team. That being said, I am an established editor and I don't think this is spam.)

I suggest that some of Wikipedia's development, either of Wikimedia Software, bots or even skins, could be outsourced to the open source community using Gun.io, which provides free fund raising and bounty listing for open source projects. It makes it very easy to raise funds for open source software development and to find talented hackers to work on projects!

Perhaps the Wikimedia Foundation will consider starting a few bounties to add new features to MW, or raise money for specific features.

What do you think? Are there any features which you want to see made?

Miserlou (talk) 00:07, 12 January 2012 (UTC)

I'm all for it, but this isn't a question specific to the English Wikipedia at all. You almost certainly want to ask this question on the wikitech list instead of here. Selery (talk) 15:51, 13 January 2012 (UTC)

Drafting an RfC proposal for a Jan 18th SOPA protest

please see the next item on this page

I'd like to try and very quickly put together a clear, concise RfC proposal, that could run in the next few days. There is little time for ideas to be refined, so it has to be simple, minimally disagreeable, easy to implement quickly, and effective. U.S. tech experts are testifying to congress next week and numerous large websites including Reddit are going to be totally blacked out. Instituting a full blackout on Jan 18th would cause too much uproar, but I think we should do something, and it should be noticeable. Here's the sketch of what I think that should look like. Proposal outline: Jan 18th 9am - 9pm Eastern Standard Time (New York) Full page click-through information page (no editing lock-out or blackout) Geotargeted for U.S. readers Providing general info about the bill and congressional contact info What we need for this to happen: Minimal consensus on the above points Detailed language for the RfC Listing at WP:CENT and a site-wide central notice banner Is this a viable outline? Who's interested in helping put an RfC together in the next 24-48 hours? Ocaasi t | c 10:50, 13 January 2012 (UTC) Suggestion for inclusion in the RFC as a proposal: one thing it might be easier to get quick-enough consensus for would be front-page highlighting the SOPA article on 18 Jan (same day as Reddit blackout). It's only C-class, so the heading could become "Today's highlighted article", with the word "highlighted" linking to the discussion about highlighting it. Rd232 talk 15:04, 13 January 2012 (UTC) That's a great idea, to develop the main page as a SOPA/Internet theme. I think, though, that it can be left out of the RfC and handled by the folks at WP:MAIN in the course of their normal operations. If the RfC were to pass, I think there wouldn't be much resistance to doing so. Speaking of which, anything we can do to get SOPA into B or A class shape before next Wednesday would be excellent. Ocaasi t | c 15:31, 13 January 2012 (UTC) Be bold and go for it! Time's a wastin'! There was already 89.9% consensus on the straw poll at Jimbo's talk page, so don't expect you have to go through that again. Selery (talk) 16:01, 13 January 2012 (UTC) Please see the next item on this page. Philippe Beaudette, Wikimedia Foundation (talk) 17:39, 13 January 2012 (UTC)

Community consultation on SOPA act

In order to allow time for the WMF to technologically support any action taken regarding WP:SOPA, we need to be able to begin preparing in advance. For that reason, we are launching a discussion to try to determine what consensus may have developed for community response. Please weigh in on the consultation page, at Wikipedia:SOPA initiative/Action. Thank you. Philippe Beaudette, Wikimedia Foundation (talk) 17:39, 13 January 2012 (UTC)

IPA

As it currently stands, when there is an article with pronunciation that is not obvious the IPA spelling is there, which is great. If, however, one is not familiar with the system, he/she can click on link and it gives a key to decipher it. The Oxford English Dictionary website — one must have a licence, but most universities have it, hence the picture here — has a similar thing, but better: a box appears in the same page with the key for only the letters present, namely the reader does not leave the page and does not have to spend a few minutes finding what letters he/she is looking for. I know the current system is okay and it is not broken, but it could be better if it were more like the OED website, or at least that is my opinion. --Squidonius (talk) 23:41, 13 January 2012 (UTC)

• Comment: Pretty simple to implement with just CSS. — Bility (talk) 00:08, 14 January 2012 (UTC)
• Support: This seems like a great way to accommodate those to whom IPA could just as well be hieroglyphics (i.e., the vast majority of readers, or at least American readers) while not slighting the fervent IPA folks. Short Brigade Harvester Boris (talk) 02:06, 14 January 2012 (UTC)
• Support: Very useful feature! As long as it's technically possible and licencing issues are solved, go ahead. Animusv3^{Talk to me! Contribs} 05:00, 14 January 2012 (UTC)
• Erm, {{IPAc-en}} ? --Cybercobra (talk) 08:44, 14 January 2012 (UTC)

New Discussion: Adding parameters of the Find sources template to the AfD template

• I've started a discussion to add the {{Find sources}} parameter to the AfD template Here. Northamerica1000^(talk) 05:22, 15 January 2012 (UTC)

Wikipedia Website Title Proposal

The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section. A summary of the conclusions reached follows.

Closing as unsuccessful per WP:SNOW. It won't be much of a change, so why care?Jasper Deng (talk) 05:23, 16 January 2012 (UTC)

---

I would want Wikipedia to consider changing their website's current title "Wikipedia, the free encyclopedia" to "Wikipedia, The Free Encyclopedia". The title's lettering can then correspond to the capital letters in Wikipedia's logo. I feel like this would make Wikipedia look more professional. --TJRana (talk) 10:43, 30 December 2011 (UTC)

It took me a while to work out what you were referring to - I presume you mean the title that appears at the top of a browser window (at least in IE and Firefox). Anyone know if this is a mediawiki interface page, or hard-coded into the software?  An optimist on the run! 10:56, 30 December 2011 (UTC)

It's defined here. I would oppose the proposed capitalization though, since it's a descriptive title and not a proper name. Jafeluv (talk) 11:05, 30 December 2011 (UTC)

But it's even capitalized on the logo. --TJRana (talk) 11:27, 30 December 2011 (UTC)

The logo also spells "WikipediA", but I don't think we should start using such conventions in normal text. Jafeluv (talk) 11:54, 30 December 2011 (UTC)

Don't be silly. It spells "WIKIPEDIA". And I'm talking about the line under it. It's not normal text. It's the title of a website! --TJRana (talk) 12:31, 30 December 2011 (UTC)

Oppose The phrase is a tagline that essentially acts as a byline and should be in sentence case. And yes, it is an interface page at MediaWiki:Tagline. ---— Gadget850 (Ed) ^talk 12:50, 30 December 2011 (UTC)

Umm, actually I think TJRana meant the page title at the very top of the browser window, where it says something like "Wikipedia:Village pump (proposals) - Wikipedia, the free encyclopedia". The tagline under the article title is a different element, although its function is similar. Jafeluv (talk) 13:09, 30 December 2011 (UTC)

• Oppose: Using Caps At The Start Of Every Word Is Stupid --Alexandr Dmitri (talk) 15:56, 30 December 2011 (UTC)

  In case anyone hadn't got my sense of humour, the saner reply lies here. --Alexandr Dmitri (talk) 23:22, 30 December 2011 (UTC)

And, oddly enough, the example in byline shows a couple examples, in title case. I would even support changing MediaWiki:Tagline to title case. I can't find a definitive answer, and my copy of TCMOS is at work, but about.com suggests that title case is appropriate for a byline here [15], even if they don't come right out and say it.... Livit⇑^Eh?/_What? 22:33, 30 December 2011 (UTC)

• Support: using sentence capitalization in a title is equally stupid. The HTML element that text is in, is, after all, <TITLE>, so why shouldn't we treat it as such? This is basically a WP:BIKE issue, but it's also a cheap fix. :) Livit⇑^Eh?/_What? 17:07, 30 December 2011 (UTC)
• Weak Oppose Its a petty diffrence. However, sitting on a fence all day would do nothing but give you a sore bum so I'm going to take the oppose side because the current version has a friendlier fell to it, even if capitals look more professional. Oddbodz (talk) 22:52, 30 December 2011 (UTC)
• Oppose. It's worked so well so far, it looks dignified - all capitals seems somehow "cheesy". And in the absence of a good reason it would be better not to make a change to every page on the wiki with the caching effects this implies. Wnt (talk) 17:22, 31 December 2011 (UTC)
• Oppose for the same reasons as Wnt. I like sentence case, which is also used for article titles. Leonxlin (talk) 19:03, 31 December 2011 (UTC)
• Oppose - It is a actually used for article mainspace titles. Katarighe (Talk · Contributions · E-mail) 19:24, 31 December 2011 (UTC)

• Huh? →Στc. 02:56, 5 January 2012 (UTC)

• Is this for changing the MediaWiki:Tagline, or changing the title that appears at the top of a browser window? →Στc. 02:56, 5 January 2012 (UTC)
• Oppose per Wnt 'cheesy'. --Kleinzach 00:50, 11 January 2012 (UTC)
• Oppose Mugginsx (talk) 12:08, 14 January 2012 (UTC)
• Oppose I'm with the "cheesy" crowd, it's really just fine as it is. Begoon ^talk 13:12, 14 January 2012 (UTC)
• Oppose Overcapitalsation is a plague.TheLongTone (talk) 17:42, 15 January 2012 (UTC)
• Oppose - The current lettering works fine and, actually, having it lower case is more consistent with our policy on article titles, which only capitalise proper nouns. ItsZippy ^{(talk • contributions)} 19:55, 15 January 2012 (UTC)
• Oppose - and speedy close. There are no compelling reasons for even suggesting such a change. Kudpung กุดผึ้ง (talk) 05:19, 16 January 2012 (UTC)

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

All articles should have a "References" section and tag

Hi. I think all articles should have a "References" section and tag. A bot could be made to insert a "==References==" heading and a "<references/>" or {{reflist}} tag in every article that lacked these. If an article lacked any references, an "{{unreferenced}}" tag could be ''automatically'' generated, but would be set to appear in the References section rather than at the top of the article. The most beneficial effect of this would be that when an editor adds a reference to an article, it would immediately appear in the References section below, even if it were that article's very first reference. At this point, the {{unreferenced}} tag would automatically disappear. I'd be interested to see what others think about this.Nankai (talk) 04:12, 8 January 2012 (UTC)

Are you aware that not all pages should have any sort of references section? WP:Disambiguation pages, for example, should never require citations. We can't just have a bot add these things to all pages, because the bot will never be able to tell you whether a page like Acute leukemia should have citations.

Additionally, we don't require articles to use the same section headings (see Wikipedia:Perennial proposals#Changes_to_standard_appendices), and we don't require the article to use WP:Footnotes ("ref tags"). Editors might choose to use WP:Parenthetical references or other systems for their WP:Inline citations instead, in which case the {{reflist}} template is useless and inappropriate.

Additionally, some articles (usually stubs) are using WP:General references rather than inline citations, so even though there are proper bibliographic citations on the page (and therefore {{unref}} is completely inappropriate), there is no need for the templates.

All of which is a long-winded way of saying I think you'll find it's more complicated than that. WhatamIdoing (talk) 04:51, 8 January 2012 (UTC)

While it sounds a great idea in theory, in practice it could be quite complicated, as WAID says. The different systems of referencing (each of which is useful in its own ways) could well make it a problem, and there are a small percentage of articles (such as dab pages) where referencing is superfluous. It's a messy issue, though in principle - if the problems copuld be worked around - it might be quite useful. Grutness...wha? 06:48, 8 January 2012 (UTC)

Perhaps it could be done with Twinkle so that NPPers could add missing

==References==

{{Reflist}}

to new pages. Kudpung กุดผึ้ง (talk) 08:02, 8 January 2012 (UTC)

What, you mean use the people already looking at these articles to add a useful edit simultaneously? You do realise that's bordering on being both a good idea and common sense at the same time? I support it, but I think you're in for a rough ride with only logic, common-sense, practicality, innovation and simplicity on your side :-) Begoon ^talk 11:31, 8 January 2012 (UTC)

You would have to ensure the article does not use any of the current referencing systems: Footnotes, Shortened footnotes, Parenthetical referencing, Embedded citations or Footnote3, or any variant of these. ---— Gadget850 (Ed) ^talk 12:08, 8 January 2012 (UTC)

That's a good point, but presumably that could be coded for if this is to be added to Twinkle or similar? I haven't studied the NPP procedure in detail, because I've never done it, but it sounds very streamlined, in principle, to add it here (provided the code can scan for existing triggers, like other "flavours" of referencing, which will cause it to not add the == References == code.) It should fail safe, obviously, defaulting to not add if anything "ref" related is already there. If that means it misses a few until the code is refined, ok, we still caught some. Begoon ^talk 12:17, 8 January 2012 (UTC)

I've been on FaceBook too much lately - I was looking for a like button for Begoon's first comment above :) Grutness...wha? 12:21, 8 January 2012 (UTC)

{{Like}} fredgandt 14:00, 8 January 2012 (UTC)

This is a great idea, provided of course that the bot is clever enough to ignore the various types of pages mentioned as not needing this. ϢereSpielChequers 23:13, 9 January 2012 (UTC)

Perhaps it's something we can suggest Jorm build into his proposed NPP Zoom control panel. That said, has development been scheduled to continue yet? Kudpung กุดผึ้ง (talk) 03:42, 10 January 2012 (UTC)

Yes. In fact, I'm (trying) to dive back into that stuff this coming week. I have a couple other things to do that orbit the project first, though.--Jorm (WMF) (talk) 03:47, 10 January 2012 (UTC)

This doesn't seem very constructive. The general idea of keeping reference sections in good order is something that is already done.--Djathinkimacowboy ^{what now?!} 14:50, 15 January 2012 (UTC)

Template:uw-copyright

Hello.

I believe that the following text should be added to the template:

If you believe that your addition was not a copyright violation, please explain your addition in the edit summary or discuss it on the article's talk page. Thank you.

Please let me know if you believe that this is a reasonable addition. Thanks. 75.53.212.214 (talk) 23:11, 10 January 2012 (UTC)

Many authors of the removed content believe incorrectly that they can add their copyrighted text, without releasing it, because they own it. Similarly, but not quite the same, some believe they can license it for our use, only, without releasing it. Still others are actually willing to release but not commercially (i.e., under a license incompatible with Wikipedia's licenses). Often all three types don't understand they must release in a verifiable manner by either a release through the OTRS system, or by changing the external site's copyright notice. Until that's done—an actual proper release—they should not be re-adding the content. Yet, by asking them to "explain" in an "edit summary", you are inviting them to re-post the content that was removed. Certainly, telling them to explain on the talk page is a good idea. I would rewrite the add-on language as If you believe that your addition was not a copyright violation, please explain on the article's talk page but we suggest you read Wikipedia's requirements for donating copyrighted material first. Thank you.--Fuhghettaboutit (talk) 00:14, 11 January 2012 (UTC)

75.53.212.214 is referring to changes to the User Page Warning template, but I'd like to mention the template used on the actual page that used to contain a copyright violation (I haven't followed this up to determine what template it is) doesn't (or didn't IMHO) explain how a third party (me) could suggest the suggested copyright violation is not actually a problem. (In the case I recall -- but don't recall enough to link to -- I felt the problem could have been a Google Book "mirror" of the Wikipedia article -- but I had trouble getting enough confirmation to bother following it up -- presumably letting the original editor and the editor noting the possible copyright issue work it out themselves.) Mark Hurd (talk) 07:09, 11 January 2012 (UTC)

The template you mean is Template:Copyviocore. The options under "can you resolve this issue" can be followed by all editors (In your case posting on the talkpage), so I don't see the problem. Yoenit (talk) 09:00, 11 January 2012 (UTC)

I agree :-) Perhaps my problem was more with not being able to obtain the Google Book contents, and I just felt frustrated... Mark Hurd (talk) 01:59, 16 January 2012 (UTC)

Navbox for all of the inline warning templates?

It would be helpful if somebody could organize and build a navbox listing all of the inline warning templates, then add it to the text descriptions for those templates. Tracking down the relevant template for a particular issue is a nuisance/time-sink, so a well-designed navbox would be an efficiency improvement.

For example:

Regards, RJH (talk) 16:40, 14 January 2012 (UTC)

Seems you did a pretty good job with the navbox yourself. Be bold and add it (as {{Inline tags}}) to the documentation pages. As for tracking the various templates, that's why categories exist. See Category:Inline citation and verifiability dispute templates. — Edokter (talk) — 16:52, 15 January 2012 (UTC)

Okay, I went ahead and set up the navbox and populated the corresponding documentation pages. Thank you. Regards, RJH (talk) 19:05, 15 January 2012 (UTC)

Looks great, but I think you're missing {{quantify}} and {{dubious}} although I didn't do a thorough check. Selery (talk) 18:05, 15 January 2012 (UTC)

Yes, that's only a subset of the templates to serve as an example. I've added your suggestions to the navbox. Thanks. Regards, RJH (talk) 18:37, 15 January 2012 (UTC)