Wikipedia:Village pump (proposals)

 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 if your proposal is already taken care of at Perennial proposals.
• Proposed software changes should be filed at Bugzilla. Editors here can help you with this.
• Proposed policy changes belong at Wikipedia:Village pump (policy).
• Proposed new wikis belong at m:Proposals for new projects.

« Archives, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213

Watched counter

The proposal in this box is shelved/withdrawn until the proposal in the next sub-section is resolved. (May be worth reading for background on that proposal, though)
The following discussion has been closed. Please do not modify it.
Wikipedia:PEREN#Create_a_counter_of_people_watching_a_page There are more good editors than vandals. Even if making the counter visible and the 'unwatched pages' page public resulted in massive abuse, editors would quickly remedy the problem by adding unwatched pages to their watchlist. Can an admin tell us how many pages there are on the unwatched list? Reasons for doing this, or why the 'vandalism' objection is invalid: Good editors would overwhelm vandals. Displaying "<5" for 0-4 would make this useless for vandals.[1] If there are still vandal concerns, an adminbot could be set up to ask recently-active editors to "adopt" articles. This would allow editors to find pages that needed "adoption". This would relieve the admins who are taking care of the unwatched list. What other reasons were given against this proposal? It might help if the PEREN page linked to the discussions. Without knowing what was said, the reasoning sounds like "the vandals would make this impossible", which is often a poor objection. –MT 03:50, 19 April 2009 (UTC) The list of unwatched pages is limited to 1000 entries, sorted alphabetically. It is rare that it extends beyond the letter A. Every time it is refreshed, there are a number of editors who dutifully watch hundreds of pages from it, yet every time it is refreshed with a new list. It really is like emptying the Atlantic with a teacup. I think the problem is hugely more widespread than you anticipate. Happy‑melon 09:36, 19 April 2009 (UTC) Not that they don't need watching, but how many of the first 1000 are redirects? Mark Hurd (talk) 11:26, 19 April 2009 (UTC) Given that points 1 and 2 would address the vandal problem, doesn't what you're saying just give us all the more reason to support this proposal based on points 4 and 5? –MT 13:51, 19 April 2009 (UTC) Another possibly 'simple' short-term solution is to provide another special page that lists unwatched pages by order of most recent edit and that can also still be limited to the first 1000. If that overlaps between runs, we'd be clearing the backlog from the more 'important' first. Otherwise we're no worse off. Mark Hurd (talk) 00:12, 20 April 2009 (UTC) Great idea. This would not only eliminate vandalism worries, but would also be extremely useful. This feature is a frequent request, is useful and informative, and aside from vandalism I don't think there are objections. We have the following options: Modify wgAllowPageInfo to display "<5 watchers" Change the list to order by last-edited rather than alphabetical, reduce displayed entries to 100, allow all to see it Change the list to order by least watched, then last-edited, reduce to 100, rename it to "least watched articles", allow all. I would support going directly to 3, but we can do a more gradual roll-out by implementing 1 and 3 (I think these are trivial changes, but perhaps a dev could comment) and then removing 1 when the list starts to shrink. Were there any lurking objections? –MT 00:53, 20 April 2009 (UTC) In the flagged protection and patrolled revisions trial implementation, special:Unreviewedpages, which lists pages that have never been patrolled, will indicate the number of active users watching the page. It's only accessible to reviewers. Cenarium (talk) 01:00, 20 April 2009 (UTC) This seems like its a lot more trouble than its worth. If you really want to help with vandalism, just get rollback and download huggle. I disagree that "Good editors would overwhelm vandals." really deals with the vandalism problem. This sounds like how wars used be fought, where each army would just stand in a line and shoot at the other one, and the bigger one would usually win. It worked, but not particularly well. Saying that fewer than 5 people watch a page still makes it nicer target for vandals, it just doesn't narrow it down quite as much. Since the people watching it might have left the project ages ago, it could still have 3-5 watchers but effectively be 0. Mr.Z-man 01:02, 20 April 2009 (UTC) Countervandalism activity is more than just RC patrol. Somebody needs to watchlist articles to catch the vandalism that the RC patrollers miss -- the majority of my vandalism reverts take place hours to days after the fact. --Carnildo (talk) 01:19, 20 April 2009 (UTC) I wouldn't like vandalism patrol, but I would like to make things much easier for editors and much more demoralizing for vandals. Your objection seems against the weakest part of the proposal. The implementation of #3 is a trivial change to an SQL "ORDER BY". The strongest part is editors being able to adopt unwatched pages. This is strengthened by the possibility of a "least watched last edited" page. Vandalism already targets unwatched pages (just click random and mess up an obscure article), this proposal would allow editors to target this already-vulnerable class of pages. –MT 08:07, 20 April 2009 (UTC) When your database contains several million rows, changes are rarely "trivial." The code for Unwatchedpages doesn't count the number of people watching the page at all right now nor does it use an explicit order, so you would need to add the "ORDER BY" and would also need a "GROUP BY." The other issue is that the list is only updated once every week or so. Given that we get about 11,000 edits per hour on around 6000 distinct pages, "most recently edited" might as well be random as it would be out of date within a few minutes. Based on a quick and dirty estimate using the number of pages in the list right now and how far it gets alphabetically, I would estimate that there's easily 60,000 unwatched pages. At 100 at a time, with updates once a week, it'll take 11 years just to work through all the pages with 0 people watching them, ignoring all the ones that are added in that time. Mr.Z-man 18:41, 21 April 2009 (UTC) I didn't and don't endorse a broken version of a recently-edited page. Given that wgAllowPageInfo doesn't use a field in the page table, I agree that it isn't trivial. It would require adding a field and index to the page table (cf. page_random, page_len, page_touched) that kept track of watchers. What sort of disruption would the addition of this field cause? Consider where unnoticed vandalism mostly occurs. The proposal would put into view these pages (which are highly vulnerable, seldom altered, and recently altered). This would allow editors to have a central place to patrol for vandalism (see Wikipedia_talk:Special:UnwatchedPages#Purpose. It would also allow editors to find pages to watch. There's a great reason Jimbo requested the unwatched pages, and given that that method is too overwhelming, there remains a great reason to implement recent least-watched pages. –MT 23:39, 21 April 2009 (UTC) Adding new tables to the database is relatively simple. Altering existing ones is generally avoided. I believe it requires stopping replication on, altering, then re-enabling each slave server one by one, then switching the master to update that. After updating all the databases, a script would have to be run to populate the new field. The page table on enwiki currently has 16,575,280 rows, and grows constantly. I've no idea how big the watchlist table is. If this is done, it might make such a special page possible (and able to be updated dynamically). The index would also probably have to be on page_latest as well if you want to be able to sort by most recently edited. Mr.Z-man 00:08, 22 April 2009 (UTC) Not forgetting, of course, that while the database master is being updated, the whole wiki goes read-only (unless they do something wierd like setting one of the slaves to be a temporary master, which could work I guess). This is the schema update script, yes? Happy‑melon 17:05, 24 April 2009 (UTC) \ Ah, pages isn't indexed by date. How does recent changes work then? (schema, large image). Perhaps it would be more appropriate to add this sort of field there. This would also involve adding a field, but might be less dramatic. The field would list the number of people watching the page at the time the edit was made, and could be used to generate our desired list. –MT 02:40, 22 April 2009 (UTC) Since RecentChanges would otherwise need to read from about five different tables every time it was requested, it actually stores all its data in its own separate table. Every new elegible edit or action puts a copy of its log into the recentchanges table as well as whichever permanent table it uses, and ever hundredth edit calls a function to clean out rows from the table that are older than the limit (currently 30 days). Happy‑melon 17:08, 24 April 2009 (UTC) Perhaps I should amend the proposal.–MT 19:38, 25 April 2009 (UTC)

A recent changes page for unwatched articles

Vandalism is a problem on all pages, but it is a much larger problem on pages that, on average, have fewer or zero people watching them. One solution to this problem is Wikipedia_talk:Special:UnwatchedPages, which was requested by Jimbo, is accessible only to admins, is updated infrequently, and is therefore very difficult to 'clean out'. Another solution, advocated here, is to modify the recent-changes table in MediaWiki to grab the watcher-count from the watchlist table. We would then be able to create a "recent changes in unwatched articles" page. This page would let editors catch vandalism that would usually have gone unnoticed for long periods of time. It would also encourage editors to expand their watch-lists, and urge editors to contribute to fringe/stub articles that are seeing some recent activity. It would also allow us to finally address one of the WP:PERENs. To get this proposal off the ground, we would need:

1. Interest from editors. Other potential benefits. Perhaps a straw-poll.
2. Critical comments, including reasons why this might not be as useful as stated.
3. Solid estimates of cost - can this be done without locking the site? How long would it be read-only for?
4. Input from a developer. Should one be contacted to check feasibility?

Comments addressing any of these four points are especially welcome. –M^T 19:38, 25 April 2009 (UTC)

Now this is an interesting, and probably feasible, idea. Technically, it could probably be done without a schema-change, and it could be useful to do so; the code in FlaggedRevs, for instance, uses the fact that it has to do a database lookup to be more clever in what it shows: it only 'counts' users who have logged in in the past 60 days, for instance, which is pretty neat. If the servers can take the strain, having that feature available on Recent Changes would be very useful, and avoids the issue of pages apparently being watched because they're on the watchlists of users who last logged in three years ago. Performance-wise, having a rc_watched column in the recentchanges table would massively reduce database load when viewing RecentChanges. Or we could define a few more types in the rc_type field (only ~3 actions defined out of a possible 16 million!), and avoid an explicit schema change, but the devs might find that a bit hackish (I remember there being hiccups over the RevDeleted bitfields). On the other hand, that field then has to be populated on every action.

Procedurally, it sounds like a godsend. Unwatched articles are only dangerous if they're edited; unwatched but untouched articles are no harm to anyone. Happy‑melon 14:39, 27 April 2009 (UTC)

I think 7 days would be the best last-login time, unless someone can give a better figure. Given the rate of revisions vs the rate of access, and the many other fields in recent changes, I don't think that this would do too much damage to performance. And the benefits, as you say, are a godsend. Should we get dev feedback, or try to get a few more comments? –M^T 02:36, 28 April 2009 (UTC)

I guess it should be the latter... –M^T 04:28, 5 May 2009 (UTC)

How might the column increase performance?   M  20:37, 13 May 2009 (UTC)

I have to agree that this is an interesting proposal. During my vandalism patrols i cross infrequently visited articles every now and then which blatant vandalism on them for periods up to (And in some cases over!) a year. While I encounter them irregularly it won't automatically mean there are not a lot of pages vandalised this way - they simply don't show up on anti-vandalism tools often. I also see possibilities for using this page for new page patrol as pages listed might very well be missed non notable or vandalism pages that slipped into forgetfullness.

On a more critical note: How would these articles be patrolled? I can imagine that this category will end up having at least 100.000 articles in them. Even if they are only infrequently edited it will still mean a lot of edits in a day - and how will double / triple / n* checks of the same page be prevented? Likewise, not every actively edited article has to be on a watchlist. Also, some active editors have massive watchlist from new page patrols (I had to remove 600 entries from three weeks patrolling). How can we prevent pages from going unnoticed due to unclean watchlists? Might it be better to filter on pages that have not been edited in say, two months? Excirial ^{(Contact me,Contribs)} 19:51, 15 May 2009 (UTC)

Another way to look at it is as filtering out all 'watched' pages from recent changes - if someone's watching, you don't need to. So right away we're preventing many multi-checks. Overflowing watchlists are a problem, but this new page will catch further edits to infrequently-edited articles. So if you can't track every page on your watchlist, then you shouldn't, and now you wouldn't have to. The other problems you bring up - inevitable double checks, thousands of edits per day - are ones we already face. This proposal can't solve them, but it does reduce them.   M  22:13, 15 May 2009 (UTC)

You could just use variables, like

"Recent Changes on Village pump (proposals): Dragonsshadows, on 09/4/2009"

But it would be a good idea for rollback

Would there be some way of combining it with the recent "whitelist" list of autreviewers? That is, for there to be a list of recent changes to unwatched pages excluding those pages where the last change is by an autoreviewer? That way it would be easy to look for vandalism without checking pages where someone else has already reverted vandalism. That might well solve some of Excirial's concerns about multiple checks of the same recent edit. Grutness...wha? 02:09, 23 June 2009 (UTC)

The list would essentially be a filtered version of the current recent-changes list, so if this idea is possible there, then it is possible with this list. I don't think that this should be handled by the server itself, though I do think that it should expose the autoreviewer or admin status of the last editor, so that scripts could use that information to do what you describe.    M   21:57, 2 July 2009 (UTC)

Recent unwatched changes straw poll

The proposal is to create a recent changes page for unwatched articles to prevent vandalism by modifying the recent-changes table in MediaWiki. (I'd really prefer not to see this one archived, since it would open up several useful features. It would permit Watched counters. A now-ignored bugfix in the watchlist code and the addition of a 'checked' watchlist row would then let you patrol your own watchlist. Adding a public-watchlist preference would then give us a passive form of Flagged revisions.) Though this is a software feature request, support from editors would help.

• Support. –M^T 04:28, 5 May 2009 (UTC)
• Support. -- John Broughton (♫♫) 18:24, 9 May 2009 (UTC)
• Support sounds good to me. It does provide a route for vandals to find unwatched articles, but I think the benefits outweigh that. Rd232 ^talk 18:34, 9 May 2009 (UTC)
  • While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. –M^T 19:46, 10 May 2009 (UTC)
• Support. Mark Hurd (talk) 15:05, 10 May 2009 (UTC)
• Comment - Just file a bug. If its a good idea and technically feasible, someone will do it. The existence of a straw poll will likely have no effect. Mr.Z-man 15:26, 10 May 2009 (UTC)
  • Isn't a bug with a supportive straw poll more likely to be implemented soon than the same bug without? Rd232 ^talk 19:35, 10 May 2009 (UTC)
  • When people voice their support for a proposal, others become more inclined to try to see it implemented. This may include filing a bug report, searching documentation, speaking with devs directly, changing the relevant code, and submitting a patch. "Well, someone else will get to it eventually" is not the approach that we should take at this page. Even if the devs were entirely blind to community requests, your support would nevertheless encourage other editors (like me) to try to see this implemented. –M^T 19:46, 10 May 2009 (UTC)
    • With this specific proposal, it may, but only because the schema change would need approval from Brion. With the amount of work required to do this, I doubt a little straw poll is going to have a significant effect on any developer's motivation. Mr.Z-man 18:58, 13 May 2009 (UTC)
      • Then let's hope that it grows to become a much bigger straw poll :) as this might demonstrate a need for better tracking of unwatched pages   M  20:29, 13 May 2009 (UTC)
• Support - I really like this idea. I know from personal experience that non-obvious vandalism on poorly watched pages can go undetected... I have a couple such pages on my watch list & when I took a month off, I cam back to find some vandalism on one of them that had been sitting for 2+ weeks. --ThaddeusB (talk) 18:34, 13 May 2009 (UTC)
• Support - Great idea. Kevin Baas^talk 20:34, 13 May 2009 (UTC)
• Strong support: The admins can't do this alone. I love the idea. Dendodge _T\^C 20:38, 13 May 2009 (UTC)
• Bug 18790 has been created. Suggesting improvements (or establishing that there is a clear need for this) here is what will help with implementation, though voting at bugzilla in addition to here should help make it more noticed. At bugzilla, only 55 wp enhancements have 10+ votes, 19 have 20+, and 8 have 30+, out of over 1300. Registration is easy, and the vote link is at the bottom-right of the bug page, under 'related actions'. (Please use this feature to vote instead of leaving a comment at bugzilla, as comments are relayed to mailinglists).   M  22:31, 13 May 2009 (UTC)
• Support - Makes a lot of sense and fills a great need. J04n(talk page) 09:58, 22 May 2009 (UTC)
• Support - If this can be done without overloading the system, then by all means please do. (Every little bit helps in targeting vandalism.) --Ckatz^chat_spy 17:18, 26 May 2009 (UTC)
• Support per above proposal --unsigned by Assasin Joe
• Support per all the other comments that I read. This would be very useful to find vandalism in more hidden pages. –Drilnoth (T • C • L) 17:02, 27 May 2009 (UTC) See my comment below. –Drilnoth (T • C • L) 15:46, 14 August 2009 (UTC) Support per my original comment. –Drilnoth (T • C • L) 19:46, 14 August 2009 (UTC)
• Support – Wow, this is a really good idea. As long as it can be configured in software, I think it would be very useful. American Eagle (talk) 06:36, 31 May 2009 (UTC)
• Support If implementable, it's an ingenious solution to the problem of vandalism to unwatched pages. --Cybercobra (talk) 08:52, 31 May 2009 (UTC)
• Support only for admin, oppose otherwise - It would be simple enough for a vandal to watch a page, and then it would fall off of everyone's radar. That would turn a good thing into a very bad one. ▫ JohnnyMrNinja 06:57, 5 June 2009 (UTC)
  • Restricting the page to admins is one solution, but I don't think that there's a problem. We would count only autoconfirmed watchers active in the past 7 (or 60) days, and the implementation would also give us recent-changes for pages with 1 watcher, or under 5 watchers, and so on. The sort of coordinated vandalism to 'get around' this is rather visible and is more difficult to deal with if we keep the pages admin-only.    M   01:14, 6 June 2009 (UTC)
    • Isn't that going to be a gigantic strain on the servers? Right now, our watchlists are the biggest strain (right?), so wouldn't a watchlist that watches thousands of pages that are selected from every page on EN based on a series of checks on each page and every user that watches any pages at all... Wouldn't that slow our WP down to the barest crawl? Even if the list of articles matching the criteria were only updated every other day or so, a watchlist that big is a massive beast. Of course you could limit the number of pages that show up, but it would still check the entire list for the 100 most recent changes (right?). I'm certainly no expert on how Mediawiki works, so maybe I'm wrong. Limiting it to admins is a better solution, I would think, if even that is feasible. If it's between having an even-more unstable connection to WM projects or having the fact that Franklin Township, Wright County, Minnesota is referred to as a "gaylord" for two weeks, I'm okay with the latter. But, again, maybe I'm mistaken about the strain. ▫ JohnnyMrNinja 09:12, 10 June 2009 (UTC)
      • No - actually, it might speed things up. The proposal is not to put every unwatched page onto a global watchlist, but to record the watcher count in the recent changes table. This is extremely fast compared to a global watchlis, and is fast in general (see Bug 18790). If the page causes people to reduce their overburdened watchlists (which it should), it may actually increase performance.    M   00:27, 11 June 2009 (UTC)
        • If that's the case then it could be workable, and it is a good idea. With the inclusion requirements you've specified, the list would actually pick up far more pages than the regular unwatched pages list. But I must stress that launching it for everybody is a bad idea, because if something goes wrong and it is deactivated, we will have provided a complete list of un-and-hardly-watched pages, and then removed our ability to protect them. I am not a fan of segregating access normally, but I still feel that it should only be accessed by admin (maybe rollbackers?) until such time that it shown to not contain bugs and we decide we're going to keep it permanently. The only thing you need to be Autoconfirmed is to not have been blocked yet. ▫ JohnnyMrNinja 02:25, 11 June 2009 (UTC)
          • Right, it wouldn't be the same, though this means it would pick up more unwatched pages and not false positives. It wouldn't be a complete list, since it would only record edits made in that short period of time (no doubt those articles would be gobbled up into watchlists by our editors). I do think that these points deserve attention, but it might be early to decide how we want to deploy the feature.    M   18:29, 16 June 2009 (UTC)
            • A few comments. This almost certainly won't speed anything up. Watchlists are not the biggest strain and the slow part of watchlist generation is generating the HTML, not the 1 database query to get the list. You're calculating something that's not currently calculated and not removing anything else. You say in one comment that people would "reduce their overburdened watchlists" then in another that pages would be "gobbled up into watchlists by our editors." That can only affect performance in one way. The question is just will the extra calculation on every edit be fast enough to be usable. Blocking a user does not remove the autconfirm right. A blocked, autoconfirmed user could still do anything that requires autoconfirmed, as long as it doesn't also require editing rights. Even if they're blocked before becoming autoconfirmed, their account doesn't stop aging, and most blocked users can still edit their talk page; so they could even become autoconfirmed while blocked. Mr.Z-man 20:36, 16 June 2009 (UTC)
              • A reduction in the size of watchlists and perhaps the need to check them might reduce some of the burden. It's not important whether it will or not, just that it definitely won't bog down the server. In the long term, this will allow editors to reduce their watchlists. In the short term, editors will tend to add these articles to their lists until they see that it's unnecessary. If something went wrong, which is entirely unlikely, we'd have no problems watching the small list of recent unwatched articles. Dedicated vandals will always get through to some extent, but checking for autoconfirmed is something cheap, relatively accurate, and effective for the majority of cases.    M   00:23, 22 June 2009 (UTC)
                • Restricting it to autoconfirmed would be trivially simple to bypass. Vandals wouldn't even need to create new sleeper accounts to see the list, they could just use existing, blocked ones. If you're not concerned with dedicated vandals, then it shouldn't be restricted at all, as only dedicated vandals would likely even take the time to check such a list. Mr.Z-man 03:28, 22 June 2009 (UTC)
                  • Misunderstanding, I think. It's safe to let everyone see it; I think the concern was a vandal registering 5 accounts, watchlisting many articles, and then vandalizing them. Autoconfirmed would be for whether the editors are counted as watchers, which makes this strategy not worth the effort.    M   08:11, 26 June 2009 (UTC)
• Support the unwatched list it too big to do anything useful with by admins. Perhaps proven vandal fighters would get blocks of these unwatched pages to add to their watchlists. Talk to me if you are interested in this idea. The article names could be emailed to those who want to change them to watched articles. Graeme Bartlett (talk) 02:16, 6 June 2009 (UTC)
• Support Sounds like a good idea. Dream Focus 09:35, 6 June 2009 (UTC)
• Support Graeme two posts up says it well. Casliber (talk · contribs) 05:29, 25 June 2009 (UTC)
• Yep, definitely a good idea. –Juliancolton | ^Talk 22:07, 2 July 2009 (UTC)
• Support Very useful idea. It will increase the efficiency of the list. In my opinion, I would not mind if I had a list of pages to watch on top of my current list. It is all going for the same cause in the end anyways. -- Dspradau → talk  14:45, 6 July 2009 (UTC)
• Support, a very good idea. 'Nuff said. Jamie^☆S93 21:41, 9 July 2009 (UTC)
• Support, with considerations. It should only go ahead if it is known with certainty to not cause added strain to the servers, as well, I think one of the suggestions above should be seconded: make it admin only for a test period, before opening it up for everyone to use, just as a precaution. (I know, I'm hardly here, but, at least I'm hardly here over a long period of time *grin*, which should let me have some say). kaVri 19:28, 12 July 2009 (UTC)
• Support - This feature would increase average article quality on Wikipedia by combating vandalism on unwatched pages. One could see it as a complement to Flagged Revisions. EconomistBR 20:56, 15 July 2009 (UTC)
  • I've heard stories about something called "flagged revisions", but I think those are just ghost tales that old editors tell each other around the campfire. They'll be implemented soon is the punchline to all the jokes. There was something about them appearing when Brion Vibber got back from his honeymoon, but he seems to be back now... Delicious carbuncle (talk) 21:54, 15 July 2009 (UTC)
  • Though I don't think that flagged revisions are as useful as they seem (I'd prefer a per-person way of tracking articles and not revisions, which is somewhat easy to implement using the watchlist), I agree that the two would work well together. Similarly, if we turned on the 'how many people are watching this page' feature, those interested in watching the unwatched pages would be able to tell if they are already watched.    M   21:05, 20 July 2009 (UTC)
• Oppose, this will just make things worse, giving the vandals a potential hit list they can use. ViperSnake151  Talk  13:33, 24 July 2009 (UTC)
  • You might be misunderstanding the proposal. While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. It's safe to leave cheese out when there's a lethal spring-loaded bar attached - which is exactly what this list is.    M   17:44, 31 July 2009 (UTC)
• Support – definitely. This is a good way to revert vandalism. —MC10|Sign here! 02:34, 25 July 2009 (UTC)
• Nuclear support. This is a brilliant idea. In the past I've randomly picked some unwatched pages to put on my watchlist, but they were never edited that I saw, and I removed them as a futile addition. One caveat, though. Are we only looking at pages that show up on zero watchlists, or will this include, for example, pages only watched by people who are long gone? Come to think of it, where we have permablocked vandals and the like, can we strip them of their watchlists and prevent them from watching articles (given that they would only have nefarious reasons to be watching anything)? Cheers! bd2412 T 19:28, 31 July 2009 (UTC)
  • It marks the recent-changes entry with how many recently-active & autoconfirmed editors were watching at the time of the edit. This ignores long-gone editors, and the 'watch pages to hide them' vandal tactic is painfully time-consuming (so watchlist-stripping is not needed). Yes, we would be able to filter recent-changes to pages with 0, <5, or >500 watchers.    M   19:52, 31 July 2009 (UTC)
• Support Ben MacDui 15:42, 1 August 2009 (UTC)
• Support Far better to match the system to the content, not vice versa: there have been calls to raise the BLP notability bar to cut down on content needing to be watched. Esowteric+Talk
• Support - great idea. --[midnight comet] [talk] 18:24, 3 August 2009 (UTC)
• Support - makes life easier. Kayau Wuthering Heights VANITY FAIR paradise lost 08:17, 4 August 2009 (UTC)
• Support-It seems like a great idea. However, there must be hundreds of thousands of unwatched articles. Perhaps we should start off with admin's first. In addition, there really should be a limit as to how many a person could see.(I see no reason to have a public list of 150,000+ unwatched articles as this invites vandalism).Smallman12q (talk) 19:28, 4 August 2009 (UTC)
  • The list pretty much only displays recently-edited unwatched pages, rather than all unwatched pages. It would slowly grow until pages started falling off the end. You're probably right about the title - we shouldn't have a page called 'here are our unwatched pages' (which isn't true anyway, since we'd watch them using this list). It should probably be just another option in the recent changes list.    M   02:05, 5 August 2009 (UTC)
• Support. What a great idea. To the editor who said it should only be admins, I can understand, but suspect that more help will be needed than just sysops. What about making it availible to those who have had rollback without incident for six months or a year? Unschool 02:17, 10 August 2009 (UTC)
• Support Couldn't hurt anything, and might wind up being useful. causa sui× 04:43, 13 August 2009 (UTC)
• Support I can't see it doing any harm to try this, at the very least. Sophus Bie ^(talk) 03:13, 14 August 2009 (UTC)
• Neutral. Would certainly be useful but... vandals can watch pages to. A vandal who is smart enough to use that list to find pages which aren't watched would probably be smart enough to watch the page after vandalising it. :/ I know, WP:BEANS, but I think that it needs to be mentioned. One option would be to limit it to a trusted group like rollbackers. –Drilnoth (T • C • L) 15:46, 14 August 2009 (UTC) Switched back to support, above. –Drilnoth (T • C • L) 19:46, 14 August 2009 (UTC)
• Support. I do not quite understand this technical jargon (please do not waste time trying to explain to me), but if the only way the server load can be tested, is to be implemented, I support. All critics seem to have been silenced by M's rebuttals. Lumenos (talk) 04:44, 15 August 2009 (UTC)
• Support. Sounds like a good idea. I just hope it doesn't backfire because of unforeseen circumstances. Maybe it should be tested first in a trial run for admins only. -- œ^™ 20:18, 15 August 2009 (UTC)
• Comment This seems to have broad support, and a bug was filed. Should the poll be closed? --Cybercobra (talk) 03:45, 18 August 2009 (UTC)
  • 34 support, 1 Oppose as of your comment, so the support is strong, yes :) It's still not clear though if this is something the community sees as not just a good idea, but something that's really needed (per my 13 May comment above). Many editors are also giving a lot of informative feedback (eg the 'rollbackers only' points) and ideas, without this generating 'drama'. I think it will die down soon enough anyway...    M   02:21, 19 August 2009 (UTC)
• String support provided access to it is limited to trusted users (perhaps admins and rollbackers?). עוד מישהו Od Mishehu 08:38, 18 August 2009 (UTC)
• Support Brilliant idea ! Mr.TrustWorthy----Talk to Me! 17:19, 18 August 2009 (UTC)
• Support GeometryGirl (talk) 11:01, 19 August 2009 (UTC)
• Support ----occono (talk) 17:06, 23 August 2009 (UTC)
• Yep, would be good. I suggest that only rollbackers and sysops be able to see it. Pmlineditor  Talk 12:10, 30 August 2009 (UTC)

Remove the sandbox functionality from the intro page

I am talking about Wikipedia:Introduction, a page that welcomes our new users. The page has sandbox functionality, in other words, the users are free to make test edits there as long as the intro template stays untouched. Too bad it doesn't, and new editors may be greeted by something along the lines of "lol wikipedia is teh suxx0rz haxd" or "Get stuff online www.fakesite.com". This is mostly incompetence and misunderstanding the purpose of the page instead of actual vandalism, but to ensure that the page looks the way it's supposed to when a new user views it, I suggest we remove the sandbox functionality from this page altogether. Obviously, it's good to have a sandbox page for our newcomers, so I suggest editing our current sandbox template to point forward to Wikipedia:Introduction_2 (titled "Learn more about editing") so new editors wouldn't have to look for the next page of the introduction OR creating a new sandbox page between the first and the second introduction page. Any support, comments, suggestions? Kotiwalo (talk) 19:03, 19 August 2009 (UTC)

I would vehemently oppose such a change. It's really helpful, in my opinion, to be as encouraging and as forthwith as possible with readers and editors alike when they reach Wikipedia. If anything, the links to WP:Introduction should be more prominent on the Main Page. The more links someone has to follow, the less likely she or he is to actually follow them. Yeah there's vandalism there, but the vast majority of it is really just people flexing their wikimuscles and testing their boundaries. Besides, unlike most other areas, it's not really harming anyone greatly. Screwing with a sandbox makes it worse for the next guy, but it's not exactly libelous. ~ Amory (user • talk • contribs) 01:43, 20 August 2009 (UTC)

Yes, screwing with a sandbox wouldn't be a big deal, but it's also our introduction page, and since many new editors have wiped out the welcome template, either accidentally or intentionally, there is a good chance of our new editors being greeted by profanity or other not especially "welcoming" content. It wouldn't matter as much if there was a way to ensure that the welcoming template wouldn't be deleted, accidentally or in bad faith. Kotiwalo (talk) 09:53, 20 August 2009 (UTC)

Why not add something like the sandbox header, so that the page would get refreshed with the proper content every 12 hours? Warrior4321 22:00, 20 August 2009 (UTC)

There is one on the intro page I guess, but it would have to be cleaned after every single edit to ensure that the template stays intact, and that would take away the entire point of the sandbox. Separate page would be better. Kotiwalo (talk) 05:41, 21 August 2009 (UTC)

Is there anyway you can divide the page so one part(or section) can be semi-protected and the other part gets cleared every 12 hours? Warrior4321 17:47, 21 August 2009 (UTC)

I'm very sure that there's a way but I'm also rather sure that it won't be too quick an' easy. Kotiwalo (talk) 18:23, 21 August 2009 (UTC)

Perhaps creating a page with the introduction on another page (like the sandbox header), and then transcluding it into there? We can place a invisible comment right beside the transclude, telling them to leave it alone? That would provide new users who are not sure where to edit much more room. Warrior4321 19:22, 21 August 2009 (UTC)

Actually the intro page has the following:
{{Please leave this line alone}}
<!-- Feel free to change the text below this line. No profanity, please. -->
Sadly, this doesn't always work. Kotiwalo (talk) 08:11, 22 August 2009 (UTC)

(outdent)I have recently been watching the introduction page. No idea how that started, but I regularily check out the new user contributions and revert offensive or immature edits. It has begun to irk me that the message we use to greet newcomers is routinely vandalised into absolute nonsense. Wikipedia is not the place to read about ketchup farts, or at least a main page isn't.

I wish to propose that the page for editing WP:Introduction redirect to the page for editing WP:Sandbox. This way, new users can read the introduction, still click edit, and edit the sandbox instead of defacing the message that they just read. WP:Introduction could then be protected from editing. - ʄɭoʏɗiaɲ ^τ _¢ 14:01, 22 August 2009 (UTC)

I really like that idea! Any idea, how we could edit the edit button? Warrior4321 19:11, 22 August 2009 (UTC)

Why not make it work the way {{doc}} works on protected templates (via transclusion of the sandbox -- in this case -- onto the protected intro page). That way the message stays intact, and you can have a special edit link right there (though the "edit this page" tab won't work right, unfortunately). Maybe have Cluebot and/or its friends lightly patrol the sandbox for profanity to stop that. --Thinboy00 @117, i.e. 01:48, 29 August 2009 (UTC)

Proposal: Have a bot autodelete any stub article of less than 250bytes if not edited in X months

Per WP:REDLINK and WP:STUB, I think there should be a balance between creating an article of one or two sentences and allowing an unimproved micro stub to exist indefinitely. My view is that a redlink is as much or more an incentive to research and create an article as is a stub to expand, but that a minimal stub detracts from the impression of the encyclopedia as a serious enterprise. As I am aware that many editors do create a very short stub as a type of placeholder and then they (or a project) begin expanding them I would think there should be a generous allowance to permit them - or others - to work upon them to bring them up to article status.
Per WP:Stub Wikipedia is not a directory and it would be difficult to argue that a one or two sentence page would not fall into that definition - except perhaps place names; "X" is a small village in Y province/state of country Z", and discussion might suggest particular stub types that might be exempt from the cull. Also suggestions regarding time frames may be beneficial, especially with input from those who can provide analysis on the likelihood of expansion on stubs over time from creation.
I look forward to comments. LessHeard vanU (talk) 14:01, 21 August 2009 (UTC)

I'd oppose your proposed exemption: to my mind, a bot that went through and automatically deleted orphan stubs should be specifically targeted at the efforts to convert Wikipedia into an atlas. A bot-created stub about a remote yak-herding village that has only been edited by bots since its creation is a perfect target for deletion. If someone wanted to write a more customized bot that automatically created "list of settlements in so-an-so" based on the geographic coordinates in those stubs, I wouldn't object to that as an alternative to outright deletion.—Kww(talk) 14:06, 21 August 2009 (UTC)

This has the same problem as people using bots (scripts) to create stubs - no human oversight as to what is happening. 250 bytes, while it may sound reasonable, is an arbitrary cutoff - and unfortunately any cutoff would be rather arbitrary. There is no way to ensure that the content being deleted should be deleted. The idea of removing data to encourage the addition of data strikes me as being somewhat backward. While I can safely say that I would (probably) support the deletion of most individual sub-stub articles of this size, I am uncomfortable with turning a bot loose to do the work on its own. Shereth 14:08, 21 August 2009 (UTC)

We should not be deleting articles until a person has at least looked at it. An article being short and not edited often is not criteria for deletion. Chillum 14:09, 21 August 2009 (UTC)

Add in a view counter parameter? I am suggesting 250byte (but am open to variance based on experience) as a really small size which unlikely be more than a directory type stub, but if it is being viewed regularly then there is evidence of worth. In a general response to comments so far, deletion is not judgement or permanent; if something that should be there gets removed then it will be recreated and hopefully for the better. LessHeard vanU (talk) 14:28, 21 August 2009 (UTC)

I suppose you could tack on numerous "parameters" for the bot to go on. Has it had more than 1 non-minor edit? Does it have X number of views? No edits since X? Only edited by bots? Only X bytes long? Inbound links? A lot of these would help ease my concerns, but the major stumbling block to me is that it's all run by bot. I am extremely hesitant about bots being involved in the creation or deletion of articles, for ultimately the inclusion criteria can only be judged by a human, not a machine. Now, I could see a bot placing them in a CSD-like "stubs eligible for deletion" category that could be reviewed by actual humans who could make the final call on whether it should be deleted, but then we're creating an awful lot of work ... Shereth 14:35, 21 August 2009 (UTC)

Add in a two-week notification to the creator of the article before the deletion, and that seems to be good (Make sure this is well-advertized with an opt-out - I don't thikn some bot operations want to see 1000s of the same messages). --MASEM (t) 14:10, 21 August 2009 (UTC)

I would oppose this, per Shereth. Arbitrary cutoffs are bad. For example:

[[File:JohnSmith.jpg|thumb|John Smith]] '''John Smith''' was a sixteenth century English author. While he wrote several collections of poetry, including [[Collection1]], he's most famous for his plays, mainly [[His famous comedy]]. {{author-stub}}

is only 247 bytes, yet it includes an image, links to other relevant articles, and contains key background information. However, one could write an article that consists of nothing but a well-filled infobox and a stub tag, and have it be well more than 250 bytes. If an article goes several months with no edits, I think its rather unlikely that a well-researched full article is on the horizon, and the only thing that's preventing it is the stub. My guess is that we would just end up with a redlink for another several months or years, and rather than providing what little information we can, we provide none. Mr.Z-man 14:33, 21 August 2009 (UTC)

• Perhaps someone could do some data-gen to give us some examples of the articles that would be caught by LHvU's proposed net? –xeno^talk 14:36, 21 August 2009 (UTC)

• I would oppose this. Being short and stable is not any kind of criteria for deletion. DuncanHill (talk) 14:48, 21 August 2009 (UTC)

• Why not have the bot just prod all the articles, rather than delete? Of course, this would create a tremendous backlog of prods if done all at once, so perhaps this could be run at a limited rate, or something like that. Cool3 (talk) 14:57, 21 August 2009 (UTC)

I had thought of that, too, and was worried about the backlog - I hadn't considered throttling the reporting bot. Shereth 15:01, 21 August 2009 (UTC)

• Oppose. we are not on a timetable to finish the encyclopedia. If stubs are notable, they can linger as long as it requires for an interested editor to come along and improve the article. With the current "completness" of the encyclopedia, it will require longer and longer for stubs to develop, but that is no reason to delete them. See also Duncan Hill's comment. —TheDJ (talk • contribs) 15:04, 21 August 2009 (UTC)

  I would support such a bot adding articles to a category for human review. Chillum 15:07, 21 August 2009 (UTC)

• The main question is, is there consensus to delete any kind of substub even if the topic passes WP:N & friends? If so, of which kind? I for one wouldn't mind seeing all "Foo is a Bar" type substubs gone, in particular if we already have a "List of Bars" article.
  My biggest problem with stubs is when they are so short that they have to be considered wrong, which can usually only happen with (quasi-)bot-created stubs (e.g. Philipp von Bismarck, Otto Fürst von Bismarck (CDU), Karl-Heinz Daehre, Mario Czaja, Karl Eduard Claussen, Christine Clauß, Paul de Chapeaurouge, Rudolf Böhmler, which all omit the most defining points of those people). With the current proposal at WP:VPP that should hopefully happen less frequently for any newly created stubs. Question remains how to identify all the existing substubs that fall into that category, be it for improvement or deletion. By default I'd think that they will always need human eyes on them, but as xeno said, a examplary selection of substubs generated by whatever filters would be enlightening.Amalthea 15:36, 21 August 2009 (UTC)
• Yes, size isn't a deletion criterion. The best treatment of a permanently short article might be to merge it, move it to wiktionary. etc., but these are operations for a human. No harm though in having bots generate lists of articles based on any criteria people find useful (but of course there's no need to add tags or categories to the actual articles - that just floods the changes lists unnecessarily).--Kotniski (talk) 16:04, 21 August 2009 (UTC)
• I also disagree with this proposal, it would have the potential to catch articles such as this one where there was content but only in a template thus making the article shorter than it actually was by byte size. I am aware this would be ok due to the article being edited within a reasonable time scale but I fear other similar articles could be caught. More basically I disagree with the premise as very short articles can be expanded by anyone, while new articles can only be created by registered users. If the articles have enough context to avoid meeting the speedy criteria and have potential to be expanded they should not be deleted or merged out of existence. Some verified information is better than no information. Davewild (talk) 18:53, 21 August 2009 (UTC)
  • Well, I don't find the last part true. Take Paul de Chapeaurouge, for example, which I mentioned before: The only verifiable (not verified!) information we have on him is that he was "a representative of the CDU" – which is basically a footnote in his biography, he joined them when he was 70, and all the time he was a founding member of a different party. Substubs like this, generated from a list, often leave out the important parts, but make it appear as if they presented the high points. Having no article would be preferable here, since the only verifiable information we have would have turned up in a search anyway, by way of the list. Amalthea 19:41, 21 August 2009 (UTC)
    • Having the article in the case you have raised does have a good purpose as it provides an easy link to the German wikipedia article which can be used for expansion of the article, which is more likely to happen now that link is there than from a list. Pointing the reader, as well as potential editors of the article, towards such a more substantial article in another language is not a bad thing. It also would not be even close to coming under this proposal anyway as it has over 500 bytes so I question whether this proposal would even achieve the aim that it's proponents would want. Davewild (talk) 19:57, 21 August 2009 (UTC)
      • The criteria are in a state of flux, of course. :)
        I'm not sure our typical reader will even notice the interwiki link and, again, this substub conveys an incorrect picture of that person. If a reader goes away with the impression that the most notable feature of him was what's in the article then we have done him a disservice. And of course, there's for example Sabine Christiansen where I'm pretty sure the interwiki link is complete bogus as well. Amalthea 20:22, 21 August 2009 (UTC)
• Oppose The age of the stub article is not relevant. It could develop into something better one day. And even a stub for a Wikipedia valid topic, is better than nothing at all. Dream Focus 19:48, 21 August 2009 (UTC)
  • Well, I would refer you to the (random!) example I've just presented directly above. Amalthea 19:52, 21 August 2009 (UTC)
    • Which would not even come under this proposal anyway as I point out above. Davewild (talk) 19:59, 21 August 2009 (UTC)
• Oppose for the reasons already mentioned.--Cube lurker (talk) 20:01, 21 August 2009 (UTC)
• Oppose as nobody is more encouraged by a red link. On the contrary, starting an article from absolute scratch is a more daunting task for the unprofessional editor then making edits to an article that has already passed the deletionists of wikipedia (New page patrol). Further to this, there is nothing gained from deleting these articles. There is only loss of information. Just because someone has it subjectively in their mind that this information is irrelevant, does not mean that it is irrelevant. - ʄɭoʏɗiaɲ ^τ _¢ 15:10, 22 August 2009 (UTC)
• Oppose Having a stub is better than nothing at all, and having half of the picture is better than having no idea at all who a person is. If information/pictures/interwiki links are incorrect, that has nothing to do with the article being a stub. Anything incorrect should be fixed. hmwitht 14:37, 23 August 2009 (UTC)
• Oppose Look at any paper encyclopedia and you will find lots of articles shorter than 250 characters. Stubs are fine. Sometimes I just want to know what something is. I also question the premise that redlinks are more likely to be expanded. Stubs allow IP users to expand. --Apoc2400 (talk) 15:41, 26 August 2009 (UTC)
  • Accius is a good example. It is 300 bytes, but that is due to lots of markup. John Vandenberg ^(chat) 12:57, 1 September 2009 (UTC)

Have the bot list such stubs for review and possible prodding/deletion/merger, etc

Well, it appears that there is a large sentiment for "something is better than nothing" - even if it triggers WP:NOTDIR, so perhaps it would be best that any initial run bot would simply list these stubs and a taskforce could go through and remove the real junk (once tagged by the bot it would whitelist any stub not deleted). Any subsequent bot runs could PROD an article under the criteria, and again allow flesh and blood operators make the decision. I would comment that this is not attempting to "finish up the encyclopedia" but to remove content that is no longer up to standard - much like some old FA's lose the status - and improve the overall quality of the project. I would, of course, sign up for such a review body in the first instance. LessHeard vanU (talk) 20:11, 21 August 2009 (UTC)

^^^ The first part of this is a "just do it" solution, no one can stop someone from compiling such a list. I would suggest the eminently helpful MZMcBride, he's great with this kind of thing. Maybe ask at WT:DBR. –xeno^talk 20:14, 21 August 2009 (UTC)

This seems to be an eminently good idea. Something vaguely similar was recently done with bilateral relations articles (a group of people went through a list of them all trying to weed out the junk) with what seemed to be fairly good results to most folks. Perhaps forming some sort of project/group/taskforce/etc. to help carry out the process wouldn't be a bad idea, and of course as it could become a standing group of sorts as new articles would enter the list over time. Cool3 (talk) 20:29, 21 August 2009 (UTC)

We already marks stubs for reviewing, via the {{stub}} templates that we put on them. The issue is not lack of marking, it's lack of volunteer time to review tens of thousands of articles. — Carl (CBM · talk) 20:32, 21 August 2009 (UTC)

This tool may help with this effort. -- œ^™ 04:28, 22 August 2009 (UTC)

• I have (had) generated a list of articles of below 250byte that has not been edited in 12 months, tools:~mzmcbride/lessheard.txt - there are 1500+ of them. A brief review indicates that some like "List of" are likely useful - but the number that uses an underscore ("_") in the title indicates that it is unlikely to be found as a search item: there may even be another better titled article on the subject. There are obvious candidates for a BLP review, too. Oh, well, I have my bot list, and something for me to do that doesn't involve being droll at the drama boards... Anyone wanting to take a punt at reviewing/prodding/deleting/redirecting/merging is welcome. If there are more than a couple we might even have to organise a small project. LessHeard vanU (talk) 16:45, 22 August 2009 (UTC)
  • An underscore and a space are equivalent: Life_Will_Be_the_Death_of_Me = Life Will Be the Death of Me. Amalthea 17:10, 22 August 2009 (UTC)

**I am happy to try and expand some of these articles. It would be a good idea to move the list onto wikipedia, where notes can be placed against entries where action is taken or which are quite appropriate to be kept short such as the disambiguation pages on the list. Davewild (talk) 18:01, 22 August 2009 (UTC)

• • • I see the list is on wiki already at User:LessHeard vanU/Mini stubs. Davewild (talk) 18:23, 22 August 2009 (UTC)
      • I am being ruthless, so if anyone sees a redlink and think they can find sufficient info to turn it into either a small article or a good stub (and don't have sysop flags) let me know and I will undelete. LessHeard vanU (talk) 19:26, 22 August 2009 (UTC)
        • Why are completely going against consensus? How about you don't delete them unless they fail afd? Prodding is pointless here as very few people likely have the stub watchlisted. Also, titles with an underscore are titles with spaces, so yes they are easily found in a search. I find it disturbing that you don't know that but are going around deciding which articles aren't fit for the encyclopedia. - ʄɭoʏɗiaɲ ^τ _¢ 15:33, 23 August 2009 (UTC)

A glance shows that LessHeard is already carrying out some rather poor speedy deletions from this list. The high failure rate at low volume is a good indicator that introducing a bot to increase the volume is a bad idea. Christopher Parham (talk) 15:30, 26 August 2009 (UTC)

deletes are here at the moment. Rich Farmbrough, 04:13, 30 August 2009 (UTC).

Date parameter

I did include a date parameter in {{Asbox}} at one point, in case it was ever thought useful to explore how long things remained as stubs, and perhaps triage them. It was taken out as scope creep. However if it would result in less stubs, in a good way, it can be put back in. Rich Farmbrough, 04:03, 30 August 2009 (UTC).

I WANT TO POST

I WANT TO POST AN INFORMATION ON AARON BERKMAN, A RECOGNIZED WELL LISTED ARTIST. COULD YOU PLEASE ADVISE HOW I MAY PROCEED IN POSTING THE INFORMATION IN ADDITION TO AN IMAGE. THANKS, JEANETTE HENDLER — Preceding unsigned comment added by Jeanettehendler (talk • contribs)

Please don't type in CAPS LOCK. Ask for help like this at Wikipedia:Help desk. Thank you.----occono (talk) 17:51, 23 August 2009 (UTC)

When you go there, you are likely to get advice like this:Writing an article for Wikipedia is harder than many people realize. Even professional writers find that the format and style needed for a good encyclopedia article are different than what might be appropriate for other venues. You could:

• Get someone else to do it—If your only goal is to make sure that an article is added to Wikipedia, you can request that someone write an article on the subject.
• Start by editing other articles—If you are interested in becoming an editor at Wikipedia, our experience demonstrates that it is better to start by improving existing articles, which will help you get a sense of how this place works, and then you will be ready to write your first article from scratch. A good place to visit is the Wikipedia backlog, where there are literally hundreds of thousands of articles needing help from editors. Find an article in a subject area you know, and add a source, or a reference, or simply help write it better.
• Go ahead and try—If you do decide to write an article immediately, please read our policy on conflicts of interest, then read our guide to writing your first article, which will repeat some of the good advice above. Then please use the Article wizard, which will help you through the steps. I urge you to accept the option to save your first draft in your user subpage, which will reduce the chance your work will be deleted before it is ready.

--SPhilbrickT 18:15, 23 August 2009 (UTC)

Hm what an encourager to contributors that template is. Rich Farmbrough, 04:14, 30 August 2009 (UTC).

Yea, there seems to be a recent uptick in... negativity? recently. End of summer, maybe? I don't know.
— V = I * R (talk to Ω) 04:32, 30 August 2009 (UTC)

@Jeanette, click here: edit Aaron Berkman and start adding stuff. File:Smily.png
— V = I * R (talk to Ω) 04:32, 30 August 2009 (UTC)

A better verb for "search on Wikipedia"

Every day I say or hear "Donno, check it up on wikipedia" or "even google it on wikipedia". A better verb needs to be coined as to wikipedia sounds silly. If it does, what is it? just an odd thought, but this could go a long way, so I am posting. --Squidonius (talk) 11:31, 24 August 2009 (UTC)

I sometimes use 'ask wikipedia', as in "I don't know, you could ask wikipedia". Personally I'm not a fan of awkward neologisms like 'google it' so if you do coin a new verb, I for one won't be in a hurry to adopt it. Mike1024 (t/c) 12:29, 24 August 2009 (UTC)

"Wikoogle"! Dendodge _T\^C 12:50, 24 August 2009 (UTC)

(ec) Just say "check Wikipedia" or some other variation. Using "Google" as a verb evolved from the near-ubiquity of the engine and its unique, short name (two syllables, not five like Wikipedia). If they had tried from the start to make "Google" a verb, it wouldn't have worked - these things need to happen naturally. It's usage as a verb is actually bad for the company, as the more common the term becomes in the daily lexicon, the more diluted their Trademark becomes, which could easily cause it to lose that status. All that being said, I do know plenty of people who say "Wiki it," which, while technically incorrect, tends to work out the way you want it to nicely. ~ Amory (user • talk • contribs) 12:54, 24 August 2009 (UTC)

I don't think it's that difficult to say "Look it up on Wikipedia", like you would say for any website. I don't think we need to just say "Wikipedia it", but go for it, if people know what you're talking about. hmwitht 15:00, 24 August 2009 (UTC)

"Wikipedia it" is a problem because it could mean more than one thing. Does that mean "read an article" or "re-write the article" or "spend the rest of the week trying to determine consensus on a single sentence"? WhatamIdoing (talk) 19:12, 24 August 2009 (UTC)

Woogle it. Wikit. Wikifact check. Wing it (from Bing it). Ahhhh, all of these suck. Maybe we would need to create a "wikisearch bar" so we could spread the the phrase wikisearch with some grounding in reality. (By "we", I mean "all of us except me and Mike1024". The brows of people who make up neologisms are decidedly higher than those of the people who use them.) Andrew Gradman ^talk/_WP:Hornbook 05:53, 25 August 2009 (UTC)

Perhaps there could be a new verb coined here - after, Google has become such a popular search engine that people now talk of "googling the web" rather than "surfing the Web". Perhaps we could talk about Wikipeding for a term? I would be against, however, saying "wikifying it" because there are a lot of other Wiki websites (such as Wikinews}other than Wikipedia.

ACEOREVIVED (talk) 06:23, 26 August 2009 (UTC)

For the term to have a chance of catching on, we'd have to associate it with our search toolbar -- e.g. as a substitute for the word "Go" in the search button. But when I imagine any of our current ideas being put in that position,

• Wiki it!
• Wikit!
• Wikisearch it!
• Wikipede it!
• WP it!
• Wikify it!
• Wikoogle it!
• Woogle it!
• Wing it!
• Waltavista it!
• Wahoo it!

I lose my appetite. Sorry Jimbo. Andrew Gradman ^talk/_WP:Hornbook 06:59, 26 August 2009 (UTC)

"Wik". Noisalt (talk) 11:33, 26 August 2009 (UTC)

No need to name it after a long-time banned user. It's like saying "Grawp it!", which, come to think of it, would sound good except for the, um, interesting connotations. :-) Graham87 16:11, 26 August 2009 (UTC)

I like "wiki it". - Peregrine Fisher (talk) (contribs) 16:16, 26 August 2009 (UTC)

I appreciate your liking of this term, but I stick with what I said above - I am a little unsure of "wiki it" myself, as there are other Wiki websites besides Wikipedia. How about Wikipede it, as AGradman suggested above? ACEOREVIVED (talk) 19:54, 26 August 2009 (UTC)

People, this whole discussion is out of place on this page, and pretty much useless anyway. We don't really get to pick. If a word arises, it will be by the usual, natural course of linguistic evolution -- someone says it and it catches on. Trying to direct that process is unlikely to be effective; it's more likely to just annoy people. --Trovatore (talk) 20:05, 26 August 2009 (UTC)

The task is to find an abbreviation of Wikipedia (5 syllables) that fits in "___ it" and is short verbally (not just in writing). Then we start using it. "Wiki it" slurs into weekeet. "Doubleyou-pee it" doesn't quite work. Check TFE? WiP? WP, pronounced as 'wip'? Whip it. Ha ha. From now on, in my head, I'll be pronouncing WP as Wip, and referring to Wikipedia as WiP. Join me! and soon we too may have an awesome nounverb.    M  

While I would never personally use any such verb, I never use "google it" either as I prefer ask.com, I would like to state I hope this thread continues and more chime in. Its fun, its interesting, it is what the Village Pump is about. Collaborate and do not let editors like Trevatore discourage or bully you into not posting and continuing. Wet-blankets abound and they need to be ignored, because if he or anyone else doesnt like this thread then they dont have to read it, we do not censor on wikipedia. Be merry and continue please. You are the heart of Wikipedia and jovial exchanges on here are a great distraction from the depressing arguments and petty bickering often found here. Collaboration should be encouraged, not stiffled. This is the perfect forum for this discussion, dont leave, I'll defend you to my last key-stroke.Camelbinky (talk) 01:29, 30 August 2009 (UTC)

Wikipate! Grandmasterka 03:26, 30 August 2009 (UTC)

In the same light that editors should never need to create articles about themselves if they think they're notable (as eventually someone will write an article about them anyway), I think trying to create a phrase for people to use is a fool's game. If society's consensus is that they enjoy saying "Wik it" or "Wing it", then that can be adopted as a neologism. Otherwise, I think we should just wait. Pushing for it almost seems like we're desperate to be "hip" and "in tune with society". Let's face it, we're on our own wavelength and not in tune with anything else. (That said, I heard that Wikipedia's natural frequency is similar to Middle C...) Greg Tyler ^{(t • c)} 21:58, 1 September 2009 (UTC)

I just noticed that Trovatore made the same point above and would like to clarify that the second half of my post is totally irrelevant, unfounded and spurious nonsense. Greg Tyler ^{(t • c)} 22:00, 1 September 2009 (UTC)

Collapsible spans in lead para for etymology and/or pronounciation

I really like knowing about etymologies, but they can get in the way of smooth reading of the lead paragraph in many articles. I'd like these to be in collapible spans (I think this would need some technical implementation) when they get past a certain length.

Beijing (Template:Pron-en or /beɪˈʒɪŋ/ in English; Chinese: 北京; pinyin: Běijīng, IPA: [pèɪtɕíŋ] ; Wade-Giles: Pei3ching1 or Pei3-ching1) (also known as Peking (/piːˈkɪŋ/ or /peɪˈkɪŋ/)) is a metropolis in northern China and the capital of the People's Republic of China.

would therefore be replaced with something looking a bit like

Beijing [pronunciation and etymology] is a metropolis in northern China and the capital of the People's Republic of China.

expanding to the former when clicked. As with collapsible divs, these could be custom-CSS-ed for users who want them always-visible. The downside would be that that the text inside the span might get read, expanded and checked less, and it's another click if that's what you were mainly after looking at the article. The OED website does something similar, hiding pronunciation and etymology by default. Pseudomonas_(talk) 13:48, 25 August 2009 (UTC)

I like this proposal. The pronounciation is sometimes too long and can get very annoying to read through in the lead. An option to open the pronounciation, when desired seems much better. Warrior4321 16:57, 25 August 2009 (UTC)

I agree... what about developing a template that we could use? something along the lines of {{Lead sentence|Beijing|pron-en|beɪˈdʒɪŋ|IPA-en|beɪˈʒɪŋ|(etc...)}}
— Ω (talk) 18:22, 25 August 2009 (UTC)

I'm not too fammiliar with making templates of this sort at the moment. Is there a place such as requests for templates?? I couldn't find one. Warrior4321 18:54, 25 August 2009 (UTC)

Before going too far on this, there may be a consensus against collapsible elements in the main part of an article.
I did a quick search, and didn't find it, but I was once considering collapsing a large table and warned against it. Collapsing nav templates at the bottom of the article was specifically exempted, IIRC.
I share the concern about cluttering up the beginning of the article with too much etymology. --SPhilbrickT 22:03, 25 August 2009 (UTC)

Here's the guidance: MOS:SCROLL--SPhilbrickT 22:09, 25 August 2009 (UTC)

I think that a specific exemption to use collapsible spans in the lead specifically for this purpose is achievable, if it is indeed needed. Just among us here, there's some question abot how to implement it, but everyone seems to agree that it's a good idea. Obviously, there are only 4 people involved so far in this discussion, but I'd think that any discussion which doesn't (yet) have an obligatory Oppose added to it is certainly suggestive that widespread consensus is achievable.
— Ω (talk) 22:11, 25 August 2009 (UTC)

Don't count on me. What was wrong with Beijing example, anyway? NVO (talk) 22:13, 25 August 2009 (UTC)

(undent) To respond to an earlier question, Wikipedia:Requested templates is the place to ask for help with a new template. And, for what it's worth, I'd support such a template, as being a benefit to the average reader, who isn't interested in pronunciation and etymology. -- John Broughton (♫♫) 22:20, 25 August 2009 (UTC)

At the risk of getting ahead of things, I'd not want to overstandardize the pronunciation & etymology sections with new templates, just collapse an arbitrary block of text tidily in those cases where they're too long. Pseudomonas_(talk) 00:07, 26 August 2009 (UTC)

I like this idea a lot, though I must say, the original language should be included outside of the collapse, though not necessarily the transliteration. But it would be nice to hide the arcane pronunciation guides and elaborate linguistic notes. --Golbez (talk) 22:35, 25 August 2009 (UTC)

I think the original language is generally a detail about the word, rather than about what the word signifies, and belongs under the cut, especially when the answer is, as so often, Greek via Latin via Norman French via Middle English. I'll concede there are exceptions, though; there always are. Pseudomonas_(talk) 23:57, 25 August 2009 (UTC)

I take the point made in MOS:SCROLL about accessibility. At the moment, collapsible spans are not possible; I don't know whether this is changeable by admins or needs devs. I figure that if this proposal is popular with the community then people who know more about screen-readers and the like should decide if there's a non-obnoxious way of implementing it. Pseudomonas_(talk) 23:57, 25 August 2009 (UTC)

MOS:SCROLL is easily bypassed if the need to improve the encyclopedia is clear. As I said above, we can easily carve out an additional exception for this, if needed. Pronunciation and etymology are good information to include, but their not (normally) central to understanding the topic, so a template that collapses this (sometimes exceedingly long) information seems perfectly appropriate. There seems to be a decent amount of support for this, so at least getting the template created to accomplish the task seems to be the obvious next step. Having a concrete implementation to look at is what will prompt movement on this subject.
— Ω (talk) 00:27, 26 August 2009 (UTC)

Excellent. Can anybody here create the template? Warrior4321 05:04, 26 August 2009 (UTC)

I'm pretty sure that I could, but I'd need to find the time. Leave a note at Wikipedia:Requested templates, and someone will get around to it.
— Ω (talk) 05:15, 26 August 2009 (UTC)

I'll ask in IRC. Warrior4321 15:31, 26 August 2009 (UTC)

I wonder if having a system where the span was default-visible and then hidden by javascript would avoid the problems with accessibility &c.? Or is that the way the other collapsible things are done anyway? Pseudomonas_(talk) 22:21, 30 August 2009 (UTC)

a general Conversation page?

Now I know that wikipedia isn't the place for "chatting", BUT I think a page just for talking and for getting to know all the editors, and other members, would be nice to have. As of now, everybody is sepperated. I also know that there is irc, but not everyone can use irc.Accdude92 (talk) (sign) 14:19, 25 August 2009 (UTC)

Wikipedia is not a social-networking site. We're here to build an encyclopedia. However, collaboration is encouraged. Try contacting an editor on his/her talk page. hmwitht 17:30, 25 August 2009 (UTC)

• mw:LiquidThreads should help, when and if it's ever deployed (see Andrew Garrett's blog for details on development). The kludginess of the current talk page system is what drives the long standing institutionalized anti-social behavior that Wikipedia presently espouses (as displayed in the reply above). I know exactly what you're saying, and personally agree with the sentiments, but until the technical restrictions are handled nothing is going to significantly change.
  — Ω (talk) 18:34, 25 August 2009 (UTC)
• For kicks, you could always try and have conversations with people in the WP:SANDBOX. Whilst WP isn't social networking, or a forum, I do sometimes feel that minor less-streamlined talk would help the atmosphere greatly. Generally when I try and do something humorous people just flip me off on here, which is a shame. It would certainly be cool to remedy that and let people have breathing space. I can handle being shot back at, but I'm sure it turns decent new editors away. Greg Tyler ^{(t • c)} 20:58, 25 August 2009 (UTC)

I agree we need a general "chat room", but maybe keep it for finding editors who have similar interests and collaborating with people instead of making it just another AOL/Yahoo!/Myspace/Facebook thing where people are. It would be nice to have a general conversation forum where you could say "Hey, this is what I've been working on, anyone out there have similar interests?" because often people are working on articles within a similar topic and never know about each other and may have insight and info the other may have been looking for. Also a great place for potential wikiprojects to be formed since suddenly a large group of people realize they have a large collection of articles they want to colloborate and organize better. If anti-social people like the one that replied up above dont want to get to know others then that is their choice, but they can not force their personal beliefs on the rest of Wikipedia.Camelbinky (talk) 22:21, 25 August 2009 (UTC)

Wouldn't it cause mass edit conflicts? Warrior4321 22:26, 25 August 2009 (UTC)

Only if it was designed poorly. If you're really concerned, you could bring your concerns up with Werdna (talk · contribs), since he's currently leading the development of LiquidThreads.22:41, 25 August 2009 (UTC)

IRC is the best way to socially interact (generally, on the Internet as well, in my opinion). I'm not sure why someone wouldn't be able to use IRC - it's easy enough to learn with some tutorial or you can always just use an applet if you have connection problems. -- Mentifisto 15:17, 26 August 2009 (UTC)

I agree with the sentiments about IRC, but even an official Wikipedia IRC channel isn't really on Wikipedia. Most people just won't bother to use something "offsite", for various reasons.
— V = I * R (talk to Ω) 03:50, 30 August 2009 (UTC)

True, IRC has to be offsite, but Wikipedia supports it and has a whole host of channels to talk on. Webchat.freenode.net makes it easily accessible, too. If you want to chat about Wikipedia, I would support IRC as the place to go. Besides, holding it on site would mean the servers had to hold masses and masses of pointless, spammy conversations. That seems like a waste when there's such valuable information held there too. Greg Tyler ^{(t • c)} 16:34, 31 August 2009 (UTC)

The other issue with IRC though is that it's chat. Personally, I just don't like chat... as for server load questions, that's really not something to be concerned with.
— V = I * R (talk to Ω) 13:37, 1 September 2009 (UTC)

Talknotice

Sometimes, we have important community announcements, but there is no optimal way to advertize them. We can use the watchlist notice, but IPs can't see it, and logged-in users don't always frequently check their watchlist, so it's not that efficient. There's also the sitenotice, which makes the message visible to all users on all pages. But some announcements are not intended for all readers or are not important enough to be put on the sitenotice, so we could use a talknotice working like the sitenotice and displayed only on talk pages, also dismissible. If we agree that such a thing is desirable, it'll be requested to the developers. Cenarium (talk) 00:26, 26 August 2009 (UTC)

I second this proposal; the decision of what to do at the end of the coming flagged revisions trial (as Cenarium notes elsewhere) is one such announcement where watchlists don't reach enough users but sitenotice reaches too many.--ragesoss (talk) 19:27, 30 August 2009 (UTC)

Sounds good to me. - Peregrine Fisher (talk) (contribs) 21:24, 31 August 2009 (UTC)

Could we just put namespace checking code into the sitenotice? Something like {{#ifeq:{{NAMESPACE}}|{{TALKSPACE}}|...}} should do? — Dispenser 21:38, 31 August 2009 (UTC)

I tried on testwiki and the sitenotice couldn't handle it, if you put checking code in, it will be displayed on pages as parsed on the page Mediawiki:Sitenotice itself. I think it's for performance reasons. Cenarium (talk) 22:51, 31 August 2009 (UTC)

If we needed it right now we could use CSS or JS to hide on articles. — Dispenser 07:07, 1 September 2009 (UTC)

I filled Template:Bug requesting this. Cenarium (talk) 00:22, 1 September 2009 (UTC)

I love this idea. I think it might work better if the notice was displayed in all the secondary namespaces, and perhaps while editing. That way, anyone who isn't just a casual reader will see it. — Jake Wartenberg 04:14, 1 September 2009 (UTC)

CC badge?

Is there a reason we don't have one of the Creative commons badges at the bottom of our pages? I seem to remember a GFDL badge being there once upon a time. --Cybercobra (talk) 11:04, 26 August 2009 (UTC)

http://creativecommons.org/policies suggests that the images might not be free enough (though IANAL) - they're somewhat trademark encumbered. I suspect this might mean that the licenses in commons:Category:Creative_Commons_icons need to be tweaked somewhat. Pseudomonas_(talk) 12:08, 26 August 2009 (UTC)

I bring it up because I noticed Wikinews has one of them on its footers: [2] --Cybercobra (talk) 12:24, 26 August 2009 (UTC)

Hm, OK. I don't know what the standards are for the stuff that sits around the text. AFAIK the Wikipedia logo is trademarked, so maybe it's OK. Pseudomonas_(talk) 12:52, 26 August 2009 (UTC)

Wikinews uses the following interface message, n:MediaWiki:Copyright, to add this button. I agree that we at least should add one of the CC license microformats. —TheDJ (talk • contribs) 16:36, 26 August 2009 (UTC)

Yeah, a Google search filtering only results free to use excludes Wikipedia, so, it at least needs the CC metadata, or whatever, flagging it for free use for searches.--Unionhawk ^{Talk E-mail} 16:45, 26 August 2009 (UTC)

(Off topic, and purely a matter of personal interest) How do you do a Google search filtering only results free to use? That would be very useful, but I've never been able to find any Google feature offering that functionality. Dendodge _T\^C 16:56, 26 August 2009 (UTC)

(←)In 'advanced search,' there's a link that says "Date, usage rights, numeric range, and more." Click it, and there will be a dropdown box that you can choose the appropriate license. It only works with Creative Commons though, I think.--Unionhawk ^{Talk E-mail} 17:00, 26 August 2009 (UTC)

First try at example microformat

I generated a preliminary example for what something like that may look like:

code

<a rel="license" href="http://creativecommons.org/licenses/by-sa/3.0/"><img alt="Creative Commons License" style="border-width:0" src="http://i.creativecommons.org/l/by-sa/3.0/us/88x31.png" /></a><br />The text of the page:<span xmlns:dc="http://purl.org/dc/elements/1.1/" href="http://purl.org/dc/dcmitype/Text" property="dc:title" rel="dc:type">{{FULLPAGENAME}}</span> by the <a xmlns:cc="http://creativecommons.org/ns#" href="http://en.wikipedia.org/w/index.php?title={{FULLPAGENAME}}&action=history" property="cc:attributionName" rel="cc:attributionURL">contributors of Wikipedia</a> is available under the <a href="http://en.wikipedia.org/wiki/Wikipedia:Text_of_Creative_Commons_Attribution-ShareAlike_3.0_Unported_License">Creative Commons Attribution-ShareAlike License</a>; additional terms may apply. See <a href="http://wikimediafoundation.org/wiki/Terms_of_Use">Terms of Use</a> for details. <br /> Wikipedia® is a registered trademark of the <a href="http://www.wikimediafoundation.org">Wikimedia Foundation, Inc.</a>, a U.S. registered <a class='internal' href="http://en.wikipedia.org/wiki/501%28c%29#501.28c.29.283.29" title="501(c)(3)">501(c)(3)</a> <a href="http://wikimediafoundation.org/wiki/Deductibility_of_donations">tax-deductible</a> <a class='internal' href="http://en.wikipedia.org/wiki/Non-profit_organization" title="Non-profit organization">nonprofit</a> <a href="http://en.wikipedia.org/wiki/Charitable_organization" title="Charitable organization">charity</a>.

Wether or not to use an image, and the exact wording and formatting still requires quite some discussion of course. We wouldn't want to get that wrong. —TheDJ (talk • contribs) 17:08, 26 August 2009 (UTC)

A demo is visible on the test wiki. Note that it only looks decent if you use Vector/Beta, in Monobook, it's one big mess. (Note that there are two license links, one to our OWN licens page, and one to the creative commons version, to make sure we are picked up by search engines. —TheDJ (talk • contribs) 17:41, 26 August 2009 (UTC)

Cool! I think it might look better in Monobook if a linebreak were inserted like so: "additional terms may apply.<br/> See". Agree it already looks fine in Vector, although I don't know if I like the stacking of the buttons. --Cybercobra (talk) 23:17, 26 August 2009 (UTC)

This includes page specific stuff though, so IF we do this, I first need to check with domas or brion to get an OK on this. We can remove that metadata if we have to. Basically the only critical part to "Searchable detection", is having this link in a rel=license. We currently have our own link, but perhaps we should have both, with the CC link hidden. —TheDJ (talk • contribs) 00:09, 27 August 2009 (UTC)

I think we should at the very least add the microformat, as I propose here: MediaWiki_talk:Wikimedia-copyright —TheDJ (talk • contribs) 00:47, 27 August 2009 (UTC)

I asked domas, and we should not use page specific functions on footers like this. —TheDJ (talk • contribs) 17:42, 27 August 2009 (UTC)

I guess we could open a bugreport to generate the RDFa crediting format in the core, that will be significantly less expensive. The license microformat should be no issue at all, the badge is really something that requires a lot more community input. —TheDJ (talk • contribs) 18:30, 27 August 2009 (UTC)

Truth be told, my focus was more on the badge; I didn't know about the RDF tagging before you brought it up. Although the tagging is still an excellent idea--Cybercobra (talk) 20:39, 27 August 2009 (UTC)

Image badge

Right, now that the microformat was added, any thoughts from people on the original question of an image badge? Possibilities: [3], [4], [5] --Cybercobra (talk) 05:31, 30 August 2009 (UTC)

I'm opposed to this; there's no reason for it at all. We should only use graphics for graphical information. It's just visual pollution. —Noisalt (talk) 01:00, 31 August 2009 (UTC)

Query: Then why do we have the "Powered by MediaWiki" and "A WikiMedia project" badges? --Cybercobra (talk) 01:12, 31 August 2009 (UTC)

You tell me. I have exactly the same opinion about them. —Noisalt (talk) 01:47, 31 August 2009 (UTC)

Basque Wikipedia

Hi from the Basque Country!
This is a message to the administrators of wikipedia in English or for someone who can help me with this issue:

I´m an user and contributor of the Basque Wikipedia., Basque language is one of the oldest in Europe and the world, it has thousands of years old and is one of the few languages that survived the arrival of Indo-Europeans to Europe. Perhaps being one of the oldest nations or countries of the world not even have their own state, but our language is our homeland and pride. It put us on the map and give a reference recognizable to English speakers, the city of Pamplona (Iruña in basque language), where they celebrate the internationally famous festival of San Fermin are in the Basque Country.

After this brief introduction I would kindly ask you this request:

On July 15, 2009, in the Basque wikipedia we exceed the figure of 40,000 items, today (August 8, 2009) and we have 42,000 items, achievement of which we are very proud, because if we compare proportionately the number of speakers of the Basque language (about a million) with other spoken language Wikipedia in more than one state or nation in the world with millions of speakers is like to be proud.

Because one of the aims of Wikipedia in addition to expanding human knowledge worldwide is also to expand the knowledge of all languages of mankind: From the Basque Wikipedia We wanted to make the request to the users and particularly to the Admin of the English wikipedia would be possible if you put the link to Basque Wikipedia in your English Wikipedia´s language list of everyone in your main cover ("Languages" section: as is currently the case Galician or Catalan language) and the Wikipedia list of more than 40,000 items that is below your main entrance page ("Wikipedia languages" section). Since English is currently the most powerful, influential and widespread in the world (your wikipedia already has 3,000,000 articles), the presence of Basque Wikipedia in your list of the world would be a great help to supervival of our language and their knowledge in the world.

Awaiting your reply.

Greetings from the Basque Wikipedia.
. --Euskalduna (tell me) 15:05, 26 August 2009 (UTC) (UTC)

Please see Template:MainPageInterwikis —TheDJ (talk • contribs) 16:33, 26 August 2009 (UTC)

The Basque Wikipedia is mentioned in List of Wikipedias, and might be mentioned in articles in the English Wikipedia which have used considerable input from articles in the Basque Wikipedia. ACEOREVIVED (talk) 21:26, 26 August 2009 (UTC)

Having re-read your posting, I understand that you would like the Basque Wikipedia to be mentioned on the Main Page, where - at the bottom of the page - a list of languages other than Wikipedia in which Wikipedias exist can be found. I think you had better contact a Wikipedia administrator there (I am not one myself), who may be able to help with proposed changes to the Main Page. ACEOREVIVED (talk) 19:47, 28 August 2009 (UTC)

Wikipedia forums

I think that there should be a forum for wikipedia.Accdude92 (talk) (sign) 14:14, 27 August 2009 (UTC)

I think that Wikipedia is an encyclopedia and we don't need forums, the current discussion pages are enough. Kotiwalo (talk) 14:17, 27 August 2009 (UTC)

Because I'm a trouble maker I'd like to respond to Kotiwalo, and the many other users who state the same thing right away whenever similar questions about forums is brought up- if discussion/talk pages (whether user or article) were enough as you state then we'd never have needed the Village Pump or Wikiprojects. Forums are just one more useful tool for people with similar interests to find each other, exchange useful tips and sources and info. I know I have a number of "friends" I enjoy asking to look over articles I work on and hear from them "hey, working on x article I found this source, it might come in handy for you on that y article your working on". Wikipedia is a family, we may not always agree, we may fight, but in the end we all mean well and want to work together on a common goal to make this a better place. If having a forum to make new friends will improve some editor's contributions, then it is a useful tool. Only if these forums become a distraction and/or do not increase an individual's contributions then I would recommend that the forums/liquid threads whatever be discouraged or blocked to those who only use Wikipedia as a social networking site and dont do any editing at all. That is something I would like to see implemented- if you use this site as a social networking site you are blocked from it. Perhaps that would satisfy some who disagree with their implementation. Those who, like Kotiwalo, want to say "this is an encyclopedia and forums are not what Wikipedia is about", then they dont have to participate in a forum, but they need to back off and stop being anti-social in a vocal way. Be anti-social but be quiet.Camelbinky (talk) 01:12, 30 August 2009 (UTC)

There are forums to discuss Wikipedia off-site, however. hmwitht 14:18, 27 August 2009 (UTC)

An ordinary web forum for general discussion would be good, but there isn't really one now. There are mailing lists. --Apoc2400 (talk) 17:15, 27 August 2009 (UTC)

Really? Warrior4321 17:41, 27 August 2009 (UTC)

There used to be, WikBack, but it appears to be down now. I visited it frequently when it first went live, but eventually stopped going. Just tried it again and nothing. Not sure what happened. Maybe a lot of people eventually stopped going as well.↔NMajdan•talk 17:42, 27 August 2009 (UTC)

There's no an official one, but they exist. hmwitht 01:24, 28 August 2009 (UTC)

Shockingly, there are also anti-Wikipedia message boards as well.↔NMajdan•talk 02:00, 28 August 2009 (UTC)

Liquid Threads are coming... eventually (and personally, I can't wait!). That should address the basic concern being expressed, here.
— V = I * R (talk) 04:16, 28 August 2009 (UTC)

Wikipedia Review is fairly active. Chuthya (talk) 11:59, 28 August 2009 (UTC)

That's to what I was referring. :) hmwitht 00:01, 30 August 2009 (UTC)

Table of contents

Check out Maglev (transport). Its table of contents is floated over to the right, next the the main text, instead of above the rest of the text. I'm sure I'm not the only one who has been annoyed by having to scroll and scroll and scroll and scroll to get past the TOC. Maybe using the method found in "Maglev (transport)" in all articles, or at least all long ones, would make Wikipedia more usable overall. All it would require would be a TOCright or TOCleft in double curly brackets where the table of contents is.--(User:Star Trek enthusiast) (talk) 23:21, 27 August 2009 (UTC)

If you want to get to the bottom of the toc, just click the first "item" on the table of contents. It will take straight to the bottom of the toc, no scrolling required Warrior4321 00:35, 28 August 2009 (UTC)

It won't work in every article, since many articles include either an Infobox or a picture on the upper right of the article (where the TOC appears in the Maglev article). Any individual articles can be changed to display the table of contents on the right hand side by placing the {{TOCright}} template on the page.
— V = I * R (talk) 04:25, 28 August 2009 (UTC)

It's a lousy system for smaller screens. the (edit) link for section one is left hanging at the top of the TOC while section one actually starts underneath the TOC. NotAnIP83:149:66:11 (talk) 10:00, 31 August 2009 (UTC)

Policy change proposal

I'm posting this in response to the CNN article which was reporting on Wikipedia's decision to use editors for select articles to approve changes before they're made public. I'd like to suggest that Wikipedia enact a system of "community based edit approval" on selected articles wherein pages need to have changes approved before being made public. Edits would be voted on by users before taking affect. In this way, when a user makes a change to an article it will not be immediately visible on the article's main page. Instead, it will be logged onto the articles edit page for review and if it receives a set amount of negative votes in a certain amount of time then edit will be discarded and the article will not be changed. This would be a good way to prevent vandalism and preventing bad changes from ever coming into action. 74.131.111.224 (talk) 23:19, 27 August 2009 (UTC)

This is the gist of Wikipedia:Flagged revisions. -- Taku (talk) 21:02, 29 August 2009 (UTC)

Voting would never work, most articles don't get enough traffic. Mr.Z-man 21:11, 29 August 2009 (UTC)

It does make sense to let the reader somehow rate and vote for particular versions. That is, the most article with the most votes will become one that is visible. (I know this isn't what was proposed above.) -- Taku (talk) 21:37, 29 August 2009 (UTC)

Opening such a vote up to the general public allows for manipulation of content. Say you're a member of a pro-whatever group, you can slant an article to favor your side, then ask all the other group members to vote for that revision, so even if it gets reverted, it'll still be the most popular version. Since the voting is done by the general public, there's no accountability. Mr.Z-man 01:57, 31 August 2009 (UTC)

Hide bots in history

I wish a hide bots button on history pages. There is so huge amount of bot edits on every history page it is really annoying to check other "real" edits. --Janezdrilc (talk) 14:42, 28 August 2009 (UTC)

I think this would make things very confusing and probably could not be implemented elegantly. –xeno^talk 14:49, 28 August 2009 (UTC)

As xeno said, this would become far too confusing. The bot edits would be merged with another users' edits, which would incorrectly attribute them to a non-bot user. What if a user reverts a bot's edit? Then there'd be a history entry where nothing changed. –Drilnoth (T • C • L) 15:10, 28 August 2009 (UTC)

Are bot edits in the history marked up as such via a class in the <tr> or something? If that's the case, I'm willing to guess it would be possible to develop a gadget/javascript to hide the edits (no, I haven't checked myself). Likewise for minor edits, if you wish to hide those. Ideally, we'd be able to turn it on and off with a link/button. --Izno (talk) 17:11, 28 August 2009 (UTC)

The problems would not be from difficulty of hiding them in the history page itself, the problems would be from the confusing diffs that would result from removing entries from the page. Mr.Z-man 17:19, 28 August 2009 (UTC)

(undent) Such a gadget would only hide the entries on the history list, not the edits themselves. So if the original history looked like this:

• (cur)(prev) 0:10 1 January, 2000 User:Example (foo)
• (cur)(prev) 0:05 1 January, 2000 User:ExampleBot (bar)
• (cur)(prev) 0:00 1 January, 2000 User:Example2 (baz)

etc.

Then the "truncated history" would be this:

• (cur)(prev) 0:10 1 January, 2000 User:Example (foo)
• (cur)(prev) 0:00 1 January, 2000 User:Example2 (baz)

etc.

but clicking the first "prev" link would (assuming no major restructuring on the part of the gadget) show a diff between the edits at 0:05 and 0:10, not the edits at 0:00 and 0:10, and the author of the old version would be correctly identified as User:ExampleBot (i.e. everything would "just work"). If the gadget somehow was designed to show the diff between 0:00 and 0:10, it would look as though the user had selected this diff via the radio buttons on the original history (complete with message about intermittant edits etc.). This, however, would entail a much more complex gadget. In short, the MediaWiki software is not stupid and won't do inconsistent things like those mentioned above without warning you. --Thinboy00 @144, i.e. 02:27, 29 August 2009 (UTC)

I like seeing bot edits... yes, most of the time they can be ignored, but occasionally a bot will make an edit that needs to be over-turned. It is important to check what bots do, to make sure that their changes are appropriate for a specific article. Blueboar (talk) 16:51, 29 August 2009 (UTC)

I'm pretty sure that simply "hiding them" was the intended functionality, Thinboy, and I think I'd actually find it useful myself. It makes the "diff" button harder to use (unless such functionality as "you may be including bot edits" is implemented), but not disturbingly so. --Izno (talk) 18:22, 29 August 2009 (UTC)

Here is one solution. You put this option in Preferences -> Gadgets -> User interface gadgets. So if you pick this option out every history page whould include show/hide buttons where bots should be listed. And if you want to make a preview or undo, you just have to click show. That's all. --Janezdrilc (talk) 22:42, 30 August 2009 (UTC)

Aha, I have to explain my reason. The problem is that smaller Wikipedias have a series of bots on the history lists (interwikis) while bigger wikis like en: or de: maybe don't know that problem so strictly. --Janezdrilc (talk) 22:46, 30 August 2009 (UTC)

Table on the recent changes page

The content on the Recent changes page is very badly arranged. Could tha data be sorted in the table? --Janezdrilc (talk) 14:42, 28 August 2009 (UTC)

How would you prefer to see it? Who then was a gentleman? (talk) 19:27, 28 August 2009 (UTC)

The table could have about 6 columns: Column1 labels N or m, Column2 Title, then hour, counter of bytes, author and finally notes. --Janezdrilc (talk) 22:28, 30 August 2009 (UTC)

I don't understand. There are 7 columns already. Are you asking for more info, or less? Who then was a gentleman? (talk) 21:03, 31 August 2009 (UTC)

The OP may be interested in "Enhanced recent changes", which can be toggled in the "Recent changes" tab of Special:Preferences. Dendodge _T\^C 21:05, 31 August 2009 (UTC)

I meant a table with grid like this (for now there is just bulleted list):

(diff) (hist)	m	Hyderabadi haleem‎	01:58	(+3)	Sarabseth (talk | contribs)	→Preparation: grammar
(diff) (hist)	N	User:Darrenhusted/sandbox22‎	01:58	(-25)	Hooliganb (talk | contribs)	→Karl
(diff) (hist)		Wikipedia:WikiProject Macau/Popular pages‎	01:58	(+57)	Baxtersmalls (talk | contribs)	Popularity stats for WikiProject Macau
(diff) (hist)		Dexilla‎	01:58	(+456)	Mr.Z-bot (talk | contribs)	→Links: moved to subcategory, Replaced: Category:Tachinidae → Tachinidae-stub,, Removed: fly-stub, using AWB

I wonder whether you meant that you would like to see the Wikipedia "Recent Changes" feature become better categorised. At present, I agree that if you click on "Recent Changes", the only order seems to be the purely temporal order of the last x number of changes (which some Wikipedians might think is fair enough - after all, this is the name of this feature). However, perhaps there could be a way to categorise this feature, so people can find what they may wish to see in this feature more easily. ACEOREVIVED (talk) 20:02, 2 September 2009 (UTC)

Check my work?

It's entirely possible that what I'm thinking about exists already and I'm simply not aware of it, but recently I've been running across situations where I feel that I'm "going out on a limb" somewhat. You know that feeling that you get, where you don't want to just leave something, but you also don't really feel comfortable with the change that you've just made? has there been discussion about some sort of feedback system that addresses this, at all? The first thing to come to my mind is some sort of template.. something like {{Check me}} or... something.
— V = I * R (talk to Ω) 07:13, 30 August 2009 (UTC)

{{check}}? --Cybercobra (talk) 07:20, 30 August 2009 (UTC)

nah... I mean, I suppose that template (or even the whole range of similar templates) could be refactored somehow. What I was thinking of is something more immediate and temporary. Like: "OK, I'm changing this because it's clearly wrong/incorrect/needed, but I'm not sure if my change is exactly correct so can you check my work please?" basically... a message box with a message that says "the last change made should be checked. Once checked, please remove this template". Something like that.
— V = I * R (talk to Ω) 07:33, 30 August 2009 (UTC)

Article wizard 2.0

Right, this has been on my back burner for a long time, and I've finally done it: based on the article for creation wizard, I've created Wikipedia:Article wizard2.0, (superceding the less helpful and less pretty and underused WP:Article wizard) as a generic wizard for registered users to create articles, including a simple template at the end. Comments please on the idea and execution; and on how we can promote it when it's ready. I've previously considered things like the MediaWiki page that produces the Search Results page (I forget the name now), that kind of thing. NB The one thing that the old Article wizard does that may be worth taking is emphasising the need to search for alternate spelling etc (see Wikipedia:Article wizard/other). But I'm tired and hungry now... Rd232 ^talk 14:13, 30 August 2009 (UTC)

I like it. I've posted feedback at Wikipedia talk:Article wizard2.0. hmwitht 14:34, 30 August 2009 (UTC)

It's an excellent start. I have a few comments, but have to gather my thoughts. Will respond in more retail at the talk page.--SPhilbrickT 17:53, 30 August 2009 (UTC)

Did not work at all, aborted without retry... and did not even say "thank you for your time, come next week...". Yes, I was honest, I really thought it's not ready for FA yet and will need some more work because the book says it's never too late and be bold and ... oh well. Seriously, I doubt that the user who do need help will actually go through all these hurdles. It's like a bank's call center computer that will drain your phone battery before even getting closer to whatever you needed... No, they'd better learn the rules the good old way. NVO (talk) 19:50, 30 August 2009 (UTC)

And the award for the least constructive comments on this topic so far goes to.... Seriously, a really good wizard of some sort would be a great asset. How about helping to create one? Or roll your own if you think this one is that bad a starting point. Rd232 ^talk 22:46, 30 August 2009 (UTC)

Wikipedia:Article_wizard2.0/subpage is broken (this is used in construction of a userspace proto-article)(instead of showing the name of the viewer, it shows the name of the last person to edit the page). Recommend replacing {{REVISIONUSER}} with Special:Mypage. --Thinboy00 @276, i.e. 05:37, 31 August 2009 (UTC)

done, thanks. Rd232 ^talk 18:57, 1 September 2009 (UTC)

An overview of Outstanding issues is now available at Wikipedia talk:Article wizard2.0#Outstanding issues. Thanks. Rd232 ^talk 18:57, 1 September 2009 (UTC)

Thank you for your work, I had thought about something like that and it could help some new users. Cenarium (talk) 17:11, 2 September 2009 (UTC)

Making our editing interface more clear and helpful

Hello all! You're probably aware that Wikipedia is reviewing its editing interface at the moment, the purpose being to make it easier to use. A lot of time and money is being spent, and this is all obviously a great idea. However, while the developers are still at work, I feel a massive improvement could be made relatively easily. The text that surrounds the edit box is confusing, unsightly, and not at all helpful. It is fragmented, and is clearly a product of years of tinkering by many different people. I feel we should take a step back and organise this important text in a much more presentable and informative way. Below are two images of the interface; before, and after my proposal.

The current editing interface, as seen by an anonymous user

Current proposal: two boxs – editing instructions for anons and newbies only at the top, warnings for all users at the bottom (incorporating the legally required text). Note also the text between the edit box and summary box.

Initial proposal: consolidate all the advice and warnings into a simple notice at the top.

As you can see, my proposal is simpler, clearer and prettier than the current situation. I'd also like that a similar one be created, identical except for the removal of the third 'create account' line, for users who are logged in. I'd also hope that its display could be turned off in user preferences. Anxietycello (talk) 15:48, 30 August 2009 (UTC)

Users with modest screen sizes will have to scroll a whole screen down to get to edit window. Why? NVO (talk) 19:32, 30 August 2009 (UTC)

It could be turned off by experienced users, so wouldn't affect you. It is mainly aimed at new and unregistered users. Anxietycello (talk) 21:12, 30 August 2009 (UTC)

First-time users will simply not find the edit window if it's in the bottom third of the screen or, worse, below the screen. They'd walk away. Usability basics. Of all the things that must be on the screen you've left out the most important. Edit window. NVO (talk) 18:19, 31 August 2009 (UTC)

That's highly speculative opinon, not usability basics. In my highly speculative opinion, I'd expect anon users to be more welcomed by the sentence "welcome to the eiting interface" than what they're currently faced with; the "you are not logged in" warning. See the second draft image below, in which the box takes up less vertical space. Anxietycello (talk) 19:53, 31 August 2009 (UTC)

Which is more than you can do with the current text, which takes up the same amount of room. Anxietycello (talk) 23:33, 30 August 2009 (UTC)

But you can easily hide it with the current setup. Also, you're missing the required text regarding the CC-BY-SA and GFDL. Anomie⚔ 00:54, 31 August 2009 (UTC)

Perhaps that highly technical text could be left as it is, but just after the save button (so that the edit here/summarise here text can be used). Anxietycello (talk) 12:52, 31 August 2009 (UTC)

I like this proposal, and you're absolutely right about the hodgepodge of the current interface. It needs developing but it's a good start. Obviously it would need to easily be disabled (and should mention in no uncertain terms that sources are required). —Noisalt (talk) 01:05, 31 August 2009 (UTC)

Perhaps there could be a [hide]/[show] symbol next to it, and an option to hide it outright in user preferences? I wouldn't say that Anomie's idea of 'easily' is the same as mine. Anxietycello (talk) 12:52, 31 August 2009 (UTC)

I can see how its clearer, by putting everything in once place. But I'm not sure its more helpful. This seems like cleaning your bedroom by putting everything on one shelf in the closet. Yes, the room is less cluttered, and you know where everything is, but that doesn't mean its a more usable system. Mr.Z-man 02:02, 31 August 2009 (UTC)

The main USP of my idea is that it has instructions on how to edit, for those within that market that we've so far been totally shunning. Anxietycello (talk) 12:52, 31 August 2009 (UTC)

But, it doesn't, really. It just takes what's already there, gets rid of a bunch of it, and puts the rest all in one place. Mr.Z-man 13:49, 31 August 2009 (UTC)

Just visually, there's too much whitespace on the page anyway. — V = I * R (talk to Ω) 14:03, 31 August 2009 (UTC)

Was that supposed to be a reply to me? Removing whitespace does not add instructions on how to edit. The proposed design does not have anything that the current interface doesn't, and I believe its missing things that the current interface has. Mr.Z-man 18:35, 31 August 2009 (UTC)

But it does! It has simple editing instructions - see the fourth, fifth and sixth bullet points on the top box. I have submitted a second draft, take a look at that, and I'm sure you'll be more satisfied. My proposal uses simple language in clear explainations. This may all seem moot to you, the experienced user, but I really feel for what those average joe types said in the video (File:Wiki feel stupid v2.ogv). Please take the time to read the recent Usability and Experience Study. My proposal is now this; the top box will display only to IP users (maybe also newly registered ones), and the bottom box will be perminantly visable to all. It's not just "thrown onto one shelf", it is a clear, coherant organisation of several highly important – fundamental, even – messages that must be taught to new users. Anxietycello (talk) 19:33, 31 August 2009 (UTC)

I agree that we need better instructions, but "Type in the big honking box full of text" is pretty much "Using a Computer 101". Anything that involves typing more than a few words typically involves typing in a textbox and almost every form everywhere on the internet has buttons. If anything, "Show changes" is the one that needs explanation. The problem is the complicated nature of wikitext, not people not being able to find the editbox or the "Save" button. Have you actually watched the video you keep linking to? Mr.Z-man 21:38, 31 August 2009 (UTC)

Yes I have, and the thought I went away with were that people were baffled by the information overload on reaching the edit page. Ok, I can see that the instruction box preceding the edit box isn't filling everyone with enthusiasm. Would you support the text shuffle following the edit box? Being more organised, perhaps it will be easier for people to understand the basic rules, etc.? Anxietycello (talk) 23:03, 31 August 2009 (UTC)

You should take this to the Usability initiative, since this is exactly what their working on right now... — V = I * R (talk to Ω)

Drawn up a new draft, adding the suggestions given. Header moved to the sides to shrink the box and remove whitespace. The code I used to make the text and boxes can be found at User:Anxietycello/Interface. Anxietycello (talk) 14:15, 31 August 2009 (UTC)

If you were reducing the amount of text, then I would support it. But you're not, so I don't. I would get rid of the "Welcome to the editing interface!" to start. Maybe if that was displayed only the first time, it might be OK (probably not), but it would become annoying fast. Having to dismiss it would also be annoying. Anyways, I would liek to see the six sentences reduced to about two. - Peregrine Fisher (talk) (contribs) 21:32, 31 August 2009 (UTC)

The top box would be displayed to anonymous users and newly registered accounts only. You would never see the top part, except when not signed in. Anxietycello (talk) 22:16, 31 August 2009 (UTC)

Well, then how about a shorter bottom box? - Peregrine Fisher (talk) (contribs) 22:24, 31 August 2009 (UTC)

Afraid not; the last four bullets are required by law in order for the website to operate, and the first two bullets are our own rules, which are fundamental to the operation of our encyclopedia. These things need to be said. Anyhow, as it stands, my box takes up less room (about 20% less) than the current situation and still says all the same things. Anxietycello (talk) 23:03, 31 August 2009 (UTC)

What's with the side boxes saying "Welcome"? Get rid of those. —Noisalt (talk) 00:21, 1 September 2009 (UTC)

Trimmed down alterations

A rearrangement of the text that follows the edit box. My proposed version (right) contains all the text of the current version (left), but presents it in a more logical and clear fashion. It also includes a request that all work submitted be neutral, verifiable and encylopedic - the core of our complex rulebook. Note how it also takes up less room.

Ok, I can see that the idea for the box I started with is not being happily accepted, for both aesthetic and practical reasons. Perhaps a simpler reform would be better recieved? Forget the top box for now, and lets focus on the mess of text below the edit box. As I said before, it is fragmented, and is clearly a product of years of tinkering by many different people. It is also a highly important peice of information, one that people should be able to easily read and understand. I therefore propose the above re-organisation. Any thoughts? Anxietycello (talk) 00:56, 1 September 2009 (UTC)

I can only support less text, but others may like more, I don't know. - Peregrine Fisher (talk) (contribs) 01:00, 1 September 2009 (UTC)

It takes up less vertical room than the current situation, and is only 168 words vs the current 183. While I do agree that it should be as short as possible, I also feel that all the text in my proposal is necessary. Is it so hard to scroll past? Surely you wouldn't need to very often? Anxietycello (talk) 01:23, 1 September 2009 (UTC)

I see what's going on. I didn't even see the "If you do not want your writing edited" stuff in the original because it's in a small font. I think I like the placement, but I'm not liking how it seems so much longer, even though it's shorter. - Peregrine Fisher (talk) (contribs) 01:30, 1 September 2009 (UTC)

See, yeah, it is as if having some text <small> and some text <big>, some bold and some bulleted makes things less visible, somehow more easy to gloss over. It's all important! Is that what you mean by it seeming longer now? Actually not so easy to ignore? Anxietycello (talk) 01:42, 1 September 2009 (UTC)

Well, I'm not convinced that it's all important, but yes, that is what I mean. - Peregrine Fisher (talk) (contribs) 02:21, 1 September 2009 (UTC)

Also, after 20000 edits, today is the first time I've ever bothered to read any of that. It's kinda like the ads on the side of a google search. I don't even see it. Can we just link to an explanatory page? - Peregrine Fisher (talk) (contribs) 02:27, 1 September 2009 (UTC)

Unfortunately, no, we can't. It has to be on that page as specified by the organisation that issues wikipedia with its licencing rights. See anomie's post above. 212.183.134.64 (talk) 02:38, 1 September 2009 (UTC)

That's not true. Lots of sites have a "Terms of Use" link, with all the info on a dedicated page. - Peregrine Fisher (talk) (contribs) 03:12, 1 September 2009 (UTC)

Lots of sites copywrite their text and operate for profit. We run under a very specifically free licence that has very specific rules. See here Anxietycello (talk) 14:48, 1 September 2009 (UTC)

I'm honestly not trying to be a stick in the mud here, but I'm really wondering why this discussion is occurring here rather then on the Usability study page. This is exactly what they are tasked with studying and improving, and they have the money, resources, time, and backing of the WMF to actually implement changes. Their also smack dab in the middle of evaluating exactly what this is attempting to address, so your suggestions and comments would be much more likely to have an impact there regardless.
— V = I * R (talk to Ω) 06:02, 1 September 2009 (UTC)

Ok, I've posted to Wikipedia Usability initiative here. -- Anxietycello (talk) 17:45, 2 September 2009 (UTC)

Hmm. Hadn't seen that meta page. It looks like we could trim it, but I'm not going to follow this discussion between wikis. Good luck. - Peregrine Fisher (talk) (contribs) 17:50, 2 September 2009 (UTC)

Wikipedia should keep peace on the earth...

Hello!

Sorry for my limited knowledge of English, but I think that the images like these:

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:Anti_Armenia.png

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:No_France.svg

http://az.wikipedia.org/wiki/%C5%9E%C9%99kil:No_Israel.svg

should not be in Wikipedia nor Users pages of Wikipedians.

Wikipedia should be a place for knowledge not for rasistic expressions of some users.

Skrabbit (talk) 16:45, 31 August 2009 (UTC)

Those images are on azwikipedia, and there's nothing we can do about them here. Sorry. Majorly talk 16:47, 31 August 2009 (UTC)

For what it's worth, they're actually all hosted on Commons. You could take the matter up there at Commons:Commons:Deletion requests or similar, though I can't say I'm up on Commons policies. Cool3 (talk) 17:12, 31 August 2009 (UTC)

I will happily tag those images on both with whatever their equivalent of {{db-attack}} is. Those images can't be used for anything positive I imagine. - ʄɭoʏɗiaɲ ^τ _¢ 17:14, 31 August 2009 (UTC)

Except the first image. Majorly talk 17:15, 31 August 2009 (UTC)

Thing is, not everything in life is positive, especially in an encyclopedia about everything. Majorly talk 17:15, 31 August 2009 (UTC)

Yes, but there's a difference between showing something negative that happened or that exists, and promoting hate. The anti-Israel flag is quite clearly being used in a negative way by the userpages it is on. - ʄɭoʏɗiaɲ ^τ _¢ 17:42, 31 August 2009 (UTC)

In fact, all three seem to be used on userpages, although I can't tell you much more than that... ~ Amory (user • talk • contribs) 20:02, 31 August 2009 (UTC)

(od) Somewhat relevant to this thread: commons:Commons:Deletion_requests/Image:Anti_Poland.png which also discusses commons:Category:Anti_logos and its >220 member files. I don't know what to make of the discussion, but in any case there isn't anything to be done within the scope of this project. BTW, someone attempted to speedy the no-France image and the speedy tag was quickly removed by the author. Sswonk (talk) 21:35, 31 August 2009 (UTC)

I have nominated the Israel one. It is clearly part of a political agenda, as can be gathered from the pages it resides upon. Unlike the anti-france or anti-japan images, it regards a current and ongoing confrontation, and not a simple dislike towards the policies of a government. - ʄɭoʏɗiaɲ ^τ _¢ 19:16, 1 September 2009 (UTC)

Coloring Wikipedia text is a BAD idea

I read this article a couple of minutes ago:

http://www.wired.com/wiredscience/2009/08/wikitrust/

Please, please don't implement this. Not only would this make reading articles difficult with this turned on, but I can only see this causing a lot of issues with 'truthiness'. Editors with get into discussions and, rather than coming to a consensus, they will simply let the edit color speak for itself.

I understand Wikimedia Foundation's interest in making Wikipedia seem more accurate to the eye of the general and scientific communities, (Despite Wikipedia already being the most expansive and accurate general source in existence. ) but rainbow coloring pages doesn't seem like the way to do this. It's distracting, may actual reduce accuracy, and makes the page seem disjointed. Instead, let's extend the extension which shows page rankings under the page title and color codes page titles respectively to where it's used by default, as well as a link to a 'research safe' version of the article. (A recent history of the page with an equal or greater ranking.)

This method would not only ensure accuracy, but would also provide a standard, static-style encyclopedia which could be used reliably in a professional or academic context. 8bit (talk) 05:41, 1 September 2009 (UTC)

What's actually occurring is covered at Wikitrust. It appears to be a Gadget, not anything forced on every user by the base software.
— V = I * R (talk to Ω) 05:48, 1 September 2009 (UTC)

Even as a gadget, I'm still kind of against it, as it seems like something which would lead to truthiness, but either way, what of my alternate proposal as a default setup? Here's an image of approximately what I'm picturing:

8bit (talk) 06:04, 1 September 2009 (UTC)

I do wish we'd show regular readers our assessments. It's a valuable piece of info when trying to figure out how much to trust an article. - Peregrine Fisher (talk) (contribs) 06:09, 1 September 2009 (UTC)

There's been a relatively extensive discussion on the wikien-l mailing list, feel free to read it as well if you like. This thing is gonna take a while to get here, if at all, and it's not going to be exactly as the sensationalist article writer makes it sound. The main aspect is how extensive a section of text has been edited, and the ability to link to the diff where it was added, something that is really cool. ~ Amory (user • talk • contribs) 12:31, 1 September 2009 (UTC)

Thanks, Amory. In this case, this does sound pretty cool as an editing tool, so long as it doesn't, say, give older users or users with more edits higher color priority or something, as that article seemed to imply. 8bit (talk) 18:09, 1 September 2009 (UTC)

8-bit, the colors don't appear by default and are accessible in a tab for those who want to use the tool (try with [6]). I think it's an innovative idea, but I'd like to see a demo on this Wikipedia. Eklipse (talk) 20:16, 1 September 2009 (UTC)

The one problem I see is that some good editors could acquire an "unstable" rating merely by getting involved in edit wars over style, or because they're commendably trying to clean up and neutralize an oft-vandalized page like Barack Obama or Sarah Palin, while mediocre editors can appear sounder than they are merely by the accident of doing most of their work on poor but uncontroversial pages where style and format don't come up as issues. —— Shakescene (talk) 20:43, 1 September 2009 (UTC)

I could swear I remember this idea being suggested years ago by some random user...He should sue! :) ----occono (talk) 00:31, 4 September 2009 (UTC)

Proposal to transform the Audit Subcommittee into an independent committee and grant new responsibilities

Please see here for details on this proposal and preliminary discussion. It's proposed to transform the Audit Subcommittee into an entity independent of the Arbitration Committee and grant several additional responsibilities regarding the overseeing of the checkuser and oversight permissions. Cenarium (talk) 22:40, 1 September 2009 (UTC)

The question of the independence has been reported for later consideration, and there is now a proposal to add new responsibilities to the Audit Subcommittee and regularly organize CU/OS elections, also added to CENT. Cenarium (talk) 03:45, 3 September 2009 (UTC)

Search box at the bottom of the page

Is there any way a Search box could be added to the bottom of every page? If one gets to the bottom of a page and is using Firefox, you have to grab the scroll bar and scroll all the way to the top of the page to get to the Search box. This isn't a problem in IE, which allows you to right click on the scroll bar and request to go to the top of the page, but you can't do that with Firefox. Or, maybe even just a link that says "Go to the top of the page". Who then was a gentleman? (talk) 20:57, 2 September 2009 (UTC)

Your keyboard doesn't have home or end buttons ? —TheDJ (talk • contribs) 21:11, 2 September 2009 (UTC)

See also Wikipedia:Keyboard shortcuts. Alt-Shift-f goes straight to the searchbox in Firefox on Windows or Linux. PrimeHunter (talk) 21:16, 2 September 2009 (UTC)

I never knew those would do that. Thanks. Who then was a gentleman? (talk) 21:19, 2 September 2009 (UTC)

On my Mac, I can also usually just hit Tab to force focus directly on the search field (though it'll get thrown off by other form elements, such as the options on the Watchlist or Contribs pages). EVula // talk // ☯ // 22:08, 2 September 2009 (UTC)

Unsourced tables

Is there a template for marking a table/chart/graph as unsourced (for example, something you can put underneath the image or the {{bar box}} that would say something along the lines of "the sources of this table/chart/graph are unclear"? I couldn't find any. And, if there isn't, does anyone think adding one would be useful? I could create one fairly easily. rʨanaɢ ^talk/_contribs 21:02, 2 September 2009 (UTC)

What's wrong with using the standard {{citation needed}}? hmwitht 21:20, 2 September 2009 (UTC)

I was thinking for marking a whole table, or an image, rather than specific facts within it. (The one that got me thinking about this was the bar chart at South Korea#Religion.) rʨanaɢ ^talk/_contribs 05:20, 3 September 2009 (UTC)

Well, I figured that you could either add it at the end of the table or after the sentence describing what's inside the table right above it. hmwitht 13:43, 3 September 2009 (UTC)

PovWatch

I'd like to propose turning on an extension called PovWatch. It allows users to push problematic pages on to the watchlists of other subscribing users. Often I see reports on ANI asking users to watchlist a certain page that is having problems, so I feel that this could really help in certain circumstances, specifically those in which there BLP issues. This functionality is completely optional - you won't be affected by it at all unless you choose to subscribe. — Jake Wartenberg 02:13, 3 September 2009 (UTC)

• Support as nominator. — Jake Wartenberg 02:13, 3 September 2009 (UTC)
• Support the idea, assuming the release is stable (which it seems to be). Should be a nice addition to what we've got at the moment like Wikipedia:Neutral point of view/Noticeboard. Ironholds (talk) 02:20, 3 September 2009 (UTC)
• Support what seems to be an excellent idea. Individual opt-in + Useful functionality = Good idea. NW (Talk) 02:30, 3 September 2009 (UTC)
• Support per those above. This should prove helpful to our efforts. Lara 03:13, 3 September 2009 (UTC)
• Support This can be easily done by simply getting people to add articles to a listing page, and watching recent changes. No need for any setup. YellowMonkey (bananabucket) 03:17, 3 September 2009 (UTC)

  The problem with using related changes is that most people check their watchlists quite often, and would not check a second page as often, if ever. — Jake Wartenberg 04:04, 3 September 2009 (UTC)

  I do. See the links on my own user page. As a matter of fact, I hardly ever use my own watchlist any more.
  — V = I * R (talk to Ω) 04:59, 3 September 2009 (UTC)

• Support Seems like an useful tool for those who are willing to use it. Does it highlight the pages "pushed" there by others though? Otherwise, we should first get such a feature added as many active users (and especially admins) usually have thousands of pages watchlisted and will not notice a new page if it's not highlighted in any way. Regards SoWhy 07:38, 3 September 2009 (UTC)
• 'Support: I wouldn't use it (I'm just not that sort of person) but I know others who would, and find it very useful indeed. - Jarry1250 ^{[ In the UK? Sign the petition! ]} 11:11, 3 September 2009 (UTC)

Query. Based on the linked pages, I'm still not entirely clear about how this works, or how fine-grained the control is. Could someone post (or link to) a more detailed description of this extension? Specific questions I have include:

• Who will have access to this extension? Will editors with povwatch_user flags set receive the updates to their watchlists, while editors with povwatch_admin set be able to add pages? Who sets/removes povwatch_admin and povwatch_user flags? Will there be a way to exclude users or groups? Who will be able to see what pages are in the log? (Not to open a can of BEANS here, but I can see this as a delightful toy for a troll: "Hey, wanna make a nasty/libellous/obscene/privacy-violating/obnoxious message appear on every admin's watchlist? Just edit any of the pages added to povwatch...".)
• I get the impression that there's a single category of pages, and you either get all of them or none of them while you're subscribed; is that correct? Is this going to be a useful feature if it pushes to watchlists every controversial BLP, vandalism target, POV-pushing dispute, long-term fringe/pseudoscience battle, etc.
• Is the purpose of this features supposed to be used 'narrowly' — that is, just for BLPs? If so, do the proposers envision ultimately watchlisting essentially every BLP raised on a noticeboard, or will there be further screening? Will the usefulness of this tool be diluted rapidly once a few high-traffic BLPs make it on to everyone's watchlists? (Once Barack Obama and a few other high-profile names get watched, all the other, minor, third-tier BLPs will get lost in the noise of crowded watchlists. I'm concerned that even though those pages will be watchlisted, they won't actually be watched.)

I may come up with more later, but I'm not convinced at the moment that some of these problems won't cause more harm than good. TenOfAllTrades(talk) 13:35, 3 September 2009 (UTC)

• Support The example images have sysops putting pages on there, which seems like a good place to start, especially as any page that should be put on PovWatch is at the very least likely have some prior admin involvement or discussion. Any user dumb enough to vandalize on any of those pages will get to watch as they are simultaneously warned and blocked by 200 users and 20 sysops. These would quickly become some of the most-watched pages. I presume it would be used rather narrowly and for limited times - otherwise it would just become pointless. Suddenly everyone finds there is a dispute on a page, and in doing so they work it out, thus leading to the page being removed from the PovWatch list. It would kind of be a neat use of a new notification system. ~ Amory (user • talk • contribs) 14:30, 3 September 2009 (UTC)

Correct me if I am mistaken, but as I understand it there is no way to automatically unwatch pages that were added via the povwatch extension. Each subscriber has to manually remove pages from his watchlist, or it stays forever...? TenOfAllTrades(talk) 14:42, 3 September 2009 (UTC)

Oh, hmm. The way I interpreted it (based on this image) was that it was an all or nothing thing. You manually subscribe or unsubscribe to PovWatch, which puts or removes all those pages on/from your watchlist. You never watch the individual pages, just PovWatch. Kind of like a transclusion. ~ Amory (user • talk • contribs) 14:56, 3 September 2009 (UTC)

That's why we really need someone who knows how the extension works to offer a more detailed explanation before (and if) this goes live. SoWhy's point is also a good one. Through some pretty vigorous trimming, I have about fifteen hundred pages on my watchlist, and I know admins who have several thousand or more. If someone makes an edit without an edit summary (or with an innocuous one) and it pops up on my watchlist, it's not going to ring any warning bells in my mind unless I know that the article is on my watchlist for some important reason. TenOfAllTrades(talk) 15:10, 3 September 2009 (UTC)

Pure vandalism edits

I was just thinking that it would be nice to be able to mark pure vandalism edits as such, in a pages edit history. The benefit to that could be the ability to hide such edits if the viewer desires to do so (in the same manner as minor edits and bot edits can be "hidden").
— V = I * R (talk to Ω) 07:31, 3 September 2009 (UTC)

Well, who would mark the edits as vandalism? Sysops are too few, but if everyone could do it it'd be abused. Maybe based off of the rollback ability? It seems like the kind of thing that could easily be misused. ~ Amory (user • talk • contribs) 13:57, 3 September 2009 (UTC)

Maybe a flag this edit button on the edit page that allows admins to take a look at it.Accdude92 (talk) (sign) 14:03, 3 September 2009 (UTC)

(edit conflict) That's just more work for the admins, and not worth it. Also, if it were just based on around rollback, you'd miss shady uses of it. hmwitht 14:05, 3 September 2009 (UTC)

Maybe a new group of people that only have registered user power, and the power to deal with vandals.Accdude92 (talk) (sign) 14:10, 3 September 2009 (UTC)

huh... I've seen this thought process expressed before here. I'm not really sure how this could be abused, anymore then the "minor edit" flag could be and is abused. Everyone always seems to want new features limited to some select group or another as well, which I don't understand either. Ah well.
— V = I * R (talk to Ω) 14:13, 3 September 2009 (UTC)

The minor edit argument is, for lack of a better word, minor. In this case, however, I can easily foresee t3h ePIC LULZ that would be achieved by marking edits as vandalism, especially those reverting vandalism. ~ Amory (user • talk • contribs) 17:24, 3 September 2009 (UTC)

I honestly don't see why... maybe I'm just not explaining what I envision correctly? All it would do is exactly what the minor flag does now, which is basically nothing. Whether or not a particular edit, or even a whole series of edits, is marked isn't actually going to have any real impact aside from possibly making the use of that flag pointless.

While we're on the subject though, It would also be nice to be able to edit the minor flag. I know that I've either forgotten to click it or accidentally clicked it several times, and I know that some people will either always or never use it, so being able to edit them ought to increase their utility in most instances. Being able to edit my own edit summaries would sure be nice, as well.
— V = I * R (talk to Ω) 17:34, 3 September 2009 (UTC)

The difference is that people can only mark their own edits as minor. Unless we expect that vandals to mark their own edits as vandalism, this would mean that people could mark other people's edits as vandalism. Mr.Z-man 17:38, 3 September 2009 (UTC)

In which case it would be entirely unnecessary makework and inconsistently applied. –xeno^talk 17:40, 3 September 2009 (UTC)

There's an easy "fix" (in quotes because I don't see the above as an issue, but I recognize that many do) to that issue: Tie the use of the "vandalism flag" to the undo feature. Since pure vandalism edits are almost always undone, this seems to me to be an obvious choice.
— V = I * R (talk to Ω) 17:59, 3 September 2009 (UTC)

What we should do is give everyone the ability to roll back (well, all autoconfirmed users, or everyone who asks for it - and strongly encourage people to ask for it - but take it away from the minority who abuse it). Then we could make rollback the standard recommended way of dealing with vandalism, and record rolled-back edits as vandalism edits. This could be used for all sorts of purposes - filtering watchlists and edit histories as suggested here, and automated tracking/warning/blocking of vandals (though obviously no automatic blocks just because a lot of your edits got rolled back). Obviously you'll get occasional misuse, as you do with every WP feature, but that shouldn't be a reason not to do it when it could provide such benefits.--Kotniski (talk) 17:48, 3 September 2009 (UTC)

Is there a problem that this solution purports to solve? –xeno^talk 17:55, 3 September 2009 (UTC)

Yea, I guess. I'm not real clear on exactly what rollback is (an easy multiple undo, is the best sense of it that I have). My only real worry there is that it's not as transparent. Everyone can see reverts in thee history, and I think that is the way it should be. I just want a way to hide them in the history when their in the way, is all.
— V = I * R (talk to Ω) 17:59, 3 September 2009 (UTC)

Kotniski's suggestion wouldn't work. Native rollback is used for many other things other than vandalism (bots gone wrong for example, and some people use various edit-summary-changing scripts to use rollback in place of undo). I think that it's too complicated to do what you want to do. Even if it were tied to a rollback, then shouldn't the rolling back edit be hideable as well? –xeno^talk 18:06, 3 September 2009 (UTC)

(edit conflict) Yea, I think so. To be clear, all I want, and all I think is ever needed, is a dumb flag. Even if anyone could edit the flags of anyone else's posts, it wouldn't really be harmful. It may make using the flag on the edit history of that page somewhat pointless, but that's not really a big deal. That's also the reason why I honestly don't see is as an abuse issue. There's just no exposure provided by it, which is what vandals and trolls always really want.
— V = I * R (talk to Ω) 18:18, 3 September 2009 (UTC)

(1) Rollbacks are just as visible in the history as undos. (2) If there were an option to hide rolled-back edits, then presumably it would include hiding the rolling-back edits (this is obviously something for the developers to think about rather than us). (3) Obviously the software could detect whether the rolled-back edit was made by a bot, and adjust accordingly. (4) If someone changes the edit summary, the software could easily detect that. (5) It's not complicated - it would make things much simpler (well, it would give developers a means of making things much simpler for editors - vandals could be warned/reported automatically, so we wouldn't have to worry about that any more). (6) A few trifling concerns is no reason to say right from the outset "this suggestion wouldn't work".--Kotniski (talk) 18:15, 3 September 2009 (UTC)

eeech... "vandals could be warned/reported automatically" now I think we're getting in to real potential abuse area. I could just imagine some schmuck tagging 100 people and causing an uproar before being blocked.
— V = I * R (talk to Ω) 18:21, 3 September 2009 (UTC)

This introduces many layers of complicated interactions, with only very minor benefits. –xeno^talk 18:23, 3 September 2009 (UTC)

I think the potential benefits far outweigh the alleged complexity (it's not complexity anyway, it's - shock, horror - "something we're not used to"). And the "uproar" in the case described would be minor - let him do that, it's better than having him vandalize 50 articles (and we're talking autoconfirmed accounts here, not random IPs, so it's not going to happen every day).--Kotniski (talk) 12:55, 4 September 2009 (UTC)

Anyway yea, the proposal is to just add a simple flag, exactly like the minor flag, which we could add to posts. The simple implementation is to make it's use available when using the undo feature (to mark the edit being undone). The more involved implementation would be to ask to have the tick box on the edit page (I'm not sure what the correct name for this would be, but the version that you see when you click on the date link of an edit from the page history). That page could actually include check boxes for both, "minor" and "vandalism", and if it's your own edit, it could allow you to edit the summary as well.
— V = I * R (talk to Ω) 18:33, 3 September 2009 (UTC)

Yes, independently of the above more far-reaching idea based on popularizing rollback, I think this is a good idea. --Kotniski (talk) 12:55, 4 September 2009 (UTC)

another possible complication

I've seen "RVV" or "vandalism" in many edit summaries, when in fact that what was not what the reverted entry was. Sometimes it's pure disagreement or difference of opinion; sometimes the reverted editor was going by a different unit or spelling convention; and sometimes that editor had a different source of facts (sometimes more recent, sometimes older, sometimes just different). Often what seems obvious to the average reader (and thus the most recent editor-but-one) has been shown over extended discussion on a Talk Page to be inaccurate or imprecise, but that doesn't mean that the reverted edit wasn't made in good faith. The reversion might well be justified, but what was reverted wasn't necessarily vandalism. —— Shakescene (talk) 20:03, 3 September 2009 (UTC)

True, and I've seen the same issues myself. I simply don't see how that is a significant problem which this proposal needs to address. I see people "misuse" the minor edit flag constantly as well, but that's not a reason (to me, at least) to remove it.
— V = I * R (talk to Ω) 03:23, 4 September 2009 (UTC)

Quite. We mustn't throw out every suggestion for new functionality just because someone sometime might abuse or misuse it.--Kotniski (talk) 12:55, 4 September 2009 (UTC)

Organ harvesting poll

A poll has been created on whether Reports of organ harvesting from Falun Gong practitioners in China‎ is a standalone topic, or should it be merged to Organ harvesting in the People's Republic of China? Please go to Talk:Organ harvesting in the People's Republic of China/FG poll. Ohconfucius (talk) 14:04, 3 September 2009 (UTC)

I fixed that link for you. UltraExactZZ ^Claims ~ Evidence 18:05, 3 September 2009 (UTC)

Request move discussion {{otheruses4}} → {{about}}

I am requesting discussion on moving the common hatnote template {{otheruses4}} → {{about}} (or → {{otheruses}}) because the current name (with an arbitrary 4) is hard to remember and esoteric. I have started the discussion at Template_talk:Otheruses4#Request_move_discussion. If you are interested, please come to discuss whether the template should be moved and if so, to where. Thanks, -Sligocki (talk) 20:43, 3 September 2009 (UTC)

Deletion discussions with "No Conensus" as a result

There are some articles which were nominated for deletion and the reult is "No consensus". Should we then be given information about the default position being keepig the article? ACEOREVIVED (talk) 21:28, 3 September 2009 (UTC)

What information are you looking for? — The Hand That Feeds You:^Bite 22:51, 3 September 2009 (UTC)

I can give an example - if you look at the article on Bob Taggart and go to its talk page, you can see that the article was nominated for deletion in August 2009; the tag on the talk page just says "The result of the discussion was no consensus". I guess that I am really saying that this tag needs modification, so that it should say something to the effect of "The result of the discussion was no consensus, and therefore the article is being kept, as that is the default position". ACEOREVIVED (talk) 23:09, 3 September 2009 (UTC)

Isn't that sort of implied by how the article wasn't deleted? Mr.Z-man 23:32, 3 September 2009 (UTC)

[edit conflict] ¶ I think that, in general (and not just with –fD discussions), when no clear consensus for a specific, articulable change can be gathered, the bias is in favor of stability and thus no action. [For one thing, to echo Eugene V. Debs' refusal to lead workers to the Promised Land, if something can change easily one way without a firm consensus, it could just as easily change back in the other direction, resulting in ping-pong or a magnified but legitimate variation of edit warring.] There are many things that I, like any editor, might like to change, but the onus is on the innovators rather than (despite WP:Ownership) upon those who prefer to keep the status quo ante. But that's probably a philosophical point when you're asking something more practical. —— Shakescene (talk) 23:46, 3 September 2009 (UTC)

The template ({{oldafdfull}}) uses the "result=" parameter, with result being what we want, so we couldn't change the existing ones without massive edits. They are linked in the form {{oldafdfull|page=<pagename>|date=<date of nom>|result='''keep'''}} below the afd tag for easily copy/pasting them to the talk page. So it would be too much cost for a little benefit in any way we proceed. Cenarium (talk) 00:01, 4 September 2009 (UTC)

Link to the introduction instead of the community portal in the sidebar

Please see and comment here on this proposal. Thanks, Cenarium (talk) 23:03, 3 September 2009 (UTC)

Proposal: Always indicate length of block

(I am not sure if this is the right place for this proposal. I looked around but didn't find anywhere better...)

I have noticed that some "you've been blocked" messages that admins add to the talk page of a blocked user do not include the duration of the block. The length of the block can be found elsewhere, but it seems like a fundamental characteristic of the block and should be included in the blocked user's talk page entry. Is there some reason why it's not included? If not, I propose that the length of block always be included in such messages, and block templates be adjusted (docs and otherwise) to indicate the requirement. Alternatively, perhaps there is some way for the Wiki software to detect the length of the current block and the templates could be modified to use that mechanism and thus avoid the need for the admin to specify the information manually.

FYI, here is one recent example. (I am not criticizing the admin involved in that edit.) Here's is another example by a different admin who apparently added the length of the block by adding text that wasn't part of the template. — John Cardinal (talk) 15:49, 4 September 2009 (UTC)

Add more html tags... especially abbr and acronym

wikipedia has <code></code> <u></u> <b></b> <i></i> <s> </s> but is missing very useful tags such as CSS or <acronym title="North Atlantic Treaty Organisation">NATO</acronym> which would really help with the readability of articles. This would make it so users wouldn't have to scroll up to the top of the page to remember what an acronym stood for. Personally, I think all acronyms/abbreviations should use this tag. We could start by just enabling the feature.