→Discussion: oppose |
|||
Line 1,223: | Line 1,223: | ||
*'''Strong support''' – [http://en.wikipedia.org/w/index.php?title=User_talk:Jimbo_Wales&diff=prev&oldid=465361123 I've previously opposed] taking site-wide action since I had believed that Jimbo's voice in the media alone would be enough. Unfortunately, I don't believe that to be the case any longer. As a result of witnessing the rejection of so many amendments on December 16th, I believe that a stronger message from the WMF and the enwiki community is needed in order to spread awareness of this bill. --[[User:Michaeldsuarez|Michaeldsuarez]] ([[User talk:Michaeldsuarez|talk]]) 21:53, 19 December 2011 (UTC) |
*'''Strong support''' – [http://en.wikipedia.org/w/index.php?title=User_talk:Jimbo_Wales&diff=prev&oldid=465361123 I've previously opposed] taking site-wide action since I had believed that Jimbo's voice in the media alone would be enough. Unfortunately, I don't believe that to be the case any longer. As a result of witnessing the rejection of so many amendments on December 16th, I believe that a stronger message from the WMF and the enwiki community is needed in order to spread awareness of this bill. --[[User:Michaeldsuarez|Michaeldsuarez]] ([[User talk:Michaeldsuarez|talk]]) 21:53, 19 December 2011 (UTC) |
||
*'''Strong support''' - SOPA poses a direct threat to what Wikipedia stands for. As Vint Cerf wrote in a letter to Lamar Smith, SOPA opens the door to "unprecedented censorship" of the web. When statements like this - including an appeal from 83 of the internet's founders about the dangers of SOPA - fall on deaf ears within Congress, it's time to act. Wikipedia has the power to reach thousands of people, and that kind of power should not be taken lightly or used carelessly. The situation is dire, but there may be hope if Wikipedia contributes to the awareness effort. As representative Zoe Lofgren pointed out, people have a tremendous power to influence legislation, as illustrated by the story of one of her colleagues rethinking his position on SOPA after a phone call from a small business owner in his district. If more representatives hear from their constituents about how counterproductive and dangerous this bill is, maybe the tide will turn. This is a crucial moment in the Internet's history, and I think that Wikipedia should take a stand, because SOPA undermines every value that this community is built on. The neutrality that people are so protective of in this discussion can only thrive in an open internet. The sum of all human knowledge will not thrive in the balkanized internet that will result from SOPA being passed.[[User:Nadya lev|Nadya lev]] ([[User talk:Nadya lev|talk]]) 22:01, 19 December 2011 (UTC) |
*'''Strong support''' - SOPA poses a direct threat to what Wikipedia stands for. As Vint Cerf wrote in a letter to Lamar Smith, SOPA opens the door to "unprecedented censorship" of the web. When statements like this - including an appeal from 83 of the internet's founders about the dangers of SOPA - fall on deaf ears within Congress, it's time to act. Wikipedia has the power to reach thousands of people, and that kind of power should not be taken lightly or used carelessly. The situation is dire, but there may be hope if Wikipedia contributes to the awareness effort. As representative Zoe Lofgren pointed out, people have a tremendous power to influence legislation, as illustrated by the story of one of her colleagues rethinking his position on SOPA after a phone call from a small business owner in his district. If more representatives hear from their constituents about how counterproductive and dangerous this bill is, maybe the tide will turn. This is a crucial moment in the Internet's history, and I think that Wikipedia should take a stand, because SOPA undermines every value that this community is built on. The neutrality that people are so protective of in this discussion can only thrive in an open internet. The sum of all human knowledge will not thrive in the balkanized internet that will result from SOPA being passed.[[User:Nadya lev|Nadya lev]] ([[User talk:Nadya lev|talk]]) 22:01, 19 December 2011 (UTC) |
||
*'''Oppose as POV and a distraction by "movement groupies" over content creators.''' We should not restrict content to make a political point (to support or oppose a law). Similar to not censoring. This is censoring the entire site. I'm also concerned that this seems to appeal to people that would rather found a movement than write content. Wales and Gardner should worry about content problems we have (10 years into this thing). This is a distraction. It takes us further down the road of losing the best writers and retaining people that want to use the blank slate as part of some meta-battle. (And if you don't like it or think I'm not AGFing or shouldn't impute motives, tough titties. I would look anyone on this site in the eye and say what I beleive.)[[User:TCO|TCO]] ([[User talk:TCO|talk]]) 22:11, 19 December 2011 (UTC) |
|||
== Reflist should be shown when previewing a section edit == |
== Reflist should be shown when previewing a section edit == |
Revision as of 22:11, 19 December 2011
Policy | Technical | Proposals | Idea lab | WMF | Miscellaneous |
- Table of contents
- First discussion
- End of page
- New post
New ideas and proposals are discussed here. Before submitting:
- Check to see whether your proposal is already described at Perennial proposals.
- Consider developing your proposal on Wikipedia:Village pump (idea lab).
- Proposed software changes that have gained consensus should be filed at Bugzilla.
- Proposed policy changes belong at Wikipedia:Village pump (policy).
- Proposed WikiProjects or task forces may be submitted at Wikipedia:WikiProject Council/Proposals.
- Proposed new wikis belong at meta:Proposals for new projects.
- Proposed new articles belong at Wikipedia:Requested articles.
"Blocked" template tweak
Multilingual search results for registered Wikipedians.
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)
- 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)
To be able to own Wikipedia.
I have a suggestion that might make some money for Wikipedia and serve its goals at the same time.
I would like to be able to BUY a copy of a certain year of the entire site. I cannot say if this would be a set of DVD's or a large stand alone hard drive, but I would LOVE to have my own copy of the whole site. There are times that one's internet is not working and to have your own copy of the closest thing to an Encyclopedia Galactica would be delightful.
A second reason I think this is a good idea is that it would allow a researcher to document changes over time. For example, the word "soandso" only has a placeholder in Wikipedia 2011, but by 2012 it is a huge document. The phrase "soandso" appears to have entered the popular lexicon between 2011 and 2012.
We can learn a great deal about the past by looking at a popular encyclopedia at that time. What were the prevailing attitudes on certain subjects and what subjects might have been taboo. It would be a shame for Wikipedia to be moving forward in time and to leave nothing historical in its wake. The evolution of Wiki's or Wikipedia itself is a subject worthy of study, but unless there exists a static snapshot of a moment in time, that historical context is lost.
In the final analysis there is the fact that when civilization collapses, I'd like to know a few backups are out there somewhere.
- See Wikipedia:Database download. You can download the whole site to your hard drive, for free. However, if civilization collapses, I think that the internet would be among the bottom of social priorities. Cambalachero (talk) 02:25, 17 November 2011 (UTC)
- Do you know about page history? You can see all versions of every page, ever. For example, So and so began as a rather odd redirect in 2005 [1], and gradually expanded [2] [3]. (Not a great example; it's far more interesting to look at the historic versions of more substantial articles). Also, you might find nost:HomePage interesting, which is a frozen snapshot of Wikipedia from 2001 - e.g. nost:Earth.
- There's various plans in place to provide a 'snapshot' of Wikipedia in various formats. I just hope they remember to write Don't Panic in large, friendly letters. Chzz ► 09:09, 17 November 2011 (UTC)
Wikipedia has never been for sale - Wikipedia always has been, and probably always will be, a free internet site, which is able to be accessed by any one who has access to the world wide web. ACEOREVIVED (talk) 20:53, 23 November 2011 (UTC)
- Oh and by the way: you can also buy printed editions of Wikipedia! mabdul 11:55, 30 November 2011 (UTC)
- Oppose It's a good idea, but the encyclopedia is too large to try to document the entire thing. At this point, how would we easily make a distinction between actual articles and "Wiki" pages, such as the projects and special pages? What articles should be included/excluded from a printed addition. At this stage, with American culture moving away from print media and embracing the digital age, it would be like taking a step backward, rather than a step forward. Tarheel95 (Sprechen) 16:57, 5 December 2011 (UTC)
- There are various (free) versions that you can own, but they do suffer form some limitations. Cambalachero's idea is a good one in principle. Rich Farmbrough, 21:29, 5 December 2011 (UTC).
Provided you don't care about the images, this provides a dedicated offline copy of Wikipedia in a handheld package. Dragons flight (talk) 21:39, 5 December 2011 (UTC)
- Proposal is out of place. There is no policy or guideline of the English Wikipedia that has much to do with this. If you want to buy a physical copy from the Wikimedia Foundation, contact them directly and see if you can come to a mutually agreeable price. Alternatively, it doesn't have to be the Foundation; nothing stops anyone, really, from downloading the whole site and selling you a physical copy, but if you want to place an ad for such a person, this is probably not the right place to do it. --Trovatore (talk) 21:44, 5 December 2011 (UTC)
- My studies show that the English Wikipedia would fit on a large external hard drive, along with all media it uses (although they may have to be at reduced size). I think this could be sold for $100 USD, possibly less. I think it's an excellent idea for someone to do this. I might do it. WMF isn't going to do it, as they generally leave commercialization of content to others. Dcoetzee 10:25, 8 December 2011 (UTC)
- Sure, go for it. Anyone can; it's (almost entirely*) free. Anyone can do anything they want with it, as long as they give credit.* Many people have copied various parts of Wikipedia to various formats; that's all great. No problem. And if they make $$$ from it, good luck to 'em. Chzz ► 10:23, 14 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)
- 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)
- 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)
- 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)
- 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)
Template:Bug "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)
- Now and then and here and there!
- 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)
- 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!
- 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)
- 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)
- 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)
- 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)
- 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)
Enable "Show changes since last visit" on watchlist
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)
- 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)
- There's no opt-in, but as I said above, it's overridable. — Edokter (talk) — 00:15, 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)
- I cannot support this proposal if there won't be an opt-out.Jasper Deng (talk) 23:33, 3 December 2011 (UTC)
- Jasper: Would you be opposed to
- 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)
- 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)
- The opt-out was what I was talking about here. Jasper Deng (talk) 00:50, 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)
- 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)
- 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 editsreview 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)
- 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)
- 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)
- I already checked, and the
- 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)
- Really? Do visited and unvisited links not show in different colors for you? ♫ Melodia Chaconne ♫ (talk) 14:56, 4 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)
- 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)
- 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)
OpposeSupport - 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. —Bruce1eetalk 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)
- 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)
- Indeed. No need to wait the full 30 days. I'll post a request at Bugzilla. — Edokter (talk) — 18:48, 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)
Call talk pages "Talk"
RfC tag added on 09:01, 4 December 2011 (UTC).
Hi. A lot of Wikipedia instructions tell people to post "on the talk page". However, it isn't obvious where this means, since the page is not labelled "talk page" but is labelled "discussion". This is very confusing, especially for someone unfamiliar with all the Wikipedia rules. Wny not change the text on the tab from "Discussion" to "Talk page" to match all the instructions? (By instructions I am referring to everything you get when you click Help, as well as so many of the templates used to tell posters why their edit was not accepted and how to fix it. (184.147.120.119 (talk) 23:07, 2 December 2011 (UTC))
Just a note: the page which will need to be changed is MediaWiki:Talk. sonia♫ 09:48, 4 December 2011 (UTC)
At 17:14, 8 December 2011 (UTC) I changed the title of the post from 'Call talk pages "Talk Page"' to 'Call talk pages "Talk"', because there is a massive consensus among people supporting this change for using 'Talk' in specific and some opposition to 'Talk Page' in specific. Sven Manguard Wha? 17:14, 8 December 2011 (UTC)
- Support this one per 2011 "State of the Wiki" address. Rich Farmbrough, 23:39, 2 December 2011 (UTC).
- Support continuity I don't much mind which is prefered or even if another name like "chatter" or "gobledigook" (well maybe not) is chosen, but I do think we would be better off with one name for all "talk pages" across the whole site. fredgandt 00:42, 3 December 2011 (UTC)
- There is a 2007 discussion at Wikipedia:Village pump (proposals)/Archive AN#Talk Pages. PrimeHunter (talk) 02:20, 3 December 2011 (UTC)
- How about just calling it Talk. That one is even more heavily implied than discussion, although to me, discussion is so obvious that I feel this change is unneeded. Sven Manguard Wha? 02:53, 3 December 2011 (UTC)
- Uh, yes I didn't read properly. Talk is what I support. Rich Farmbrough, 13:04, 3 December 2011 (UTC).
- Uh, yes I didn't read properly. Talk is what I support. Rich Farmbrough, 13:04, 3 December 2011 (UTC).
- I support discussion. This is primarily because of the popularly brought up rule "This is not a forum for general talk about the article's subject". Georgia guy (talk) 14:31, 3 December 2011 (UTC)
- I support Talk because that's what most people call it anyway. @Georgia guy, talk and discussion are basically synonymous, so that rule could be changed to "This is not a forum for general discussion about the article's subject". There's not really any difference. Bazonka (talk) 17:28, 3 December 2011 (UTC)
- How about suggested improvements pages?? Georgia guy (talk) 18:25, 3 December 2011 (UTC)
- That is a little too specific. It would also only make sense for article talk pages. The proposal (I agree with in principal) is to name all talk pages the same way so that wherever users are guided to talk pages they are not confused by finding a "discussion" page but no "talk" page. fredgandt 18:57, 3 December 2011 (UTC)
- P.s. Also it would be a massive tab!
fredgandt
- How about suggested improvements pages?? Georgia guy (talk) 18:25, 3 December 2011 (UTC)
- I support Talk because that's what most people call it anyway. @Georgia guy, talk and discussion are basically synonymous, so that rule could be changed to "This is not a forum for general discussion about the article's subject". There's not really any difference. Bazonka (talk) 17:28, 3 December 2011 (UTC)
- Support. I've idly wondered about why this isn't labelled "Talk" on and off for years. Thryduulf (talk) 01:59, 4 December 2011 (UTC)
- Strong support for Talk page. I have also wondered about this many times myself. It may also be confusing for non native speakers. Kudpung กุดผึ้ง (talk) 02:28, 4 December 2011 (UTC) - or just simply 'Talk'. Kudpung กุดผึ้ง (talk) 06:16, 4 December 2011 (UTC)
- Support "Talk". The name "discussion" is simply never used for talk pages, so it is simply counterproductive to use it in the most prominent place of all. 124.168.87.221 (talk) 05:29, 4 December 2011 (UTC)
- Support. Improving clarity is rarely a bad thing, and I can't remember ever seeing "discussion" used except in the tab. Alzarian16 (talk) 06:14, 4 December 2011 (UTC)
- Support "Talk". As pointed out previously, it's the most commonly used term for the page, so it would be the most user-friendly.--JayJasper (talk) 06:20, 4 December 2011 (UTC)
- Minor Oppose I don't want to be the lone dissenter here....and my reasons are mainly aesthetic. On places where it DOES say 'talk' it just kinda looks...off. It's probably just a matter of getting used to one over the other, but also the word 'discussion' seems to carry a better connotation, IMO, than 'talk'. ♫ Melodia Chaconne ♫ (talk) 07:05, 4 December 2011 (UTC)
- Don't worry Melodia, you're not alone. I've already stated my feelings but not my personal preference, since my preference goes against what I see as the best course of action (if any). I prefer "Discussion" too, but as is being mentioned time and time again here, "Talk" is a colloquialism we can't escape. If this proposal has any value (and I believe it does), it will be to set a standard, continuous use of one word across the site. If we were to choose "Discussion", we would have to change so many policies and templates etc. we would get nothing else done for years. Quite simply, "Talk" is too engrained to oust now, so supporting continuity may mean not getting the word we prefer, but we do get less confusion. fredgandt 07:37, 4 December 2011 (UTC)
- Support Many templates use "see the talk page" or similar for direction, and it's more common to see "talk page" in discourse than "discussion page". Do international language versions of Wikipedia use the same word? In any case, it feels more natural and intuitive to use "talk" and I fully support the motion to change it doktorb wordsdeeds 07:12, 4 December 2011 (UTC)
- Strong support for "talk". It should be labelled as what we call it to avoid completely unnecessary confusion (I'm thinking especially of non-native English speakers, as well as newbies who didn't get enough sleep last night) - and it's always called "the talk page". Pesky (talk …stalk!) 07:15, 4 December 2011 (UTC)
- Strong Support Talk- been waiting for this for a long time. New people only realizes it's the "talk page" after they click the tab and see the page is actually called the "talk page". Plus all our "informative" pages call it "Talk page" like with Wikipedia:Talk page guidelines - Help:Using talk pages - Wikipedia:Talk page layout - Wikipedia:Talk page templates. So lets not confuse our editors right off the bat when there reading introductory pages. Lets make it all match. Moxy (talk) 07:27, 4 December 2011 (UTC)
- I have listed this proposal at Template:Centralized discussion. Cunard (talk) 09:01, 4 December 2011 (UTC)
- Support. "Talk page" is a jargon term, which we should normally avoid in the UI. The name "discussion" is more accessible. But considering how likely it is that we'll change all the help pages, policy pages, and user comments to stop saying "talk pages" (read: will never happen), this is the more prudent alternative. Dcoetzee 09:36, 4 December 2011 (UTC)
- Weak support "Discussion" makes a bit more sense especially to the newcomer than the (relatively vague) "talk", but "talk pages" is simpler and easier for most purposes. sonia♫ 09:48, 4 December 2011 (UTC)
- Weak oppose. If I remember correctly, the tabs for the talk pages were labelled "Talk" when I joined the project. I think it was changed along with the switch from Monobook to Vector, and I think this particular change was based on the findings of the usability project. Apparently, we used to have a lot of readers who had no idea that Wikipedia articles have associated discussion pages and had no desire to try out the cryptic "Talk" tab. Hans Adler 13:57, 4 December 2011 (UTC)
- This was not as you describe. Some versions of Twinkle and Friendly used to include a script which changed the title of the "discussion" tab to "talk". This script was disabled a while back (around the time of the change to Vector). — This, that, and the other (talk) 04:10, 5 December 2011 (UTC)
- Strong support Talk for the sake of consistency with namespace: Talk:Example suggests the link to Talk page. Calling things by their names is an important aspect of usability. — Dmitrij D. Czarkoff (talk) 16:05, 4 December 2011 (UTC)
- Support. PaoloNapolitano 16:36, 4 December 2011 (UTC)
- Oppose On the contrary, we should change the help, docs, etc. to speak of "discussion pages" rather than "talk pages". "Discussion" seems to make more sense as a descriptor, particularly for outsiders. --Cybercobra (talk) 21:37, 4 December 2011 (UTC)
- Discussion name has already failed replacing the Talk name in general use. No need to revive dead. — Dmitrij D. Czarkoff (talk) 10:29, 5 December 2011 (UTC)
- Tentative support, but also question for clarification: are we talking only about the link in the tab row at the top of each page, where it now says "Article | Discussion" or "Project page | Discussion", or is "Discussion" also found somewhere else? If it's only that one link, I'd go for changing it, for consistence with the actual namespace labels, but perhaps go for "Talk page" rather than plain "Talk". Fut.Perf. ☼ 21:47, 4 December 2011 (UTC)
- Just that tab link I believe, and the original proposer did say "talk page", although it's gotten a bit garbled along the way. sonia♫ 22:06, 4 December 2011 (UTC)
- Yes, I am the proposer and that is what I meant. "Talk" would be just as clear. I am glad the idea has support. What happens next? Do I have to request anyone in particular anywhere in particular to make the change? Or do I wait more time and then request? Or something else? Thank you everyone for understanding. (184.147.120.119 (talk) 02:11, 5 December 2011 (UTC))
- Here's what happens next. This change appears to have significant support, so this discussion has become a request for comment to get input from the broader community. It will run for 30 days gathering input. After the 30 days, somebody that hasn't participated in the dicussion will judge the consensus and close the discussion with a summary of what the community has decided. If there is consensus for the change, somebody will file a Bugzilla request to have the software changed to make the pages show talk instead of discussion. That may seem like a long time, but once started the process runs until it's completed. So you aren't required to do anything else, but you are certainly welcome to if you'd like to. Best regards. - Hydroxonium (T•C•V) 04:30, 5 December 2011 (UTC)
- This does not require a bugzilla request or a software change. An admin can just modify Mediawiki:Talk to make the change. --Yair rand (talk) 04:35, 5 December 2011 (UTC)
- Cool, thanks for the info. (184.147.120.119 (talk) 22:16, 5 December 2011 (UTC))
- Here's what happens next. This change appears to have significant support, so this discussion has become a request for comment to get input from the broader community. It will run for 30 days gathering input. After the 30 days, somebody that hasn't participated in the dicussion will judge the consensus and close the discussion with a summary of what the community has decided. If there is consensus for the change, somebody will file a Bugzilla request to have the software changed to make the pages show talk instead of discussion. That may seem like a long time, but once started the process runs until it's completed. So you aren't required to do anything else, but you are certainly welcome to if you'd like to. Best regards. - Hydroxonium (T•C•V) 04:30, 5 December 2011 (UTC)
- Oppose The argument is flawed because in many pages, we tell users to look at the "discussion page". "Discussion" is much much more easy to understand than "talk" for a new user—what's a "talk page"? Do we call conference rooms "talk rooms" or forums "talk boards"? Discussion is more newbie-friendly; if we need to reword help pages, then we should do that to make it more sensible in the long run. /ƒETCHCOMMS/ 02:37, 5 December 2011 (UTC)
- In which pages do we tell users to look at the "discussion page"? Thanks, —{|Retro00064|☎talk|✍contribs|} 05:26, 5 December 2011 (UTC).
- There are some that refer to the "discussion page", that is true. But there are far, far more that refer to the "talk page". Take a look around. — This, that, and the other (talk) 06:30, 5 December 2011 (UTC)
- "Discussion page" results, etc. Just because more pages use "Talk" over "Discussion" is no reason to change to "Talk". "Discussion" is far more understandable to new users—and that's what counts, no matter how many changes we have to make on our end. We must make Wikipedia simpler to understand and navigate for newbies. /ƒETCHCOMMS/ 15:23, 5 December 2011 (UTC)
- There are some that refer to the "discussion page", that is true. But there are far, far more that refer to the "talk page". Take a look around. — This, that, and the other (talk) 06:30, 5 December 2011 (UTC)
- Hey, come on! Both talk and discussion describe the same process. The difference is too small. — Dmitrij D. Czarkoff (talk) 10:29, 5 December 2011 (UTC)
- In which pages do we tell users to look at the "discussion page"? Thanks, —{|Retro00064|☎talk|✍contribs|} 05:26, 5 December 2011 (UTC).
- Support. We should name it what we call it. Kaldari (talk) 03:10, 5 December 2011 (UTC)
- Comment - I would absolutely love for this to happen. Absolutely.--Jorm (WMF) (talk) 05:02, 5 December 2011 (UTC)
- Support: (edit conflict) It would make sense to have consistency between what the tab's text is and what users refer to the page as. It seems to me that "talk page" is the common term, so if we are going to continue to use "talk page" in our comments, help and policy pages, templates, etc., then we should change the tab to say "talk" or "talk page" to achieve that consistency. If we are going to continue to have the tab say "discussion", then we should actually start calling the page to which it links the "discussion page" instead of the "talk page" in our comments, help and policy pages, templates, etc. Regards, —{|Retro00064|☎talk|✍contribs|} 05:26, 5 December 2011 (UTC).
- Support "Talk" for consistency and clarity reasons. --TorriTorri(talk/contribs) 06:37, 5 December 2011 (UTC)
- Oppose The word talk is misleading because we don't talk there; we write. Readers might confuse this with an audio interface such as Siri. Warden (talk) 09:30, 5 December 2011 (UTC)
- This is actually a good argument for renaming the whole talk namespace to discussion. Good luck getting consensus on that though. Yoenit (talk) 09:33, 5 December 2011 (UTC)
- Actually I hadn't considered that: "talk" could give the misleading impression that it is possible to hear the article read out to you by clicking that tab. Make of that what you will, though. — This, that, and the other (talk) 10:33, 5 December 2011 (UTC)
- Support But "Talk", not "Talk page". The latter is ghastly. If you prefer "Discussion", I'm sure we can write some CSS/JS to give you the old style. —Tom Morris (talk) 14:48, 5 December 2011 (UTC)
- Neutral If you are concerned about 'Talk' being an audio interface, then you could change the tab to Discuss, though it's not as friendly as Talk. Whatever is the consensus is fine, but I do agree that consistency is best either way. ʘ alaney2k ʘ (talk) 17:05, 5 December 2011 (UTC)
- Strong Support for "Talk". Click on "Discussion", and what does it take you to? A page that has the title "Talk:Page" right there at the top. The proposal makes very good sense, per the principle of least surprise. I've also noticed when I talk to non-editors in real life that when I explain to them how we use talk pages, they ask me how they can find the talk page for a given article. I find that I have to tell them to click on "Discussion", and that's the way to get to "Talk". Admittedly, it's not that hard to figure out, but it really is more user-friendly to make this change. --Tryptofish (talk) 20:09, 5 December 2011 (UTC)
- Support with comments - I agree that if someone wants to call their talk page something else its fine and that the default would be better as Talk page. However, it would be fairly easy to create a script to rename the page so an individual can call it whatever they want (i.e. talk, Talk page, discuss, etc). --Kumioko (talk) 21:49, 5 December 2011 (UTC)
- Support new, and especially foreign language editors are often confused about our nomenclature. We need to be consistent, and it's typically easier to change a label than to change what many people call them. Buddy431 (talk) 00:05, 6 December 2011 (UTC)
- I'm in favor for consistency, but then we should go with Discussion. It describes the function of the page much better than the vague 'Talk' . —TheDJ (talk • contribs) 00:18, 6 December 2011 (UTC)
- Oppose - Fetchcomms is right, 'talk page' is not user friendly, actually it's such a weird name that if I were not a regular Wikipedia I would probably be confused as to what it means. In fact just a few days ago I changed my signature and talk page header from 'talk' to 'contact' for this reason. If the problem is the lack of consistency referring to the namespace, then the change is needed at the help page level, not in the display tabs. For what it's worth, I would support moving the namespace to
Discussion:
; in the meantime I will oppose changing the displayed tab to "talk page", as 'discussion' is much more straightforward. CharlieEchoTango (contact) 08:14, 6 December 2011 (UTC)
- Many people at first do not know what "wiki" means, and they also learn what "talk page" means. -Wikid77 13:32, 6 December 2011 (UTC)
- So you're saying that new users should just learn random things about how Wikipedia works before contributing? Just because people learn what "talk page" means later does not mean we should expect people to take the time to figure that out before they get impatient and just give up. /ƒETCHCOMMS/ 01:42, 7 December 2011 (UTC)
- Many people at first do not know what "wiki" means, and they also learn what "talk page" means. -Wikid77 13:32, 6 December 2011 (UTC)
- Strong support "Talk". The menu option "Talk" is shorter than "Discussion" and the term "talk-page" provides a distinctive, while still short, name for such wiki-pages. A Google search for "talk-page" reveals it is closely linked (80%) to wiki websites, whereas a search for "discussion page" reveals wide, rambling use in many other websites, with no specific meaning as to what "discussion" entails. For over 6 years, many Wikipedia users have understood that a "talk-page" is not an open forum to blog about ideas; however, "discussion" might be imagined as a different type of page, perhaps open to blog-forum posts or other general discussions. Name the menu tab "Talk" to be more precise and avoid confusion. -Wikid77 13:32, 6 December 2011 (UTC)
- Support for the purpose of consistency, I support "talk". "Discussion" is overly long and the page is called a talk page, not a discussion page. We shouldn't rename the talk namespace to discussion though. Talk and Discussion have the same meaning, the only difference being "Discussion" is much longer lengthwise. Alpha_Quadrant (talk) 17:48, 6 December 2011 (UTC)
- Support. - Dank (push to talk) 18:50, 6 December 2011 (UTC)
- Comment - Classic skin (which doesn't have tabs) links to talk pages in the sidebar with the link Discuss this page. Would there be any change to this? — An optimist on the run! 21:38, 6 December 2011 (UTC)
- Question How would this affect Monobook? I like the idea for the default skin, since it's simpler for people not already familiar with Wikipedia, but I prefer "discussion" for my own purposes simply because I'm accustomed to it. Nyttend (talk) 03:40, 7 December 2011 (UTC)
- Support "Talk" - as a volunteer in #wikipedia-en-help connect, I've found that many new users find it disorienting when we direct them to the "talk page". Often, the reaction is "Wait, where is that?" and we have to explain how "discussion" == "talk". ~ Matthewrbowker Say hi! 05:42, 7 December 2011 (UTC)
- Support Talk Per common name, common sense, it's shorter, it's more inviting, it's consistent with the namespace. A small step towards UI sanity. Ocaasi t | c 07:29, 7 December 2011 (UTC)
- Support this obvious and long-overdue change. I don't know what caused it, but I'm impressed by the sudden outbreak of common sense in this thread. Robofish (talk) 12:42, 7 December 2011 (UTC)
- Support talk An obviously good idea--why was this ever changed to "discussion?" —Justin (koavf)❤T☮C☺M☯ 10:18, 8 December 2011 (UTC)
- Support, although I also think its neither here nor there. Even if English is not your first language, if you can't find the "talkpage" by clicking on the word "discussion", you should probably think about whether editing Wikipedia is the best use of your time. --FormerIP (talk) 18:49, 8 December 2011 (UTC)
- Oppose, though I would support a broad effort to update references to "talk pages" to "discussion pages". Not sure on the namespace; I don't think keeping it "Talk" is necessarily confusing. Powers T 19:13, 8 December 2011 (UTC)
- Oppose I don't mind informal mentions and references to talk pages, but changing the actual tab seems to imply (intentionally or otherwise) a morphing of the pages' purpose, to general debate about the article rather than for content development as it is now. That's an erosion of wp:NOTFORUM. 66.127.55.52 (talk) 17:42, 9 December 2011 (UTC)
- Support Talk - It's a common name, and it's more consistent with the namespace and what everyone calls it. Very rarely have I ever seen someone say "discussion page".--Unionhawk Talk E-mail 19:34, 9 December 2011 (UTC)
- Support–It's not only far more commonly used, it's also the name of the namespace. "Discussion" does sound a bit more formal, but the consistency with most usage and with the namespace system makes it preferable to me. oknazevad (talk) 14:22, 10 December 2011 (UTC)
- Oppose I prefer keeping it "Discussion" especially for new readers and editors. In many dialects of English talk and discussion are not the same thing. Discussion implies for many of us civil, rational analysis and discourse. It is not surprising that in shorthand discussions talk is used more often than discussion; it is shorter. That does not mean we should formally accept "Talk" as the default tab. There should be no problem in providing an optional display for those editors who wish to use a "Talk" tab. But for new users "Discussion" is clearer and more appropriate. --Bejnar (talk) 22:18, 10 December 2011 (UTC)
- On the other hand, when we say "talk page" all the time, when several of the templates we use (such as {{Expert-subject}}) say "talk page", and when all the namespace names use the word "talk", it probably makes it confusing to new editors when the tab doesn't also say "talk". and while the second and third could be fixed, the first can't - both because we would need to go through all the pages in the Discussion: namespace, the User discussion: namespace, etc. to fix them, and since users are so used to using this term that they will keep doing so, even to new users. עוד מישהו Od Mishehu 09:01, 13 December 2011 (UTC)
- Support - Neither term is precisely correct, and arguments could be made either way. "Discussion" is not precisely correct, because a user talk is not for discussing the user or the user page. It's important to keep things simple, and consistent. Any potential benefit of "discussion" being more clear than "talk" is lost through the constant confusion (new) users have, wondering what we mean by a "talk page". Especially when their own 'user talk' is called what it is. The word "talk" is short, snappy, matches the internals, and isn't all that mystifying. Keep it simple. I think this is a classic case where a 'usability study' did not truly consider all ramifications of a change - if we were designing a new mediawiki from scratch, we might go for 'discussion' - but we're not; "talk" is ingrained into our culture; it is unrealistic to change "talk" to "discussion" in every place (indeed, for historical discussion, it's effectively impossible). Changing "discussion" (tab) to "talk" is simple. Chzz ► 00:30, 11 December 2011 (UTC)
- Support - For consistency with the mainspace and with what we actually call it, and to be less confusing to newcomers. I think their nature won't change regardless of what is actually written on the tab, so no possible harm done. Zidanie5 (talk) 13:02, 11 December 2011 (UTC)
- Support unless we are going to change the talk namespace to be a discussion name space. The current setup is unclear. -- Eraserhead1 <talk> 22:03, 11 December 2011 (UTC)
- Support, since the page in question is always Talk: (or NamespaceName talk:), not Discussion:. עוד מישהו Od Mishehu 09:11, 12 December 2011 (UTC)
- Support - greater consistency; less likely to cause confusion among newer users. Chris (talk) 00:22, 13 December 2011 (UTC)
- Oppose. In simple, it makes sense. Here, no. theMONO 03:11, 13 December 2011 (UTC)
- Here, we talk about "talk pages", not "discussion pages". And the namespaces of these pages all use the word "talk", never "discussion". עוד מישהו Od Mishehu 05:31, 13 December 2011 (UTC)
- Oppose Instead of changing the tab labels, we should rename the namespace from Talk to Discussion. Why? Because I think it is more natural to advice someone to participate in an article discussion by editing the discussion page and talk gives a stronger impression that the page is for general talk about the article topic. Should I make a counter proposal to rename the namespace? Toshio Yamaguchi (talk) 16:21, 13 December 2011 (UTC)
- I, personally, could only support that if you can also have all past discussions changed from "talk page" to "discussion page", and make sure that all Wikipedians, including those who happen to be on Wikibreak in paralell to the discussion, will use the word "Discussion page" in stead of "talk page" - and I don't think that you could do that. עוד מישהו Od Mishehu 16:25, 13 December 2011 (UTC)
- Support. Strongly needed. Rcsprinter (gas) 16:42, 13 December 2011 (UTC)
- Oppose per most of the other oppose reasons. That and I just like the way it is now. - Purplewowies (talk) 17:20, 13 December 2011 (UTC)
- Ovbious Support. Well, yes. It seems obvious that some people who are unfamiliar with Wikipedia, might say, "Talk page? Where's the talk page?" and all they would see is "Discussion". All I'm saying is that it seems obvious. yrtneg talk contr 23:19, 13 December 2011 (UTC)
- P.S. I also oppose this in some matter, such as the word "discussion" being more, eh, mature than "talk". My vote is now neutral. yrtneg talk contr 23:19, 13 December 2011 (UTC)
- Comment. Did nobody read two week ago's signpost, where it becomes clear that such inconsistencies are exactly (one of) the kind of difficulties newcomers are experiencing, or why is it that this is not mentioned a single time? Unfortunately, topics like these always result in wikiarguing, so I prefer abstaining from further input on this. Nageh (talk) 23:32, 13 December 2011 (UTC)
- support duh. It is the talk page. Protonk (talk) 05:10, 14 December 2011 (UTC)
- To people seriously think that the tab being called discussion somehow elevates the level of discourse on the page? And that the solution is to change the namespace to "discussion"? Even worse, are people serious in renaming both to "collaboration" or something likewise obfuscatory and multi-syllabic?! That's pretty surprising, so I apologize for my incredulity. It seems to be much easier to change the site CSS to say "talk" than change every single link and mention of the talk namespace in order to satisfy our sense of superiority. The only cogent argument I can see against using "talk" is that it mischaracterized what actually goes on in talk pages--we don't "talk", we write. But that seems needlessly pedantic. I guess we can chalk this up to the community's willingness to accept the status quo because they are used to it, consequences for new users be damned. Protonk (talk) 23:44, 16 December 2011 (UTC)
- Support That was one of my first questions when I discovered non-Mainspace Wikipedia. BTW, it's already done over at the Simple English Wiki. Zlqchn (talk) 12:44, 15 December 2011 (UTC)
- Oppose; discussion was never a good alternativ to talk - same problems. I suggest Collaboration - and change the Namespaces accordingly (I think we can set up a namespace redirect from Collaboration->Talk and change relevant links). Then make an effort to stop saying "talk page" :) --Errant (chat!) 13:06, 15 December 2011 (UTC)
- Oppose. I oppose for reasons of dignity and the value of description. "Discussion" is a nicely dignified word, appropriate for the prominent position given to it on each article in this encyclopedia. "Talk", in the sense of discussion, as opposed to exposition or demonstration, seems quite the opposite. And "discussion" is a better descriptor, in part because "talk" can only clearly have a sense which is general for the page. Click on the "discussion" link and you are brought to a page which hosts a discussion, a particular discussion. You are not brought to a page which hosts a talk, unless one takes "talk" in an obscure sense for such a usage. Even in the case of their general senses, "discussion" seems to be a better descriptor. What happens, or is supposed to happen, on the page, "discussion" accurately describes that; and that is a discursive conversation in any medium focused on a particular matter. "Talk" can have a sense which can refer to such a thing by subsuming it under a more general heading, but as such it does not pick out it so specifically. Lastly, "talk" having many other senses, if it is taken in these, it is prevented from referring to such as "discussion" does. This last point has been partly illustrated above by others.--Atethnekos (talk) 03:43, 16 December 2011 (UTC)
- Support—aside from consistency, it's more inviting to newbies to see a tab that says "talk". Tony (talk) 10:55, 18 December 2011 (UTC)
- Support This would make things easier for new editors, and would have some consistency when linking to the talk page. And changing the name to something different than "disucssion" or "talk" and trying to get editors to change their habits is untenable. Let's call a spade and spade. Angryapathy (talk) 15:06, 19 December 2011 (UTC)
Insert-able edit points without creating a new section
Proposal to create a new magic word we can insert into long threads to create an [edit] link without creating a new section.
- I envisage being able to add the magic word (e.g. {{EDITPOINT}}) anywhere within a section, and have an [edit] link created at that point in the thread (floated to the right of the page as with all normal edit links). This would not create an {{anchor}}, section or subsection heading, or be recognised by the toc.
- When followed, the editor would be presented with an edit page populated by all the text of the section the EDITPOINT is in,
from that point onward(including text in sub-sections),as would be normally expected, but not any text from that section that is above the EDITPOINT.An alternative to this would be that all text from that section is presented as normal, with the exception thatthe raw text is then automatically scrolled to the point at which the EDITPOINT is featured.This may be a more practical and appealing usage, but may have technical difficulties the primary proposal doesn't.
- The reasoning is that when wanting to edit half way through a long section, we are presented with the whole section and its subsections, with little to no obvious indicators throughout the unformatted raw text to follow in order to find the point at which we wished to make our edit.
- With EDITPOINTs inserted at intervals, we could access the section far nearer to the point we wish to edit than at present. We could simply use the nearest EDITPOINT that is above the focus of our attention.
- I believe this would make editing easier, would be relatively simple to create and install, and would have few downsides.
- There is one obvious possible downside: Overuse. A simple solution for this is to Assume good faith. A more cynical approach might be to allow only a given number per section. Uses of templates are already limited (good thing too), so the scripting is almost entirely in place to handle the task already. This possible downside (even if not monitored or controlled by the software) is as easily dealt with as all other editing faux-pas, so would cause little extra work for guardians.
- Summary: A simple new mark-up that creates an [edit] link without creating a section. When followed, the editor gets an edit page populated by all text from the section the EDITPOINT is in, but automatically scrolled to the point in the raw text where the EDITPOINT used is situated.
only from that EDITPOINT onward.This would make it easier to hone in on the point in that thread we wish to edit (reduced searching of the raw unformatted text).
- Thanks for reading. fredgandt 08:43, 4 December 2011 (UTC)
Questions about EDITPOINT
Questions: I am concerned that the feature would just be used to make every paragraph an EDITPOINT and deter people from making logical section headers, as they would have in the past.
- Q1: Would points be overused, and flood a page with [edit][edit][edit][edit][edit][edit]?
- Q2: Since headers were no longer needed, would header titles suffer?
- Q3: How about create non-indexed headers "==Break2=={{nonindex}}" shows header "Break2" as [edit] but not in Table-of-Contents box?
- Q4: Should a page be "fractionalized" instead, by a menu option "Fract" which re-displays the page with dozens of "[edit]" links, for each paragraph of the page (with no need to embed editpoints)?
- Q5: How would a page redisplay to the edited thread unless editing by header? I do not think it could, and after an edit, the page would display to the top and no longer jump down to the section just edited.
Those are some other questions to consider before stating Support/Oppose. -Wikid77 14:27, revised 18:23, 6 December 2011 (UTC)
Compare to header [Edit] as a name: The concept is intended to not list any EDITPOINT headers in the Table-of-Contents box. However, that it might be ok to name a small section header as "====[Edit]====" to show a left-side "[Edit]" break (with a right-side "[edit]" button). For example, there is an header as "[Edit]" here:
[Edit]
This section, with header "==== [Edit]====" is a 4th-level header which clearly indicates that it can be edited, without needing to create an {EDITPOINT} marker here. However, the header "[Edit]" will also appear in the Table-of-Contents box, above. Logically, users might see such break points are obvious edit-buttons, without the need to conceal editpoints. As more users insert headers named "[Edit]" as text edit-points, then the concept would be understood more widely, without adding special features. Does that seem like a good idea? -Wikid77 18:18, 6 December 2011 (UTC)
Support/Oppose of EDITPOINT concept
- Strong support - eminently sensible. Pesky (talk …stalk!) 08:53, 4 December 2011 (UTC)
- Support. Seems like a good incremental short term solution, and I'm pretty confident it could be implemented easily (but would require minor Mediawiki code changes). Some concerns: if the page is very large, including all text all the way to the end might be too much text. Perhaps just to the end of the section? Also, should the {{EDITPOINT}} tag itself be included or not? How would edit conflicts be handled? Alternatives: I think the better long-term solution here is a real in-place WYSIWYG editor that lets you edit as you read without switching views or formats, but that's a long way off and very hard to get right. As an intermediate alternative, it might be nice if there was some kind of "edit here" feature that let you just right click any piece of text and choose "Edit here" and it would open up an editing view scrolled directly to that location. Dcoetzee 09:25, 4 December 2011 (UTC)
- As I see it, this is a small step in the right direction, not a giant leap. I proposed that the text presented in its raw format is all the text from the section the EDITPOINT is in, from that point onward. Edit conflicts would be dealt with in exactly the same way as they are now. This is basically just an invisible section heading that even the toc doesn't see. The actual tag would of course be visible in the edit window, otherwise nobody could ever remove or more them. fredgandt 09:54, 4 December 2011 (UTC)
- Support. The number of times I'd have used this recently just at WT:NOT would have saved me a good hour at least (not including fewer edit conflicts). Thryduulf (talk) 12:45, 4 December 2011 (UTC)
- Weak support: to me it seems that those edit points are useful before inserting them, not after; another concern is that the articles would get littered with edit points. Still, that might be useful, so why not? Though I would prefer an option to add (visually) tiny edit point to every block element on the page. — Dmitrij D. Czarkoff (talk) 13:27, 4 December 2011 (UTC)
- What do you mean by "block element"? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
- It was about HTML elements with block properties, though I get that Mediawiki abuses HTML markup, so this could be limited to the topmost sub-elements of the article (each text block, blockquotes, etc...) — Dmitrij D. Czarkoff (talk) 16:09, 4 December 2011 (UTC)
- What do you mean by "block element"? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
- Comment: this isn't going to happen; the devs will say it's covered by LiquidThreads, and anyway editing is based fundamentally on sections, so the best you can do is scroll to a pre-specified point in the wikitext. That latter idea though can be done by a script. The timestamp with (UTC) at the end of each signature is fairly unique; a script could add a little mark at the end of each (UTC), and when clicked it goes into edit mode and searches for that timestamp in the wikitext. Rd232 talk 13:45, 4 December 2011 (UTC)
- Is liquid threads ever coming though? It's being trialled on some user talk pages on Wiktionary, but it's not ready for general release yet and hasn't had any significant changes for a couple of years. It's good in theory, but I've yet to be convinced it will actually do what it's trying to do. So in the meantime, why not implement this interim proposal that is technically possible without requiring years of development? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
- Well for one thing, the client-side script I suggested would be a better solution than the magic word. For another, I severely doubt that if a bug was filed today it would result in a change to Wikipedia's functionality in less than 2 years, even if the developers agreed in principle. Developer time is simply too limited. Rd232 talk 19:39, 4 December 2011 (UTC)
- The Extension:LiquidThreads is being rewritten, and you can follow the status of the LiquidThreads 3.0 development on this page: mw:LiquidThreads_3.0/status#2011-10-31. Helder 22:20, 4 December 2011 (UTC)
- LiquidThreads is for discussion pages, not articles... I don't see the relevance. Dcoetzee 04:49, 6 December 2011 (UTC)
- Is liquid threads ever coming though? It's being trialled on some user talk pages on Wiktionary, but it's not ready for general release yet and hasn't had any significant changes for a couple of years. It's good in theory, but I've yet to be convinced it will actually do what it's trying to do. So in the meantime, why not implement this interim proposal that is technically possible without requiring years of development? Thryduulf (talk) 13:51, 4 December 2011 (UTC)
- Rd232 is correct: whatever the merits, this proposal will not be implemented. For one thing, inserting "===Break 1===" is almost equivalent (yes, it's not the same and has defects, but it's very similar). Re LiquidThreads: That's the knockout; devs would not want to work on some tweak that would be obsoleted by LQT. My opinion: LQT would kill good editors, and I hope the community manages to repel it (in brief: too obtrusive; encourages "this is a forum"; POV pushing would never end; too hard to remove unhelpful comments). Johnuniq (talk) 02:25, 5 December 2011 (UTC)
What about automatically inserting edit points every x bytes in a section over a length of y bytes? That way it would be impossible for people to go nuts with it. Add an option to show/hide edit points in the preferences, or for each page individually, and anybody that doesn't like them wouldn't have to deal with them. Put me down for a Weak support. Falconusp t c 11:58, 5 December 2011 (UTC)
- Although I agree with those suggestions and think they would improve the overall proposal, I think asking for more than the simplest upgrade could lead more certainly to it not being added. I'm going to be updating the proposal to simplify it (technically) with just that in mind. Very basically, I think proposing the alternative (in the proposal lead) method is more likely to be considered for creation and installation, since it is nothing more than an adaptation of the code controlling nd displaying section headings. fredgandt 20:36, 5 December 2011 (UTC)
- Support. They don't have to be used in articles. If an article section is that long we would make section breaks.Jasper Deng (talk) 22:42, 5 December 2011 (UTC)
- I've struck out (crossed through) and inserted (shows underlined) some text in the proposal lead since having a think about it. The proposal seems to be getting bogged down in technical details. Can we first establish simply if there is a rough consensus for some sort of functionality that allows this kind of thing? Once we know if the basic idea is worth exploring, we can get techy-wid-it!
- I've started work on a user script and a template that may or may not amount to something useful. I'll keep you posted. I would prefer the function/feature to be part of the Mediawiki software though. fredgandt 19:42, 6 December 2011 (UTC)
- Support - sensible idea for pages with longer sections. A can see issues arising with these edit points being overused, however, so there would need to be clear instructions on how to use them (perhaps a new WP namespace page on edit point guidelines). Chris (talk) 00:54, 13 December 2011 (UTC)
- Week support: "==Break2=={{nonindex}}" could be used too.. as well as the normal breaks. Weighing it with the possible litter we can get yet the usefulness of such edit-point. --lTopGunl (talk) 23:47, 13 December 2011 (UTC)
End of EDITPOINT thread
To add a Support/Oppose note, edit this section and place text above the header "End of EDITPOINT" so that new text will be listed in the Support/Oppose section. -Wikid77 14:03, 6 December 2011 (UTC)
Proposal for minimising the number of relisted AfDs
The Articles for deletion process currently operates as follows:
Deletion discussions |
---|
|
Articles |
Templates and modules |
Files |
Categories |
Redirects |
Miscellany |
Speedy deletion |
Proposed deletion |
In some cases, this process is unsatisfactory. If no meaningful contributions are made to a discussion on its first day, it is likely not to be visited by contributors until the eighth (closing) day. Many people will only click on today or closing, and not seek out any of the intermediate days. So some AfD's disappear, undiscussed, into limbo for a week, during which time nothing happens - the AfD is effectively inactive.
So, I propose the creation of an AfD holding pen for new discussions. The following process will then take place:
- A discussion is opened in the AfD holding pen (or whatever we want to call it). This pen can be accessed through the Deletion discussions box - technically, it will be just the same as a daily deletion log, but won't be limited to one day's AfDs only.
- It stays in the pen (potentially for several days) until the discussion has properly begun, i.e. someone has contributed who is not the deletion proposer or the page's creator. It is then moved to that day's deletion log.
- The AfD then follows the current procedure until closing day. Perhaps the length of discussion time can be reduced to less than a week.
This will reduce the number of AfDs that are relisted by ensuring that all undiscussed AfDs are still easily accessible via the Deletion discussions box.
I don't think that the holding pen would get overloaded, because things should be moved out of it fairly quickly. We may want to consider a maximum holding time before an Admin can retire the AfD as unresolved, though I suspect that this would not be reached often. Bazonka (talk) 22:33, 5 December 2011 (UTC)
- An interesting idea, but is there really a problem with the current system? It only takes a few seconds to relist a debate and most articles up for AfD aren't of the "urgent that this be deleted" variety. --Philosopher Let us reason together. 04:31, 6 December 2011 (UTC)
- The problem is not with the few seconds to relist, but the fact that it can take a week to get there, during which time it is likely that nothing will happen because the discussion isn't readily accessible. I do take your point about urgency though; perhaps it's just me that gets frustrated by these unnecessary delays. Bazonka (talk) 07:51, 6 December 2011 (UTC)
- I disagree that the debate isn't readily accessible. CAT:AFD, for example, is a great way to view all the active debates in a particular topic area - or in all areas, if you have time to kill. To be honest, I doubt I've ever used the discussions template posted here. UltraExactZZ Said ~ Did 20:28, 6 December 2011 (UTC)
- That is indeed useful, if you know it exists. I didn't, and I bet plenty of other people don't either, because there is no simple route to it from WP:AFD. Perhaps this should be made more prominent. Bazonka (talk) 20:49, 6 December 2011 (UTC)
- You could also promote Article Alerts that sorts deletion discussions by topic. </shameless plug> — HELLKNOWZ ▎TALK 10:14, 7 December 2011 (UTC)
- As you can see, I have added some all options to the Deletion discussions template. This should help people to more easily find discussions that aren't on their first or last day. This does not necessarily mean that discussions won't remain undiscussed though, but it might reduce the number a bit. Bazonka (talk) 20:51, 8 December 2011 (UTC)
- Someone has been reverting my edits to the "Deletion discussions" template claiming that it is "completely unusable", which I dispute. Some other opinions at Template talk:Deletion debates would be appreciated. Thanks. Bazonka (talk) 07:20, 14 December 2011 (UTC)
- As you can see, I have added some all options to the Deletion discussions template. This should help people to more easily find discussions that aren't on their first or last day. This does not necessarily mean that discussions won't remain undiscussed though, but it might reduce the number a bit. Bazonka (talk) 20:51, 8 December 2011 (UTC)
- You could also promote Article Alerts that sorts deletion discussions by topic. </shameless plug> — HELLKNOWZ ▎TALK 10:14, 7 December 2011 (UTC)
- That is indeed useful, if you know it exists. I didn't, and I bet plenty of other people don't either, because there is no simple route to it from WP:AFD. Perhaps this should be made more prominent. Bazonka (talk) 20:49, 6 December 2011 (UTC)
- I disagree that the debate isn't readily accessible. CAT:AFD, for example, is a great way to view all the active debates in a particular topic area - or in all areas, if you have time to kill. To be honest, I doubt I've ever used the discussions template posted here. UltraExactZZ Said ~ Did 20:28, 6 December 2011 (UTC)
- The problem is not with the few seconds to relist, but the fact that it can take a week to get there, during which time it is likely that nothing will happen because the discussion isn't readily accessible. I do take your point about urgency though; perhaps it's just me that gets frustrated by these unnecessary delays. Bazonka (talk) 07:51, 6 December 2011 (UTC)
IP Editors
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.
I'm all for IPs being able to edit. However, with ClueBot being down there is a growing amount of vandalism and it is gettiing hard to control. I would like to sugest a tempoary suspesion of IP editing rights until ClueBot is fixed. I sugest this because the majoraty of vandalism I see is by IPs. Oddbodz (talk) 19:54, 6 December 2011 (UTC)
- Support Unfortunate but true. Can't say much else due to unclean feelings of IPism and guilt. I'd prefer to feel bad than watch WP get trashed. fredgandt 20:07, 6 December 2011 (UTC)
- Strong Oppose - ClueBot did not rule Wikipedia and its absence should not affect the spirit of openness that we should have. Sure, vandalism is a problem, but it is not insurmountable. We must not let the vandals spoil Wikipedia for the vast numbers of well meaning IPs. See WP:HUMAN. Bazonka (talk) 20:20, 6 December 2011 (UTC)
- There's nothing to debate here. It's not even a consensus issue -- the foundation wants IP editors to be allowed to edit. I normally hate killing discussions with archive boxes, but in this case it's probably a good idea. ♫ Melodia Chaconne ♫ (talk) 21:05, 6 December 2011 (UTC)
- Strong oppose How is that going to stop vandalism? Vandals will simply take the extra minute to get an account. On the down side, Wikipedia will loose good content contributers. Over 60% of IP edits are good edits. Alpha_Quadrant (talk) 21:10, 6 December 2011 (UTC)
- Strong Oppose for the above reasons and for the fact if we go this far whats to stop peopel requesting ip ranges being blocked in the future, requesting isps be block or countries???. i have edited under ip before just because it was easier to makea quick edit that log in just fora something minor i wouldnt liek to think i need to worry about logging in evr time--Andrewcrawford (talk - contrib) 21:23, 6 December 2011 (UTC)
- My personal feeling is that most vandalism is opportunism or accident. I think very few acts are thought through. Obviously some are, but that's not really what ClueBot ever dealt with. The tens of thousands of little '''boldtext''' that get dumped and left because the editor was not really sure what they were doing or were just bored are where ClueBot ruled. I am fully on the side of free editing, but 60% isn't a massive majority. Another way to view that figure is that 40% are vandals (or at least not helpful). As a temporary measure to at least calm the flow of rampant destruction (if people realise the opportunity exists for their work to be shown off for longer) by the deliberate IP vandals, it would not be truly a bad idea. Once ClueBot is back, then so could be the IP editors. I know we are all supposed to strongly oppose because the IPs are wonderful, but if you've ever watched WP:AIV, you'll know damn well that IPs far out-way logged users in the vandalism league and it takes a constant and concerted effort by many people to just keep up. fredgandt 21:29, 6 December 2011 (UTC)
- Oppose per Wikipedia:Five pillars, Meta:Founding principles, Wikipedia:Perennial proposals#Prohibit anonymous users from editing. Absolutely no chance that this proposal would be accepted, even as a temporary measure. Chzz ► 09:46, 7 December 2011 (UTC)
Does it just have to be ClueBot who fixes vandalism? I am sure that many acts of vandalism on Wikipedia get corrected by users who are not bots. ACEOREVIVED (talk) 10:59, 7 December 2011 (UTC)
- I actually noticed during some recent huggling that a number of IPs were reverting vandalism (manually). In fact, I'm pretty sure that one IP was following the huggle feed in the IRC, because I ran into him or her reverting stuff about 20 times in two hours. Sven Manguard Wha? 16:47, 8 December 2011 (UTC)
- Past research has indicated that for every IP-based act of vandalism, there are three or four well-intentioned edits by unregistered users. It's not at all uncommon to see unregistered editors fixing vandalism. WhatamIdoing (talk) 23:37, 12 December 2011 (UTC)
This discussion appears that it should be totally closed now, as it appears that ClueBot is again active - look at the history of the article Higgs boson, and if you click on the article's history, you will see that an act of vandalism was corrected by ClueBot today (December 15 2011). ACEOREVIVED (talk) 16:09, 15 December 2011 (UTC)
- I would like to see the data regarding IP users, where can I find the analyses? WP:HUMAN has a graph from 2007 (4+ years ago — donkey's years for a website). Thanks --Squidonius (talk) 19:21, 15 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)
- 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)
- 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)
- 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[citation needed] 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)
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♫TCN 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)
- 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 wordsdeeds 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)
- 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
- 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)
Namespace and watchlist
There should be an option to not watchlist by default pages in a certain namespace. For example, I have enabled watchlisting by default as it is very convenient, but I try to keep my watchlist below 600-700 pages at any given time. It's fairly tedious to do, because everytime I edit a WT:AFC page, block a user, or leave a message to a user talk page, the page is watchlisted. I would like a feature that enables automatic watchlisting only for specific namespaces. This also addresses the above proposal on separating pages from their talk pages (e.g. WT from WP, etc). Any support for this? — Preceding unsigned comment added by CharlieEchoTango (talk • contribs) 06:22, 8 December 2011 (UTC)
- Oppose due to this being potentially a pain in the rear end. I can imagine too many occasions when I would have to override the exclusion of a particular namespace manually. This proposed feature would actually more than likely cause the very issues being cited as reasons to oppose the above proposal to be able to un-watch talk and other pages etc. etc. In particular the potential to forget to watch and to think that you are when you're not seems rather strong. With the other proposal, the normal behaviour (we have now) would have to be manually undone on a per page basis, meaning the likelihood of forgetting is significantly reduced (to basically zero). Simply speaking: I wouldn't want to automatically not watch all (for example) talk pages, since more often than not I want to watch both the talk and main (just occasionally not both). Blanket exclusion of a particular namespace from being auto watched is too harsh for my liking. fredgandt 09:16, 8 December 2011 (UTC)
- Support. Anything that helps customization of autowatch would be useful. I wouldn't expect most users to use it, but I don't think it would hurt. I think a prototype of this could potentially be implemented in pure Javascript, and then anyone who wants to try it out can just include it. Dcoetzee 09:54, 8 December 2011 (UTC)
- Support as an opt in with the suggestion that it be made a "gadgets" feature - I wouldn't use this, but I understand how it could be useful. If it isn't possible to do opt-in, the simple alliterative would be to have autowatchlisitng on for all namespaces or for none of them, creating results identical to the two options we have now. Sven Manguard Wha? 10:43, 8 December 2011 (UTC)
- Comment: I would certainly think that an admin who blocks a user should, for at least a reasonable time, have that user's talk page in his watch list. I would also expect this if you leave a message. Communication is two-way. If you initiate it, you have the obligation to be reasonably attentive to replies. --Stephan Schulz (talk) 11:59, 8 December 2011 (UTC)
- Note that for some users like myself, I currently have autowatch disabled (because I make minor changes to many articles) but would be more likely to enable it for the User talk namespace, for precisely that reason. So your argument seems to actually favor the proposal. Dcoetzee 13:12, 8 December 2011 (UTC)
- Yes, this is a two-headed snake, which is why I put it in as a comment, not a !vote. --Stephan Schulz (talk) 15:02, 8 December 2011 (UTC)
- Well, my message wasn't very well worded, heck, wasn't even signed, of course I keep the page on my watchlist when I leave an open-ended message, what I'm referring to is mostly related to script sent messages on user talk pages; e.g. welcomes, "Your submission at AfC was created", user warnings, CSD notices, etc. No point in watching most of the time and it grows very quickly to an unmanageable (for me) watchlist. I get your point on communications, but I also see no point in keeping hundreds of declined AfCs or various WP pages (like this one). Removing them manually every other week is tedious. Regards, CharlieEchoTango (contact) 15:38, 8 December 2011 (UTC)
- I suspect this will get lost, but it reminds me of a feature I would like, the ability to watchlist a page, with the watchlist expiring after a month or so. Perfect for this situation and many others--SPhilbrickT 15:58, 14 December 2011 (UTC)
- Note that for some users like myself, I currently have autowatch disabled (because I make minor changes to many articles) but would be more likely to enable it for the User talk namespace, for precisely that reason. So your argument seems to actually favor the proposal. Dcoetzee 13:12, 8 December 2011 (UTC)
- Yes please! -- John of Reading (talk) 16:02, 14 December 2011 (UTC)
- Yes, that's something I also would like to see. Toshio Yamaguchi (talk) 16:18, 14 December 2011 (UTC)
- A biodegradable watch of a page? So after n time it auto un-watches? Yep, I'd go for that. As long as it was something that could be selected on a per page basis and was not default behaviour. Perhaps this should be separately proposed. fredgandt 18:07, 14 December 2011 (UTC)
- Opppose You could do this with a simple user script. And I echo Stephan Schulz's comment above. Anomie⚔ 12:05, 8 December 2011 (UTC)
- Which script? CharlieEchoTango (contact) 15:38, 8 December 2011 (UTC)
if (wgAction == "edit" && [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 100, 101, 108, 109].indexOf(wgNamespaceNumber) != -1) {
document.getElementById('wpWatchthis').checked = true;
}
- Customize the numbers in the list as needed; namespace numbers in the list will be auto-watched if you add this to your user JavaScript page. For a namespace-number-to-English guide, see Wikipedia:Namespace#Programming. Numbers -2 and -1 need not be added as you probably won't be editing in those namespaces. {{Nihiltres|talk|edits|⚡}} 16:00, 8 December 2011 (UTC)
- Well this would certainly solve my problem, thanks! I added it to my User:CharlieEchoTango/common.js, but it doesn't seem to work. Purged the cache, logged out logged in, tested on two namespaces. :/ CharlieEchoTango (contact) 16:14, 8 December 2011 (UTC)
- Nevermind, I had to disable automatic watchlisting first. Silly me. Thanks a lot, Nihiltres. :-) CharlieEchoTango (contact) 16:20, 8 December 2011 (UTC)
- It seems to watchlist the associated talk namespace regardless of the script (e.g. if I choose to watch ns4, ns5 is included with it even if left out in the script). Not a big deal, though. CharlieEchoTango (contact) 16:33, 8 December 2011 (UTC)
- That's inherent to the watchlist feature. If you watch a page, you also necessarily watch the associated talk page or content page. My script merely chooses which namespaces will have auto-watch enabled: it might make sense to auto-watchlist page pairs when you edit a talk page, but not when you just edit content. {{Nihiltres|talk|edits|⚡}} 16:50, 8 December 2011 (UTC)
- Support as an option that should probably be available by default, but I'll otherwise make my above 30-second script into a more user-friendly Gadget as soon as Gadget preferences are available (hopefully, an upcoming feature). {{Nihiltres|talk|edits|⚡}} 16:10, 8 December 2011 (UTC)
- Support with comment - I don't see that this would be a bad thing as long as its opt in and not required. I think that there is a lot of room for improvement in the way Wikipedia handles Watchlists and any functionality that allows users some flexibility in it is helpful. --Kumioko (talk) 16:14, 8 December 2011 (UTC)
- Oppose I do not see the need for such a feature. When the 'Add pages I edit to my watchlist' feature is enabled, you can just uncheck the 'Watch this page' checkbox above the 'Save page', 'Show preview' and 'Show changes' buttons. Toshio Yamaguchi (talk) 17:43, 10 December 2011 (UTC)
- Support I also agree with an opt in comment, as not every user (including myself) are user script literate. Only a few are, and I agree that so many articles I tagged for deletions, users I warned and so forth gets automatically watchlisted and removing it can be a pain. Secret account 06:29, 13 December 2011 (UTC)
- This proposal would offer you the opportunity to not watch any talk pages or all; any articles or all. Are you really sure that will be helpful? fredgandt 06:59, 13 December 2011 (UTC)
- Comment Some people here might find user:js/watchlist useful. It's fairly easy to install and to use in my opinion (see instructions on that page)
. I have it installed, since I also have "Add pages I edit to my watchlist" enabled (hell I would miss a whole lot of stuff if I hadn't) and it makes killing unwanted pages popping up on your watchlist mostly painless. Toshio Yamaguchi (talk) 22:58, 14 December 2011 (UTC)
- Support Per Sven Manguard. Rcsprinter (state the obvious (or not)) 20:36, 16 December 2011 (UTC)
Creation of new namespace for automatically substituted templates
Proposal to create a new namespace. Suggest TemplateS:
- Any template created in this namespace would automatically substitute when saved.
- If
subst:
orsafesubst:
is added it should be ignored (as wherever used it will always subst). - The preview display should be as is presently the case with e.g.
{{subst:Example}}
If used in another template, the syntax should be e.g.{{{Example}}}
instead of{{{{{|safesubst:}}}Example}}
Although if safesubsted, thesafesubst:
should be ignored.
- If a TemplateS is included within another template (either in the Template or TemplateS namespace) it should sit and wait to be transcluded before substing.
In simple terms, a template namespace allowing the creation of templates that should always be substituted, without the need for the use of subst:
This would cut down on accidentally not substituted templates where they should have been. It would cut down on unnecessary transclusion. It would save a lot of explanation and confusion. Any present templates that should always be substituted (e.g. {{subst:Uw-vandalism1}} etc.) could be moved to the new namespace and continue to function just the same way but with automatic clean-up of errors. Etc. etc.
However patronizing this is going to sound: Please keep the comments free from hyperbole (this would be the worst thing ever!), presumption (this would be too difficult to implement), and negativity (this is a shit idea). This may not be 42, and I'm quite sure there are lots of technical issues involved. If you think the idea is shit, explain how it can be improved. Most importantly, where there's a will there's a way. fredgandt 20:48, 9 December 2011 (UTC)
- How about introducing a new magic word, e.g.
__AUTOSUBST__
instead? When a template containing this magic word is used, it will be automatically substituted. Also, triple-braces are used for template parameters. Another syntax will have to be used. Perhaps anosubst:
prefix. - ctzmsc3|talk 21:17, 9 December 2011 (UTC)
- I have to say this: This would require a major rewrite in core, so perhaps it is best to submit a feature request at Bugzilla first to see if there is any support in doing so. This is standard advice for proposals requiring a major rewrite. A note about why this will not work: template space is technically no different from any other namespace. The parser will transclude or substitute anything you can throw at it. I myself would love to see parser functions not being substituted at all, but that also requires a rewrite. — Edokter (talk) — 21:19, 9 December 2011 (UTC)
- My thinking was that, for example, to transclude Wikipedia:Example we use {{Wikipedia:Example}} but to transclude Template:Example we just use {{Example}}. My thought is thus, that since certain page names in certain namespaces are assumed by the tranclusive process, to be the source of templates, a new namespace could (when assumed).........
- I have just found an enormous hole in my plan.
- How would the software know...?
- Hole fixed. As long as there were no Template: and TemplateS: templates with the same name, all is well.
- .......parse the result of the transclusion as if substituted.
- Simply put: If {{Example}} works (it doesn't transclude User:Example or Example or Wikipedia:Example) then we use that part of the system to add the new namespace and providing there are no templates in both template namespaces with the same name, each would behave uniquely.
- You (Edokter) and I will it seems forever disagree about substituting parser functions. I believe that once they have done their job, they should be substed. The only time I see a use for an unsubsted parser function or magic word is when the refreshed page should return a new value. Example (not parser but...) substing {{REVISIONUSER}} is always correct unless you specifically want the page to show the last editor every time it's loaded. Or a parser function {{#ifeq:A|A|Yes|No}} is written in stone. It will never tell you anything else. Not substituting it is a waste of resources with no justification. Obviously that is a long a complex converstion with many what if's.
- I actually didn't know we could go direct to Bugzilla to make feature requests. For the immediate future, I'd like to see where this leads. I rather like the idea of a magic word to use in the template (suggested above). fredgandt 21:54, 9 December 2011 (UTC)
- Although I have had second thoughts (see below) fredgandt 00:48, 10 December 2011 (UTC)
- My thinking was that, for example, to transclude Wikipedia:Example we use {{Wikipedia:Example}} but to transclude Template:Example we just use {{Example}}. My thought is thus, that since certain page names in certain namespaces are assumed by the tranclusive process, to be the source of templates, a new namespace could (when assumed).........
- Like the new magic word idea (I'm assuming that would take a lot less of a rewrite in the wikimedia code?)Crazynas t 23:35, 9 December 2011 (UTC)
- Although the magic word idea does seem simple, I have my doubts.
- The creation of a custom namespace is very simple. See mw:Manual:Using_custom_namespaces#Why_you_would_want_a_custom_namespace (zooms in on section highlighting exactly what this proposed namespace would be for).
- The new namespace would be in almost all ways an exact copy (in function) of the Template: namespace (so easy to create the basics).
- Here's where the magic word idea gets complex when considered against the new namespace.
- A new magic word would need to be recognised throughout Wikipedia, by all scripts that might encounter it. This could mean (not 100% sure) a great deal of interweaving and rewriting. Like trying to play Pick-up sticks in reverse; not only when correctly used but also when incorrectly used. Without each and every script knowing what to do with the magic word if it finds it, we could end up with a great many spanners in the works.
- The proposed new namespace would be a stand-alone development area where the few tweaks required could be carried out, without disturbing anything else.
- The tweaks would be where the technicalities are not fully known to me, but I can hazard an educated guess that not much more would be required than an instruction to add "subst:" to the raw text of any template transcluded from the TemplateS: namespace (unless already there etc. etc.).
- These tweaks could amount to little more than a series of ifs and else ifs. fredgandt 00:48, 10 December 2011 (UTC)
- The main problem with a magic word is irreversibility. A vandalised or accidentally __AUTOSUBST__'d
{{Convert}}
woudl be a nightmare. - The name-pace idea is cute, though. Rich Farmbrough, 19:11, 10 December 2011 (UTC).
- If it's implemented correctly, then __AUTOSUBST__ vandalism shouldn't be a big problem. As I understand it, adding __AUTOSUBST__ to a template and clicking "Save" wouldn't automatically subst every existing transclusion of the template. It would only cause subsequent transclusions to be substed. In other words, only when someone adds the template to a page and clicks "Save" would the template get substed. Most high-use templates are protected anyway, so it's unlikely that even a clever vandal would be able to do too much damage.
- The main problem with a magic word is irreversibility. A vandalised or accidentally __AUTOSUBST__'d
- I like this proposal, but it will require thinking like this to ensure that more problems aren't introduced. The current solution to this problem is to add {{substituted|auto=yes}} to the template so that it gets added to Category:Wikipedia templates to be automatically substituted and a bot will go around and fix non-substed transclusions. —SW— yak 20:20, 12 December 2011 (UTC)
- That's ({{substituted|auto=yes}}) good to know. Thanks
I still think a new namespace is simplest all round. fredgandt 20:32, 12 December 2011 (UTC)
- That's ({{substituted|auto=yes}}) good to know. Thanks
- I like this proposal, but it will require thinking like this to ensure that more problems aren't introduced. The current solution to this problem is to add {{substituted|auto=yes}} to the template so that it gets added to Category:Wikipedia templates to be automatically substituted and a bot will go around and fix non-substed transclusions. —SW— yak 20:20, 12 December 2011 (UTC)
What if Governments Sponsored Wikipedia In Exchange For Transferring Their Knowledge Bases Into the Public Domain
UNESCO's Open Access to Knowledge and Information could not ask for a better platform than Wikipedia.
What if government committed to these ideals incrementally shifted their tax-funded knowledge resources to Wikipedia? This would pose a considerable increase editing burden on Wikipedia, but would also dramatically increase the quality of the information resources, shifting to a true "real-time" encyclopedia.
I am trying to include this in a proposal for healthcare reform in Ontario, as it pertains to certain policies/procedures in our province's healthcare system that are often poorly understood/obscured. I would like to train/encourage my colleagues to participate in Wikipedia Medicine project and the other initiatives relevant to human health.
Ideas/Feedback? Always appreciated. Laith Bustani (talk) 14:25, 10 December 2011 (UTC)
- How would we cover events that are politically controversial? Wikipedia doesn't have ads to avoid any appearance of bias, this would be worse. -- Eraserhead1 <talk> 15:24, 10 December 2011 (UTC)
- Response: Hi Eraserhead1. Thanks for your feedback. I think the governments would have to subject themselves to the editorial policies of Wikipedia or risk deletion of their content, just like anyone else. That is the beauty of the concept, governments would be accountable to a universal, democratic/systematic means of validating their communications. Laith Bustani (talk) 16:01, 10 December 2011 (UTC)
- My current policy focus is healthcare, which is unique because everyone is affected by it, and my colleagues and I are actively looking at ways to improve engagement and transparency in the data analysis that leads to new recommendations for healthy living in its broadest sense.Laith Bustani (talk) 16:05, 10 December 2011 (UTC)
- Government programs are often politically charged, I don't see how we could have large scale contribution from government without a large dose of political bias coming with it, based on what ever party happens to be in charge at the time. Governments are not immune from having conflicts of interest either. Monty845 17:39, 10 December 2011 (UTC)
- Oppose - there's no way we could remain neutral if we did this. Sven Manguard Wha? 19:30, 10 December 2011 (UTC)
- Comment - confused here. All U.S. government produced material is PD and all country articles were expanded or started by importing the CIA Factbook. All U.S. city articles were created or expanded by importing U.S. census data. Thousands of articles are illustrated by images from the U.S. military, the U.S. National Archives, the German archive[4], Queensland Library and many other government libraries and archives. But I don't see how having governments directly involved would make us more an encyclopedia or more "real-time". You certainly don't expect that the U.S. government would edit the 2011 NATO attack in Pakistan until after their investigation is completed? Or that U.S. and Pakistan government would cooperate to build a neutral article on the death of bin Laden while Pakistani jets were still flying combat patrol. (Or choose your favorite 'friendly' pair -- Israel/Gaza, Georgia/Russia, whatever) Rmhermen (talk) 20:06, 10 December 2011 (UTC)
- Comment- Thanks Monty845, Sven Manguard, and Rmhermen for your points. The same "difficulties" "biases", etc. exist in the way that information is currently handled. The scary thing is that that we pretend these problems don't exist and at least with regards to health policy, we end up with a muddled web of recommendations that are often contradicting/confusing and biased. The strength of wikipedia is not the software, but the community. I can replicate a "wiki" for all sorts of things, but without the human editors to maintain integrity of the knowledge, it is a waste of time. I guess what I am saying is this: I am committed to trying to adopt the democratic editing principles behind Wikipedia to public health policy and even (this would require some tweaking on the privacy side of things) electronic medical records. What I need to know is the best way to "integrate" this effort with Wikipedia's existing treasure trove of knowledge. If there was a "win-win" way of doing this without replicating the wikipedia infrastructure/community, that would be amazing and go a long way of convincing the government that this is a good idea. Laith Bustani (talk) 22:50, 10 December 2011 (UTC)
- Even restricted to the matter of health, individual governments give conflicting recommendations. The U.S. and EU differ whether several compounds are generally safe for human consumption, the U.S. withdrawal of RotaShield was not appreciated in Africa, the continued use of DDT in Africa is not appreciated by some Americans, etc. I am not seeing how this relates to Wikipedia the encyclopedia. Rmhermen (talk) 23:14, 11 December 2011 (UTC)
- Comment: Rmhermen, the problems you (and others) point out here are actually opportunities. The problem with the world health organization and other governmental regulatory agencies is 1) lack of resources (mainly human) 2) lack of a prospectively agreed-upon, teachable system for resolving conflicting/contradictory recommendations. As a physician, I have to process conflicting recommendations all the time. When I recognize that recommendations are opinions, and trust the opinion of the person who I am trying to help above those of "experts", then amazing things happen. Yes, I have to be conscious of laws, regulations, my personal abilities/limits, etc. This is the "art" of medicine. What I see the wikipedia community/platform as making possible is a "transparent" debate/discussion of universal health issues/treatment recommendations that will take them from being improperly applied/generalized to highly customized/refined through broad-based, and ongoing editing. It pushes the concept of "real-time" historical record, but because of the diversity of its community, and it's Wikipedia:Five_pillars its it has perhaps more integrity than any governed body I know. I have no delusions that this is a "perfect fit", or that there are not real "problems", but I would not be surprised if Wikipedia's founders were challenged with the same logistical impossibilities when they originally came up with the idea.Laith Bustani (talk) 16:55, 12 December 2011 (UTC)
- As a former public health worker myself, I fear your naivete has led you astray. We already have a massive problem gathering sufficient administrators and editors to edit the existing 3.8 million articles in the English-language Wikipedia alone. There is no way on Earth we could assemble the additional volunteers to maintain even the flawed level of accuracy and integrity which the existing Wikipedia articles display, for all the additional subject matter you are proposing to dump into our laps. --Orange Mike | Talk 17:02, 12 December 2011 (UTC)
- Response: Orangemike, I freely admit to my Naïveté in this regard. Do we have statistics on the number of editors and the contributions they make to Wikipedia's integrity (last I heard, studies cited 96% accuracy, surpassing Encyclopedia Britannica). What is the processing cue like? OK, now, what if in exchange for governments agreeing upon wikipedia as a "good-enough to start" place to start embracing UNESCO's principles, how difficult do you think it would be to teach the skills required to 1) write higher quality articles 2) learn the editing tasks essential to maintaining Wikipedia's integrity? You see, if you are telling me that even on Wikipedia, there is way more work to do than people to do it, what hope in hell do I or any other government have in setting up a separate "walled garden" to replicate the process. I see this as a potential area to develop win-win relationships with small groups that are ready for this type of experimentation. I am holding up my hand and saying "pick-me, pick-me" as a test case for the application in healthcare policy. With respect to health care conditions/treamtent, though I have signed up for the Wikipedia medicine project, I do not routinely reference Wikipedia in the treatment of my patients and stick with more traditional information sources (journals, UpToDate, etc, colleagues). That being said, I have been amazed at the quality of some of the content and think that if I could get more of my (smarter, less naive) peers to participate, then we might go a long way to capturing/cleaning up the knowledge/experience that is wasted every time a treatment is initiated for an individual and the results of the treatment lost. Laith Bustani (talk) 22:41, 12 December 2011 (UTC)
- That material could never be used in Wikipedia - unless you first get it published in a reliable peer-reviewed journal (preferably it get collated into a review article) and we decide it is a necessary addition to a encyclopedia-type article. No original research is a basic rule. Rmhermen (talk) 23:04, 12 December 2011 (UTC)
- I'm not really certain what it is you're trying to achieve. To have accurate information about public health on the English Wikipedia? Great, you can get started by fixing these thousands of problems. To have health policy makers use the English Wikipedia to communicate with each other and to decide what their next policy will be? No, thanks: that's not an encyclopedia's job. We'll report what they've decided after they have WP:Published their decisions. Being involved in interpreting raw data and making these decisions would be a violation of the WP:No original research policy. WhatamIdoing (talk) 23:49, 12 December 2011 (UTC)
Bot to maintain and auto update a list
I would like to get consensus for the following bot task:
Automatically update Sony Corporation shareholders and subsidiaries#Shareholders with information from http://www.sony.net/SonyInfo/IR/stock/information.html where it says Principal Shareholders. That is, the shareholder rang, name and percentage should be checked by the bot against the information present on the website and automatically updated, when there is a discrepancy between the two pages. Toshio Yamaguchi (talk) 17:16, 10 December 2011 (UTC)
- confused why this is here and not on the Bot request page.Crazynas t 00:34, 11 December 2011 (UTC)
- I am not a bot programmer. I want to reach a consensus here and then file a request at WP:BOTREQ. I thought such a task should have a consensus before being requested. Toshio Yamaguchi (talk) 00:56, 11 December 2011 (UTC)
- You can still post your request at WP:BOTREQ. I will do it as a courtesy. PaoloNapolitano 10:56, 11 December 2011 (UTC)
- Botreq would likely ask for consensus. Funnily enough I have been thinking about this sort of thing. The development cost for a single section of a single page is fairly high, but a generic solution (also called AI) is attractive. Rich Farmbrough, 21:19, 11 December 2011 (UTC).
- Botreq would likely ask for consensus. Funnily enough I have been thinking about this sort of thing. The development cost for a single section of a single page is fairly high, but a generic solution (also called AI) is attractive. Rich Farmbrough, 21:19, 11 December 2011 (UTC).
- You can still post your request at WP:BOTREQ. I will do it as a courtesy. PaoloNapolitano 10:56, 11 December 2011 (UTC)
- I am not a bot programmer. I want to reach a consensus here and then file a request at WP:BOTREQ. I thought such a task should have a consensus before being requested. Toshio Yamaguchi (talk) 00:56, 11 December 2011 (UTC)
Straw Poll on Jimbo's talk page
Jimbo is looking for input regarding the passage of SOPA and how it will effect Wikipedia.here. Crazynas t 22:55, 10 December 2011 (UTC)
- Wikipedia:SOPA initiative in the unlikely event that we get to that point, some advance planning would be good. Crazynas t 10:31, 13 December 2011 (UTC)
The catastrophically failing merge process
- Please visit this discussion on Wikipedia talk:Merging to comment. Protonk (talk) 00:53, 14 December 2011 (UTC)
Move AfD to Afd
To get some highly needed outside input on this issue, please see Wikipedia_talk:Articles_for_deletion#Bold.2C_revert.2C_discuss where I argue that AfD should be Afd. Debresser (talk) 14:40, 11 December 2011 (UTC)
- Oh, my. I thought it was another round of Wikipedia:Perennial proposals#Rename_AFD, but this is actually a discussion on the capitalization of the initialism, i.e., whether the page should refer to itself as "AfD" or "Afd". Don't we have anything better to do with our time these days? WhatamIdoing (talk) 00:07, 13 December 2011 (UTC)
New Donation Idea
Hey Ya'll - I am going to copy and paste this e-mail i've sent to three wikipedia admins/contacts. I got shot down by all three, the last one gave me this link.
See here, and if you do this -- more donations will come. Thanks.
Howdy,
I know you probably get a bunch of e-mails all day every day. But I think I have a good idea. Other public non profit organizations use this idea, and i suggest wikipedia use it too. I didn't know who to contact, so I ended up here, although i'm in South Carolina. My suggestion (ready?)... have an online gift thing that you can give to wikipedia in OTHER PEOPLES NAMES and wikipedia e-mails the person you're gifting, confirming the amount you gave IN THEIR NAME, FOR THEM, instead of getting them a stupid little gift...
Do you hear me? This is much better than getting someone a crappy dollar store gift, this is me donating to wikipedia and pawning it off as a gift ;)
They will like it, I would love it (showing off my support....) and less crap is given (they're just going to throw away my gift, or re-gift)
Please let me know how you feel about this idea. If you don't like it, I would still appreciate a response.
Thanks, Greg — Preceding unsigned comment added by 68.209.77.205 (talk)
- Seems like a perfectly reasonable idea to me. Psychological trickery that would probably work. fredgandt 21:14, 11 December 2011 (UTC)
- Who would want to receive a gift like this? Whilst Wikipedia is wonderful, I reckon most people would prefer a gift donation to be made to a charity that saves lives (or puppies or whatever they're into). Presents have to be meaningful, and unless the recipient is already a keen Wikipedian, then I think the gift would be a bit misplaced. Bazonka (talk) 21:19, 11 December 2011 (UTC)
- Assuming by your indent that you are talking to me; It strikes me this would work in the same way you can buy people a square foot of moon or a Scottish Lordship. Not all gifts have to be meaningful or serious. Apart from anything, it is whether this would encourage giving that matters. I think it probably would, since people like to give things they might not have thought to buy for themselves. fredgandt 21:26, 11 December 2011 (UTC)
- Who would want to receive a gift like this? Whilst Wikipedia is wonderful, I reckon most people would prefer a gift donation to be made to a charity that saves lives (or puppies or whatever they're into). Presents have to be meaningful, and unless the recipient is already a keen Wikipedian, then I think the gift would be a bit misplaced. Bazonka (talk) 21:19, 11 December 2011 (UTC)
- You need to talk to User:Meganhernandez, who is in charge of the 2011 fundraising campaign. I'll let her know about your question. WhatamIdoing (talk) 00:10, 13 December 2011 (UTC)
Scroll to section after cancelling edit
When cancelling an edit on a section (more often than not after finding the code you were interested in or looking at a preview of something), the page we are returned to is top of page, with no hashed section title.
I'd like to be auto scrolled to the section I didn't edit, in the same way we are scrolled to the section if we did edit. fredgandt 21:20, 11 December 2011 (UTC)
- Is it not simpler to click your browser's Back button? — This, that, and the other (talk) 10:11, 12 December 2011 (UTC)
- Simpler for whom? Certainly simpler for WMF but no so simple for however many millions of users per day. I see the current behaviour as being contrary to expected behaviour. fredgandt 11:34, 12 December 2011 (UTC)
- Hmmm. I have never used the Cancel link. Looks like all it does is reload the page without linking to the section. I always used browser back or backspace. ---— Gadget850 (Ed) talk 11:56, 12 December 2011 (UTC)
- Simpler for whom? Certainly simpler for WMF but no so simple for however many millions of users per day. I see the current behaviour as being contrary to expected behaviour. fredgandt 11:34, 12 December 2011 (UTC)
- I always use the back button for this reason. It should not be hard to add a section to the link. However, a bigger peeve of mine is that the Cancel link should be a button. — Edokter (talk) — 17:27, 12 December 2011 (UTC)
- I see the individual MediaWiki messages, but where is the edit summary and related built? Directly through the software or in an interface page? -— Gadget850 (Ed) talk 18:00, 12 December 2011 (UTC)
- Totally agreed Edokter. Not being a button is also contrary to expectation. The addition of the section title to the URL would be a doddle for WMF. The question is, whether anyone feels it should be requested. So far, it seems people don't even use it. fredgandt 18:11, 12 December 2011 (UTC)
Compos Mentis - proposal
From [[5]]
Dear readers of this Talk:Non compos mentis. I am having troubles with Compos Mentis, as it is not mentioned in the English Wikipedia. I would like to refer to Compos mentis from my article about a new word called: Mentification. So I would like to change the subject of the page to Compos mentis and explain about it, and after having done that, in the same page I will let it be followed by the original explaination about Non compos mentis. To mention Compos mentis first is for reason that Compos mentis is more essential compared to Non compos mentis. I will leave all explanations as well as all references intact concerning the original term Non compos mentis. For your information: the term Compos mentis in my language (Dutch) has the same basic meaning in legal terms as in English, although the approach is in Dutch more from the neutral side, as Non compos mentis holds implicitely a judgement about the status of the mind and therefore the term: Non compos mentis seems like a prejudgement. A comparable situation would be with the term: Billable hours (at work) as there are also Non billable hours that would not directly lead to a specification on the clients bill. So to explain Non billable hours, one would explain billable hours as well, and first. My question to you: Would the proposed change above be all right with you? I will just wait for a couple of days. If I hear nothing, then I will make the change with all related consequent changes. Else we can discuss the subject further. Bouwhuise (talk) 23:16, 11 December 2011 (UTC)
Bouwhuise (talk) 07:56, 12 December 2011 (UTC)
- List_of_legal_Latin_terms#C has "Compos Mentis" listed. FYI. fredgandt 11:37, 12 December 2011 (UTC)
"Liking " others' edits
- 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.
- SNOW close. Sven Manguard Wha? 08:56, 15 December 2011 (UTC)
Oftentimes I come across edits where I think, "that's a really useful bit of editing". Little things like adding sources, tweaking grammar, tidying up section headers - gnomish things which all contribute to improving the encyclopedia, but aren't especially showy. Whilst we do have barnstars (and kittens, cookies and all sorts of other crap) to show approval for this sort of thing, sometimes that level of Wikilove seems excessive for individual edits. What would be nice would be a "Like" (or "Approve", or "Commend" or something else that doesn't make us look like Facebook) button, perhaps next to the button for "Undo", that appeared when an edit was viewed. Users could then show their approval for one another's more minor edits without having to slap a barnstar on their talkpage ("Thanks for deleting that one extraneous apostrophe! I hereby award you this award! Keep up the good work!").
It would also be motivating for new users to see that their edits were approved of - it can take a while to get positive feedback when you first start out (far easier to receive a warning template), and this would show newer users that their efforts were appreciated.
Just a thought - second opinions solicited... Yunshui 雲水 14:52, 12 December 2011 (UTC)
- On the other hand, editors would assume that their 'liked' contentious edits (whether by other similar editors or not) have support from all those editors and would wrongly assume consensus or quote such in a talkpage discussion. --lTopGunl (talk) 17:15, 12 December 2011 (UTC)
- Absolutely irreversible oppose Adds useless clutter to the database / edit history and would enable a new level of WP:MEAT that is practically impossible to prove or disprove. If you think an edit is fine, just drop the editor a note on his or her talkpage. This also could lead to newbies having their absolutely worst crap liked by their friends and would make it even harder to communicate Wikipedias principles to them. (Sorry for the strong language). Toshio Yamaguchi (talk) 20:56, 12 December 2011 (UTC)
- Intensely oppose - whatever gloss you put on it, this would add to the further degenerative Facebookification of Wikipedia, even worse than the contemptible Wikilove. If you wish to communicate with a fellow editor, take the four extra seconds to click on the link to her/his talk page and actually communicate with them like human beings. Templated "goodies" are cheap and sleazy substitutes for actual human interaction. --Orange Mike | Talk 22:08, 12 December 2011 (UTC)
- Oppose upon every grounds possible and with the right to oppose on any ground as yet undiscovered I remain bemused and somehow impressed by the inventive ways editors invent to turn Wiki into a social media platform doktorb wordsdeeds 22:15, 12 December 2011 (UTC)
So that's a "no", then? Okay, bad idea... Yunshui 雲水 00:10, 13 December 2011 (UTC)
- Yeah, but Template:The Minor Barnstar can be awarded to the aforementioned "gnomish" editors. —David Levy 00:18, 13 December 2011 (UTC)
- Oppose and suggest a "For Christ's sake, not another Facebookification proposal" template. Ian.thomson (talk) 00:24, 13 December 2011 (UTC)
- Strongly Oppose per previous objections, WP is an encyclopedia - not Facebook or a social media site. Let's please keep it that way. Per Orangemike, we can "like" other editor's contributions by dropping them a note of appreciation on their talk page.--JayJasper (talk) 05:42, 13 December 2011 (UTC)
- Taking bets that WMF will implement this before long Think about it and you'll realize it's only a small step from the "WikiLove" business to something like this. Those of us who lament the Facebookization of Wikipedia need to get used to the fact that we're fighting a losing battle. Short Brigade Harvester Boris (talk) 05:50, 13 December 2011 (UTC)
- The WMF should seriously think about what they actually want. Do they want to alienate their established editor community in favor of a bunch of "Ey yo don't undo ma ediz where I addez that image I finded in Google and it looks more cool naw cuz I tell my homies to dislike all you edits!!!"? Toshio Yamaguchi (talk) 12:32, 13 December 2011 (UTC)
- Oppose per Ian.thomson --Guerillero | My Talk 05:56, 13 December 2011 (UTC)
- Comment – More or less in response to Toshio Yamaguchi's and my orange colleague's comment, isn't this already being done with the Article Feedback Tool, in which absolute pieces of crap and obvious speedy deletable articles get up-voted 5's across the board for being "Trustworthy", "Objective", "Complete", and "Well-written", when they are in reality not? (I think somebody on WikiEN-l a while back said that the Feedback Tool would be "griefed like with YouTube comments".) Those are not true assessments (at least there is virtually no validity behind it), but rather a measure of how people like an article. –MuZemike 06:03, 13 December 2011 (UTC)
- Sorry, but no. I see too many potential issues with this, apart from the whole "Wikipedia is not facebook" issue. Imagine the history of an article, with each edit having a like button next to it. Imainge an edit war with one edit saying something like "3 people like this" and another saying "5 people like this". It could create some sort of voting system, where people "like" the version they prefer. If someone sees an edit they find is good, post a friendly, handwritten talk page message. Makes one feel a lot better than an automated "like". Wikipedia is becoming too impersonal nowadays... Steven Zhang Join the DR army! 06:10, 13 December 2011 (UTC)
- Neutral. A lot of people here are just knee-jerk reacting to "anything similar to Facebook is bad" without considering its merits. Some kind of system for fine-grained feedback for individual edits could benefit editor motivation on a continual basis, increase community engagement with low investment, and just as importantly, help people reviewing changes to focus on those changes that someone else hasn't already carefully reviewed. Despite all this, I share Steven Zhang's concerns about the number of likes being used as some sort of edit-comparison metric. I think a superior and less controversial proposal would be an "edit review" system would you can mark an edit as "reviewed" to indicate you've checked it out and it looks okay. A bit like pending changes but purely voluntary. Then at least we'd know people are looking at what we're doing. Dcoetzee 17:04, 13 December 2011 (UTC)
- "Some kind of system for fine-grained feedback for individual edits"
- We already have that. It is called a talk page. Toshio Yamaguchi (talk) 17:11, 13 December 2011 (UTC)
- GIANT, Strong Oppose per Toshio Yamaguchi and Steven Zhang. As a rollbacker, I already have an extraneous link on the end of the descriptions in the edit history, and I sometimes feel even that link is too much. Adding a "like" button would add useless clutter, especially since it is not a function I would use often here, if at all. If a user's contribution(s) have moved me enough to want to hit a "like" button, I consider that grounds for showing them a bit of Wikilove. - Purplewowies (talk) 17:42, 13 December 2011 (UTC)
- Oppose. I'm not a fan of this whole WikiLove thing in the first place, and I just see this as a useless addition that doesn't add any value or quality to Wikipedia, but rather adds a distraction for editors away from doing productive work. New additions to Wikipedia should be focused on improving quality.--Slon02 (talk) 01:53, 15 December 2011 (UTC)
- Oppose. A good-faith proposal, but it would clutter us too much and make it too Facebooky. In disputes, good arguments might get overwhelmed by a big "like count" even if the likes lack any context. I'm open to other, less disruptive proposals to promote WikiLove. Lagrange613 02:04, 15 December 2011 (UTC)
Grafting the external links numbering mechanic onto IP signatures
I feel that when multiple non-registered users are participating in a discussion on a talk page it is sometimes difficult to keep track of who is saying what (as strings of numbers are less memorable IMO than names). Therefore I propose that the current mechanic which governs how external links in square brackets are displayed (i.e. by labelling them as the nth link on the page, where the number changes automatically – e.g. [6] [7] [8]) be grafted/exported/whatever onto IP signatures, so that in future they automatically look something like this:
- Comment 1. 1.23.456.78(1) (talk) 14:56, 12 December 2011 (UTC)
- Comment 2. 9.01.234.56(2) (talk) 14:56, 12 December 2011 (UTC)
- Comment 2a. 1.23.456.78(1) (talk) 14:56, 12 December 2011 (UTC)
- Comment 3. 7.89.012.34(3) (talk) 14:56, 12 December 2011 (UTC)
- Comment 3a. 9.01.234.56(2) (talk) 14:56, 12 December 2011 (UTC)
- Comment 3b. 1.23.456.87(4) (talk) 14:56, 12 December 2011 (UTC)
Except that this is evidently a mock-up, and the aesthetics can be played around with, but you get the idea. My thinking is that the "[9] [10]" technology already exists, so it would reduce the workload in creating this feature? It Is Me Here t / c 14:56, 12 December 2011 (UTC)
- Just a note, and I say this as a someone not very familiar with the underlying software and mechanics of Wikipedia, but when you create three external links, of which the first and third are the same, they will not have the same number (see here). So I am not sure, whether applying the external links mechanics to the IPs (if that's possible at all, I don't know) would have the effect you want to achieve. Toshio Yamaguchi (talk) 15:09, 12 December 2011 (UTC)
- I don't think there's much chance of this being incorporated into MediaWiki, but it would be easy enough for someone to write a userscript that adds your indicator after all IP sig links. Anomie⚔ 16:51, 12 December 2011 (UTC)
- There is no way to do this with the current method of applying the link icons; see Help:External link icons. -— Gadget850 (Ed) talk 17:40, 12 December 2011 (UTC)
The proposer is presumably thinking of citation links, which can be made to repeat numbers, but which involves quite a bit of overhead. --erachima talk 18:30, 12 December 2011 (UTC)
- Those are done by the Cite software extension. ---— Gadget850 (Ed) talk 12:53, 13 December 2011 (UTC)
Making Special:Protectedtitles a restricted special page
After spending some time recently RevDeling and RFOing salted titles I now believe that Special:Protectedtitles should become a restricted special page. This is because some of the deleted and salted pages I sent to RFO were (a) themselves suppressed and (b) associated logs were suppressed, meaning that when you now try to create such a page no indication is given (unless you are an Oversighter, presumably) that it ever existed, except for the fact that it is create-protected. However, even these pages which have been hidden from public view using some of our most stringent technical means still show up for all to see at Special:Protectedtitles, because they are still salted, even if their protection logs, owing to the nature of the pages' titles, are suppressed.
Therefore, if there is to be any point in the RevDel and Suppression tools in removing grossly offensive article and user names from public view, then Special:Protectedtitles must also be removed from public view.
N.B. restricting Special:Protectedtitles to Sysops and above would still leave the problem of Admins having access to a sort of oblique Oversight log, but at least this move would be a start. It Is Me Here t / c 10:52, 13 December 2011 (UTC)
- I think a better solution would be that if you RevDel (or RFO) a SALTing of a page, you unSALT it, RevDel (or RFO) the unSALTing log, and if necessary add an approrpiate entry in MediaWiki:Titleblacklist. This way, you don't have the problem of admins seeing RFO material; you don't restrict the community's ability to view Special:Protectedtitles, a restriction which should only be done if absolutely necessary; and frequently the user who was thwarted in recreating the SALTed page due to SALT will try to get around it by homoglyphs - and Titleblacklist is a better way to stop such users. עוד מישהו Od Mishehu 16:30, 13 December 2011 (UTC)
- But surely that would not solve my main concern (publicly viewable/un-hideable gunk, whose existence means that we are not following through with WP:DENY fully), since in your situation we would simply have gunk at MediaWiki:Titleblacklist rather than at Special:Protectedtitles?
- Having said which, another thought has just struck me: is it possible to have the software check whether a salted page cannot now be created by non-autoconfirmed/non-Sysops anyway (since a lot of the titles I was sending to RFO were quite old, possibly predating AbFil, Titleblacklist and the rest of it)? If so, perhaps a list of such "over-salted" pages could be drawn up, and an OS could go through them and remove them from Protectedtitles in the way you suggested? It Is Me Here t / c 17:25, 13 December 2011 (UTC)
- I imagine it would be relatively simple for a bot to take all the pages listed at Special:Protectedtitles, and check if each one of them has a SALT log entry which it can find. If the bot in question is run from an admin account, it will find just the "over-salted" ones; if it runs from an account without admin access, it will also find the salted ones where the log was admin-hidden. עוד מישהו Od Mishehu 20:04, 13 December 2011 (UTC)
RfC on making {{Orphan}} tag invisible
There's an RfC on making the the {{Orphan}} tag invisible. It's at Template talk:Orphan#Proposal - Change this to a hidden category template. I'm spamming it here because it's a highly visible template and so this is an important issue. (Arguably a CENT RfC might be in order since this is template that many readers see often. It might be called for to bump it up to that level if anyone wants to.) --Herostratus (talk) 16:48, 13 December 2011 (UTC)
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)
- 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)
- Need to exclude The The as well. -- WOSlinker (talk) 21:20, 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)
- 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)
(←) 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. [11] [12] [13] [14]). –xenotalk 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)
request explicit user consent before moving a file to commons
I uploaded files to here and not Commons with good reason; I'm fine with them being on commons, but they are easier to manage from en.wiki (such as tracking where they are, for instance) and it is a rather a rude shock when you're tryimg to assemble an article months or years later and you find they are no longer in your contributions list or upload log (yes, they somehow...disappear). Could people please obtain the explicit consent of users before rudely moving their image to commons? John Riemann Soong (talk) 05:34, 14 December 2011 (UTC)
- Bear in mind that you consent to allow this with any of your contributions. Photos simply happen to be most likely to be moved off wikipedia entirely (rather than text which is edited, deleted, moved around, etc.). I have a number of files uploaded here rather than commons for a variety of reasons and I don't usually have an issue with someone else reuploading them to commons and deleting the copy here. IF that happens just download the commons copy and re-upload it. Protonk (talk) 06:11, 14 December 2011 (UTC)
- The problem is when people delete your files and you have no idea where they went (because they disappear from your upload log, and they don't show up as a redlink because they are on Commons). John Riemann Soong (talk) 07:35, 14 December 2011 (UTC)
- Use the {{keep local}} tag, designed for this purpose. Making requesting user consent mandatory would make the majority of cases, where the uploader is no longer active, rather difficult. However, I personally find that keeping them all on commons makes them easier to track, especially with the ListFiles function. sonia♫ 06:34, 14 December 2011 (UTC)
- You're free to use {{keep local}} if you really want, but keep in mind this means any improvements made to the images or their descriptions on Commons, possibly long after you've departed the project, will not be seen on enwiki. This should not be a long-term solution. I agree that tracking files moved to Commons by user is an important issue and hope that once it's solved it'll eliminate this concern. Obtaining permission beforehand is infeasible because many departed users are impossible to reach. Dcoetzee 07:36, 14 December 2011 (UTC)
- While I sympathize with your inconvenience here, having to get the permission of the author to move or change something flies in the face of so many principles, policies, and standards on Wikipedia that the answer is, flat-out, no. --erachima talk 08:01, 14 December 2011 (UTC)
- There's nothing wrong with having the file kept locally. Yes, it can be copied freely -- but deleting a perfectly good, encyclopedic, functional copy without the author knowing about it at all is an issue. John Riemann Soong (talk) 08:18, 14 December 2011 (UTC)
- Deleting an encyclopedic, functional copy where it is redundant is common and sensible-- say, for example, if a user made the same article twice under different names. Unifying all possible images in one place means that changes made will apply across all projects, making things more efficient (not to mention it being easier to find free files in one place). I doubt that anyone has meant to be rude in moving your files; they're just doing their job. The simple solution is to use {{keep local}}; it's created as a courtesy to users like you who prefer it this way, as much as it's not ideal. But your proposal is impractical and its implementation would slow file work dramatically. sonia♫ 08:36, 14 December 2011 (UTC)
- I seems that an automatic notification if/when a file is moved would be helpful. At least then people would know if the (not their) files were moved, and where to. fredgandt 08:43, 14 December 2011 (UTC)
- Yeah, notification could be done, but "explicit consent", no. It'd just add bureaucracy. Choyoołʼįįhí:Seb az86556 > haneʼ 08:51, 14 December 2011 (UTC)
- Oppose: moving to Commons no way harms editor — the image can still be watched, tracked and whatever. Moving images to Commons is in line with word and spirit of Wikipedia rules, and explicit author's content would just make matters worse for Wikimedia with no one's benefit. — Dmitrij D. Czarkoff (talk) 09:07, 14 December 2011 (UTC)
- Oppose, but see the problem: As WP:5P says 'all of your contributions can and will be mercilessly edited and redistributed.' However I do think that something better really should be done about the contribution list rather than deleting history. I find the business of contributions to deleted articles disappearing from history worrying too, I'd prefer they be listed even if one could not look at them. Personally I always upload to commons if possible, I view uploading to Wikipedia as something that only should be done for things with a restrictive license. Dmcq (talk) 10:26, 14 December 2011 (UTC)
- Oppose: Sleeping editors shouldn't block a move forever. A little background, before sending thousands of pix to Commons I sent hundreds (mostly more useful ones) to en and many of those have later been found by other edtitors and moved to Commons. Problem is, sometimes I don't see the notice in the original file, thus fail to follow the link and watchlist it in Commons, with the result that they are poorly categorized and not geotagged. So, if I fail to see the pre-announcement or otherwise do not object in a few days, the transfer ought to go ahead anyway. Silence implies consent. On the other hand, the thing I wish is, the moving bot should also watchlist it for me in Commons. Jim.henderson (talk) 19:39, 15 December 2011 (UTC)
- Oppose. I like the idea of an automatic notification if it's possible, but requiring consent would be problematic indeed. Commons exists for the sake of making media available to all WMF sites, so all images should be there unless there are copyright issues — please establish a Commons account and upload images there, rather than here. Nyttend (talk) 13:20, 18 December 2011 (UTC)
Create a new userright
I propose to create a new userright. Users with this right would be able to circumvent the spam filter. The rationale behind this is that it would make my work archiving reference links MUCH easier (see also this discussion). The way I want to work is I copy all the reference links to a page in my userspace, then go through this list, archive the links with WebCite and add the archive link to the reference links in my userspace. Then I would go back to the article and add the archive link to the corresponding reference. Toshio Yamaguchi (talk) 20:27, 14 December 2011 (UTC)
- What happened to administrators? We can ask them to make necessary modifications if necessary. This doesn't often happen, so I wouldn't support. Hazard-SJ ± 03:48, 15 December 2011 (UTC)
- Last I checked, administrators can't get around the spam blacklist; other than adding something to the whitelist. This was last week I had this problem.--v/r - TP 03:58, 15 December 2011 (UTC)
- Bypassing the spam blacklist would render the page uneditable to all other users. No. T. Canens (talk) 04:13, 15 December 2011 (UTC)
- Not exactly, since approx. 2010 you can edit and save paged with blacklisted links: spamlist only prevents new blacklisted links. Still, I don't think a new userright is a proper solution to Toshio's problem. — AlexSm 04:29, 15 December 2011 (UTC)
- Bypassing the spam blacklist would render the page uneditable to all other users. No. T. Canens (talk) 04:13, 15 December 2011 (UTC)
- Last I checked, administrators can't get around the spam blacklist; other than adding something to the whitelist. This was last week I had this problem.--v/r - TP 03:58, 15 December 2011 (UTC)
- If it's any help, I recently submitted a patch that would help by telling you all the instances of offending links in one go. This makes it even easier to write a script that automatically 'nowiki's the bad links. - Jarry1250 [Weasel? Discuss.] 00:22, 18 December 2011 (UTC)
Turn Wikipedia off RfC
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.
I'm not sure what the state of play with the proposed shutdown of WP is. It looks like we will probably do nothing. But this is a last-ditch attempt at a concrete proposal. Please note that there is not much time left for fine detail, so please oppose this if you oppose the idea of a protest. If you support the idea of a protest but have quibbles about exactly how to do it, quibbling may well mean no clear consensus so nothing happens. Apologies but I will not be around for much of the discussion. Amend and tweak in good faith as you will.
I also have no knowledge about whether this will be technically do-able at short notice, so apologies if the RfC succeeds but still nothing happens.
Editors are asked to bear in mind that there was strong support for the general idea of action of the type described at User_talk:Jimbo_Wales#Request_for_Comment:_SOPA_and_a_strike.
The proposal
English Wikipedia articles will be made inaccessible to everyone geolocate-able to the United States from one minute past midnight EST on Thursday to midnight PST on Thursday.
The Wikipedia homepage will either stay as it is or consist of something appropriate to the action being taken, as decided by community consensus. Attempts to reach a particular page on en.wp will result in a redirect back to the homepage.
The lockout will apply to all readers and editors in the US except those who are absolutely needed for technical purposes.
Users outside the United States are encouraged to support the "strike" by not editing during it, except to undo vandalism.
Please vote support or oppose. --FormerIP (talk) 00:36, 15 December 2011 (UTC)
- Comment I would point out that RFCs customarily run a month. In a matter of such moment, how would it be fair to decide this based on whoever votes in the next four hours? I would say that would be very ill advised.--Wehwalt (talk) 00:44, 15 December 2011 (UTC)
- OK, well you've said it. Thank you for saying it. --FormerIP (talk) 00:45, 15 December 2011 (UTC)
- Its a good point; but, this is the best effort at process that can be made given the limits of the community's neglect of processes for snap actions and/or the threat of this law to it. It is an attempt more in line with process than private consensus building attempts that appear to have no actionable component. Fifelfoo (talk) 00:50, 15 December 2011 (UTC)
- It's past midnight in the UK. Generally, in societies where people's rights are valued, sneaking things through in the middle of the night is disfavored. While their access, of course, would not be blocked, for certain they might have something to say about the politicization of this website. As might those Americans and Canadians who only edit during the day.--Wehwalt (talk) 01:05, 15 December 2011 (UTC)
- This is an excellent reason to argue that this RfC not be abnormally closed, or abnormally closed early. I notified WP:AN/I of this RfC, and suggest that you restate this point there as well. Despite supporting this RfC, I support your argument that it not be abnormally closed, and will make this point at AN/I myself right now. Fifelfoo (talk) 01:14, 15 December 2011 (UTC)
- It's past midnight in the UK. Generally, in societies where people's rights are valued, sneaking things through in the middle of the night is disfavored. While their access, of course, would not be blocked, for certain they might have something to say about the politicization of this website. As might those Americans and Canadians who only edit during the day.--Wehwalt (talk) 01:05, 15 December 2011 (UTC)
- Support. I support the en.wikipedia taking action where another body poses a serious threat to the encyclopaedic process; but, where our action does not compromise our responsibility as encyclopaedists by altering content. Given the timeframe, this "snap action" combines a symbolic representation of outrage, with a real economic threat presented by locking out US geolocated users and by forming a moral picket against use of the encyclopaedia amongst non-US users. It is far more strategic than either an indefinite withdrawal of service, or a purely symbolic advertisement. This balance represents the broad balance of a consensus building straw poll on a well trafficed user page. This gives us "currency" and would allow us time to make a more considered action or inaction decision after the highly time critical element of the US state's process has occurred. Fifelfoo (talk) 00:50, 15 December 2011 (UTC)
- Support I have no hesitation in joining anything which helps build this movement doktorb wordsdeeds 00:53, 15 December 2011 (UTC)
- Support. Ironholds (talk) 00:54, 15 December 2011 (UTC)
- Comment. If the proposal goes through it has my moral support. However I am uneasy about the precedent. Until now, as far as I'm aware, English Wikipedia has never taken an explicit political stand on anything. If we do it once, will the next one seem like something all right-thinking people should agree with, but it's less directly connected with our mission? And then the one after that maybe I don't agree with? If this is adopted I think it needs to be with the clear understanding that it does not open the floodgates to political action on WP's part on just any issue where say 80% of editors happen to be on the same side; it's an exceptional action that should be taken only when the legislation is a direct threat to the encyclopedia as such. --Trovatore (talk) 01:03, 15 December 2011 (UTC)
- Agreed. —David Levy 01:09, 15 December 2011 (UTC)
- Support, but the only realistic way this is going to happen in the required timeframe is bold action by Jimbo Wales, not through an RfC. He had his informal poll, for what it's worth; not ideal, but certainly an indication of where the community stands. CharlieEchoTango (contact) 01:07, 15 December 2011 (UTC)
- Support. Replace the main page with an explanatory message and point all pages to it (or something comparable). And just as the French Wikipedia's strike wasn't restricted to France, I don't believe that this one should be restricted to the United States (given the fact that the proposed legislation stands to affect readers around the world). If that's a sticking point, however, a U.S.-only protest is better than nothing. —David Levy 01:09, 15 December 2011 (UTC)
- Oppose until we get a wider and more authoritateve consensus than can come from the relatively few who watch VP and respond to a day's notice. For example, a week's worth of replies to a banner replacing the money-begging ones.Jim.henderson (talk) 01:12, 15 December 2011 (UTC)
- Oppose. Time to take a deep breath. Let Jimbo and the WMF decide how they want to communicate with the US government. No one in the government is going to shut us down in the next few days, so we don't need to over-react. Jimbo said very clearly on his talk that any actual shutdown would require thorough evaluation and consensus by the community. That's going to take some time. --Tryptofish (talk) 01:14, 15 December 2011 (UTC)
- I guess I should support as OP. And add a request for the closer to consider in conjunction with the discussion on Jimbo's talkpage. --FormerIP (talk) 01:16, 15 December 2011 (UTC)
- Oppose; if consensus is to lockdown we need to a) write a proper notice to explain the action to our users (otherwise the event is pointless) b) estalish proper media coverage (or the event is useless - simply reporting us being down is useless if there is no organised media response) c) confusing. Rushing it through in a few hours with probably minimal input is also problematic. (FWIW I don't think it is technically possible to implement a US geolocated lockdown with any tools available to admins - unless we find a way to hack geonotices). If the community is in favour of a shutdown, fine. But we need to do it properly, with (as Jimbo said), careful discusion as to options. This can only hurt our cause. --Errant (chat!) 01:17, 15 December 2011 (UTC)
- Oppose - With respect, this RfC is pointless. Jimbo has had plenty of response on his talk page, and if he intends to play god with the site, he will do so regardless of this RfC. (I would also note that we do have a process for things that require "snap action": WP:BOLD.) If this RfC is felt to be required because the discussion at Jimbo's has not yielded a firm consensus, then we already have the answer. Giving 3-4 hours for the few people who are on right now, and read this page to determine the ability of everyone to edit and read would be a complete farce. I might be in favour of blanking the main page only, but at this point, it is too late for the community to achieve a legitimate consensus on shutting the entire site down at midnight EST. Resolute 01:18, 15 December 2011 (UTC)
- The discussion on Jimbo's talk page has yielded a firm consensus, but it explicitly wasn't intended to determine a specific implementation. —David Levy 01:23, 15 December 2011 (UTC)
- And there is absolutely no possible way that such an implementation could be determined in three hours. More over, the community does not have the power to shut the site down for just American users. Even if it did, to allow a couple dozen dictate something this big to the thousands who will not have even the opportunity to give input would be ridiculous. Let Jimbo and/or the foundation decide what to do, or pick another date that allows time for the entire community to weigh in. Resolute 01:29, 15 December 2011 (UTC)
- Those are valid points, and I agree that this proposal is unlikely to succeed. I'm merely addressing your comment regarding "the discussion at Jimbo's [possibly having] not yielded a firm consensus." —David Levy 01:39, 15 December 2011 (UTC)
- And there is absolutely no possible way that such an implementation could be determined in three hours. More over, the community does not have the power to shut the site down for just American users. Even if it did, to allow a couple dozen dictate something this big to the thousands who will not have even the opportunity to give input would be ridiculous. Let Jimbo and/or the foundation decide what to do, or pick another date that allows time for the entire community to weigh in. Resolute 01:29, 15 December 2011 (UTC)
- The discussion on Jimbo's talk page has yielded a firm consensus, but it explicitly wasn't intended to determine a specific implementation. —David Levy 01:23, 15 December 2011 (UTC)
- Oppose until we have a firmer starting point with drafts.--Guerillero | My Talk 01:20, 15 December 2011 (UTC)
- Support. I very strongly agree with the proposal. Time and again issues like this in the US have been decided solely by legislative agenda because those of us who care - the members of a certain community, or even the whole Internet community - have raised awareness among ourselves but not enough with the general public. I feel that something on the scale of "turning off" English Wikipedia is absolutely necessary to raise the public awareness this cause needs. And make no mistake, this is an issue which can shake the Internet as we know it today to its foundation. I would furthermore suggest that, during the time English Wikipedia is disabled, site-wide headers be added to all other Wikipedia sites explaining the situation. Jantman (talk) 01:20, 15 December 2011 (UTC)
- Oppose Even if all the dots were crossed and the ts dotted, this would still be an ill-advised proposal. As it is, it will set the community at each other when people realize what happened who do not edit Wikipedia incessantly.--Wehwalt (talk) 01:22, 15 December 2011 (UTC)
- Strong support - (edit conflict)x2 We have never had something so directly threaten Wikipedia and basically the vast majority of the internet in the past and I feel that due to the unprecedented threat an equally unprecedented response is fully justified. Barts1a | Talk to me | Yell at me 01:23, 15 December 2011 (UTC)
- Oppose – The deadline for this proposal (less than four hours from when this comment is posted) is outrageous. This doesn't leave much time for the community to be involved in planning stages of this proposal. We haven't even constructed "Learn why SOPA will be bad for Wikipedia and the Internet" message that the readers will see. This proposal is being rushed through. We should at least be on the same page as Jimbo and the WMF. --Michaeldsuarez (talk) 01:25, 15 December 2011 (UTC)
- As one of 47,592,442 who actually knows what this rushed mess is all about, I have to say; for a web site that prides itself on neutrality and protection of copyrights, to throw a hissy-fit and shut itself down out of fear of something that might not even happen, that might actually do some good, that might not be as bad as pundits predict even if not good, or that at worst could be undone if found to have been a bad idea, is plain bloody stupid.
- As for this half-arsed RfC, shockingly shoddy and painfully panic inducing. fredgandt 01:27, 15 December 2011 (UTC)
- Oppose trying to get this done in less than five hours. --Yair rand (talk) 01:28, 15 December 2011 (UTC)
- Send him to the stocks You're trying to shut the site down with a six hour poll? I recognize that people aren't sanctioned for idiodic proposals, but this is ridiculous. Buddy431 (talk) 01:30, 15 December 2011 (UTC)
- Oppose Whilst I completely disagree with SOPA, I do not think that it is in our best interests to blank Wikipedia. SmartSE (talk) 01:34, 15 December 2011 (UTC)
- Moral support for the proposal, but I'm with Buddy— send him to the stocks. The previous RfC was crystal clear, and if Jimbo wants to turn off Wikipedia based on that, then he should do so by all means. But starting a "concrete proposal RfC" to supposedly determine this in only a few hours is absurd. The vast majority of users who supported this in the previous RfC may well not get to comment on this at all. Swarm X 01:37, 15 December 2011 (UTC)
- Strongly Oppose Isn't fair to shut down a website without a fair and reasonable proposal and at least some time to debate over it. People rely on Wikipedia on a daily basis, and doing this would be too risky. --Radiokid1010 (talk) 01:46, 15 December 2011 (UTC)
- Moral support, practical oppose. If people who've looked at the current SOPA proposals think it would have a serious, deleterious effect on Wikipedia editing then a protest like this is appropriate. But it should be done with wide consensus and careful consideration to getting the most benefit. I would support a similar proposal for a temporary shutdown next week or next month. Will Beback talk 01:47, 15 December 2011 (UTC)
- Oppose. I've opposed it on Jimbo's talk page, and I'll oppose it again. Going on strike will damage Wikipedia's reputation as a neutral encyclopedia in the eyes of the global community, and it will be a betrayal of every editor who contributed with the expectation that Wikipedia would remain neutral and not become a political tool. I will not !vote for the destruction of Wikipedia's reputation, and I will not !vote for the splintering of our community and the breaching of our contributors' trust.--Slon02 (talk) 01:50, 15 December 2011 (UTC)
- Oppose procedurally and substantively. Procedurally, this is completely unfair to users who live time zones where the few hours this would be open are inconvenient for editing, or who are traveling for the holidays, or who don't edit on Wednesday/Thursday. Way to go countering systemic bias. Substantively, it is inappropriate for the community to compel any user to edit or not edit to make a political point. It would also set a truly awful precedent, with unknowable consequences. If some threshold of consensus is all it takes to turn Wikipedia into an instrument of politics, then Bill O'Reilly can take over the encyclopedia if 1% of his three million nightly viewers respond to a call to register accounts. Even if nothing like that happened, Wikipedia would be permanently politicized. Every time a controversial piece of media legislation got introduced, it would be "How will Wikipedia respond?" all over the news. Lagrange613 01:52, 15 December 2011 (UTC)
- Meaningless RFC that should be closed and ignored. I've had meals that lasted longer than the proposed duration of this RFC. Townlake (talk) 01:56, 15 December 2011 (UTC)
- Oppose on procedural grounds for reasons stated by Errant. This was never proposed to be implemented immediately and the decision to do so should not be rushed. Also opposed on substantive grounds for the reasons I stated on Jimbo's talk page. I think there is a better than 50/50 chance that if Wikipedia does this, we are going to regret it later. Many of the "votes" on Jimbo's talk page simply expressed opposition to the legislation, and I oppose it too, but that doesn't mean that this is the correct strategy to fight against it. Neutron (talk) 01:57, 15 December 2011 (UTC)
- Oppose as not a meaningful process. I happen to have woken up in the middle of the night in the UK and spotted this odd discussion. It may be a hoax or perhaps just an exercise in pointiness, but I have no intention of spending time investigating as I need to get back to sleep. Please close this non-RFC as malformed. --Fæ (talk) 01:58, 15 December 2011 (UTC)
- Support - If we aren't willing to stand up to a threat to our operations, then why are we contributing in the first place? I'd also point out what Jimbo, the WMF and many others have said; that Wikipedia is political by it own nature. Sharing knowledge freely and openly has always been inherently subversive and a political act throughout recorded history, including modern times. - Hydroxonium (T•C•V) 02:06, 15 December 2011 (UTC)
- (edit conflict × 5)*Support - as I said at the original RfC, this is not about politics, but what is good for the encyclopedia. This bill gives control of the internet to whoever wants to spend the most money censoring it, which is the pretty much the opposite of the egalitarian and free access to knowledge this site provides. We've already had an RfC about this (and those who opposed should not ignore that they got outside votes as well), so this should really be a discussion of whether we're going to do a banner or a complete blank. Ian.thomson (talk) 02:13, 15 December 2011 (UTC)
Making editing easier
This is something that had bugged me for a very long time: How come the way we edit on Wikipedia is needlessly complicated? Although I have come to terms with it (at least with most of it), I imagine that a turn off for many new editors is how confusing everything is. They would not know how to use templates/categories/infoboxes etc. or even know how to bold or use headings. On many online sites, where you can contribute to discussions etc, there are buttons at the top of the editing box, not unlike microsoft word, that allow you to easily edit colour/bold/size etc. and a lot of other stuff without having to worry about three lines for bold and a copy and pasted line of text for colour etc. In other words, what you see is what you get. Whilst editing, you would see stuff in bold or coloured etc. Also if there were buttons along the "Advanced", "Special Characters", "Help", "Cite" row that had all the infoboxes/templates etc.. or something like that... it would make all our lives soo much easier. Why isn't this done?--Coin945 (talk) 11:19, 16 December 2011 (UTC)
- There is wikiEd – is that what you were looking for? It Is Me Here t / c 15:04, 16 December 2011 (UTC)
- And see Wikipedia:Village pump (technical)#Visual editor. – ukexpat (talk) 15:18, 16 December 2011 (UTC)
Reply link/button at the end of talk page sections
Currently editing the section loads the whole source and sections are sometimes very long and all that content is loaded in to the edit-box as well. How about placing a small reply link (or button) at the end of talk page sections, clicking which will load the same section as an almost empty edit box and by default will have only the indentation suitable for a reply to the last comment which could be changed if required by the editor. This will prevent loading the whole text if some one only needs to reply and will also prevent mistaken editing of other comments. Or maybe even better than the reload, clicking the reply link expands into an edit box of the same format as mentioned above and clicking a save button in that would simply post the reply at the end but not reload the page instead become "your reply has been saved - reload page to see it" or something similar. The normal editing can still take place by clicking the 'edit' link while this will be an additional help. The proposal is open to be further decided as an opt-in/opt-out option that would be adjustable by individual users for themselves so as to see or not to see the reply link. --lTopGunl (talk) 15:27, 16 December 2011 (UTC)
- The Liquid Threads extension does this, but we don't use it. I would however oppose implementation of the extension as many talk pages would need reconstruction. Hazard-SJ ㋡ 23:54, 17 December 2011 (UTC)
Remove fundraising banners once a person has contributed
Would it be possible to remove fundraising banners for IPs from which donations have already been received this year? — Preceding unsigned comment added by Heymisterbill (talk • contribs) 20:54, 16 December 2011 (UTC)
- technically, probably, but that would involve tracking and finding out whether it's a public computer (removing it from a shared computer is not good). And it would only work with cookies or something. Choyoołʼįįhí:Seb az86556 > haneʼ 22:16, 16 December 2011 (UTC)
- In theory, it already does that. --Yair rand (talk) 05:42, 19 December 2011 (UTC)
RfC on eliminating the comment from the Persondata template
There's an RfC on eliminating the need to add the <!-- Metadata: see [[Wikipedia:Persondata]] --> comment from the persondata template and perhaps even eliminating it from the articles as more significant edits are made. It's at eliminating the comment from Persondata. I'm spamming it here because it's a highly visible template and this issue has come up multiple times in multiple venues for multiple reasons and I would like to put it to rest once and for all. --Kumioko (talk) 04:10, 17 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)
- 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)
Proposal to add -suppressredirect to the filemover user group
Currently, when a filemover moves a file, a redirect is always left behind. However, after all instances of the file have been replaced with the new file name, the redirect becomes obsolete and the redirect is deleted. I would like to propose that -suppressredirect be added to the file mover user group. It would allow a file mover to move a file without leaving a redirect behind, and save an admin from having to come by and delete the obsolete redirect. Alpha_Quadrant (talk) 04:26, 18 December 2011 (UTC)
- Would there be any cases where a redirect being left behind was desirable or even necessary? fredgandt 04:37, 18 December 2011 (UTC)
- There may be exceptions where the current title serves as attribution, something like Template:Copied. There wouldn't be any problem with keeping the redirect unless the image is non-free. If a redirect is used instead of the actual filename, the use will not display in the "File usage" section on the file description page. This poses a potential challenge for non-free content enforcement, as every use of an un-free file should have a specific fair use rationale. While the use would still be listed in WhatLinksHere, it would not be listed in the "File usage" section, making it a bit more difficult in tracking the usage. Alpha_Quadrant (talk) 04:58, 18 December 2011 (UTC)
- Very bad idea. The creation of a redirect should only be suppressed when the redirect qualifies for speedy deletion, and in the vast majority of cases, that's not the case with the image. In particular, redirects never qualify for R3 (newly created and unlikely) unless the original title is new; if File:IMG 2222.jpg was uploaded in 2005 and you move it to File:Descriptive Title.jpg in 2011, it does not qualify for R3, because despite what the history of File:IMG 2222.jpg says, the title has existed since 2005. Nyttend (talk) 13:01, 18 December 2011 (UTC)
- There may be exceptions where the current title serves as attribution, something like Template:Copied. There wouldn't be any problem with keeping the redirect unless the image is non-free. If a redirect is used instead of the actual filename, the use will not display in the "File usage" section on the file description page. This poses a potential challenge for non-free content enforcement, as every use of an un-free file should have a specific fair use rationale. While the use would still be listed in WhatLinksHere, it would not be listed in the "File usage" section, making it a bit more difficult in tracking the usage. Alpha_Quadrant (talk) 04:58, 18 December 2011 (UTC)
- Is this proposal for the generic supress-redirect or a new image specific one? Yoenit (talk) 13:23, 18 December 2011 (UTC)
- This proposal is for the generic -suppressredirect. It would require additional unnecessary work to implement the tool for just the file namespace. File redirects do qualify for G6, G7 (if nominated by the mover), and R3. If the file has just been moved, the redirect was just created. It doesn't matter how long there was an image there, the redirect is still new. The deletion of these redirect are non-controversial providing all incoming links are corrected. The previous name was incorrect for some reason. And if the redirect is tagged by the file mover, then it is a valid author requested tagging. I have seen some file movers take redirects to RfD, but I am yet to see one of these redirect nominations challenged and kept. It would be excessively bureaucratic to have to send all of these obsolete redirects to RfD, where they are always deleted after 7 days.
- If an image is renamed under file move criterion #1, the original uploader has requested a move for some reason. Usually these requests are made because of an error they made. Redirects can safely be deleted, as the reasons for the move are often based on one of the other below reasons.
- If a file is renamed under file move criterion #2-5, the original file name was completely incorrect. The redirect left behind is completely implausible and can be deleted after all file usages are corrected.
- If a file is renamed under file move criterion #6-7, the file was moved to harmonize with the rest of a group of images or disambiguate images with very similar names. These redirects are obsolete after all instances are corrects, and the redirect can safely be deleted.
- If a file is renamed under file move criterion #8, the redirect must be deleted, as the original file name was pejorative, offensive or crude. If this file redirects to a file depicting a living person, the redirect would potentially violate the biography of a living person policy.
- All of the above reasons are non-controversial. There may be the occasional exception, but overall, these redirects are obsolete once the file instances are corrected. Alpha_Quadrant (talk) 17:10, 18 December 2011 (UTC)
- I support this: people with the permission can choose if the redirect is left or not, so in case it's needed to keep it, they would just not check it. Petrb (talk) 13:57, 18 December 2011 (UTC)
- Oppose: Deleting image redirects should only happen in exceptional circumstances, and the need for this ability is therefore substantially decreased. I worry that if this right is given to all file movers, it will be misused unintentionally. This right is handed out fairly liberally (and rightly so), but in the rare circumstances where redirect deletions are needed, they should be tagged and reviewed by administrators. PeterSymonds (talk) 18:25, 18 December 2011 (UTC)
- Deletion of delinked file redirects are a commons occurrence though. For example Wikipedia:Redirects for discussion/Log/2011 October 26. Once the redirects have been delinked, the deletion is non-controversial. Suppressredirect does not allow users to delete anything. The flag just allows the user to skip auto-creating a redirect. Failing to create a redirect after a file move has no more potential damage than moving files themselves. As far as finding the renamed files, the move log will be visible, directing to the new file name. Alpha_Quadrant (talk) 19:43, 18 December 2011 (UTC)
- What about proposing a trial for limited time (1 month) to check if this feature would be misused or constructive update of configuration? Maybe it would be better than permanent change, Peter's point makes a lot of sense, however it's hard to know if it would be really misused or not, file moving does happen rarely on english wikipedia and people who do that are probably familiar with the rules enough. Petrb (talk) 20:50, 18 December 2011 (UTC)
- Oppose - A recurrent complaint from uploaders is that files are moved (either on this project or to Commons) without appropriate linkages or notification, and subsequently cannot be relocated. At least with the redirects, people have a chance to find their now-moved uploads. Risker (talk) 18:29, 18 December 2011 (UTC)
- Even after a file redirect has been deleted, it still leaves behind text pointing to the new page.
“ | 19:20, 18 December 2011 (UTC) Example (talk | contribs) moved File:Example.jpg to File:New filename.jpg (Move reason here) | ” |
- So even if the redirect is deleted, the author can still find the upload quite easily. The problem is when the image is transfered to commons under a new name, and the administrator does not make a note in the deletion log as to what the new commons name is. Alpha_Quadrant (talk) 19:20, 18 December 2011 (UTC)
- Oppose. Even if we assume that eliminating these redirects is desirable (which is disputed), how does it make sense to do so before transclusions have been updated (thereby breaking them in the interim)? —David Levy 20:10, 18 December 2011 (UTC)
- The brief time it takes to fix a tranclusion is no different than fixing double redirects after a page move. In the off chance there are a large number of file tranclusion replacements needed, AWB or a script could be used to quickly make the replacements. Over at commons, User:CommonsDelinker goes through and makes the translusion corrections after the file rename. How is keeping the file redirects desirable? As I have linked above, they are deleted after they are delinked. There has never been any opposition at RfD over a file redirect deletion because the task is non-controversial. Alpha_Quadrant (talk) 20:20, 18 December 2011 (UTC)
- The brief time it takes to fix a tranclusion is no different than fixing double redirects after a page move.
- No, the two scenarios aren't comparable.
- Firstly, a double redirect merely adds an additional step (a link that must be followed). This is inconvenient, but it doesn't sever access to the desired content. Conversely, if an image were to be moved without leaving behind a redirect, all transclusions would simply be broken (resulting in red links instead of media).
- Secondly, the need to repair double redirects is unavoidable (unless settings are changed to enable them to function as normal redirects, which I believe proved too resource-intensive). Conversely, the current setup already prevents broken transclusions from arising as a result of file moves.
- How is keeping the file redirects desirable?
- It's been noted that this assists users seeking files under their original names (who might otherwise have difficulty finding them) and prevents transclusion breakage in historical page revisions.
- As I have linked above, they are deleted after they are delinked.
- And if we assume that the redirects should be eliminated, that's the proper means of accomplishing the task (deleting them after they're delinked).
- There has never been any opposition at RfD over a file redirect deletion because the task is non-controversial.
- Some users are expressing opposition now. Has a relevant community discussion ever occurred? RfD isn't a high-traffic forum, so it's possible that the practice has gone largely unnoticed. —David Levy 21:21, 18 December 2011 (UTC)
- A moved file red link merely adds a second step as well. When clicked, it displays the move log along with a link to the new file location. This move notice provides an easy way for the user to find the file. If a uploader is looking for an old file they uploaded, it is more plausible that the uploader would look at their contribution page, rather than searching for it manually. This is especially true considering that most of the file moves are done because the images have random strings of numbers. If a user checks an old page revision with a moved image, they will find the image after clicking the red link. File redirects have been actively nominated for deletion since back in March when the filemover flag was created. There has not been any opposition in that time period, at all. There are a fair number of users involved in RfD. Hundreds, if not thousands, of badly named files have been renamed in that time period. That is not something that can go unnoticed. If there is opposition to the deletion of useless file redirects, then why hasn't it been brought up. Keeping a redirect just because it would leave a red link in an old revision is not a valid keep rationale. Alpha_Quadrant (talk) 21:41, 18 December 2011 (UTC)
- A moved file red link merely adds a second step as well. When clicked, it displays the move log along with a link to the new file location.
- The latter statement is true for administrator/confirmed/autoconfirmed accounts. Please log out and click on File:PICT3902.JPG.
- Regardless, would you honestly expect most readers to follow such a link? And are you suggesting that this would result in an experience comparable to the media's transclusion in the article ("merely [adding] a second step" to its access)?
- If a user checks an old page revision with a moved image, they will find the image after clicking the red link.
- See above.
- Regardless, that isn't the same as viewing the image in its intended context.
- File redirects have been actively nominated for deletion since back in March when the filemover flag was created. There has not been any opposition in that time period, at all.
- Again, there appears to be opposition now. I'm expressing neither agreement nor disagreement. I'm merely acknowledging its existence.
- There are a fair number of users involved in RfD.
- You linked to a page on which numerous nominations simply went unchallenged. That establishes an absence of expressed opposition, but it provides no indication of wide awareness or consensus within the Wikipedia community.
- If there is opposition to the deletion of useless file redirects, then why hasn't it been brought up.
- Setting aside your description of the redirects as "useless", such opposition has been raised in this thread. Are you suggesting that it's too late for these opinions to be considered?
- Keeping a redirect just because it would leave a red link in an old revision is not a valid keep rationale.
- Of course it is. It just doesn't necessarily outweigh one or more deletion rationales. —David Levy 23:23, 18 December 2011 (UTC)
- A moved file red link merely adds a second step as well. When clicked, it displays the move log along with a link to the new file location. This move notice provides an easy way for the user to find the file. If a uploader is looking for an old file they uploaded, it is more plausible that the uploader would look at their contribution page, rather than searching for it manually. This is especially true considering that most of the file moves are done because the images have random strings of numbers. If a user checks an old page revision with a moved image, they will find the image after clicking the red link. File redirects have been actively nominated for deletion since back in March when the filemover flag was created. There has not been any opposition in that time period, at all. There are a fair number of users involved in RfD. Hundreds, if not thousands, of badly named files have been renamed in that time period. That is not something that can go unnoticed. If there is opposition to the deletion of useless file redirects, then why hasn't it been brought up. Keeping a redirect just because it would leave a red link in an old revision is not a valid keep rationale. Alpha_Quadrant (talk) 21:41, 18 December 2011 (UTC)
- The brief time it takes to fix a tranclusion is no different than fixing double redirects after a page move. In the off chance there are a large number of file tranclusion replacements needed, AWB or a script could be used to quickly make the replacements. Over at commons, User:CommonsDelinker goes through and makes the translusion corrections after the file rename. How is keeping the file redirects desirable? As I have linked above, they are deleted after they are delinked. There has never been any opposition at RfD over a file redirect deletion because the task is non-controversial. Alpha_Quadrant (talk) 20:20, 18 December 2011 (UTC)
- Support there is no reason to keep behind redirects to titles like File:IMG_156987. If the mover does what he is supposed to, all uses of the file are switched over to the new better name. I do think that we need to patrol people's file moves more like they do at commons. I have seen people move files that do not need to be moved in any way --Guerillero | My Talk 20:26, 18 December 2011 (UTC)
- To the contrary, one reason that we keep these titles (like all other titles) is that their deletion causes problems in article histories. That's a major reason that we have RFD: it exists to get rid of titles that aren't useful, but a title that's been linked in an article is generally useful. The speedy deletion criterion only permits the deletion of new titles, and proposing a solution that will get around this is entirely unacceptable — the criterion may only be ignored in unusual circumstances, so making it easy for deletion policy to be ignored is a very bad idea. Nyttend (talk) 20:45, 18 December 2011 (UTC)
- RfD is designed to determine whether or not a redirect meets the redirect guidelines. We do not keep redirects just because it is linked to in a previous page revision. Now if the redirect has useful page history, then in that exception, we would keep it. If we were to keep all pages just because it was linked once, there is very little that we could delete. When we have XfD discussions, no votes "Keep, it was linked to once, so we need to keep the page so that it doesn't show up as a red link if someone looks at an old revision of the page." It isn't a valid reason for keeping a page. For example, this diff from 2005. There are a large number of red links there, that, at the time the edit, were blue links. Wikipedia changes constantly. Red links in old revisions are inevitable. Alpha_Quadrant (talk) 21:02, 18 December 2011 (UTC)
- No one has asserted that historical usage automatically precludes a redirect's deletion. But there should be consensus that the harm caused by retaining a redirect (or type of redirect) outweighs the benefits. If a redirect (or type of redirect) causes no significant harm, even a minor benefit is a sufficient reason to retain it. (This is hypothetical. I'm not expressing an opinion regarding the harm:benefit ratio.) —David Levy 21:21, 18 December 2011 (UTC)
- Assuming the user follows the file rename criteria, there are no benefits for keeping a redirect. The names are inappropriate for some reason. Given that we are transferring our free images to commons, that will just leave non-free images and a few free images that cannot yet be transfered there. As I stated above, non-free images need to have their redirects deleted because when a file redirect is used, it does not show up in the file usage section on the file description page. Alpha_Quadrant (talk) 22:04, 18 December 2011 (UTC)
- Assuming the user follows the file rename criteria, there are no benefits for keeping a redirect.
- Benefits have been clearly noted. It's reasonable to argue that they're minor and outweighed by detriments, but it's unreasonable to claim that they don't exist.
- As I stated above, non-free images need to have their redirects deleted because when a file redirect is used, it does not show up in the file usage section on the file description page.
- That's a valid argument as to why the detriments of retaining redirects to non-free files presently outweigh the benefits, not evidence that no benefits exist.
- This problem strikes me as something potentially fixable via a MediaWiki improvement. —David Levy 23:23, 18 December 2011 (UTC)
- Assuming the user follows the file rename criteria, there are no benefits for keeping a redirect. The names are inappropriate for some reason. Given that we are transferring our free images to commons, that will just leave non-free images and a few free images that cannot yet be transfered there. As I stated above, non-free images need to have their redirects deleted because when a file redirect is used, it does not show up in the file usage section on the file description page. Alpha_Quadrant (talk) 22:04, 18 December 2011 (UTC)
- No one has asserted that historical usage automatically precludes a redirect's deletion. But there should be consensus that the harm caused by retaining a redirect (or type of redirect) outweighs the benefits. If a redirect (or type of redirect) causes no significant harm, even a minor benefit is a sufficient reason to retain it. (This is hypothetical. I'm not expressing an opinion regarding the harm:benefit ratio.) —David Levy 21:21, 18 December 2011 (UTC)
- RfD is designed to determine whether or not a redirect meets the redirect guidelines. We do not keep redirects just because it is linked to in a previous page revision. Now if the redirect has useful page history, then in that exception, we would keep it. If we were to keep all pages just because it was linked once, there is very little that we could delete. When we have XfD discussions, no votes "Keep, it was linked to once, so we need to keep the page so that it doesn't show up as a red link if someone looks at an old revision of the page." It isn't a valid reason for keeping a page. For example, this diff from 2005. There are a large number of red links there, that, at the time the edit, were blue links. Wikipedia changes constantly. Red links in old revisions are inevitable. Alpha_Quadrant (talk) 21:02, 18 December 2011 (UTC)
- To the contrary, one reason that we keep these titles (like all other titles) is that their deletion causes problems in article histories. That's a major reason that we have RFD: it exists to get rid of titles that aren't useful, but a title that's been linked in an article is generally useful. The speedy deletion criterion only permits the deletion of new titles, and proposing a solution that will get around this is entirely unacceptable — the criterion may only be ignored in unusual circumstances, so making it easy for deletion policy to be ignored is a very bad idea. Nyttend (talk) 20:45, 18 December 2011 (UTC)
- Comment I am really happy to see that most of opposing are sysops :) that implies that although it might look bothering to them to fix file moves after file movers, they probably don't have problem with that. It seems that proposal was started to spare them of that activity, but maybe it's not necessary. However I still believe that giving this bit to file movers would cause no harm. Petrb (talk) 20:54, 18 December 2011 (UTC)
- Breaking file transclusions is harmful. —David Levy 21:21, 18 December 2011 (UTC)
- Oppose David explains it well; Nyttend brought up points I didn't even think of. Choyoołʼįįhí:Seb az86556 > haneʼ 21:46, 18 December 2011 (UTC)
- Oppose - deleting redirects is often unnecessary and user hostile; adding 'suppressredirect' to filemover would extend deletion privileges to 235 users who have not been vetted for the same. –xenotalk 16:09, 19 December 2011 (UTC)
Ability to delete latest revisions of files
While I'm doing my part to reduce the huge backlog in Category:Non-free images with orphaned versions more than 7 days old, I've several times found images in which an old version, not the current version, is preferable; for example, if the latest version is of substantially higher resolution than an older version. Unfortunately, in such cases I must delete the entire image, rather than just deleting the version, and then I need to restore the older version. If it's possible, I'd like to see the (del/undel) text for the latest revision be just as useful as it is for all older versions. Is it possible? Nyttend (talk) 13:11, 18 December 2011 (UTC)
- For an example of what I'm talking about, look at the logs for File:Beastie Boys - Ch-Check It Out CD cover.jpg. Nyttend (talk) 13:15, 18 December 2011 (UTC)
Coordinated SOPA reaction in early 2012 RfC
It was announced on December 16, 2011 that a floor vote on SOPA is delayed, likely until early 2012. While the threat of this legislation still looms, the brief reprieve gives our community time to reach a meaningful consensus about whether to take action, and what action to take.
Background information
The Stop Online Piracy Act ("SOPA", H.R.3261) is a piece of proposed federal legislation in the United States. The bill would expand the ability of law enforcement and copyright holders to fight online trafficking in copyrighted intellectual property and counterfeit goods. It has seen widespread opposition from all corners of the Internet, and poses a unique threat to Wikipedia's continued operation.
Two proposals for a response from the Wikipedia community have been advanced so far (first proposal, second proposal), but neither was conducted with enough lead-time to reach a meaningful consensus.
Proposal
Here is a proposal that we believe strikes a reasonable compromise, chosen as a moderate sampling of the ideas posted on Wikipedia:SOPA initiative:
- Triggering event: When SOPA has passed committee and is scheduled for a floor vote in either the House or Senate. The banner runs for the week before the vote, and switches to the blackout on the day before.
- Scope: Response is geotargeted to United States IP addresses only
- Duration: Maximum of 7 days for banner component, maximum of 24 hours for blackout component. Blackout is triggered on the business day before the vote. If the vote is on a Monday, blackout runs for 24 hours starting Friday.
- Action (banner): Banners encourage people to contact their Senators and Representatives (priority given to whichever is urgent, House or Senate).
- To the maximum extent possible, readers are given instant information on how they can take action. Campaign is designed to mobilize the public maximally.
- The focus is on generating high-value congressional contacts (phone calls and in-person contacts vs letters or emails)
- A VOIP-based callback system (such as the one used recently by tumblr) is an option if we can find one that fits our needs and allows us to remain acceptably independent.
- Banners operate like the fundraising banners (served via CentralNotice, can be closed per-user, etc).
- Action (blackout): All requests are answered with a black page. The page is semi-protected Wikitext. Once the page is displayed, a cookie is set which prevents its display again. Exact wording to be decided, but it hits the following points:
- SOPA puts Wikipedia, and the rest of the free Internet, at risk
- You can help by contacting your representative and senators (with maximally easy help with ways to do that)
- A "Learn more about SOPA" link which points to the relevant article on the English Wikipedia
- A "Why am I seeing this" link which points to a page detailing the process for reaching this consensus
- A link to click through to the originally requested page
- "You will only see this page once"
This gets the message across clearly, explains how to help, is targeted to people who have the ability to effect change, shows that the protest was a community decision, and doesn't reduce the utility of Wikipedia for readers.
To set this proposal in the context of similar actions in the past, see this summary.
Need
While most of us understand the power that Wikipedia has in this situation and the size of our audience, some are still skeptical that a citizen response can change the course of this legislation. Rep. Zoe Lofgren, member of the House Judiciary Committee addressed this concern on Reddit:
My best assessment is that most members of the House who do not serve on the Judiciary Committee have not yet focused on SOPA. People should realize that incredible power they have to impact the thinking of their own Representative on the subject. For example, a very intelligent colleague who is not on the Committee approached me today asking about the bill. Why? He had received an urgent and forthright telephone call from a small business person in his district who is tremendously opposed. He wanted to know more about our Open Act Alternative. This is the power that each of you have with your own Representative. --Rep. Zoe Lofgren
Critique
The most common critique of this proposal is that it controverts NPOV (the spirit, not the letter which specifically regards article content). This came up often in response to previous proposals, so it's worth addressing directly. We'll try to re-state the objection and respond:
Objection: Presenting unbiased information is one of Wikipedia's most important values. This sort of action demonstrates a clear bias, undermines our integrity, and sets a dangerous precedent with regard to the possibility of future actions.
The encyclopedia should be neutral. Nobody is suggesting that we make biased pages to wreck the careers of politicians who vote the wrong way, or that our page on SOPA itself should be biased. "NPOV is non-negotiable."
However, the project space need not be NPOV, the Foundation need not be NPOV, the community need not be NPOV. There are very good reasons to avoid general political activism that might split the community or cause drama, but that's more about practicality than principles. There are also very good reasons to embrace political activism when the core policies that make the Internet successful are threatened, and when that activism can actually draw our otherwise diverse community into a sense of unity around a cause that we can nearly all support by the nature of being Wikipedians. Such an event is so rare and extraordinary that we can't imagine this sort of protest becoming common practice.
SOPA threatens the very same values that the many well-meaning editors making this argument seek to protect. User:Neilk articulated this in a comment on a previous proposal:
I believe that NPOV is a reason to take a public stance. This proposed law would ensure that some points of view are not represented on Wikipedia. It would be as if the government were removing information from Wikipedia, and then threatening jail time for anyone who dared to revert. It is appropriate for Wikipedia to take a stance on issues that directly threaten our project and our values.
We agree that there is value in staying out of political discussion. It's important that the world perceive Wikipedia to be neutral, and distinctions between content and community are often lost on the uninvolved public. Ultimately, the question we're asking is this: is the potential for harm to Wikipedia's reputation worth enduring to oppose legislation that could threaten its very existence, and undo years of work in creating a free and open Internet? We believe it is.
Personal statements from proposal authors
Ian Baker: While I work for WMF as a developer, this proposal is made by myself as an individual. I am aware that the Foundation officially opposes SOPA, but am in no way representing the Foundation when I write this. I care about Wikipedia deeply, and am therefore very concerned about this bill's imminent passage. raindrift (talk) 00:09, 19 December 2011 (UTC)
Jimbo Wales: I have sought to assist Ian in trying to make this proposal mild and widely acceptable. We do not have a lot of time for debate, as markup is set to begin again on December 21st and this could still make it to the floor of the House quite quickly.--Jimbo Wales (talk) 12:28, 17 December 2011 (UTC)
The above comment signed by Jimbo, was not added here by Jimbo. fredgandt 00:20, 19 December 2011 (UTC)
- Sorry about that. It's from this userspace draft raindrift (talk) 01:10, 19 December 2011 (UTC)
Discussion
- I support this proposal, but I believe that a full-scale, international blackout (à la the Italian Wikipedia) would be more effective.
SOPA stands to affect readers around the world (not merely those in the United States). During the Italian Wikipedia's strike, users in various countries contacted ambassadors of Italy to express their concerns. It would be helpful if the same were to occur with ambassadors of the United States.
I also worry that a one-off message (with the ability to click through to the desired article) would be treated as little more than a nag screen (dismissed and forgotten). As upsetting as it is to deprive readers of the encyclopedia, that might be the only way to get their attention and prompt them to take action. —David Levy 00:45, 19 December 2011 (UTC) - Purely technical issues/concerns Some readers may not have cookies enabled. Session id? Could this cause accessibility problems for some users? fredgandt 00:53, 19 December 2011 (UTC)
- Against First, quite likely several US presidential candidates (to candidates) have different views on this subject. Which candidate(s) will WP support? Second, I do not know anything about SOPA in particular, but I strongly believe that defending intellectual property is extremely important (unless we want to descend into a dark age of search and copy, as creating does not pay for your food and bed) This is highly ridiculous, this is - I thought - a encyclopaedia, not a political platform. - Nabla (talk) 00:55, 19 December 2011 (UTC)
- You acknowledge that you "do not know anything about SOPA in particular". If you were familiar with the bill, perhaps you'd understand why opposing it isn't remotely the same as opposing the defense of intellectual property (just as opposing the USA PATRIOT Act isn't tantamount to supporting terrorism).
Indeed, Wikipedia is an encyclopedia — one based on specific principles. If a politician happens to disagree with said principles, that can't be avoided. —David Levy 01:20, 19 December 2011 (UTC)- I take the criticism - of not knowing - as fair and took a look at our article. Actually I have already seen it sometime. Overall it looks fine. Sites facilitating copyright infringement should be stopped. It supports my guess that this is "the internet at large" being against copyright. That includes WP. WP - as a community, not every member - show little respect for copyright. I once uploaded a few photos, the copyright tags I placed on them were changed several times by some random users a couple times or so. WP also leaves up to community discussion several legal matters (like fair use for images) while we are no court at all. WP has no moral authority at all to protest. Joking a little, this is like a bank robber opposing a law against robbing banks. But all that is my opinion about copyright and its (poor) implementation at WP, subject for a nice calm, or heated, internal discussion. This discussion here is about WP direct and intentional interference in USA politics. First, that is completely against WP purpose, as I see it; Second, the WMF may natuirally do turn WP into a political platform, as they may, and probably have the right to. Me, I am against. - Nabla (talk) 02:01, 19 December 2011 (UTC)
- Thanks for clarifying your position. I was unaware of your bias. —David Levy 02:15, 19 December 2011 (UTC)
- I take the criticism - of not knowing - as fair and took a look at our article. Actually I have already seen it sometime. Overall it looks fine. Sites facilitating copyright infringement should be stopped. It supports my guess that this is "the internet at large" being against copyright. That includes WP. WP - as a community, not every member - show little respect for copyright. I once uploaded a few photos, the copyright tags I placed on them were changed several times by some random users a couple times or so. WP also leaves up to community discussion several legal matters (like fair use for images) while we are no court at all. WP has no moral authority at all to protest. Joking a little, this is like a bank robber opposing a law against robbing banks. But all that is my opinion about copyright and its (poor) implementation at WP, subject for a nice calm, or heated, internal discussion. This discussion here is about WP direct and intentional interference in USA politics. First, that is completely against WP purpose, as I see it; Second, the WMF may natuirally do turn WP into a political platform, as they may, and probably have the right to. Me, I am against. - Nabla (talk) 02:01, 19 December 2011 (UTC)
- You acknowledge that you "do not know anything about SOPA in particular". If you were familiar with the bill, perhaps you'd understand why opposing it isn't remotely the same as opposing the defense of intellectual property (just as opposing the USA PATRIOT Act isn't tantamount to supporting terrorism).
- Oppose Is this not what could be fairly called "a perennial proposal"? It has been knocked back twice already. How many more times do we have to go through this? I emailed Jimbo stating my concerns regarding the hypocrisy of this proposal. It went something like this: For Wikipedia to state loudly that it is against proposed laws that are (from most peoples perspectives) designed to protect copyrights, will be a media nightmare. Who honestly thinks the media at large will stand shoulder to shoulder with us, and sing our praises for doing the right thing? They sell dung; and the stinkier the better. This is delivering it to them in truck loads. Wave buh-bye to our reputation folks! fredgandt 01:24, 19 December 2011 (UTC)
- Firstly, you're referring to two very different proposals, both of which failed for reasons irrelevant to this one. The original RfC (which focused on the general idea instead of specific implementations highly unlike the one proposed above) generated broad support.
Secondly, you seem to suggest that we should worry more about PR than about defending principles that enable Wikipedia's existence. Obviously, I disagree. —David Levy 01:44, 19 December 2011 (UTC)- Irrelevant'? Excuse me for looking bemused O.o. PR matters. If the aim of this proposed fiasco is to protect Wikipedia, consider the harm it might do. This is surgery with a rusty spoon. There are better ways. fredgandt 01:51, 19 December 2011 (UTC)
- 1. Yes, irrelevant. Those proposals failed because they entailed rushing into implementations substantially different from the one proposed above. The general idea received broad support.
2. I didn't say that PR doesn't matter. However, it will cease to matter if Wikipedia fades into history.
Also note that the Italian Wikipedia engaged in a significantly more extreme variant of this protest with positive results.
You say that "there are better ways." What do you suggest? —David Levy 02:15, 19 December 2011 (UTC)- Not responding to the end of the world posturing.
I suggested to Jimbo by email that he use his own clout to raise awareness without dragging Wikipedia through the shit in the process. How ever many readers Wikipedia has each day, it will be nothing compared with the numbers that read the papers and watch the telly. He, without the backing of WMF could easily get any audience he chose, and no one could deny him the right to claim the limelight as creator of Wikipedia (although many try). This is now for certain my last comment on this thread (my last was but I was asked a direct question). Not being dramatic, just said my bit and moving on. fredgandt 03:09, 19 December 2011 (UTC)- I don't believe (and I don't think that Jimbo believes) that he commands such power and influence. He's well known, of course, and he is doing his best to raise awareness of the issue. —David Levy 03:35, 19 December 2011 (UTC)
- Not responding to the end of the world posturing.
- 1. Yes, irrelevant. Those proposals failed because they entailed rushing into implementations substantially different from the one proposed above. The general idea received broad support.
- Irrelevant'? Excuse me for looking bemused O.o. PR matters. If the aim of this proposed fiasco is to protect Wikipedia, consider the harm it might do. This is surgery with a rusty spoon. There are better ways. fredgandt 01:51, 19 December 2011 (UTC)
- Firstly, you're referring to two very different proposals, both of which failed for reasons irrelevant to this one. The original RfC (which focused on the general idea instead of specific implementations highly unlike the one proposed above) generated broad support.
- Support but go further. Blackout all articles about movies made by MPAA members, with no possibility of viewing the article for the 24 hours. Jc3s5h (talk) 01:38, 19 December 2011 (UTC)
- Yeah and then permanently blackout all pages to do with Nazis and terrorists and child abusers and rapists and cheese and frogs... fredgandt 01:41, 19 December 2011 (UTC)
- But I like cheese. --Hobbes Goodyear (talk) 01:59, 19 December 2011 (UTC)
- Support: action could well go further into economic restraints on the utility of Wikipedia to the supporters and groups lobbying in favour of this bill. As an immediate proposal this is worth supporting and putting in place. Fifelfoo (talk) 03:05, 19 December 2011 (UTC)
- Support: Including internationally as described by David Levy at the top. Mark Hurd (talk) 07:20, 19 December 2011 (UTC)
- For the third time, support, though I'm concerned the proposal is not bold enough. A full, almost immediate, complete blackout is in order if we are to generate serious and significant media attention, which is basically the only thing politicians care about. But then that's only my view. I support WMF action against SOPA, though only if not associated with political organizations (e.g. those also associated with other causes than SOPA). CharlieEchoTango (contact) 07:27, 19 December 2011 (UTC)
- One attempt to workshop a stronger proposal exists at Wikipedia:SOPA initiative#Concrete proposal 1 Fifelfoo (talk) 07:36, 19 December 2011 (UTC)
- Strong oppose - Wikipedia should not appear to have political bias. An optimist on the run! 08:19, 19 December 2011 (UTC)
- Support, as Wikipedia is concerned with free access to the web. Thus it's a part of Wikipedia's mission to react on such events. The political bias issues are irrelevant here, as no politics concerned. — Dmitrij D. Czarkoff (talk) 09:25, 19 December 2011 (UTC)
- Strong Oppose - By carrying out these actions Wikipedia will sacrifice its perceived neutrality and the protecttion that it gives. Lose that neutrality and it will be much easier for companies (or people with an agenda) to take legal action as the FIRST step without the bad PR that would create now.Even worse are some of the suggestions above that want to censor Wikipedia - I mean "Blackout all articles about movies made by MPAA members, with no possibility of viewing the article for the 24 hours" and "action could well go further into economic restraints on the utility of Wikipedia to the supporters and groups lobbying in favour of this bill Then goodbye Wikipedia. That is just asking for Wikipedia to be sued or shut downNigel Ish (talk) 11:26, 19 December 2011 (UTC)
- Oppose. As I wrote previously, it is inappropriate for the community to compel any user to edit or not edit to make a political point. It would also set a truly awful precedent, with unknowable consequences. If some threshold of consensus is all it takes to turn Wikipedia into an instrument of politics, then Bill O'Reilly can take over the encyclopedia if 1% of his three million nightly viewers respond to a call to register accounts. Even if nothing like that happened, Wikipedia would be permanently politicized. Every time a controversial piece of media legislation got introduced, it would be "How will Wikipedia respond?" all over the news. Nigel Ish also highlights some upsetting avenues this could open toward liability. And as Nabla says, how far does this go? If it becomes an issue in the U.S. presidential campaign, which candidate do we endorse? Lagrange613 17:50, 19 December 2011 (UTC)
- Strongest possible support - Having read the bill and numerous informed analyses of it, I believe that SOPA threatens the very existence of Wikipedia. This requires decisive action, and requires it urgently. It makes little sense for Wikipedia to refrain from action in order to uphold our apolitical ideals when so doing may well result in the elimination of the site itself. This is an extremely poorly-conceived and constructed piece of legislation, and it demands an unequivocal response. This is not a slippery slope. The Wikipedia community has historically shown great restraint against taking indiscriminate political action, and will continue to do so in the future, regardless of what decision is made here. The is no equivalency between an awareness-raising action regarding a bill that would necessitate universal censorship of Wikipedia and, say, the endorsement of a political candidate. To propose such is an insult to the intelligence and discretion of this community.
- Of the three SOPA-related action proposals thus far put forth, this is by far the best-articulated, and most immediately practicable one. It is respectful of the community, addresses all major the previously-raised objections, and is compatible with NPOV. It also—and I consider this crucial—includes a strong emphasis on creating high-value action on the part of the Wikipedia community and readership. The Tumblr auto-calling system mentioned in the proposal was a massive success, without which SOPA might have sailed through without the scrutiny that it is now receiving, and which it so needed. Without the tumblr action, our community might not even have the opportunity that we now have to draw further attention to this deeply-flawed legislation.
- SOPA threatens the very existence of Wikipedia, not merely in the US, but globally. This proposal was co-authored by Wikipedia's Founder, and is our best chance of stopping this seriously flawed legislation.AaronMuszalski (talk) 19:19, 19 December 2011 (UTC) — AaronMuszalski (talk • contribs) has made few or no other edits outside this topic.
- Strong oppose. As I have said, the statute as presently drafted is inapplicable to Wikipedia. End of story.--Wehwalt (talk) 20:17, 19 December 2011 (UTC)
- Support - I support this because while not being consistent with NPV, SOPA endangers the very idea of open internet sites like wikipedia Cat Cubed (talk) 20:26, 19 December 2011 (UTC)
- Support SOPA will effect the very nature of the internet --Guerillero | My Talk 20:55, 19 December 2011 (UTC)
- Support - I'm not fully understanding arguments against this action due to Wikipedia's perceived neutrality - Wikipedia is indeed not neutral in this situation and needn't behave as such. With lawmakers making comments such as "this worked in China" we, of all those on the web, should certainly be supporting any action that could help prevent this bill from going through in its current state. This is an effective option; take advantage of the opportunity to make an impact. LoriLee (talk) 21:37, 19 December 2011 (UTC)
- Strong support – I've previously opposed taking site-wide action since I had believed that Jimbo's voice in the media alone would be enough. Unfortunately, I don't believe that to be the case any longer. As a result of witnessing the rejection of so many amendments on December 16th, I believe that a stronger message from the WMF and the enwiki community is needed in order to spread awareness of this bill. --Michaeldsuarez (talk) 21:53, 19 December 2011 (UTC)
- Strong support - SOPA poses a direct threat to what Wikipedia stands for. As Vint Cerf wrote in a letter to Lamar Smith, SOPA opens the door to "unprecedented censorship" of the web. When statements like this - including an appeal from 83 of the internet's founders about the dangers of SOPA - fall on deaf ears within Congress, it's time to act. Wikipedia has the power to reach thousands of people, and that kind of power should not be taken lightly or used carelessly. The situation is dire, but there may be hope if Wikipedia contributes to the awareness effort. As representative Zoe Lofgren pointed out, people have a tremendous power to influence legislation, as illustrated by the story of one of her colleagues rethinking his position on SOPA after a phone call from a small business owner in his district. If more representatives hear from their constituents about how counterproductive and dangerous this bill is, maybe the tide will turn. This is a crucial moment in the Internet's history, and I think that Wikipedia should take a stand, because SOPA undermines every value that this community is built on. The neutrality that people are so protective of in this discussion can only thrive in an open internet. The sum of all human knowledge will not thrive in the balkanized internet that will result from SOPA being passed.Nadya lev (talk) 22:01, 19 December 2011 (UTC)
- Oppose as POV and a distraction by "movement groupies" over content creators. We should not restrict content to make a political point (to support or oppose a law). Similar to not censoring. This is censoring the entire site. I'm also concerned that this seems to appeal to people that would rather found a movement than write content. Wales and Gardner should worry about content problems we have (10 years into this thing). This is a distraction. It takes us further down the road of losing the best writers and retaining people that want to use the blank slate as part of some meta-battle. (And if you don't like it or think I'm not AGFing or shouldn't impute motives, tough titties. I would look anyone on this site in the eye and say what I beleive.)TCO (talk) 22:11, 19 December 2011 (UTC)
Reflist should be shown when previewing a section edit
When previewing a section, a presentation of a reflist should show beneath the preview, 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)
Interwiki and domain redirects via URL
Alright, this may sound silly, and may possibly be more appropriate on meta, but I don't use meta, so I'm asking here. I generally use the URL to navigate between wikis, for example if I'm looking at someone's Special:Contributions, I just have to change en.
to fr.
, and there I am. And then, if I need to go to commons.
, I don't need to change .wikipedia.org
, the software automatically translates it to .wikimedia.org
. My "problem" is that it doesn't do the opposite translation. So if I come from the French Wikipedia, e.g. Discussion utilisateur:
, I'm not redirected to User talk:
when I change fr.
to en.
, nor is wikimedia.org
redirected to wikipedia.org
once one changes the prefix. I propose that domain and subdomain redirects be established for all languages, at least to and from (from is already done) .en
for interlanguage, and from .wikimedia.org
to .wikipedia.org
when going from meta or commons to a wikipedia (the opposite is already done). This could also apply for other types of wiki though I'm not familiar with them. Thoughts? P.S. I'm technically incompetent, sorry if there is something preventing this in the software or some kind of technical conflict that I'm not aware of. Regards CharlieEchoTango (contact) 07:01, 19 December 2011 (UTC)
- This sounds similar to something proposed on the wikitech-l mailing list recently. Anomie⚔ 12:24, 19 December 2011 (UTC)
Watch the threads (as opposed to watch the whole page)
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)
Suggest we start a writer's workshop
May I suggest we start a workshop like they have on the French Wikipedia? I don't exactly know how they work, but the idea seems to be that they are pages where novices and experts congregate and discuss things. I know that sounds similar to the Ref Desks, and they are working well, but I mean starting workshops focused on specific goals, not linked merely to existing projects, but encompassing something broader. I think the best starting point would be a writers' workshop, focusing solely on improving the writing standard/ encyclopedic style of articles. The workshop would consist initially of one page, where we would nominate an article to work on, thrash out suggested improvements to the writing, and then post the changes back in the articles. Editing of content would be kept to the barest minimum. If successful, the idea could be expanded. IBE (talk) 13:50, 19 December 2011 (UTC)
- Haven't finished reading the proposal and a firm Support from me. Volunteers and students in a relaxed, easily found (and suggested (linked)) project space somewhere. would be awesome. Perfect way to boost quality, productivity, and retention (by way of encouragement). fredgandt 13:57, 19 December 2011 (UTC)
- Check with WikiProject Guild of Copy Editors. ---— Gadget850 (Ed) talk 13:59, 19 December 2011 (UTC)