Jump to content

Wikipedia:Village pump (proposals)/Archive 50

Add links
From Wikipedia, the free encyclopedia
Village pump (proposals) archive  

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

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

Rating Project Groups

Can I suggest that as well as being able to rate individual articles, Wikipedians should be able to rate project groups? I am interested in psychology (which I teach), and have been struck by how quiet the Project Group for Psychology seem to be compared with other Project Groups (such as those for Philosophy, Christianity, Religion or Spirituality). I shall be honest, and say that I do not think that the project group for Psychology would get more than a C at most. ACEOREVIVED (talk) 20:27, 9 July 2009 (UTC)I typed this yesterday (that is, July 9 2009) and now have feelings of misgivings about this proposal. Without going as far a total wishing to revert it, I can understand that it is problematic. As other Wikipedians are members of project groups, such ratings might be misconstrued as ratings of individual Wikipedians, and I am sure that if we were to lapse into doing this, it would not be considered good netiquette. So, I shall understand entirely if people would prefer to shy away from this idea. Many apologies if my earlier comments on the WikiProject group for Psychology upset any one - no offense to any individual Wikipedians was intended. ACEOREVIVED (talk) 21:28, 10 July 2009 (UTC)

You can usually tell how active a Wikiproject is based on talk page activity and how recently to-do lists have been updated. hmwithτ 13:39, 14 July 2009 (UTC)

I kinda like this idea. Grade each project according to how many members it has and how much work it is doing. Of course it would be a challenge to measure said work in a comparative manner. Rating Projects would help them improve and better organize themselves. Rating would also allow Wikipedia to know which areas need more attention from editors. As for the rating tarnishing editor's imagine, IMO this concern is not important.

Ratings would definitely stimulate projects to work harder and become more responsible over the articles belonging to them. EconomistBR 20:27, 15 July 2009 (UTC)

Wikipedia entry through text messages

Very often I come across the name of a person, place or thing I don't know about. My usual way of knowing more about it is to search for it in Wikipedia. But for that I need to be connected to the Internet. Wouldn't it be great if we could send a text message from my cellphone to a number with the topic that we want to know about and receive a short summary from its Wikipedia entry as a reply? —Preceding unsigned comment added by Wiki wiks (talk • contribs)

Who do you suggest establishes and pays for such technology, bearing in mind that the Wikimedia Foundation is a charity? ╟─TreasuryTag►Speaker─╢ 08:41, 11 July 2009 (UTC)
The user could pay for it - make it a premium rate number. --Tango (talk) 19:50, 11 July 2009 (UTC)
See [1] for an example of a third party providing such a service. Dcoetzee 09:40, 11 July 2009 (UTC)
Not really... they just offer to provide you a link to the Wikipedia page, requiring that one accesses the page as if one was Wikipedia. Sounds pretty pointless and a bit of a con to me. ╟─TreasuryTag►Not-content─╢ 13:53, 11 July 2009 (UTC)

Is your cellphone one that has internet access, as some do? ACEOREVIVED (talk) 19:46, 11 July 2009 (UTC)

If you text "G-O-O-G-L-E" (the numbers that coordinate with those letters), they send back information that answers almost any query. Commonly, it's information that's cited to Wikipedia. hmwithτ 13:32, 14 July 2009 (UTC)

Thank you, but who should you send this text to? For example, if you are with Orange, would you send it to Orange? ACEOREVIVED (talk) 19:01, 15 July 2009 (UTC)

You actually send it to Google. hmwithτ 20:07, 15 July 2009 (UTC)
i.e. 466453. –xenotalk 20:12, 15 July 2009 (UTC)

Quick Word Definition Roll-overs

Roll over a linked word to have a short definition (or its article's first paragraph) pop up. Saves having to visit the word's wiki page or use something like "define:word" in Google to quickly find out what that word means. Regarding the technology, it could utilise Javascript and JSON to cut down on extra load (i.e. loading a definition per word versus loading all the definitions per page) and be easily degradable for older browsers.—Preceding unsigned comment added by 58.108.194.58 (talk • contribs)

We could call them popups. Algebraist 12:52, 14 July 2009 (UTC)
You can install this Firefox addon to fetch dic. defs. from Wiktionary. --59.95.112.60 (talk) 10:56, 15 July 2009 (UTC)

Section reorder edit

Sometimes an article needs the sections reordered into something more reasonable. Unfortunately this means any diffs say practically everything has changed so it is difficult to see if some edit to the text has been sneaked in at the same time. What I'd like is an edit mode which could only reorder complete sections with perhaps a little extra functionality like renaming or changing the levels of the section headers. This would not change any text with sections, only move them around.

The edit history would say specifically that this was a section reorder and guarantee the text had not changed in that edit. Then people watching the page could be assured they didn't have to check everything.

A nice development would be to be able to show the reordering without showing all the text and a long term project for someone might be to incorporate knowledge about the section edit to do an intelligent diff before or after the section edit. An alternative is to detect moved blocks automatically with a better diff, though getting that right seems to be a continuing problem with diffs. Dmcq (talk) 22:08, 19 July 2009 (UTC)

Well one thing you can do is check to see if the size of the page has changed by more than a few characters. ♫ Melodia Chaconne ♫ (talk) 00:09, 20 July 2009 (UTC)
While I don't oppose this, I'd be inclined to believe that it doesn't come up incredibly often for most editors. Some editors might be more inclined to do this sort of thing than others. This might be something that someone can make a JS tool for (kinda like WP:HOTCAT), that can edit section names and reorder the ToC right there as you're looking at it. Even with such a tool, the diff will still look just as drastic. I'd say that the best way to avoid confusion is to use a very descriptive edit summary. ▫ JohnnyMrNinja 05:32, 20 July 2009 (UTC)
You probably want to try the cross-browser compatible wikEdDiff (also integrated into wikEd), a diff script that detects block moves and is usually better to read than the line-based standard diff view. Cacycle (talk) 12:30, 21 July 2009 (UTC)
Thanks very much for that. It looks like a very good solution to the problem of checking such edits and it does quite a good job of small changes within the blocks as well. And it only needs to be invoked when the straightforward diff is overloaded. Yep that does the job for me, thanks again. Dmcq (talk) 17:24, 21 July 2009 (UTC)

Alternative title display configuration

(moved from VPT:) According to this, if we set $wgRestrictDisplayTitle to false, we can display any string as the title of an article. This would presumably get round the annoying restrictions on use of special characters that arise occasionally, on pages using {{wrongtitle}} and so on, like The Singles 81–85. Is there support for doing this?--Kotniski (talk) 16:41, 19 July 2009 (UTC)

No, it would be a great vandalism tool. —TheDJ (talk • contribs) 17:17, 19 July 2009 (UTC)
So vandals could change the name of a page - so what? We'd change it back. Why would this be any worse than normal vandalism? (It ought to be much easier to detect.)--Kotniski (talk) 17:28, 19 July 2009 (UTC)
I only speculate, but I'd think that restriction exists so that it is always possible to copy&paste the displayed page title and use it as a wikilink. Amalthea 19:19, 19 July 2009 (UTC)
That's a fair point, but it's putting editors before readers, which is the wrong way round. Rather than have a big "wrong" title and a note underneath for readers saying what the title should be, we should have the "right" title as the header and a smaller note for editors saying what title to use for links.--Kotniski (talk) 09:20, 20 July 2009 (UTC)
This should probably be discussed at WP:VPR though, at a more abstract level, to see if there's support for it.
The javascript function that had been in place until recently ({{DISPLAYTITLE:}} can handle that on its own now) also allowed modification of article titles only if they were copy&pastable as a wikilink. You might want to have a look into the discussions that lead to the script.
Cheers, Amalthea 14:28, 20 July 2009 (UTC)
For reference, the old VPT discussion from 2006 & the resulting Common.js discussion. Amalthea 15:29, 20 July 2009 (UTC)

Any more thoughts on the above suggestion?--Kotniski (talk) 14:43, 20 July 2009 (UTC)

Please no. That would encourage people to just slap DISPLAYTITLE in an article instead of moving it properly. What we need is a proper escaping syntax for titles. Percent-encoding would fit in very well with out existing URL-like link syntax. For example, we should be able to type [[Wolfram%7CAlpha]] to link to the article titled "Wolfram|Alpha", as "7C" is the ASCII code for "pipe". This method would also make sure that in watchlists and logs, the title shows up correctly as "Wolfram|Alpha" instead of "Wolfram Alpha". —Remember the dot (talk) 02:20, 21 July 2009 (UTC)
Maybe you're just using it as an example, but I don't think "Wolfram|Alpha" is a correct title for a Wikipedia article. We don't change our typography to match the logo of a product. And perhaps this is a counter to the overall proposal: having advanced syntax for titles with all kinds of crazy characters in them would just encourage people to use that syntax in unnecessary ways. The vast majority of topics in Wikipedia can be named without using reserved characters. rspεεr (talk) 02:41, 21 July 2009 (UTC)
Benzo(a)pyrene looks like a better example of an affected article. The escaping syntax would work for all articles with this kind of problem, making the decision of what to call the article a purely editorial one. —Remember the dot (talk) 05:33, 22 July 2009 (UTC)
That would really only be an issue with those few characters that are currently unusable in titles. We can already have the titles REALTOR®, TIME, KISS, Macy*s, skate., Se7en. Extending the functionality of DISPLAYTITLE will only slightly broaden the possibility of abuse, so I don't think this concern applies here. Amalthea 06:36, 21 July 2009 (UTC)
People could abuse DISPLAYTITLE like that already: Have you ever seen it abused to correct capitalization of a name (e.g. John doe → John Doe)? I haven't. Extending the functionality of DISPLAYTITLE won't change that, so I don't think this concern applies here. Amalthea 06:36, 21 July 2009 (UTC)
You can't change "John doe" to "John Doe" because of the change in the capitalization of the D. If we opened things like this up, can you imagine how many titles like "John Doe" would be changed to "HAGGER WANT GRAP!!!!" in the blink of an eye? —Remember the dot (talk) 05:33, 22 July 2009 (UTC)
Eh, you're right on both accounts. That leaves me convinced, and I support a solution with escaped titles. Amalthea 05:39, 22 July 2009 (UTC)
I actually started a patch to implement this, but never finished it. If you e-mail the developer mailing list and voice your support, maybe the other developers would lend a hand. —Remember the dot (talk) 02:20, 21 July 2009 (UTC)
Is there something we could refer to to say we're supporting? And in general, is mailing this list a better way of getting through to the devs than Bugzilla? (I've always used Bugzilla for such requests, and been pretty frustrated with the (negative/lack of) response there.)--Kotniski (talk) 07:25, 21 July 2009 (UTC)
Welcome to a thing called open source software. :D —TheDJ (talk • contribs) 10:09, 21 July 2009 (UTC)
This issue has been filed as bugzilla:19872. Votes and comments would probably help get the developers' attention. I've had better luck with the mailing list, but hey, at least it has an official bug number now. —Remember the dot (talk) 05:33, 22 July 2009 (UTC)
Yes, the solution suggested in that bug report looks pretty cool. Let's hope it gets enough attention to be acted on.--Kotniski (talk) 05:50, 22 July 2009 (UTC)

Spanish Version of Wikipedia

I was looking around in the Spanish version of wikipedia when i noticed the spanish logo, It says "La enciclopedia libre" which means the free encyclopedia however "libre" refers to being free (as in liberty or not in bondage). If you want to say something is free (no cost or you don't have to pay) you need to use the word "gratis". Just wanted to let your people know in case you meant cost instead of freedom. If not just disregard this message. Thanks!

The ambiguity between the two possible meanings of "free" is deliberate; neither of them is the sole 'intended' meaning. As you note, however, many languages do not have a word that has both meanings, making translation very difficult. (also)Happy‑melon 13:59, 21 July 2009 (UTC)
We've even got an article on the distinction: Gratis versus Libre. --Carnildo (talk) 00:06, 22 July 2009 (UTC)

Changing how subcategories appear in category pages

This is somewhat hard to say coherently, but I will try. I personally find it rather counterproductive to have subcategories appear in the contents of categories in the same alphabetization scheme as articles. I know that I find it both difficult and less than useful to have to page through sometimes twenty or more screens just to see what all the subcategories of a given category are, which at present you sometimes have to do to see all the subcats, given the number of articles some categories have. Would there be any technical way to make all the subcats appear on the first screen of the contents of a given category? I personally think that such a change would make it much more likely that people will use the subcategories, and thus reduce the number of articles less than accurately placed in the larger parent category. I also think it will make categorization of subcategories, as well as creation of them where appropriate, easier and thus more likely. John Carter (talk) 15:49, 25 July 2009 (UTC)

You can get all subcategories to appear on the first page (indeed on every page) using the category tree hack described at WP:CAT somewhere, though that's not ideal. I think the reason they're done the way they are is so that eponymous categories appear on the same page as their corresponding articles. However as you've noticed, that's not usually desired behaviour in case of other subcategories. I made a feature request (T21281) which would solve the problem of eponymous categories in an all-round satisfactory way, opening the door to having subcategories at the start of the listing as we'd like. But of course, no-one's responded to that request - perhaps a few voices of support would get some developer's mind working in the right direction... --Kotniski (talk) 16:05, 25 July 2009 (UTC)
That function doesn't seem to allow that the subcats also display their own subcats, however, which I think would be at least useful. And having never actually commented on Bugzilla before, I am tentative regarding how to do so. Any pointers would be more than welcome. John Carter (talk) 14:02, 27 July 2009 (UTC)
Any "category tree" should allow subcats of subcats to be displayable, ad infinitum (you click on the + next to a category to see its subcategories etc.) On Bugzilla you just have to create an account (I think you have to give an e-mail address), then you can add comments to existing bug reports, or create new ones (they can be either bugs or feature requests, though the latter don't usually get much positive response), or "vote" for existing ones.--Kotniski (talk) 14:20, 27 July 2009 (UTC)

ANI page rename - discussion

A discussion about renaming the Administrators' noticeboard for incidents to a name that will be more intuitive to users.

Link

FT2 (Talk | email) 10:52, 26 July 2009 (UTC)

Create the Wikilympics

I propose that we create the first Wikilympics. Its the alternative for the WikiCup (it'll be held in the winter so it won't conflict with the WikiCup in the Summer). It'll follow the same rules of the WikiCup but there will be some difference: IP's are allowed to participate, Two flags for one person will be allowed, more points for each round, add "on this day..." for expansion of it, help for different wikis and uploading pictures. The winner will get a medal.

Support:

Neutral:

Oppose:

For More questions, respond on my talkpage. Secret Saturdays (talk) 01:07, 28 July 2009 (UTC)

Tag as "Major Edit"

Do you guys think it would be a good idea if the Mediawiki Foundation tweaked the editing interface to allow users to tag their changes as a "Major Edit," a complement to the idea of a minor edit? In the edit history it could be prefaced by a capital M where minor edits are prefaced with a small m. Alternatively or additionally, the text in the edit history could be bolded, or its row could be highlighted some color as decided on by the community. Abyssal (talk) 19:05, 19 July 2009 (UTC)

What you seem to be proposing here is that a simple division of edits into "minor" and "non-minor" is an over-simplification. One side of me likes this idea, although I would warn against making grading of edits too complex so that we do not confuse users. ACEOREVIVED (talk) 23:25, 19 July 2009 (UTC)
It's only three categories- minor, regular and major; two of which already exist. I don't think it's too complicated. Abyssal (talk) 04:42, 20 July 2009 (UTC)
Is there a problem that this would address? EVula // talk // ☯ // 04:46, 20 July 2009 (UTC)
No, not a "problem" per se, but it would make tracking the development of articles in the edit history of an article much easier. Abyssal (talk) 14:32, 20 July 2009 (UTC)
IMO "minor edits" should be marked as minor automatically, or not at all. I don't really see the benefit of marking as a "major edit", as the size change is a good indicator. What would a major edit qualify as? More importantly, why would people that are making such edits mark them as such? If they are trying to draw attention to the edit, surely it should have already been discussed, right? ▫ JohnnyMrNinja 05:40, 20 July 2009 (UTC)
Size change is not inherently a good indicator. If you replace a 7,000 character block of text with a very different 7,000 character block of text the net change is zero, yet the article has been strongly changed regardless. The purpose of marking as major edit is the same as marking as minor edits or edit summaries- it helps other uses keep track of article devlopment and history. Abyssal (talk) 14:32, 20 July 2009 (UTC)

My earlier comment was just warning against getting too complex with grading edits, for example, a Likert type ranking of edits on a five-point scale according to how major they are would surely confuse people. Can I just ask for clarification as to what you are saying would constitute a "major edit"? We would need to have a little piece of hypertext by the "major edit" box saying "What's this?" just how we do by the "minor edit box". ACEOREVIVED (talk) 05:57, 21 July 2009 (UTC)

I don't think there's any definition that could apply universally, it would all be so-context dependant. But, what I'm thinking of, would include major restructuring of the page, or additions that alter the page significantly (eg doubling its size.) Abyssal (talk) 02:36, 22 July 2009 (UTC)
Also, why would anybody mark an edit as minor? I think the major edit idea is good, for example, in the case of a major rewrite to an article. I don't think it is extremely confusing, but, this might be obvious, we need to make sure that only one of the choices, major or minor, can be selected, and not both. TheMushroomKing (Talk | Special:Contributions/Mr._Kite) 01:41, 28 July 2009 (UTC)

For non-administrators there is no link to delete an article or image, and it is very hard remember the process or appropriate place in the documentation. Could we add a "Delete" link (like Move/Edit) to the interface that redirects the user to the relevant documentation page? In particular I've been using the new "Vector" skin and a link would fit easily in the drop-down menu. For administrators the delete link could remain as it is. Barrylb (talk) 20:26, 19 July 2009 (UTC)

I'd like to pirate this thread, if I may (although in the absence of what I'm about to say, I think Barrylb's suggestion is good and should perhaps be done with site JavaScript). I'm currently overhauling the DeleteQueue extension, which is a (currently fairly skeletal) framework for organising the deletion of wiki pages into software-based queues. So you can have a 'speedy' queue that holds pages marked for CSD; a 'prod' queue for Prods, and a 'deletediscuss' queue for deletion discussions like AfD, MfD, etc. Discussion pages are automatically allocated, and there is a Special:DeleteQueue that has a bang-up-to-date list of all nominated pages. I think there is great potential for this extension on enwiki. My question is, what features do people want to see in such an system? A brainstorm from the community would be very helpful for me to guide developement. A few ideas that I'm already implementing:
  • Subqueues: while the main queues are defined in site config, administrators can create 'subqueues' that further filter results. So for the 'speedy' queue, we'd have a subqueue for each criterion.
  • Grouped discussions: there'll be a system to create nominations that share a discussion page with an existing nomination (brainstorm on how to prevent this feature being abused would be welcome).
  • Automagic notifications: when a page is nominated to a queue, a system message is subsequently included at the top of the page during pageviews. So the addition of {{afd}}-esque templates will become automagic.
Other thoughts and suggestions would be welcome. Happy‑melon 20:51, 19 July 2009 (UTC)
Commons has a "nominate for deletion" link that automates much of the process. Perhaps we should have something similar? --Carnildo (talk) 22:50, 19 July 2009 (UTC)
Can you point me where to see this feature? I am not familiar with it but it sounds interesting. Barrylb (talk) 00:07, 20 July 2009 (UTC)
Any image will have it at the bottom of the Toolbox on the left; for a sample, check out commons:File:EVula's beloved Vera.jpg. EVula // talk // ☯ // 04:48, 20 July 2009 (UTC)
Looks like it's just 'Twinkle-lite': a JS script (commons:MediaWiki:Quick-delete-code.js) that automates the process of nominating for deletion. (also)Happy‑melon 13:46, 20 July 2009 (UTC)
Ok, I tested it out and wasn't impressed! It just asked a simply question "why do you want to nominate this file" and didn't offer any guidance or policies. So I would like to have either a fully-guided process or, for now, a link to the process and guideline documents. I think the terminology is useful ("Nominate for deletion") and this is what I would like to see alongside the other links at the top for all users. Perhaps only in the new Vector skin though. Barrylb (talk) 00:48, 21 July 2009 (UTC)
Sounds like a job for a gadget or other Javascript. Twinkle and some other tools try to provide this service, already; might be good to refer this suggestion to them. – Luna Santin (talk) 06:50, 21 July 2009 (UTC)
I'll take something to Bugzilla and see what people come up with. Barrylb (talk) 02:10, 23 July 2009 (UTC)
A link to deletion policy shouldn't be a tab, at most it should go in the toolbox. We just need to make a simple link called "How do I delete this page?", right? I don't think automating deletion for everyone is a great idea, I do think that giving easy access to deletion policy and procedure on every page is. ▫ JohnnyMrNinja 02:27, 28 July 2009 (UTC)

Warn me if I'm not logged in

Why doesn't this happen? I don't want my IP to be all out and about, and I want to take credit for my work. >.> JPjuice23 (talk) 04:17, 20 July 2009 (UTC)

This could probably be a cookie thing, so if a registered editor is logged-out on their computer it could produce a warning. We certainly don't want to warn all IPs. The only problem I could think of is a public computer. Maybe the warning could be set as a preference? ▫ JohnnyMrNinja 05:36, 20 July 2009 (UTC)
There is a warning posted when you edit as an IP, but it seems it isn't intrusive enough. Preferences can't help with this, since preferences only affect logged-in users. One approach is to use javascript or CSS to significantly change the appearance of the edit screen when you're logged in (making the 'save' button a different colour, say), so you'll notice when you're logged out. Algebraist 05:41, 20 July 2009 (UTC)
Use a skin other than monobook? That way there'll be a noticeable difference when logged in and logged out :D (also)Happy‑melon 13:47, 20 July 2009 (UTC)
Yes, I was going to suggest this. If you use a different skin, then you would be able to tell if you were logged in or not. Who then was a gentleman? (talk) 20:01, 20 July 2009 (UTC)
I recall someone posted a nice little javascript you could install in your browser a while back to do this. –xenotalk 20:06, 20 July 2009 (UTC)
This might be a task for the usability study to consider, I think it is important. I bookmark "My watchlist" which will not display my watchlist when clicked if I am not logged in, that is how I make sure. I think having a single line Logged in as: Sswonk, or if not: Not logged in and the "Create account" link immediately below the "Save page" button would be enough to warn most people. Accomplished with display of "Logged in..." or "Not..." controlled via sitewide javascript? Sswonk (talk) 22:36, 20 July 2009 (UTC)
Puzzled by this, as I do get a warning: when I start the edit, a banner appears at the top. Here's a copy & paste from when I was just logged out:
However, its location isn't ideal as the session can drop while I'm editing so I would not necessarily see that banner when I'm about to hit Save. So, I support a proposal to relocate that warning, moving it right next to the Save button. Meanwhile: one thing I use to help warn me my session's dropped: the "minor edit" and "Watch this page" checkboxes don't appear if I'm not logged in. As they're located right there between the edit summary and the Save button, I'm quite likely to notice their absence now I know about this. Another thing is that even if you don't use a different skin, if you happen to like non-default settings (in my case, having the preview appear below instead of above the edit box; I think I unchecked "Show preview before edit box") then things look "wrong" when you're not logged in, so that's another warning I use. But as I say, I support a proposal to move the warning right next to the Save button. PL290 (talk) 13:47, 21 July 2009 (UTC)

I am not sure which web browser you use, but certainly, if you use Google Chrome,

you can normally put a tick by "Remember me" which will (for thirty days after you tick it) ensure that your username gets recorded, even if you have not logged in. ACEOREVIVED (talk) 20:32, 21 July 2009 (UTC) 

/* Turn the "Save page" button green if I'm logged in */
INPUT#wpSave {
    background-color:#88ff88;
}
  • Nice! I am now using this. But, at the risk of undue repetition: all these workarounds are great, but the value of the proposal is that all users will benefit, not just those who know about and apply workarounds. PL290 (talk) 21:40, 21 July 2009 (UTC)
I think it should bear a big red label, "Warning: Lark's vomit". - Denimadept (talk) 21:44, 21 July 2009 (UTC)
It sounds like you don't have an additional button that allows you to preview a section and show the footnotes for that section. I find that very useful, and it has the added advantage of making it easier to see if you're not logged in - you'll see only three (regular) buttons, not four. You'll find the script to install the button at User:Anomie/ajaxpreview.js. -- John Broughton (♫♫) 14:44, 23 July 2009 (UTC)
That is brilliant! I've wanted something like that for ages. Thanks for the link. Gwinva (talk) 02:41, 28 July 2009 (UTC)

Browing through page and wiki history

Sometimes when I am browsing through page histories (especially old page histories) and I click on links to other pages, it would be nice if the new page I clicked on chould show a page revision from roughly the same date. Sometimes given the context of the old page, it would be helpful to see what the other page looked at the same time. Besides, it would be an interesting way to browse the development of the wiki, see how things looked on such and such a date, watch how the wiki grew up. Is it possible for something like this to be implemented? --NickPenguin(contribs) 06:50, 28 July 2009 (UTC)

WikiProject TRANSWIKI

Hi. In light of recent events and community concerns about the way in which content is transferred I have proposed a new wikiproject which would attempt to address any of the concerns and done in an environment where a major group of editors work together to transfer articles from other wikipedias in the most effective way possible without BLP or referencing problems. Please offer your thoughts at the proposal and whether or not you support or oppose the idea of a wikiproject dedicated to organizing a more efficient process of getting articles in different languages translated into English. Dr. Blofeld White cat 11:50, 28 July 2009 (UTC)

User contributions prior to a block in block logs

Similarly to the article history prior to a protection linked in protection logs, it could be useful to have a link to the user contributions prior to a block in block logs. This would ease the search for informations on the circumstances and reasons for the block, though this may be controversial, as most block-related matters. What do you think ? Cenarium (talk) 21:07, 28 July 2009 (UTC)

Interactive applets for illustrating some articles

I don't have a firm proposal at this stage, more an idea that I'd like to throw out there for discussion. Has any thought been given to supporting embedded applets(e.g. those Java things you find on physics demonstration sites)? This would be extremely useful in illustrating certain articles in physics, maths and engineering. Of course we are currently using GIFs where applicable, however an interactive application could allow the user to specify certain parameters and see what influence they would have. Interactive apps also aren't limited to graphing. A calculation result may be just as illustrative.

A few concrete examples:

  1. In maths, changing the input parameters of a function to show how the parameter affects the graph e.g. graphs of real-valued functions, fractals, chaotic processes etc.
  2. In physics, illustrating random or chaotic processes e.g. temperature and thermodynamics
  3. In physics, illustrating Newtonian gravity e.g. planetary orbits or the classic "cannon ball" trajectory demonstration, adjusting the angle and initial velocity to see how the flight path changes.
  4. Some other things which we simply haven't thought of due to not having this functionality.

A couple of (difficult) questions to answer:

  1. Does the community support this idea?
  2. How can it be implemented? Is there an open source means of doing it?
  3. Is it possible to have graceful fallback to a GIF or some sort of static result for unsupported platforms?
  4. How would the apps be coded? Would it result in tons of requests to the programmers amongst us?

Thoughts and ideas welcome. Zunaid 12:33, 23 July 2009 (UTC)

You missed out question 0: would this be a gaping security hole? Algebraist 15:04, 23 July 2009 (UTC)
Such things would probably belong more on Wikiversity, which is explicitly about teaching, and thus the interactivity would make more sense. --Cybercobra (talk) 20:44, 23 July 2009 (UTC)
To answer some of the questions. The difficultly of implementation would vary significantly depending on how complex the system would be. Something where admins can just put Java code in the MediaWiki namespace where it can be complied, then used as an applet in a page wouldn't be too terribly difficult, but it would require people to know Java. If you want some sort of GUI based thing that almost anyone could use, that would be a lot harder. Fallback to a static image would likely not be too difficult. As for security, Java is executed client-side, so I believe the only security issue for Wikimedia would be things like compiler bugs that might be exploitable for DoS purposes. For client-side security, Java is designed to be run on websites, so I believe its about as secure as JavaScript, but I'm not a Java developer, so I could be totally wrong. A big issue I can see is a lack of Java programmers, though if use things like Jython, that could help. Mr.Z-man 21:06, 23 July 2009 (UTC)
The main problem I see is that Java applets in a browser create a usability flaw. It causes most browsers to freeze for seconds at a time just to load the runtime, and continues to slow down the browser just by existing. There are very few sites that use Java applets anymore, and it would be a mistake for Wikipedia to start now. rspεεr (talk) 06:27, 24 July 2009 (UTC)
No, most sites now use Flash, but that isn't open source or free enough to be considered for use on Wikimedia. Mr.Z-man 14:52, 24 July 2009 (UTC)
Java is faaaaar more secure than JavaScript. It's also much faster these days if you keep everything up-to-date. I know lots of websites that use applets, you just don't tend to notice. Couldn't bear to have slow-loading, closed-source Flash all over Wikipedia. And if you're in search of Java programmers... OrangeDog (talk • edits) 23:59, 28 July 2009 (UTC)

Edit screen clutter

Every edit screen includes boilerplate text below the edit box: eight or more lines of reminders and an often lengthy list of transclusions and categories. Can we give registered users the option to hide this extra text? This would simplify edit and preview screens, reducing page lengths and allowing quick access to the edit box using the Home or End keys.

Perhaps boilerplate could be placed in two collapsible sections (divs), one for policy reminders and another for transclusions and categories. We could optionally add a checkbox in My preferences to show or hide these sections by default. This would be more friendly and flexible than a monobook.css hack.

Hiding the extra text would make for less clutter, less scrolling, and more efficient editing. Pslide (talk) 16:56, 25 July 2009 (UTC)

Well, you could always hide the worst of it with something like this in your monobook.css:
#editpage-copywarn { display:none; }
div.mw-tos-summary { display:none; }
#editpage-copywarn2 { display:none; }
span.editHelp { display:none; }
span#minoredit_helplink { display:none; }
I personally like the lists of templates and categories (I even use a script to add more info to the template list); but if you want, div.templatesUsed { display:none; } and div.hiddencats { display:none; } will hide them too. Anomie⚔ 17:31, 25 July 2009 (UTC)
Right, the lists of templates and categories are occasionally useful, which is why I'd like to collapse/expand the sections on demand rather than permanently hide them. Thanks for the code though. Pslide (talk) 17:51, 25 July 2009 (UTC)

Here's a quick edit screen mock up – wouldn't this be cleaner and more convenient? Editors could show/hide policies and templates on demand, or set the default state with a checkbox in user preferences.

It would seem ridiculously easy to implement, since it's done here with just three extra divs per section. Pslide (talk) 12:04, 26 July 2009 (UTC)

1) NavFrame is deprecated. We use CollapsibleTables instead. 2) Adding those divs is not "ridiculously easy" because there are only limited places where there are editable system messages through which we can add the extra code. 3) This would, undoubtedly, annoy a lot of editors unless the default state of the collapse sections was totally cusomisable, which is again not trivial. And 4) there may be legal issues with hiding the copyright notice, although we'd have to ask Mike Godwin about that. Happy‑melon 15:44, 26 July 2009 (UTC)
And MediaWiki message pages are a mess in how links and other markup work. Wikilinks work on some message pages and not on others, and there seems to be no rhyme or reason. ---— Gadget850 (Ed) talk 15:48, 26 July 2009 (UTC)
Thank you both. In reply to Happy-melon: 1) Oops. Perhaps we should change the message at WP:NAVFRAME: "NavFrame is still useful for non-table content." 2) So ... it'll never happen? 3) The default would definitely have to be "show", to avoid surprise and annoyance like you say. 4) I was hoping that required legal language could be summarized and linked in one, permanently visible line, or that we could consent to policies just once, upon setting the default state to "hide". Wishful thinking? Pslide (talk) 18:17, 26 July 2009 (UTC)

Which one is "If you do not want your writing to be edited, used, and redistributed at will, ..." ? –xenotalk 15:08, 29 July 2009 (UTC)

That's MediaWiki:Wikimedia-editpage-tos-summary. The text is wrapped in a <small> tag with the id "mw-wikimedia-editpage-tos-summary" which is wrapped in a div with the class "mw-tos-summary". Algebraist 15:14, 29 July 2009 (UTC)
Ah, that's already up there above. Thanks! –xenotalk 15:15, 29 July 2009 (UTC)

Monthly mediator meetings


See User:Geoff Plourde/medcon for full information
I have considering the idea of monthly mediator meetings as outlined in the proposal. What are thoughts/questions critiques? Geoff Plourde (talk) 07:15, 29 July 2009 (UTC)

Last best revision

I check my watchlist by starting at the bottom; for each article I compare the last revision I checked with the current revision. If the current is better, I move on. Sometimes another editor is changing things, and I don't quite see where it's going - should I leave it and lose track of the revision I thought was better, or should I revert/'fix' and get in the way of the other editor? I also dislike having to open the history for each item - I never know if the last entry is the last-since-I-checked, or if there have been 5 new additions to look through in bulk.

The software has certain features which help us track important things. I want to track what I thought was the last best revision. This would be easy to implement since we already have a watchlist. It would let us leave articles to be checked later. We wouldn't have to go through the watchlist linearly - we'd pick an item, click 'compare to best', and then either mark current as best, fix it, or leave it the way it is without losing track of the "good" version. Perhaps this would reduce the number of reverts? I think that this would make watchlists substantially easier to manage. Yes, there are scripts that probably do something like this, but I think that this, like watchlists, should be handled by the wiki itself.

(It's difficult to get consensus for a lot of things at once, so this is just an incremental step that would even now benefit a large number of editors. But, if we implement this: There's a proposal above that you too should check out by clicking here for creating a recent changes page for unwatched articles. That proposal also has clear immediate benefits, but it's really there just to let us safely turn on the 'how many people are watching this page?' feature (which also has immediate benefits). If we then give editors the option to make their watchlists public, we no longer need flagged revisions: we'll be able to have automated tools that tell us how many people are paying attention to a page, if it's been checked by at least one editor/patroller, if many people prefer an earlier version, and so on. But all this is an aside.)

Summary: What are people's thoughts on being able to keep track of the last seen/approved/best version of a watchlisted article?    M   22:03, 16 July 2009 (UTC)

WP:Flagged revisions may address some of your concerns. hmwithτ 10:29, 17 July 2009 (UTC)
Yes, you'll see that I linked it above. Flagged revisions is a) misguided to begin with - we shouldn't be marking each revision, all we need is a pointer to the last acceptable version, b) not useful since it's only intended to be used against blatant vandalism, and c) not useful for managing individual watchlists, since it is per revision table entry, rather than using a field (already available!) in the watchlist table. How would flagged revisions help editors track what they consider to be the best versions, and how would it help with making the watchlist easier to use, as described above?    M   19:23, 17 July 2009 (UTC)
(responding to points) a) We don't need to mark each revision with flagged revs, if someone makes 5 edits, all good, only the last needs to be flagged. b) We can use FR for anything. Blatant vandalism is just the simplest proposal. c) What field is already available that this could use? Mr.Z-man 23:34, 18 July 2009 (UTC)
a) Is there a pressing need to mark revisions at all if we can just mark the page? b) Is flagged revisions a per-user feature, the way that watchlists or this last-best marker is? c) The currently disabled notificationtimestamp.    M   03:59, 19 July 2009 (UTC)
a) I don't understand the question. I'm not sure you know how FlaggedRevs works, as it works pretty similarly to what you're proposing, just not per-user. Most of the time with FR, people will just flag the current revision of the page. There's no need to flag non-current versions unless we have a very fine-grained flagging system. c) Just because its disabled on this site does not mean that we can go about repurposing it for something else. A feature that you can only use if you disable some other related feature is just strange and poor design. TBH, I really don't think knowing what revision a user says is the best would be particularly useful. It means nothing to readers, so I don't see how it can replace FlaggedRevs. People will have differing ideas of "best" - some users may choose the real best revision, while others will choose the most recent good version. It also depends on several users watching a page and all of them checking their watchlist often, whereas with FR, the flagging can be done during normal recentchanges patrol. Mr.Z-man 05:59, 19 July 2009 (UTC)
Suppose that flagged revisions allowed users to move a pointer, instead of creating a pointer. How many of the important use cases (preventing multiple checks, etc.) would actually be affected? (This is tangential to the current proposal, though.) Sure, ok, create another field, if you'd like. This proposal is just to allow individual users to track a (best) revision - one might see it as enabling the notificationtimestamp for manual use.
You open your watchlist, click compare, and see all changes. If you like them, you click update, and don't have to see that article on your watchlist until someone changes it again. And for any dispute, I suspect that having the ability to keep track of "your" version will prevent editors from trying to keep track of it by reverting to it.    M   19:03, 19 July 2009 (UTC)
FlaggedRevs basically does that. When someone flags an edit, it creates a pointer toward that revision as a "flagged" revision and if the edit is the most recent flagged revision, it moves the "latest stable version" pointer used by FlaggedRevs to determine what version to show to readers. Mr.Z-man 15:20, 21 July 2009 (UTC)
I don't think that most editors, for pages that they have watchlisted, want the pointer moved by other people in most cases.    M   18:53, 22 July 2009 (UTC)
Why not? What makes you think that "most editors" want to be solely responsible for patrolling and maintaining a page? I know I'm always delighted when the top watchlist entry is someone I know and trust to have vetted any edits hidden underneath their contribution; it means I can move happily on to the next page. Successful maintenance on this project is all about working together, not working in isolation. (also)Happy‑melon 12:06, 23 July 2009 (UTC)
I too am delighted when I don't have to check a page. I'd prefer it if the page didn't even appear on my watchlist when that happened, though. But that's beside the point. Most of the time, I open my watchlist and half of the entries I know I've already checked, though there's no indication of this. When I do want to check an entry, I have to go to history, try to remember which revision I checked last (often I forget), select it, hit diff. And then back to the watchlist to repeat this for the rest. This would let me essentially see changes since last check or approved version.    M   01:47, 25 July 2009 (UTC)
Wikipedia:Patrolled revisions. Cenarium (talk) 02:24, 25 July 2009 (UTC)
Your points are inconsistent. With FlaggedRevs in place, you would go to your watchlist and see all your articles; some of them would be in a 'flagged' state, where the top revision has been reviewed, and others would not, the two easily distinguished by the presence of a big bold red exclamation mark (or optional styles, etc). So you would be in a position to only review those articles that had not already been checked. Unless you only wish to consider your own reviews as 'valid', and would want to check those articles that have been reviewed by other editors. But you say that you don't want to do that. Which is it? Happy‑melon 11:28, 26 July 2009 (UTC)
For articles that I am passively watching for vandalism, review by other editors is fine, and useful. There are many articles, though, where not all editors agree that the current revision is the best. Will you rely on flagged revisions for all the articles in your watchlist? I certainly won't. I'd simply like a tool that lets me do what I already do with my watchlist, but more efficiently.    M   07:38, 28 July 2009 (UTC)
Someone asked for something similar at Wikipedia talk:Flagged protection and patrolled revisions#I.27d like to see personal flags. I noticed there's an option to mark all pages 'visited' for meta watchlists, and then changes since the latest visit are in bold. An enhancement would be the ability to mark pages as visited individually, and provide diffs since the latest visit. But as noted, this wouldn't replace the function provided by flagged revisions, it wouldn't allow to globally maintain a continuous and global monitoring of pages as would do patrolled revisions. Plus, there's the question of server space. Though this could be of a certain use, for reviewers, and non-reviewers. This wouldn't have the meaning 'latest best/good/etc revision', rather 'latest visit we are fine with'. Cenarium (talk) 16:40, 29 July 2009 (UTC)
Yes, that's pretty much it. The reason this could replace flagged revs is that because we don't need to mark every revision, a single per-editor revision would suffice. If we then query for editors in group X that have marked it, we get the same thing as flagged revs. Server space isn't an issue for this, it's just an (extra?) date field in the watchlist table. Because it's per-editor, the meaning is exactly what the editor wants. If you're fine with non-vandalism, great, if you only accept something after you've checked all the citations, that's great too.    M   18:32, 29 July 2009 (UTC)
This couldn't replace FlaggedRevs because, among other things, standards would diverge and it's anonymous, so there would be no indication to which standard the revision is held, so it would be unusable. Mistakes couldn't be corrected, too. It would be a good enhancement for the watchlist system, but wouldn't replace a global monitoring system. Cenarium (talk) 20:05, 29 July 2009 (UTC)

Appeal Committee

The establishment of an independent way of appealing ArbCom decisions, and certain community decisions has been discussed quite regularly. As of now, User:Jimbo Wales can appeal ArbCom decisions which doesn't concern himself. But this is not entirely satisfactory, because appeals cannot be considered by a single person timely, fairly and thoroughly enough, and it's not viable in the long term. The only 'appeal' method besides Jimbo Wales is to request for amendments to the ArbCom itself, which is not a proper appeal method because it's the same body that made the decision. There are also other roles that the Appeal Committee may take, which couldn't be conducted by a single person. The Appeal Committee could hear publicly or privately requests to appeal a decision by the Arbitration Committee, community sanctions and some administrative actions. When accepted, the community, the Arbitration Committee when concerned, and the concerned admins when relevant, should be informed, so that they can give their views or evidence, privately or publicly. It is proposed that the Appeal Committee can do some or all of the followings:

  • nullify an Arbitration Principle, Findings of Facts or remedy, or even an entire Arbitration case (for an example of a case largely nullified by ArbCom itself, see here), and overturning subsequent actions.
  • overturn an ArbCom decision that is not internal affairs taken outside a formal case, a motion or injunction
  • overturn, suspend with conditions or decrease in severity a community sanction, but only if there is no consensus in the community to retain the sanction as is. As of now, ArbCom has part of this role, with the dedicated ban appeal subcommittee, it would be superseded.
  • overturn a deletion, overturn or decrease a protection or block, but only if there is no consensus in the community to retain them as is.
  • Additionally, ArbCom may have to inform the Appeal Committee of the acceptance of private cases, as a safeguard. If desirable, for elections, the committees could appoint each other.

Decisions by the Appeal Committee are binding and final on en.wikipedia (with the exception of WMF directives), but are not necessarily permanent, and contradictory decisions can later been taken by the community and ArbCom. The Appeal Committee would be elected by the community, members would have to meet the access to nonpublic data policy and identify to the WMF, and could be granted CU/OS permissions, like arbitrators. No user could serve on both committees simultaneously. This is only a draft proposal for preliminary discussion, organizational details could be worked out later (the clerks and the announcement noticeboard could be shared, for example). Cenarium (talk) 02:09, 23 July 2009 (UTC)

And then we will need an Appeal Committee Appeal Committee, and then an Appeal Committee Appeal Committee Appeal Committee... The point of arbcom is to be the final step, the end of dispute resolution. I don't see any reason to make things even more complex and drawn out. Prodego talk 04:49, 23 July 2009 (UTC)
The point of the Arbitration Committee is to arbitrate disputes and issue binding rulings. It is theoretically the final step in dispute resolution, but already, it's possible to independently appeal ArbCom decisions, to Jimbo, and sometimes disputes are not durably resolved through an arbitration case (there are some disputes coming back regularly at ArbCom, the final decision is rarely 'the end' of the dispute). So the situation is not as you describe it. Yes, we would have two committees instead of one, but it will allow to put things clearer and redistribute power, and they could be related in some way (see below). The role of the 'AppCom' would not only be to appeal ArbCom decisions: ArbCom already appeals certain community decisions (with the WP:BASC), that power could be transferred to the Appeal Committee. It could also be used to appeal some admin actions. Cenarium (talk) 12:59, 23 July 2009 (UTC)
I agree with Prodego. I would also note, that by having a committee that can only repeal or reduce sanctions, users would have nothing to lose by appealing any sanction made against them. Right now users making appeals run the risk of ArbCom deciding that it was too lenient and increasing the sanctions. If an appeal committee cannot issue new sanctions or increase existing ones then the worst case scenario for an appeal is that nothing changes. That, plus the slightly higher likelihood of an independent group disagreeing with ArbCom compared to ArbCom disagreeing with itself, would likely lead to a significant increase in the amount of frivolous appeals, or worse, ArbCom just ends up being a required step before users can get a final decision from the appeals committee. Mr.Z-man 06:27, 23 July 2009 (UTC)
Prodego's argument would be fine if ArbCom acted only as a higher instance. But in practice, it itself imposes sanctions that have never been considered before (or never would be considered by any reasonable admin - would you give someone a 12-month editing restriction for a couple of minor edit-warring incidents that took place several months ago?) So to ensure the possibility of proper independent reconsideration, we should either restrict ArbCom to reviewing judgements that have already been made by admins etc. or instigate an appeals committee above and independent of ArbCom, as proposed. I prefer the first solution, but either would be an improvement.--Kotniski (talk) 09:22, 23 July 2009 (UTC)
I agree with Z-man; it is important to recognise that the court of last appeal will be considered as the ultimate 'target' in the majority of cases. I do agree, however, that it is preferable to have an appeal handled by a separate group to that which made the original judgement. My preferred method of achieving such would be by instituting two circuits within ArbCom: that way appeals to a case could be heard by the other circuit, and a fresh group of Arbitrators who were still kept 'in the loop' on the original case and so who would not have to spend as much time rehearing evidence. However, with the substantial decrease in the number of cases ArbCom has been accepting of late, the other arguments in favour of this division of labour have weakened, so I'm not sure if it's still a viable proposal. (also)Happy‑melon 11:35, 23 July 2009 (UTC)
The AppCom would not have to consider each appeals, it could refuse frivolous complaints, and we could impose some conditions, for example having already requested an amendment of the decisions to the ArbCom. So they would have to take the risk to have their sanction escalated by ArbCom. The two committees could indeed be related in some way, as long as they don't overlap; we could have two circuits, or for example a rotation of membership between the two committees, partial or complete. Now the question of the workload is important, it would be ridiculous to create an AppCom that has only to deal with two or three cases a year. But this is not the only job that this committee could do; they could, as described in my initial post, take the job of the ban appeal subcommittee, and appeal some admin actions. This would make a viable body, I think. Cenarium (talk) 12:59, 23 July 2009 (UTC)
I have a great deal of respect for you Cenarium, but I feel that you're really just rearranging deck chairs here. There doesn't seem to be a substantial gain. Watching the watchmen just creates the need for yet more watchmen. There is no division of labor, just one with veto power over the other. Who would get elected to arbcom will now just get elected to the appeal committee, and arbcom wouldn't be able to return to its core function without having the final say.--Tznkai (talk) 15:10, 23 July 2009 (UTC)
Saying that there should be one more instance doesn't imply there must be an infinite number of instances (slippery slope argument). The view is that just one instance is too few, and ArbCom has shown that it's prepared to act as the first and last instance. Might not seem important to you, but if you'd been a victim (as I feel I have, and others most certainly have - to the extent that good editors are driven away from the project by ArbCom's mistakes) you'd realise why this matters.--Kotniski (talk) 15:50, 23 July 2009 (UTC)
Its worth noting there is a small battalion of administrators, mediators, and plain vanilla editors - hell even bots - that get involved at multiple steps of the way before it reaches Arbitration. They are the final say, sometimes - an indefinite block done on administrator discretion is the final say far more often.--Tznkai (talk) 16:24, 23 July 2009 (UTC)
Yes, that's how it should be - then the blockee can appeal to other admins and to ArbCom. But if ArbCom suddenly throws a restriction at someone that no admin has ever or would ever consider, then that someone has nowhere else to go.--Kotniski (talk) 16:49, 23 July 2009 (UTC)
If the ArbCom does something totally unreasonable, there are still three routes available. 1) The community can refuse to enforce the decision -- this happened once in the early days of the ArbCom. 2) They can appeal to Jimbo. 3) They can appeal to the Wikimedia Foundation. --Carnildo (talk) 23:14, 24 July 2009 (UTC)
In practice, this doesn't happen. Some admin or clerk will apply the sanction, and it's unlikely to be overturned, and for processes or projects, we won't easily agree to shut them down, even if we almost never use them (example case: WP:BLPSE) or largely discredit them (example case: WP:ACPD). Appeals to Jimbo or the WMF are dreams. I don't know if Jimbo already appealed an ArbCom decision, he may have, but in any case, a person alone is not a valid appeal method. As for the WMF, they stay out of community decisions, and consider Jimbo and ArbCom as part of the community (me too, but some not !), so yes, theoritically they could, but practically, they won't; except in extremely exceptional circumstances we never saw and likely won't ever see any time soon. But this is an occasion to discuss appeal on Wikipedia, not simply of ArbCom decisions. I'll reply to the other comments later. Cenarium (talk) 00:32, 25 July 2009 (UTC)

(unindent) I don't feel Wikipedia is sinking, so why not rearranging deck chairs ? ;) This is simply a preliminary proposal like any other, but I feel we need to further discuss appeals on Wikipedia, this is a recurrent subject of contention. With respect to the ArbCom/AppCom relationship, being able to appeal a decision by a body doesn't make yourself a police/watchmen over this body. If ArbCom is 'the end', or more rightly 'the last step' in dispute resolution, then under this proposal it would be ArbCom + AppCom. I don't feel it would undermine the authority of ArbCom, but potentially make it stronger, since the endorsement of an ArbCom decision by an independent committee would actually reinforce it, while cases were an ArbCom decision would be overturned would probably be extremely rare and not without good cause. However, if this is deemed too controversial, we could not allow the body to overturn ArbCom decisions, but only admin- or community-imposed sanctions for which there is no community consensus to retain as is (and maybe also, deletions and protections ?), and ArbCom would have the final say in any case. So it would be a lower committee, and it could include a limited number of arbitrators in rotation like the Audit Committee, the rest being elected. I definitely feel it could be more efficient than appealing decisions directly to ArbCom, or the Ban appeal subcommittee, because arbitrators have too much workload, and for appealing those decisions to ArbCom, there are no well-defined guidelines, most are through private requests. This would be an occasion to set out clear guidelines. The standards for membership in the Appeal Committee wouldn't so high as those for ArbCom, because ArbCom would be the higher committee, and the Appeal Committee authority would be much more circumvented and lesser, so we would have more candidates likely to be elected. In effect, the later proposal would amount to transform the Ban Appeals subcommittee in a committee including arbs and elected non-arbs, with a specific policy. Cenarium (talk) 20:58, 28 July 2009 (UTC)

Just see there's been a discussion about this here, I'll try to work out a proposal. Cenarium (talk) 00:28, 30 July 2009 (UTC)

Publicity photos in media or press kits

This page Wikipedia:Publicity photos is currently inactive, yet the topic is significant in contributing pictures to Wikipedia articles. Wikimedia Commons has no interest in the fair use of images provided in media kits. There is immediate and pending interest to revive discussion regarding this subject and seek broader input via this forum/proposal page. Henry Delforn (talk) 22:50, 25 July 2009 (UTC)

Why ? Have the arguments changed ? Where is this immediate and pending interest coming from (a link might be handy) ? —TheDJ (talk • contribs) 23:31, 25 July 2009 (UTC)
The traditional arguments have always been that subjects would prefeer us to use their own publicity material (aka no legal risk), and also that such material is generaly of higher quality that user submited photos. While that might all be true it doesn't change the fact that such photos are still non-free in a copyright sense, as such it goes against one of the projects core principles to use such material except for the limited excemptions already allowed per Wikipedia:Non-free content. If a spesific use of a spesific photo can satisfy all the policy criteria then it may be used, otherwise it may not. There is nothing about publicity photos in general that merit any kind of special treatment. --Sherool (talk) 20:08, 29 July 2009 (UTC)

American perspective

Most articles are written in an american perspective, I've probaly noticed this since i'm Australia. For example an article explains the release of a new game, the article will then say some problems [about the game] occur in Perth, Australia and then it will go on to say that Ohio has some problems with it(the problem is, the sentence does not explain that ohio is in America). Now i realise most people who edit/read wikipedia are Americans but that dosen't constitute for an American perspective, there are ALOT of people that read english outside of America too. Before you reply, try to consider yourself living in another country reading this. I propose all articles be written in worldwide perspective. Thankyou--TUSWCB (talk) 12:01, 23 July 2009 (UTC)

Have a look at our guideline on systemic bias. It is a known and widely recognised problem on Wikipedia. You may also see some articles tagged with a banner that says something to the effect of "this article may not represent a world-wide perspective on its topic" or some such. Your proposal is not a proposal so much as a call to action. In essence there is nothing to be done but for non-American (non-Western, non-Anglophone, insert your favourite bias here...) editors to make changes to the offending articles, as I always try to do. You are an editor just as much as everyone else here is, just do it one article at a time. Zunaid 12:40, 23 July 2009 (UTC)
Thanks!--TUSWCB (talk) 05:37, 2 August 2009 (UTC)
The banner in question: {{globalize}} --Cybercobra (talk) 19:16, 23 July 2009 (UTC)
Or {{globalise}} :D Happy‑melon 19:18, 23 July 2009 (UTC)
Not to sound jingo or chauvenistic (and no chauvenistic has nothing to do with hating women, it means being overly nationalistic to clarify that before an idiot comments) the problem does not exist as badly as some are making it seem. Having 300 million Americans (most of whom do speak English) simply means we outnumber other English speaking countries (except of course India, but I'm havent seen many edit here, I assume they must be editing in other languages in large numbers, but not here). Being a great power, then a super power, and after the end of the Cold War we were given the label coined by the president of France- a hyper power, and who am I to argue with the president of France?, it has its perks. One of those perks is- having a larger population makes it more likely that something of importance or invention or whatever will happen or have its start by one of your citizens compared to happening in, say New Zealand. Being a great power means more likely a war or even minor occurance or anything is of greater value world-wide than in, say Nauru. Having a larger population means you have more professors, more publications, more sources from your point of view, and really we can ONLY use what the sources say, we can not start using OR to "even" things up and give a "world-view". If the sources are biased (and YES THEY ARE BIASED, I agree) then YES Wikipedia WILL AND MUST be biased. Wikipedia can not be MORE biased than the sources, but at the same time can not be LESS biased either. It must keep OR out. Yes, for good or most likely bad, American culture has for the past 100 years spread across and captivated much of the world. There are bigger problems in Wikipedia than an American conspiracy to take over Wikipedia and marginalize (marginalise? ;-) the rest of the world. For things like New York, saying it is in America is overkill, just as saying Sydney is in Australia is unneeded. This complaint is overused and has been mentioned over and over in just about every forum and on too many article talk pages already. It sometimes takes this form about having to clarify when a city or state or area is in the US just as we do for other countries. Yes, Ohio is not notable enough to get away with not saying it is in the US; Texas, California, New York are states that could get away with it. No one needs to clarify that Queensland is in Australia (and if an American thinks you do, send them to me and I'll bust them down for being retarded).Camelbinky (talk) 21:05, 23 July 2009 (UTC)
So what are you suggesting? If something isn't understandable by a person who doesn't live in the United States, it shouldn't be in the article? Are you requesting less content? Who then was a gentleman? (talk) 01:15, 24 July 2009 (UTC)
No, but our articles should not take it for granted that every reader parttake in what is considered "common knowledge" in the US. If an article is not understandable by a person who doesn't live in the US then the artcle fail miserably at educating the reader and should be improved to the point where anyone who have learned the English language regardles of cultural background can understand it. --Sherool (talk) 06:39, 25 July 2009 (UTC)
Any first mention of a place in an article should address it fully, up to the country, and link it if possible. Include city/town, county, state, country. - Denimadept (talk) 07:19, 25 July 2009 (UTC)
Which in turn hits the problem that such useage would be somewhat non standard in british english which tends towards assumeing that the reader has a fairly high standard of geographical knowlage.©Geni 16:49, 25 July 2009 (UTC)
Exactly. If an American inserts London, England, they're derided for their parochialism. Who then was a gentleman? (talk) 21:39, 25 July 2009 (UTC)
In which case we've got a British perspective. Let's assuming a total furriner...from France! What do they know?? Alternatively, just link the article for the location and let that article explain it, but for locations without an article, be explicit. - Denimadept (talk) 22:21, 25 July 2009 (UTC)
Could be worse. If they wrote Bude, England they risk starting an edit war.©Geni 15:58, 26 July 2009 (UTC)
Much of my article editing these days is simply putting in the words "United States", my knowledge of the US is sufficient that not only do I recognise all the states, but most of the two letter abbreviations or in some instances when only the city is included (I usually expand or include the state where necessary). Sometimes my edit summary is not "add nation" but "counter hickism"... LessHeard vanU (talk) 18:31, 26 July 2009 (UTC)
Sigh. Who then was a gentleman? (talk) 18:38, 26 July 2009 (UTC)
And LessHeard vanU some of my edits are removing such retarded edits as adding United States to things that dont need it. Any article that mentions the city of New York DOES NOT need to state it is in the United States, even in the first instance that NYC is mentioned, it is one of the cities of the world that does not require further explanation of where it is (London, Paris, Sydney are also on that list). This is per the standard for newspapers AND wikipedia. Im not a guideline quoter like some, so look it up yourself if you dont believe me, dont just state- Camelbinky your wrong. YOU prove me wrong. Anyways- I agree with Denimadept that YES just linking to the article and letting people LEARN is the best way than hitting them over their heads. Plus- why would a person from France reading English version of Wikipedia anyways? Wikipedia is not to dumb down to the lowest common denominator. LessHeard is claiming to be correcting "hickism", in reality all LessHeard is doing is WRITTING FOR THE HICKS to understand. If you dont know that Chicago is in the United States, reading Wikipedia is the least of your problems.Camelbinky (talk) 19:08, 26 July 2009 (UTC)
New York City isn't the whole of New York. That's just parochialism, that is. - Denimadept (talk) 19:41, 26 July 2009 (UTC)
Uh, ok, really?! Gee, being from Albany, the capital of New York, and one of two cofounders of the New York Capital District Wikiproject, I didnt know that the city of New York isnt the whole state!! Thank you so much for letting me know there are cities in my state that arent the city of New York. Now point out where I said otherwise and made that mistake in my post? And btw the name of the CITY is New York, NOT New York City, according to the city, the state, and the United States Postal Service. The name New York City is a stupid mistake copied through the years from when published material did not use parenthesis and therefore when distinguishing between the city and the state the names would be written as New York city and New York state (lower case to show it wasnt part of the official name). Over time idiots starting saying and writting it as if it was part of the official name. We dont write Michigan State, or Texas State even though there is a Michigan City and a Texas City. You have now had your history lesson, try calling me out again when you know your facts.Camelbinky (talk) 20:25, 26 July 2009 (UTC)
We are not writing the encyclopedia for those who know how to click links, and know that Chicago is in Illinois, and that Paris normally refers to the capital of France rather than a place in Texas, but everyone (including hicks). Another reason for placing the names of nations within the lead sentence/paragraphs is that it helps search engines; If you search for a city and use the nation as a parameter (because you are trying to find which State or county or whatever national subdivision used is) then you get a better/more accurate result. Lastly, a lot of people use WP to get the information they need from a single article - they are not interested in proceeding through links, and if they knew what some people assume they should then they likely would not be wanting to use this particular resource anyway.
Lastly, you seem to be more than a little adversarial. You might want to try and chill and see that adding what might seem obvious to you is actually the function of an encyclopedia - all the information is common knowledge to those who are expert in that particular field, but not so perhaps to the general readership. LessHeard vanU (talk) 21:55, 27 July 2009 (UTC)
Signal to noise has decreased to the point where this thread is unreadable. Please do not feed the douchebaggery. ▫ JohnnyMrNinja 01:02, 28 July 2009 (UTC)

That post above made no sense except apparently someone is insulting other editors. Call someone a douchebag again and you will be blocked.Camelbinky (talk) 07:10, 28 July 2009 (UTC)

Example. While an extreme, it is not rare - in this instance I was so dismayed that I just stuck a globalize template on it; I couldn't be bothered to follow the link. LessHeard vanU (talk) 21:38, 28 July 2009 (UTC)
Wow, yea, I have got to agree that the way that article was written it needed to be, in your words "globalized", and I use the word written in the most generic way as I dont think it met any standard of writing I am aware of. The problem, in my eyes though, is not that it needed to be written for someone from outside the US, it needed to be written for anyone outside the college sport field. Where the "f" is Baylor?! You can be an American and not know that. And apparently you can be an American and not know your own state's capital, but that is a different matter, and one that upsets me, stupid lazy Americans! I'm not against describing in an article where a place you are mentioning is located, but there are some places that writing style guides used by newspapers, book and magazine publishers, and yes here at Wikipedia state that they do not need qualifiers. Places like Los Angeles, Hong Kong, Sydney, London, Paris, Moscow. We dont need to muddy up and dumb down Wikipedia. Does everyone realize how long articles would be if we abandoned the blue links and had to explain out every word instead of allowing people to click on a link if they wanted to learn more? An NRHP building mentioned in a historic district article would have to be followed with a paragraph or two instead of just being linked to the building's article and a small sentence. We routinely break up articles into separate articles because of length requirements and have a link to the full article, see New York City for how many times a section is only a summary of some much larger article that fully explains the topic. We cant have every piece of information spelled out in every single article. There is also the weirdness factor of places being written out as "Albany, New York, United States" and the much more unweildy wordings that are out there for places when people decide to slap "United States" on the end of a description. Maybe my problem is there there is no accepted universal "right way" guideline in Wikipedia for that opening sentence on settlement articles to explain in a straightforward and normal-looking fashion where a particular city is, without it looking like someone came in and slapped the US label on the end of the sentence. Maybe if we can work together right now to come up with a good wording then I'd be more comfortable. And for the editor who said I'm "adversarial", um, yea, this is a DEBATE, that's what the other side does, it takes the opposing view and defends it with their points and facts and then attacks your side and discredits it. Ever been to a debate club in high school or a courtroom trial? Same thing.
I'm sorry, but how is it so difficult to click on the Baylor University link to see where Baylor is located? Is it that hard? And if you're worried about articles about American subjects being so difficult for non-Americans, take a look at almost any article about Indian or Pakistani subjects. I notice Harry Altham doesn't explain where Repton School or Oxford University are located. Should I toss a "globalize" tag on that for no particular reason? Who then was a gentleman? (talk) 19:23, 1 August 2009 (UTC)

To be honest this thread has gotten to a point where it's completley indecipherable. I don't think I care anymore, do whatever the hell you want. (btw i havent been around because my internet connection has been slow) --TUSWCB (talk) 00:30, 2 August 2009 (UTC)

Ok, this if for those who have attention spans of an adult and not ADHD- Whothenwasagentleman? first off, Oxford is not the same as Baylor just as Chicago is not the same as Darwin, Australia. Someone does NOT need to clarify where Chicago is (and ask any newspaper in any part of the English speaking world) whereas Darwin probably does, despite the fact it probably is on most globes, is historically significant from WWII, and is the territorial capital. I agree however that not everything needs to be explained, but really? not mentioning what city Baylor is in is ok? Really? You think so? You dont think it should state where the hell the college is? It isnt exactly Harvard, or even Yale, or (gasp) Princeton. Which even for those three unfortunately there are alot of Americans and people around the world who dont know where they are.
For those who think this thread it indecipherable, too long, or what-have-you. Then dont read it anymore, please stop writting stupid comments about how you cant follow it. That is not our fault. Read slower. Huked an foniks wherked four mee, et cann werk four u 2!Camelbinky (talk) 01:05, 2 August 2009 (UTC)
You neither addressed my comments on Repton School nor on why it's so difficult to click on the Baylor University link. Who then was a gentleman? (talk) 01:26, 2 August 2009 (UTC)
Ok, first of all, I'm trying to read everything (and stay on the TOPIC). To address Who then was a gentleman?'s comments, It could be at inconventence for an individual to follow a link, it's best to just explain the basic location.--TUSWCB (talk) 05:36, 2 August 2009 (UTC)

Addressing this question about whether or not to add national identifiers to locales, I'd like to point out a couple of things. First, omitting to say which nation a given place is located is not always chauvinism, but frequently simply being too close to the material to realize that it might not make sense to another reader -- whether or not that reader is a US citizen. Second, I think everyone would agree that if any passage in an article is unclear to an editor, it is likely to be unclear to many other people, & that editor is encouraged to edit that article & make it clear, whether it is simply the location of a given place, or any given explanation; if the edit is unnecessary, someone else will revert it, at which point all parties involved are encouraged to start talking about the matter. Thirdly, not all Americans are citizens of the United States: this noun is also correctly applied to citizens of Canada & Mexico, for example, & there are a number of active editors from those countries on the English Wikipedia. Lastly, the best solution for this problem is simple education: too many people simply strike out when they encounter a problem like this (& I'll agree that TUSWCB has a point), instead of simply assuming the other party might simply have made a mistake which she/he would be glad if someone fixed it. -- llywrch (talk) 07:10, 2 August 2009 (UTC)

The correct term for a citizen of the United States of America is American I am sorry if it is also a term used for someone who lives on the continents of North or South America. As the term for a citizen of a country ONLY the US uses that term for its citizens, and it is the only correct term regardless of what people in other countries want to use because they find it offensive that the US has taken it for themselves, the US was the first country on these two continents to become independent, being first has its advantages. Oh, yea, and so does being a superpower for the past 60 years and a hyperpower (in the words of the French President) for the past 18. Not our fault. History is written by the victors. The "noun is also correctly applied to citizens of Canada & Mexico" is WRONG, a citizen of Mexico is not called an American when you are talking about their citizenship. Only if you are referring to them in the manner we refer to Germans and Bulgarians as Europeans, in which case you now have to go yell at every editor on here who refers to East Asians as "Asians" because Asian applies to Israelis and Saudis, and Iraqis as well. And it is the reason we use terms like "North American" and "South American" (and sometimes Central American though one can argue they should be included as North Americans) instead of using American as a geographic demonym.
The whole reason we started this line is that THERE ARE CERTAIN CITIES THAT BOTH WIKIPEDIA AND THE GUIDELINES FOR NEWSPAPERS (INCLUDING THE AP) SAY YOU DO NOT NEED TO CLARIFY THE COUNTRY (OR STATE/PROVINCE). THEY INCLUDE SYDNEY, NEW YORK, CHICAGO, LONDON, MOSCOW. No article should clarify country for those cities when mentioning them. Furthermore- For countries like Canada, the US, and Australia the city should be followed by the state/province and NOT THE COUNTRY, if we are going to have bluelinks lets use them! If you have Perth, Western Australia then how stupid do we assume the average reader to be?! The purpose of the bluelinks are for people to learn more IF THEY WANT TO, no need to clutter articles with information for the retarded and bother those that actually know something. If you dont know what country Paris is, perhaps you should have to be forced to click the bluelink and learn something (probably for the first time in your life) because you are ignorant and possibly below 70 in IQ.Camelbinky (talk) 07:34, 2 August 2009 (UTC)
Camelbinky, there are only two points I can make in response to your misdirected rant. The first is that I am a US citizen, & my ancestral roots are very tightly tied to US history: they fought in the Revolutionary War, were part of the Civil War, were Yankee captains (one is mentioned in the classic Two Years Before the Mast), gave shelter to one of the Younger brothers, travelled the Oregon Trail, & panned for gold in California in 1849. Second, I disagree with you on several points you stated above. Take some time to think about these two points. -- llywrch (talk) 01:31, 3 August 2009 (UTC)

This is the second time during this calendar year that some one from Australia has observed the pro-American bias on the Village Pump - the earlier comment was that "Did you know" entries on Wikipedia's main page were often about U.S. matters. This led to an involved discusion, including comments to the effect of Wikipedia is written by many people in the United States, and as they will write about what they know about, a pro-U.S. bias is inevitable. I made the point then that Wikipedia is culturally biassed, specifically to Northern American and certain parts of Western Europe. I live in the United Kingdom where coverage of topics related to my home country is probably better than coverage of many parts of the world, but I did point out that this bias is inevitable as long as people are able to log on to the internet in certain parts of the world more than others. ACEOREVIVED (talk) 18:20, 3 August 2009 (UTC)

So are you suggesting limiting the number of Americans who can edit Wikipedia? Who then was a gentleman? (talk) 20:03, 3 August 2009 (UTC)

I still don't see why it's so difficult to click on the Baylor link, which clearly lets you know where the University is located. Who then was a gentleman? (talk) 20:04, 3 August 2009 (UTC)

In practice you could make the same kind of complaint about any term or for that matter any word in the article that someone might not understand without further explanation. Heck, off the top of my head, I don't remember where Baylor is. I really thought that one of the points of linking all those words was so that, if you didn't understand, you could click through and get things explained. This really is a job for WP:NOTPAPER; we don't have to cram everything someone needs to know to read the article into the article itself. Mangoe (talk) 20:20, 3 August 2009 (UTC)

In answer to Who was then a Gentleman:

I am certainly NOT suggesting that there should be any limit to the number of Americans, or for that matter, people of any nationality, who edit Wikipedia; I was just pointing out that, owing to where people in the world with internet connections are likely to be, there are likely to be cultural biasses on Wikipedia and indeed, many other websites. ACEOREVIVED (talk) 23:01, 3 August 2009 (UTC)

I'm sorry, I didnt understand Aceorevived comment. But if we are to state how long our families have been in the US, well mine have been here since the 1600s (came in through Philadelphia) before there was a US, and there have been books written on my family's history about our time here and before we came over, in fact I'm directly descended from over 50 individuals that have articles in Wikipedia. How is that at all relevant to my "rant" in which I was answering the individual who commented TO ME that American was not the term for a US citizen but instead was for Canadians and Mexicans as well. My "rant" was directed to that individual informing them of their MISTAKE, they were WRONG.Camelbinky (talk) 23:18, 3 August 2009 (UTC)

Peren?

Can we add this one to peren, on the basis that when it does come up, it generates an excessive amount of often hostile and non-productive discussion? These things really just need to be directed to the systematic bias page.    M   23:24, 3 August 2009 (UTC)

Tips to avoid editing logged out

Some editors are very distressed by the possibility of accidentally editing while logged out, thus inadvertently revealing their IP address. In most cases it's not a big deal, really, but it seems very important to some people. I've noticed a few regular tips that can help avoid this, and was thinking it might be a good idea to collect them in one place, either as a new {{infopage}} or as a supplement to some existing page.

So, a few questions:

  1. What might such a page be called? Wikipedia:Tips to avoid editing logged out is wordy.
  2. Does any current page seem like a decent home for this content?
  3. Does anyone have tips to add to the collection?

Currently I can only recall a few such tips. First, and the one I use, apply some special style to the user interface in your custom style sheets (in my case, the save button) that will quickly indicate whether you're logged in or not. Second, get into the habit of checking your watchlist first thing, probably even from a bookmark, since it will fail to open if you're logged out.

Anyhow, just a thought. Any suggestions? – Luna Santin (talk) 09:14, 3 August 2009 (UTC)

Handy tip: Take "We could not process your edit due to a loss of session data" as a warning that you are no longer logged in. - Jarry1250 [ In the UK? Sign the petition! ] 09:30, 3 August 2009 (UTC)
Your first tip is a good one. I checked out the alternative skins, and didn't see any that were a clear improvement, so I'm using the standard. I may have to switch just so I can change a color, although this feels like a kludge, not a solution.
Regarding your second suggestion, it either doesn't help, or I'm missing something. The first thing I always do is check my watchlist. That does guarantee I'm logged in, but doesn't prevent me form being logged out—something that happens quite often. I can't identify all the reasons I get logged out, but I have identified one. I log into the secure server. If I follow someone's link to another page, whether policy, or article, or talk page, it often is not on the secure server. Then I have a Wiki page open, but I'm not logged in. If I don't look up at the top of the page EVERY time, I might find I've accidentally edited without being logged in. Changing my skin color will help, but I'm surprised that such a common event as opening a new tab, something I do several hundred times a day, would give me a page where I'm logged out. Is this truly the intent, or am I doing something wrong?--SPhilbrickT 13:53, 3 August 2009 (UTC)
This is fantastic if you use FireFox: http://userscripts.org/scripts/show/7209. -- Avi (talk) 14:42, 3 August 2009 (UTC)
Thanks Avi, that worked--SPhilbrickT 16:41, 3 August 2009 (UTC)
My pleasure. -- Avi (talk) 16:43, 3 August 2009 (UTC)
Adding &assert=user to the end of the edit URL would also cause the save to fail if you're logged out. -Steve Sanbeg (talk) 17:01, 3 August 2009 (UTC)
We already have Help:Logging in which is where I refer help desk posters who logged out unintentionally. I think additional tips should be added to that and not a separate page. It should probably also mention Wikipedia:Requests for oversight. Wikipedia:OVERSIGHT#Policy added in December 2008 [2]: "This includes hiding revisions made by editors who were accidentally logged out and thus inadvertently revealed their own IP addresses." PrimeHunter (talk) 17:15, 3 August 2009 (UTC)
Good place. I have been considering some of the same thoughts. ---— Gadget850 (Ed) talk 00:37, 4 August 2009 (UTC)
Now started at Help:Logging in#Editing while logged out. ---— Gadget850 (Ed) talk 17:27, 4 August 2009 (UTC)

Depreciation of "Future" templates

I have started a discussion on the possible depreciation of the "Future" templates at Wikipedia:Centralized discussion/Depreciating "Future" templates, and would welcome comments of all kind. --Conti|✉ 16:25, 4 August 2009 (UTC)

Do you mean deprecation? Algebraist 17:52, 4 August 2009 (UTC)
Eh, probably. :) --Conti|✉ 18:01, 4 August 2009 (UTC)

Whenever I read really good WP articles (e.g. featured articles), I'm caught off-guard by the lack of citations in the Lead. The policy makes sense, but it can have some weird side effects:

  • In the July 22 in-the-news piece, Solar eclipse of July 22, 2009, we are explaining the use of "longest" with a hyperlink to an internal section, Solar eclipse of July 22, 2009#duration. But it looks like I should expect a definition of the word "longest."
  • In today's featured article 243 Ida, there is a sentence in the Lead, "Its surface is one of the most heavily cratered in the Solar System", that struck me as wildly speculative; I was about to point this out at the talk page until I remembered our Lead policy. Indeed, the section "Craters" contained the verification.

My proposal: when I'm making a claim in the lead, I should be able to insert a discreet, downward-pointing, superscript arrow↓ (not necessarily this particular arrow -- just some alternative to the [2] or the [3]), thus indicating an internal (downward) wikilink pointing to a header/anchor in the document below.

If this requires a template, would someone program it for me?

Or should I just move this proposal, and my silly arrow↓, to WP:LEAD?

Agradman talk/contribs 04:19, 29 July 2009 (UTC)

WP:LEADCITE says to use citations when needed in the lead just as in any other section. Anomie⚔ 11:02, 29 July 2009 (UTC)
From WP:LEADCITE:
The necessity for citations in a lead should be determined on a case-by-case basis by editorial consensus. Complex, current, or controversial subjects may require many citations; others, few or none.
It also says that if something is challengeable, it needs to be cited, no matter where it is, and that the only reason why lead sections are "special" are because of their generality. I dream of horses (T) @ 02:05, 5 August 2009 (UTC)

Bot of the month.

So I got to thinking after browsing through some WP:Bot pages that maybe we can have a featured bot of the month? This would be almost like the featured article process. People would vote for a featured bot status based on the following criteria: (1) How effective the bot is, (2) The different array of tasks a single bot handles, (3) If it has ever malfunctioned, if so, then completely fixed, and (4) Just an alround great bot! The criteria needs improving, but hey, it's a suggestion! The featured bot would be posted on WP:Bot and hopefully the mainpage of wiki.riteme.site. What do you guys think? Wii Wiki (talk) 02:40, 31 July 2009 (UTC)

You could do something like that in your userspace I think (just like "Awesome Wikipedian of the day", you could start an "Awesome bot of the month" program if you want), but these things certainly don't belong to the Main Page. Main Page is strictly for assessed encyclopedic content. --59.95.122.164 (talk) 09:42, 31 July 2009 (UTC)
I think both suggestions are great. If we drop the "of the month" part, I'd support it being on the main page. Just having a "featured bot" is a grand idea. I dream of horses (T) @ 01:58, 5 August 2009 (UTC)

Button/box links instead of text links on the "for this specific page click here"

For example, if you type help desk in the search box (which is how I always find it, I cant find it any other way) you will get to this page Help_desk. you see these two lines of text


For the help desk of Wikipedia, see Wikipedia:Help desk

For the webcomic, see Help Desk (webcomic).

Wouldnt it be a bit more tidy to make some type of button or box like the box that shows Refimprove|date=September 2008 with brackets instead of just text with links?

Ivtv (talk) 04:18, 1 August 2009 (UTC)

Seems unnecessarily disruptive to the look of the page. --Cybercobra (talk) 04:43, 1 August 2009 (UTC)

I think the links are worse. but thats just my opinion. thanks for the reply Ivtv (talk) 05:20, 1 August 2009 (UTC)

You can actually get to help desk via WP:HD. There's often a white box to the right (I think) showing such "short cuts". I dream of horses (T) @ 01:49, 5 August 2009 (UTC)

Multiple Watchlists

Would it be possible to have Multiple Watchlists? It could be useful.----Occono (talk) 19:36, 4 August 2009 (UTC)

You might like to search the archives of this page for that one. IIRC this particular topic has been discussed a great deal, looked at from a number of different angles and many peoples' thoughts contributed. They may even be a few implementations of fit hanging around you could use. - Jarry1250 [ In the UK? Sign the petition! ] 19:40, 4 August 2009 (UTC)
Okay, thanks. Sorry I didn't search, I just looked in Perennial proposals.----Occono (talk) 19:42, 4 August 2009 (UTC)
Oh sure, and sorry if that came across a little strongly, I didn't mean it, honest :) - Jarry1250 [ In the UK? Sign the petition! ] 19:45, 4 August 2009 (UTC)

Also, see this. ╟─TreasuryTag►constabulary─╢ 19:42, 4 August 2009 (UTC)

Thanks. And it didn't come off strongly Jarry, I just say sorry a lot.----Occono (talk) 19:57, 4 August 2009 (UTC)

Charity forks

The people behind Gives Me Hope have created a fork of Google called Givoogle that uses the Google search engine and a similar webpage interface, but features advertising whose revenue is given to charity. I thought it would be really cool if a fork of Wikipedia could be created that could similarly use advertising to raise money for things like educational charities. Abyssal (talk) 19:04, 19 July 2009 (UTC)

Many mirrors exist, and such a program is easily done, as all content here is free. The WM Foundation already is a non-profit, so I for one would be irritated if they started a separate project of their own to raise money for another one. If they do any sort of ads, I'd like it if the money went to bandwidth and the like. ▫ JohnnyMrNinja 05:46, 20 July 2009 (UTC)
Why would you be "irritated," isn't benefitting the education of the public our goal? Abyssal (talk) 14:51, 20 July 2009 (UTC)
JohnnyMrNinja would be irritated because the Foundation, as an educational charity itself, could itself use any money generated from advertising to further our mission. That being said, advertising is already a contentious issue that isn't likely to be implemented unless the Foundation is in financial danger. {{Nihiltres|talk|edits}} 14:50, 23 July 2009 (UTC)
Which is why I said charity fork and not "Hey, let's put ads on Wikipedia." Abyssal (talk) 22:02, 23 July 2009 (UTC)
Thus my use of the phrase "contentious issue". While the money would be nice, the public relations consequences wouldn't—the idea of the Foundation profiting from advertising for third parties doesn't look good no matter which site is used for it. {{Nihiltres|talk|edits}} 22:19, 24 July 2009 (UTC)
I proposed raising money for other charities with a fork, not raising money for the Wikimedia Foundation on the main site. Abyssal (talk) 01:31, 25 July 2009 (UTC)
I didn't see you had responded. Yes, my point was that I'd be irritated if WM raised money for a project other than WM, if that makes sense, as WM is a non-profit. Otherwise, it is entirely possible for any non-profit to host their own version of WP with a database dump, as all the content is free. This would, of course, require hosting and bandwith and all of that, and require people to go there in the first place. What might be neat is to just create a separate interface for WP with Google ads on it. Maybe a skin/js. ▫ JohnnyMrNinja 01:48, 25 July 2009 (UTC)
Interesting idea. How would it work? Abyssal (talk) 03:27, 25 July 2009 (UTC)
Back in the 90's I remembered that there was this program that paid you a very small amount for looking at ads while you were on your computer. It shouldn't be that hard for someone to make a skin that people can load that brings up Google text ads related to the content on the page, should it? Then the funds can be sent to whatever charity. The problems are 1)getting it made, 2)getting people to use it, and 3)it wouldn't be very much money. ▫ JohnnyMrNinja 17:54, 25 July 2009 (UTC)

WIkipedia:Appeal Committee

There is now a proposal to create an Appeal Committee for sanctions imposed by administrators or the community, modified from this thread. Comments and suggestions are welcome. Cenarium (talk) 01:35, 30 July 2009 (UTC)

Special:Audiosources

We have Special:Booksources for providing access to many different search engines for ISBNs. Has there been any attempt to do the same for sources for recordings? Major modern recordings have similar unique identifiers. +sj+ 23:46, 30 July 2009 (UTC)

Move all Wikipedia: namespace pages in (disambiguation) format to /subpage format

I think this was brought up for the VP earlier, but I'd like to bring it up for all of EN. I think we should take full advantage of our software by moving all Wikipedia: namespace pages with (disambiguators) (pretty sure that's a real word) to /subpages. I mean to change pages like Wikipedia:Naming conventions (long lists) to Wikipedia:Naming conventions/Long lists. The benefit of the subpage is the backlink created at the top, a more consistent search criteria, and a clear hierarchy/grouping of policy pages. Article space is not hierarchical, but often times WP space is (notice the text of the template on the Manual of Style). I am well aware that "it ain't broke" and it is a "solution looking for a problem" (BTW, so was the laser), so please actually consider it before responding. The annoyance of actually moving the pages will be slight, and the appearance will IMO be more attractive and organic to an online encyclopedia. It's a shame and a waste to leave subpages for user "secret pages" and template documentation (and, of course, WP:AN/I). ▫ JohnnyMrNinja 05:12, 1 July 2009 (UTC)

By using disambiguators, we're matching our naming conventions for articles, which I don't think is a particularly bad thing. You already mention the "it ain't broke" argument, but really, that's what it comes down to. Your arguments aren't particularly compelling (the "search criteria" bit is a total non-issue, since it doesn't affect how one searches for anything in either direction). *shrug* I wouldn't be upset if it happened, but I just don't feel that passionate about it one way or the other. :) EVula // talk // ☯ // 21:05, 1 July 2009 (UTC)
My search comment was rather half-formed; they do affect the search when using a prefix: search, like in the box at the top of this page, although the two options (when properly titled) are very similar for this. This was more of a comment of support for subpages in general. The ethnic and religious conflicts is a great example of a page that has benefited form being moved to a subpage of WP:AN (from an unrelated title), with much increased traffic because of the clear association, which also falls under the same search parameters as WP:AN and WP:AN/I.
You mention that we would be using a different convention for WP page than article pages. This is a very good point. The use of parenthesis down-plays a word. There is no game called Conan (2007 video game), it is a game called Conan that we have disambiguated. Conan/2007 video game would be improper, putting undue weight on the made-up qualifier. Wikipedia-namespace pages are totally different. These pages are 100% self-referential. Wikipedia:Manual of Style (biographies) is called Wikipedia:Manual of Style (biographies). There is no reason to down-play the thing that makes a WP page unique, and that particular page would sit better at Wikipedia:Manual of Style/Biographies. ▫ JohnnyMrNinja 04:32, 2 July 2009 (UTC)
How is that going to work where the disambiguation page itself is not located at the primary topic, and other pages naturally located on the disambiguation page do not have disambiguators - e.g. George Washington (disambiguation) and George Washington University, which is certainly ambiguous, but is the official name of the institution, making it inappropriate to locate it at "George Washington (University)" for example. bd2412 T 04:43, 2 July 2009 (UTC)
There is no need to move most of the pages in that format. Keep in mind that I am only talking about project pages here, not articles. I don't think that WP:Administrators' noticeboard should be a subpage of WP:Administrators even though they start with the same word. Some articles with different titles would do well as subpages, but those should really be handled on a case-by-case basis. For now I am only talking about pages that actually have disambiguators. If you are talking about articles, I think that subpages for articles are a very bad idea. ▫ JohnnyMrNinja 13:25, 2 July 2009 (UTC)
My bad, I misread it. I have no objection to moving pages in project space to subpages of the appropriate project. Not sure I see a need for it, but no objection. bd2412 T 19:31, 31 July 2009 (UTC)
I agree with JohnnyMrNinja - This page, for example, isn't a disambiguated page from Village pump, it's a subpage of it. George Washington (disambiguation) isn't a subpage of George Washington. עוד מישהו Od Mishehu 07:11, 2 July 2009 (UTC)

It looks like some small consensus is forming, but it certainly isn't formed yet. I'll ask around for some more opinions. ▫ JohnnyMrNinja 02:16, 7 July 2009 (UTC)

This seems reasonable for things like the VP, MOS, naming conventions, etc. It really makes more sense then the current setup, IMO, and some pages like Project:Reference desk already use subpages. –Drilnoth (T • C • L) 02:28, 7 July 2009 (UTC)
I also think this seems reasonable, but I don't think it's that urgent. I won't object if people start doing this. As long as the same shortcuts we're all familiar with redirect to the same guidelines they've always pointed to, it really doesn't matter to me.--Aervanath (talk) 03:29, 7 July 2009 (UTC)
Thanks for clearing up the section title. It was not my intention to imply any urgency in applying any consensus. I wanted people to respond before this dropped off the page. :) ▫ JohnnyMrNinja 03:34, 7 July 2009 (UTC)
  • Oppose. This seems to be a solution in search of a problem - where is the problem currently, exactly? Do people have difficulty finding pages? Fixes should have problems they're designed for, and I'm not seeing one. It seems excessive to move the namespace to a different standard from the mainspace (thereby confusing more people, which undermines your "ease of use and clarity" argument somewhat) and go around the whole namespace moving stuff as an answer to a problem I can't see. Ironholds (talk) 06:47, 7 July 2009 (UTC)
  • Weak support. The analogy with articles is wrong. "Quark (cheese)" and "Quark (kernel)" are not subtopics of "Quark" but totally different subjects which just happen to have the same name; on the other hand, Wikipedia:Manual of Style (abbreviations) and Wikipedia:Manual of Style (biographies) are subtopics of Wikipedia:Manual of Style, and hence would be clearer if written Wikipedia:Manual of Style/Abbreviations etc.; OTOH, we have had those pages at those titles until now and the sky hasn't fallen yet, so it's unlikely it will fall in the future. --A. di M. (talk) 10:52, 7 July 2009 (UTC)
    I fear there has been some confusion above, but is also my veiwpoint. Subpages imply a relationship which shouldn't exist for articles, but it should for project pages. ▫ JohnnyMrNinja 13:35, 7 July 2009 (UTC)
  • Oppose. This proposal assumes that most if not all readers and contributors understand what a subpage is. While this is undoubtedly true for those with experience with command-line interfaces and computer file systems, this group represents only a portion of the Wikipedia community. For many without a technical background, this change would be nothing more than exchanging one set of mysterious characters with different set and leaving the community to clean up the effects of the resulting mass confusion. --Allen3 talk 11:34, 7 July 2009 (UTC)
Why would the reader have to know what a subpage is? If they are diddling URLs manually, they are actually more likely to understand about chopping off things at slash boundaries, since that's how the rest of the web works. Gigs (talk) 21:40, 7 July 2009 (UTC)
  • Oppose. I agree with the above opposition and would also point out that, e.g., "Manual of Style/Abbreviations" could just as easily mean it's a manual of both style and abbreviations, so it is not as unambiguous as suggested. Powers T 13:30, 7 July 2009 (UTC)
    While I can see that confusion is conceivable, does anyone actually think it is likely? Even if we assume that people who get as far as that page don't know that there is something called "Manual of Style", and assuming they also miss the automatic backlink right below the title to the Manual of Style, do you find it likely that they will assume there is such a manual? Surely, if such confusion was an issue, the Reference desk would have been changed at this point, as they go through a lot more newbies than the MoS. Is your opposition just for MoS, or all pages with subpages?
    More to the point, it's a manual of style for abbreviations. If someone did assume it was a manual of style and abbreviations, how would that assumption be wrong? What problems would that cause? ▫ JohnnyMrNinja 02:34, 8 July 2009 (UTC)
  • Oppose - I originally had no strong opinion either way on this, but LtPowers raises a good point about possible ambiguity. Mr.Z-man 15:37, 7 July 2009 (UTC)
    Does my above response to that point have any effect? The issue could only affect MoS, as the "Style" is capitalized. It wouldn't be an issue for Wikipedia:Naming conventions/Aircraft. The possibility of ambiguity is small, and again, what problems would it cause? Not to mention that many (if not most) people reach the MoS pages through links from the main page or other policy pages, which would nullify any possible confusion. I don't think that issue really has anything about it that would constitute even a small problem. ▫ JohnnyMrNinja 03:17, 12 July 2009 (UTC)
  • Support. I skimmed this a bit ago and didn't think it was worthwhile, but I've changed my mind now that I've gone through it in greater detail. As Od Mishehu points out above, this isn't a matter of moving disambiguation pages to a subpage format for easier navigation, it's a matter of moving pages that are actually subpages over to subpages. The "solution in search of a problem" objection needs to point out why the solution would be a burden - in this case, the solution only makes things easier, and the renaming is trivial. The "users don't understand subpages" objection seems confused, since nobody needs to understand anything to make that little breadcrumb link appear. The objection of the slash being ambiguous is trivial, and I think that users tend to use the headings a fair bit more than the URLs. This proposal would make the structure of those pages much clearer (which currently is a problem), and JohnnyMrNinja and others who support have done a good job with responding to potential objections. This proposal points out the very valid reason that it's WP:VP/PR and not WP:VP(PR). I support.    M   04:26, 19 July 2009 (UTC)
    Thanks for the second read. This may not be a very sexy proposal; there's nothing about banning Jimbo, or a vandal-to-sysop program. It's very simple and slightly boring, but it has little-to-no drawbacks. I'm hoping a few more regulars here will weigh in. ▫ JohnnyMrNinja 13:55, 24 July 2009 (UTC)
    You might want to list the specific pages you want to move. I've noticed that a couple would not be appropriate as subpages of policy, since they are merely guidelines. Their names should be changed, though.    M   23:13, 30 July 2009 (UTC)

Color-code wikicode

How difficult would it be to have wikicode automatically colored differently from plain text in the editing window, a la emacs? Reading over the results of the Usability and Experience Study, it seems like this could greatly lower the barrier for entry among technophobe potential editors. » Swpbτ • ¢ 16:00, 27 July 2009 (UTC)

wikEd does something like this. Mr.Z-man 16:19, 27 July 2009 (UTC)
(edit conflict) You can already do this using wikEd (locatable through the search tool), Swpb. I appreciate that add-on, while easy to activate, isn't the same as an on-by-default standard feature—plus adds several more buttons. I don't think it would be that difficult (not that I could be the one to do it) a patch. Care would be needed to keep the scope narrow, to avoid wishitems for syntax-coloring of many programming languages drawing its development out, I suppose. I think your suggestion's definitely worth considering. –Whitehorse1 16:21, 27 July 2009 (UTC)
Hmm - yes, I think having the functionality only available through an add-on negates the potential benefit to technophobes. As far as the scope, it should only be applied to code that is active on the page (headers, internal/external links, namespaces, transclusions, table syntax, html tags, latex codes inside <math> tags, etc.), and not to random snippets of any old programming language that an article might be quoting. Also, it needn't differentiate between different code elements, the biggest benefit would just be in differentiating code from non-code, which might also allow it to be developed faster. For example:
== Unicorns ==
[[File:unicorn.png|thumb|200px|A unicorn grazing]]
A '''unicorn''' is a [[mythology|mythological]] creature.{{cite}} Unicorns are typically {{convert|8|ft|m}} tall.<ref name="pegasus"/>
[[Category:mythological creatures]]
I would suggest that for any parameters, user-supplied values should be treated as plain text, whereas pre-defined parameters (like "thumb" for the "file:" namespace) should be highlighted as code, as I've done above. Alternately, all parameters could be either highlighted or not. » Swpbτ • ¢ 17:40, 27 July 2009 (UTC)

Sounds like a good idea (though I'd hope for an easier-on-the-eyes default colour than red). Rd232 talk 14:07, 28 July 2009 (UTC)

Ok, so how should I go about getting broader consensus on this? I figure something like changing the default look of the editing window merits some significant community input, like its own talk page and a mention in the signpost, if not one of those nifty watchlist notices. Does anyone know how to do the latter? Then, assuming a consensus emerges, I figure I should submit it to the developers by means of a bug report? » Swpbτ • ¢ 15:05, 29 July 2009 (UTC)
The only reason why this is not implemented is because there is no good way to do it. Automatic syntax highlighting tools written in JavaScript mess up the undo/redo buttons. The best wikEd can do is give you a button that you have to click to update the highlighting. If you can find a good solution to this problem, I'm sure there'd be little opposition to rolling out syntax highlighting by default. —Remember the dot (talk) 06:00, 30 July 2009 (UTC)
If this is ever implemented, ensure that there's a way to turn it off. I don't want my text garbaged. Thanks. Greg Tyler (t • c) 16:16, 30 July 2009 (UTC)
Right. Pink letters (example above) are an eyesore. Please default to all blacks. NVO (talk) 10:21, 31 July 2009 (UTC)
Well, red (or pink) need not be the color used. However, syntax highlighting would be extremely helpful to many editors, which I think trumps the "eyesore" argument for having it off by default. If it bothers you, I agree with [[Greg Tyler that you should be able to turn it off. » Swpbτ • ¢ 15:40, 31 July 2009 (UTC)

To prevent Edit Conflicts...

...maybe there could be a locking system like on TV Tropes. There a page gets locked for a certain amount of time when someone starts editing a page. If they do not save their edit before the time runs out it's not added. This idea could use some work, I admit.--Occono (talk) 00:28, 2 August 2009 (UTC)

Why would this be superior to the current system? Algebraist 00:29, 2 August 2009 (UTC)
I think this would be less frustrating when another editor is making lots of edits and you cannot get any in...I suppose I can't ::give a great reason why this would be superior, I'm just throwing it out there.--Occono (talk) 00:34, 2 August 2009 (UTC)
TBH, it seems like it would be a lot more frustrating to not be able to edit the page at all then to get a couple edit conflicts, especially since only edits that can't be automatically merged cause conflicts, not every instance when edits overlap. Mr.Z-man 02:09, 2 August 2009 (UTC)
Agreed. Wikipedia is just too busy and frequently edited for that option to work here. hmwithτ 13:50, 2 August 2009 (UTC)
We do need a less-crappy system for handling edit conflicts, though. Having to root through the entire page, rather than just a section, is no fun.    M   01:46, 3 August 2009 (UTC)
If you're planning an edit which affects large portions of a page and may require a significant amount of time to complete (restructuring a whole article, massive copyediting, etc.), then you can use the {{inuse}} template to flag your work in progress to other editors. If you do come across an edit conflict, many web browsers will allow you to hit the back button, taking you back to the edit window in which you were just working and allowing you to copy any text you wish to preserve. For more complex edits (why didn't you use {inuse}?) you can open a new tab with a fresh copy of the edit window, where you can paste in material from the original edit window. TenOfAllTrades(talk) 02:57, 3 August 2009 (UTC)
If you give me just the section I was working on, I won't have to click back and forward.    M   03:07, 3 August 2009 (UTC)
I believe M was referring to what happens when you get an edit conflict: you see the entire content of the page, even if you were previously editing just one section. Powers T 12:53, 3 August 2009 (UTC)

(unindent) Having to go through the entire page after an edit conflict IS SO FREAKIN' ANNOYING I have to emphasize it through font and an exclamation point! The solution would be to make so you go back to the section you were working on after an edit conflict, and to use the {{inuse}} and {{underconstruction}} tags, not to lock the page when it's being edited. I have several disabilities that, I'm sure, at times make it so it takes longer for me to edit a page. I do horribly with time limits. My IQ allegedly can't be tested because of this. So, in other words, this solution makes it inaccessible to me at least, and probably a lot of other people with disabilities. I dream of horses (T) @ 01:43, 5 August 2009 (UTC)

Sounds like a perfect tool for hijacking an WP:OWNing articles, keeping those pesky patrollers off the turf for hours. Hagger's dream. NVO (talk) 05:36, 5 August 2009 (UTC)

Some time be allowed to pass before we start AfD and tagging new articles?

I think there should be at least an informal suggestion somewhere encouraging editors to give new pages "some time" to develop before AfD or slapping a tag on them about "orphan", "uncategorized". or "needs citations" or what have you. Two things brought me to this. One, quite awhile ago, I changed an article that had been a redirect for 2 years into an actual article. It was put up for deletion before I could expand it and show notability, and the reason the editor gave for putting it up for deletion was that it had been around for over 2 years and no one had expanded it from the two sentences that were there (the two I had just put there). He had not checked the history and seen it had been a redirect for those two years and had just got turned into an article. Luckily me and another quickly expanded further and showed notability. Second, and this happened today- I created an article, left it to post at another editor's page and at the appropriate wikiproject's "new article" page that I had created it, and in the 3 minutes it took to do that... someone tagged it with orphan and uncategorized tags! It seems a bit silly to me to not give an article, oh, maybe a couple days to a couple months before we start doing that kind of stuff, what do others think?Camelbinky (talk) 03:32, 4 August 2009 (UTC)

This falls under WP:PEREN - attempts to impose some kind of arbitrary limits on how/when nominations may be made come around fairly often and are always rejected as being instruction creep. Granted, it is pretty silly to show up at an article within a matter of a few minutes and start slapping it with tags - or worse, deletion nominations - but it is a matter for common sense, not set time limits. Shereth 04:28, 4 August 2009 (UTC)
Perhaps you didnt read my post closely enough before trying to stop conversation prematurely. I never said anything about imposing a limit, I said "informal suggestion" to encourage editors to stop being overly...well, I guess overly stupid. As for creep, that's ridiculous and I'm sick of that being the default excuse anytime someone doesnt like change. Anyways, this is the village pump (proposals), this isnt the village pump (policy) and I'm not trying to set up a new policy. The village pump is an open discussion forum. I suggest we allow everyone to simply comment and talk about this, which was my whole reason for bringing it up. It doesnt matter if this is a perenial discussion, perhaps if it continues to be brought up over and over maybe those editors who do it might just get the hint and do some research before tagging a new article.Camelbinky (talk) 05:29, 4 August 2009 (UTC)
When it's clear that a brand-new article is obviously headed for deletion, it wastes less of everyone's time to do it right away. It's not a kindness to stand idly by while people who don't understand the standards pour effort into a page that was always destined for the gallows. --Trovatore (talk) 08:26, 4 August 2009 (UTC)

I think that this falls under the spirit of WP:PEREN. Any limit is just an informal suggestion anyway :P ╟─TreasuryTag►without portfolio─╢ 08:36, 4 August 2009 (UTC)

Since when has a proposal being listed at peren been grounds for dismissing it out of hand? Consensus can change folks - but not if a debate gets stamped on before it can start. DuncanHill (talk) 12:05, 4 August 2009 (UTC)
Consensus can change, but when a proposal has been made often enough that it appears on WP:PEREN it isn't unreasonable for us to ask what has changed since the last several times the idea was proposed. A reference to PEREN is a shorthand way of saying, 'I think that the reasons brought up in previous discussions still apply'. As for 'informal suggestion[s]' thats editor 'stop being...overly stupid' — well, I'm all for that. Unfortunately, teaching people how to use common WP:SENSE when they just don't have any is often like trying to get blood from a stone. TenOfAllTrades(talk) 12:52, 4 August 2009 (UTC)
Camelbinky, I’m sympathetic to the frustration of trying to improve an article, and seeing it proposed for deletion even as you start working on it. On the other hand, I can easily imagine the first step triggering an entry in a watchlist, and a user taking a quick look at the very limited information and deciding it deserves deletion. That user may be unaware that the article is in the process of improvement, even when there are signs that an attentive editor could read. Your proposal is that we pass along informal suggestions to give the article some time. While I understand the suggestion, it creates a process problem without a simple solution. The user reviewing the article either has to do some detective work to ascertain that the article is being worked on, or find some way to calendar the article to return later to see if there is progress. While this isn’t a lot of work, why is it fair to out the burden on the reviewer? There are two better solutions, which remove the burden from the reviewer. One is for the editor improving the article to place the appropriate template (hangon, inuse, or underconstruction) to let the reviewer know you are working on it. A better option is to work on the article in your sandbox, and move or copy it when there’s enough to stave off the deletionists. I think the last option is the preferred option in any case, so I think it makes more sense to encourage editors to follow best practices, rather than put a burden on reviewers to determine whether the article is about to be improved.--SPhilbrickT 15:07, 4 August 2009 (UTC)

(<-){{underconstruction}} is very helpful in these cases. -- Avi (talk) 15:10, 4 August 2009 (UTC)

Maybe the templates can be changed in a matter I suggested at WT:CSD to only show them after some time has passed, so they still exist but are not shown on the article before a fixed time has passed. Unfortunately, the MMORPG approach to NPP is still too often used... Regards SoWhy 15:18, 4 August 2009 (UTC)
A previous suggestion to write the articles in a sandbox - or make heavy use of the "show preview" button to check on small revisions - is a great one. NPP is a difficult place that I have long avoided because it can be extremely difficult for the patrollers to make an informed decision on what amounts to a sub-sub-stub, and given the volume of stuff going through there, it is not very reasonable to burden them by requiring additional steps. A lot of this conflict could be avoided if articles were not constructed piecemeal style in mainspace. Shereth 15:27, 4 August 2009 (UTC)

Unless it's a SNOW close, an AfD discussion lasts 7 days. If an editor or group of editors can't make the article look like it should be kept in seven days, then either they have no interest in doing so, or they can't. People involved in the discussion can change their minds based on improvements, or the closing admin can take a look at the article in question and decide that, despite the stale !votes, the article now appears notable enough to be kept. Why is the seven days not a sufficient time to get the article improved? Who then was a gentleman? (talk) 18:47, 4 August 2009 (UTC)

Seven days is enough time to get the article improved, but if it is being put up for deletion after only existing for 2 days then the editor has just begun and now has a 7 day deadline, which as others have pointed out is still enough time to make it notable. But the thing is, alot of editors always make the comment "why put undue burden on the reviewer", how about we think from the editors point of view and say "why do we put undue burden on the contributor?" If you are going to tag something, then do your homework first. I know the work these reviewers do is just as important as those who actually edit and put info in, its just important in a less noticeable way and users like me who focus on putting things in instead of tagging often dont appreciate those other types of editors (who we often think of as making our lives miserable). I guess I brought this up to vent. But maybe we really should think again about having on a guideline page a sentence along the lines of "it is common courtesy to do some research, by looking at the talk page and the history on a page before tagging it with AfD or other tags to make sure it is not a new article or one whose problems are currently being addressed", similar to the paragraph we already have regarding removing uncited material that says:
  • "Any material lacking a reliable source may be removed, but how quickly this should happen depends on the material in question and the overall state of the article. Editors might object if you remove material without giving them enough time to provide references, especially in an underdeveloped article. It has always been good practice to make reasonable efforts to find sources oneself that support such material, and cite them."
So that reviewers and editors know the burden is on the editor, but really the reviewer should take some time to be courteous and do some work themselves, instead of just slapping a tag and expecting someone else to come along and fix it.Camelbinky (talk) 23:02, 4 August 2009 (UTC)
I don't agree with this proposal in any form whatsoever.
Sometimes, when I am new page patrolling, I see articles that in my opinion (or stubs) that don't or just barely qualify for articles (or stubs). Sometimes I'm not sure if the article really qualifies to be speedied, sometimes I think the article has potential and deserve five to twelve days to improve. A lot of times, I'll PROD, tag and continue to new page patrol. Sometimes I'll clean up a little myself. However, there are times when I simply don't have the energy or expertise to clean it up, and sometimes there are simply too many articles that do qualify for speedy that I'll just do a "drive-by" tagging and continue patrolling.
If you disagree with a PROD tag, just take the tag down. We'll take it from there. I may or may not take it to AfD. Usually I don't.
If you can't improve an article in twelve days, then you can't improve the article, period. In the meantime, I will do you the courtesy of nominating it for deletion so you can hopefully move on with editing.
By the way, I don't "officially" patrol pages with {{underconstruction}} tags on them. I just realize the page is still being written and move on. No tagging, no nominations, nothing. Sandboxes are another, better alternative, as I then don't have a page clogging up the page setting off my "Hey, I have to look at this" alarm.
Hopefully, you will see a better side of Wikipedia someday.I dream of horses (T) @ 01:30, 5 August 2009 (UTC)
Camelbinky, there is nothing an editor can do to "make [an article] notable" — the topic either is notable or it isn't. Sure, in some borderline cases, time could be useful to make the case that the subject is notable. But when it's clear that the page is something made up in school one day, or if it's an attack page, or copyvio, or if the article name is tendentious or clearly a neologism, then there's not much point in waiting.
Deletion is not supposed to be (much) about the current quality of a given article, but about whether there should be an article about that thing at all. --Trovatore (talk) 01:51, 5 August 2009 (UTC)
But Trovatore, that is the problem, it isnt supposed to be about the current quality but to alot of these patrollers that's what they look at because too many of them patrol articles they have no expertise in and have no idea what they are looking at and therefore cant possibly know if it is notable or not. The one article I talked about earlier that had been a redirect for a long time before I made it and it then got put up for deletion right away is one example. The patroller had no knowledge about traffic circles or even the region it was in. I had to take time out while I was in the middle of putting an article through a GA review (which because I had to dedicate so much time to the one article the reviewer failed my GA review because I didnt get to her concerns fast enough, luckily I brought it back to her later and passed). This is one instance where it was indeed an UNDUE BURDEN to the editor (me) to quickly have to show notability. All because these reviewers, and I know they do it in good faith, go around to articles they dont know about. My personal policy is to keep my nose out of articles I dont know about. Perhaps if wikiprojects could police their own some of these problems could be handled without tags, if your a patroller and you see an article you have a problem with, and it has a wikiproject banner on it, let the wikiproject know and they can handle it since they would have a better understanding of what is notable in that subject/geographic region. I know with the wikiproject I co-founded concerning the Albany, NY region this has happened before and three or four members will jump to the article and have issues fixed within 48 hours (we just did that very thing last week, actually took us less than 6 hours I would say). Obviously not every wikiproject has motivated active members willing to do this, but many do I'm sure.Camelbinky (talk) 04:59, 5 August 2009 (UTC)
How are we supposed to judge an article if not by its current quality? And, quite frankly, it's not as if you have to drop everything to "defend" an article that's been marked for deletion. Recreation is allowed and, perhaps, it's just a sign that the article should be improved first before being moved to mainspace. If nothing else, just request it be userfied until you've had a chance to improve it. — The Hand That Feeds You:Bite 19:27, 5 August 2009 (UTC)
In deletion discussions, you're actually not supposed to be judging the article. You're judging the title. Should there be an article about Plutonian hydrogen hockey, or not? That's the question before you, not whether it has a good writeup at the moment.
Granted, there are exceptions, but this is the baseline concept. --Trovatore (talk) 19:43, 5 August 2009 (UTC)
Thank you Trovatore, I completely agree and hope more reviewers in AfD read your post and follow it.Camelbinky (talk) 23:54, 6 August 2009 (UTC)

I noticed on the Polish Wikipedia that on the upper right links (where you see "my talk"/"my preferences" etc) there is a link to a user's personal sandbox, which when clicked opens up at the equivalent of "User:YourName/Sandbox". I would find this option very useful as I frequently work in a user sandbox before publishing in mainspace. Is something like this already available? Or even feasible to activate on en.wiki? I think in usability terms it would help too, as many new users could benefit from having a personal, safe location to work on their first articles etc. Sillyfolkboy (talk) (edits)WIKIPROJECT ATHLETICS NEEDS YOU! 04:46, 5 August 2009 (UTC)

You can do this for yourself easily with personal javascript. It can be implemented easily enough for all logged-in users if there's consensus, but I think I remember a fair amount of opposition last time this came up. Algebraist 14:27, 5 August 2009 (UTC)
Previous discussion here and here. Algebraist 14:31, 5 August 2009 (UTC)
I have that on my personal user javascript file. Feel free to copy from User:A_Knight_Who_Says_Ni/monobook.js.

Proposal to change where WP:PLOT redirects

There is a nascent discussion at Wikipedia talk:PLOT about whether it is best to keep WP:PLOT as a redirect to this section within WP:What Wikipedia is not, where its been for a while, or should be changed to redirect to an existing guideline article about plots (Wikipedia:How to write a plot summary). You're encouraged to join the conversation. Thanks. 67.100.126.76 (talk) 00:45, 7 August 2009 (UTC)

Blocking abuse filters?

We've had abuse filters nearly 5 months now, and they have been quite a tremendous asset. After a few slipups at the beginning, the quality of these filters, has been great, with very little collateral damage. We have learned to prioritize filters, and use the abuse filter efficiently and effectively. Filters of several groups have been developed. One group warns users who make common 'newbie' editing mistakes. For example, if someone were to add '''Bold text''' to an article, they will be given a friendly warning pointing them to the sandbox, a warning that they can override if they wish. Another type attempts to identify and tag possible vandalism. Tagged edits can be reviewed by editors, to identify which edits are vandalism, and which are not. Finally the third type of filter targets specific, repeated, high-priority, and ongoing vandalism. Filter 179 is an example of this. As you can see, the hits from this filter are packed tightly in time, and have extremely good discrimination between good and bad edits. They look only for one specific type of vandalism, and target only that type as narrowly as possible. Due to the nature of these filters, the users who hit them are nearly always compromised hosts, or open proxies. Filter 7s recent repeat triggering today is a great example of this phenomenon. To block these proxies, someone has to manually block every IP that hits the filter. Because of the very targeted nature of these filters (for example, a filter might only target page moves where the new page name contains 'on wheels'), and because these filters tend to be active only during the periods where these vandals are active, is is virtually guaranteed that any hit of the filter is genuine. I think that the ability to make this very small subset of filters automatically block users that trip them would save administrators a great deal of time, as they would not have to constantly monitor and block anyone tripping the filter. Obviously the filters that would be set to block would only be the most narrow in scope and most accurate. What are people's thoughts on enabling the ability to create blocking abuse filters? Prodego talk 22:03, 31 July 2009 (UTC)

I think it is an overdue need and that in circumstances that the filter has a very low false positive rate and its an edit that would be a blockable offense (as judged by its creator) there is no reason that this ability should be restricted. Alexfusco5 22:13, 31 July 2009 (UTC)
That is an important point Alexfusco, this would only be used for actions which would justify an immediate block. Prodego talk 22:14, 31 July 2009 (UTC)
I don't think implementing this is a good idea. Blocks, are recorded on the permanent history of an account. I do not share your faith in the unlikelihood of false positives or lack of need for human checks before such blocking. For these reasons I'm against the proposal. Despite your suggesting only very select filters would be involved here, I do not share your confidence in trusting them to appropriately autoblock. –Whitehorse1 22:20, 31 July 2009 (UTC)
Is it really too much trouble for a human admin to adjudge the merits and side effects of blocking each IP or user? That isn't a rhetorical question. This proposal is clearly against the WP:BLOCK policy as it is now written and presumably requires a very broad discussion. Delicious carbuncle (talk) 22:33, 31 July 2009 (UTC)
I wouldn't say it is against the block policy. Let me just give you an example of what would be an acceptable situation for a filter to block. Lets say, some vandal, using many proxies, is going around and replacing the content of random pages with some phrase. Lets say the phrase is something like 'I will sue you in a Court of Law in Trenton, New Jersey!', you can use any obvious example you want, say some image of a penis... In this case, you could create a filter which would trip only when a non-registered user takes an existing page and blanks it, leaving only the text 'I will sue you in a Court of Law in Trenton, New Jersey!'. Any administrator, knowing that this is just a throwaway proxy, would immediately block that IP, and there is no situation where you would legitimately replace a page with this phrase. Even then, the filter would immediately be disabled once the vandalism stops. To be honest, when I create a filter with this level of accuracy, I block those who hit it without looking at the content of the edit. Why don't I have to look? Because I already know what the content of the edit was, the filter is so specific as to immediately identify it. Prodego talk 22:40, 31 July 2009 (UTC)
The first sentence of the policy is: "Blocking is the method by which administrators may technically prevent users from editing Wikipedia". It is a mistake to assume that simple text string matches will never have false positives. You seem to have skipped my non-rhetorical question - is it really too much trouble for a human admin to adjudge the merits and side effects of blocking each IP or user? Delicious carbuncle (talk) 23:28, 31 July 2009 (UTC)
It takes enough time that I have not been doing it. Perhaps some people do. Prodego talk 23:30, 31 July 2009 (UTC)
I'm going to oppose this until there is a very clear procedure on when to set a filter to block a user, and when not to. Just activating this would be a very, very bad idea, and I don't think any single administrator should be allowed to just set a filter to block when triggered. There needs to be a very clear consensus first, and there should be no false positives. I suppose that's common sense, but I want this to be set in stone (as in, written into the edit filter guideline) before I'm even thinking about supporting this. --Conti|✉ 22:44, 31 July 2009 (UTC)
Of course. I'm talking about the general idea of implementing it, not the specific procedure that would be used. One option we have is to restrict who can create blocking filters to a new user group, which could be selected in some way. Additionally, there would have to be something done about the 2 non-admins who currently have access to edit the filters. What I am asking is: do you believe that enabling blocking filters would be positive. Not: this is how we are going to implement it. So I agree with your analysis fully Conti. Prodego talk 22:50, 31 July 2009 (UTC)
I suppose in an ideal world the blocking feature for the filter would be a good thing. I'm just not sure if we live in such a world yet. :) If the feature is not abused, if no careless mistakes are made, if people get a fair way to be heard when they disagree with the blocks, then yes, I don't oppose the new blocking feature. I like FT2's proposal below. --Conti|✉ 10:41, 1 August 2009 (UTC)
I note that no one has answered Delicious Carbuncle's non-rhetorical question: is there a problem that needs to be solved with this? How much work is being done by admins that would be avoided by this solution, and that could not be taken care of by FT2's "parallel proposal" below, and is it sufficiently burdensome to warrant this solution? I concur with EdJohnston's recommendation below that each blocking filter have a specific admin who takes responsibility for it. ☺Coppertwig (talk) 13:06, 2 August 2009 (UTC)

Proposal

If some filters are now identifying issues with high precision, then I would suggest a specific process, akin to approval for an bot. It's the same kind of idea - an automated process will be allowed to act on-wiki, and the community should have the chance to scrutinize the evidence that the filter is tested, stable, mature, and discriminating, before it is in effect given an admin right. Proposal:

A filter that has achieved stability, maturity and a high level of precision (and in particular an extremely low "false positive"), over a period of time, may be proposed to have administrator tool responses added to it. These may include blocking and page protection.

Such requests are presented for communal scrutiny, with a formal statement and evidence section showing

  • The filter's purpose
  • Evidence of need
  • Evidence of track record (including in each case, "false positive" analysis showing how it would have acted if admin tools had been in place)
  • An explanation why adding admin tool responses would be beneficial to the project
  • An explanation of how the filter will be maintained, how its quality will be reviewed, and any proposed safeguards over its admin tool use.
  • If there is a false positive risk, but this is said to be of a very low level, then the statement should explain why this is on balance reasonable, and how the responses will be designed so that users who are affected by a false positive will receive a courteous explanation and be able to quickly and without prejudice rectify it.

If consensus agrees then after a discussion lasting [7, 10] days, the tool will have admin responses enabled (possibly to an agreed limited extent) for a trial period of 2 weeks. Subject to lack of evidenced problems, admin responses will then be considered approved.

Any subsequent significant change to the filter code, or nature of responses of a kind likely to introduce a higher risk of errors, shall require reconfirmation. Users making such amendments may wish to trial the code on a new filter so that the original filter is not disturbed.

Any good?

FT2 (Talk | email) 23:03, 31 July 2009 (UTC)

In my opinion, any blocking that does not involve a human performing the block is a bad thing.--Rockfang (talk) 23:14, 31 July 2009 (UTC)
I was able to look at today's log of Filter 179. This is an extremely specific filter that nobody could run into by accident, it deals with conscious vandalism of a certain kind, and I wouldn't see a problem if each of those edits had triggered a block. Since all these accounts were IPs, a block of anywhere from one day to a week might be reasonable. Let's say that it would be extremely surprising if anybody would have the temerity to ask for an unblock, if they were caught by Filter 179. So far as Filter 7 goes, my own review didn't convince me that Filter 7 was ready to do any automatic blocking; I'd need to hear more. If automatic blocking is ever turned on, the blocks need to be 'owned' by some administrator who is responsible if anything goes wrong and whose reputation would suffer if they goofed up. There needs to be a community review of whatever scheme (if any) is adopted, and FT2's idea may be heading in the right direction. (If the details of Filter179 were fully explained, though, it might lose its value). EdJohnston (talk) 23:33, 31 July 2009 (UTC)
The difference is that 179 was designed to be extremely specific. It is effectively my personal filter for ongoing attacks. 7 is rougher because it is being customized for ongoing vandalism, by many people, and is only supposed to be enabled during anontalk attacks, not all the time, like (most of) 179. I'll discuss FT2s proposal later, but the gist of my response is going to be that the type of filters that need to be blocking will not be useful 7 to 10 days after you need them. Prodego talk 23:38, 31 July 2009 (UTC)
(e/c)@Rockfang: I would point out that we've had a bot blocking open proxies for about 6 months now as well as a bot blocking pagemove vandals and abusive usernames. Mr.Z-man 23:43, 31 July 2009 (UTC)
Not to mention the unapproved blocking adminbot that is User:Misza13. Prodego talk 23:48, 31 July 2009 (UTC)

<-I agree with Rockfang, automated blocks make me very nervous, if one cannot be virtually certain that false positives will not occur. I'm not familiar with the proxy that blocks open proxies, but if I understand open proxies correctly (and I'm not sure I do), the concept of a block on one's permanent record isn't an issue in that case. I'll toss out an intermediate option (intermediate between a bot blocking and an administrator having to manually block). Why couldn't a bot identifying what appears to be a blockable offense drop a notice on the talk page - saying something like "Attempted edit xxxx appears to be a violation for which blocking is warranted. If you think this is in error, please contact an administrator (you can do this with template adminhelp) within n days. If you do not provide a reason, you will be blocked. If an administrator reviews the edit prior to that time, you may be blocked sooner."--SPhilbrickT 19:44, 1 August 2009 (UTC)

"within n days"? I'm not quite sure you you understand the purpose of such filters and bots. These are things that require immediate attention. Spambots, pagemove vandals, attack usernames, etc. Mr.Z-man 21:33, 1 August 2009 (UTC)
Sorry, I'm not buying this. And it is fully possible I don't fully understand, so if there's a place to read more about it, please point it out.
Can we distinguish between a user moving a single page in violation of a policy, and a vandal attempting mass movement of pages for disruption? I have no problem with a bot doing blocking if it detects multiple blockable offenses, but I find it hard to believe that a new user, me for example, couldn't accidentally move a page in a way that violates the rules. I cannot believe that such a single move is so egregious that it can't wait a few minutes for an admin to look into it—instead, a bot must block immediately. While my original proposal didn't distinguish between a single action and multiple actions, that distinction now seems appropriate.
I don't follow how an attack username requires immediate attention. By "attackusername", are you talking about a name in violation of policy? If so, why does it require blocking within seconds? Keeping in mind that a very egregious violation is likely to attract a live admin in short order anyway, the only time this would otherwise go unnoticed for several days if if the violation is in a gray area. Do you have bots that are that good? Again, I'm sure I'm missing something - please help me figure out what I'm missing.--SPhilbrickT 16:56, 3 August 2009 (UTC)
I'm referring to page move vandalism like moving Judaism to "JEWS DID 9/11" and other things like these, I find it hard to believe that a user could do that by accident. Given a few minutes, a dedicated page move vandal could move a couple dozen pages. (And yes, both bots and the abuse filter can distinguish between multiple violations, though in obvious cases, it isn't necessary). For attack usernames, I'm referring to things like "User:X's real name is John Doe and he lives in ...". Things like that require an oversighter to clean up after it. And yes, we do have a bot that catches these - User:AntiAbuseBot. Nobody is proposing handing full control of anti-vandalism work over to bots, just to allow the abuse filter to handle some of the obvious cases without manual intervention. Mr.Z-man 17:34, 3 August 2009 (UTC)
I'm afraid we aren't on the same page. My question is motivated by the observation that we have bots with the ability to block users, and the culture which tags a block as a serious blot on one's record. If true, false positives are serious. I don't disagree that moving "Judaism" to "JEWS DID 9/11" is blockable—are you telling me you have a bot that can distinguish that move from an attempt to move "Judaism" to "Jewish Religion", the latter of which deserves a revert and an admonition but not a block? That's a fairly sophisticated bot, if true.
Thanks for the explication of attacknames, I did misunderstand the term. Now that I understand it, are you really saying there are bots that can find such an statement without any false positives? And that such an action requires immediate blocking? I understand why the elimination of the outing requires prompt attention, I'm missing why the block as to be done mechanically, rather than by a human. We don't have any bots with oversight rights do we? I assume oversighters have admin rights, so if an oversighter cleans up the mess, why can't they do the block.
Sorry if I sound obtuse, I'm trying to understand.--SPhilbrickT 20:11, 3 August 2009 (UTC)
I can't tell if you're over- or under-estimating the capabilities of bots. Are you imagining that a bot would just block everyone who moved the Judaism page? Or that one would need a complex set of heuristics to tell the difference between the 2 moves? It would not be especially difficult. It might be more difficult to avoid a false positive if the page was (in good faith) moved to something like "RELIGION OF THE JEWS AFTER 9/11" but that's a rather unlikely scenario.
Its easy to avoid false positives if you just have very strict criteria for a match. Its just a balancing act. We would (using hypothetical numbers) basically have to choose between the bot catching 90% of all abusive usernames, with one false positive per week, or 70% of abusive usernames with one false positive per year. You're never going to be able to catch 100% with 0% false positive rate, but that doesn't mean we shouldn't try. As for "if an oversighter cleans up the mess, why can't they do the block" - its about damage control. The sooner its blocked, the fewer edits have to be oversighted and the fewer people see the potentially private, libelous, (or sometimes both) information and the more frustrating it is for the vandal. Mr.Z-man 22:02, 3 August 2009 (UTC)

Not sure. Would requiring 7-10 days of discussion make the feature relatively useless, since it's needed (?) in specific situations where huge numbers of sockpuppets are appearing at that moment? On the other hand, would allowing it without such discussion make it too dangerous? Here's an idea (if it's established that this is needed at all; maybe just FT2's parallel proposal would be enough): Identify a number of admins who have experience with abuse filters and are trusted to do this. If an admin wants to make a filter to address an immediate situation, they get it (quickly) approved by one of those experienced admins, implement it, announce it on AN/I, and if there isn't consensus for it, it can be turned off again. ☺Coppertwig (talk) 13:06, 2 August 2009 (UTC)

A parallel proposal

In parallel with that, this may be an alternative approach that doesn't require approval for admin tool responses, and does not have a problem with error rates, and therefore is useful for many filters that would not meet the approval level above.

If the extension provides a page of "filter hits" with check boxes next to each (AJAX filterable by filter # or the like), then an admin can click on individual checkboxes or shift-click a range, to perform a specified admin action on all selected events or the users responsible. FT2 (Talk | email) 23:45, 31 July 2009 (UTC)

Good idea, I think, whether or not there is automatic blocking as such. Admins would still have to be careful about false positives. ☺Coppertwig (talk) 13:06, 2 August 2009 (UTC)
Special:AbuseLog isn't quite that quick, but it does allow for fast review, and can be sorted by filter, user, and/or page. I'd be worried people might not look closely enough at edits before taking action, but nevertheless it's an interesting idea. – Luna Santin (talk) 09:28, 3 August 2009 (UTC)

Who would get the new flag?

See also: Wikipedia:Village_pump_(policy) § Criteria_for_Abusefilter.2Feditfilter_permissions

Should all admins get it, or should it be separate from the admin flag? If the latter, how should users get the flag?

I think it would be very wise not to give the abilty to every admin, since abuse or misuse of it could mean serious harm. Only those that need it should have it, and there should be an informal (like WP:BAG nominations, maybe) vote/discussion about each person who requests the new user flag. --Conti|✉ 10:51, 1 August 2009 (UTC)

I think a new userright is overkill, but perhaps we could have some kind of "Senior edit filter managers", and the understanding only they are allowed to set the flag. They could be voted on at WT:EF. –xenotalk 00:44, 2 August 2009 (UTC) Edit: just read Werdna's statement below that the blocking functions could be restricted to admins, and perhaps a subset of the same. That's a good idea, especially the former, the latter if it doesn't require a usergroup.
I'd rather not have 1000 admins with the ability to automatically block users with the edit filter. I don't see what's wrong with a new usergroup, since the new feature would be used by only a few admins, anyways. Giving it to all admins will simply heighten the chance dramatically of someone making a rather bad mistake. --Conti|✉ 11:47, 2 August 2009 (UTC)
It is important that many people have the ability to disable a blocking edit filter. It is fine if not many people can create one, but it needs to be easy to shut down while everybody who understands the code is sleeping. Kusma (talk) 06:49, 3 August 2009 (UTC)
I have just given myself the editabusefilter right. In the current implementation, I could shut down a misbehaving filter, and will be able to figure out quickly what to do. Of course, any admin who writes sucky abuse filters should be told not to do so, and be desysopped if they don't stop. But that's no different from other admin tools. I don't see a need for an extra usergroup here, unless you want to have non-admins who write blocking abuse filters. Kusma (talk) 06:59, 3 August 2009 (UTC)
It would make me nervous, but a new user priviledge is overkill -- just restrict it to all abuse filter editors who are also admins, and treat it much like the MediaWiki namespace editing every admin can already do, where consensus is a must and the expectation is pretty much that one screw-up will lead to immediate mauling by angry bears. As has been mentioned, the more people can disable one of these filters, the safer we'll be. – Luna Santin (talk) 09:22, 3 August 2009 (UTC)

Technical Clarifications

Note that the following so-far-unseen features apply to blocking abuse filters:

  • Filters which match a large percentage (currently 5%, I think) of edits and are set to block will have the blocking part disabled.
  • Adding the block action to a filter, or editing a filter which is set to block, is restricted to users in a particular group. This group could be the administrator group, or a subset thereof.

Time permitting, I am happy to implement features of reasonable complexity that improve the safety of blocking Abuse Filters. — Werdna • talk 09:00, 1 August 2009 (UTC)

Can users who are not part of the block-filter group still see the contents of the corresponding filters? --Conti|✉ 10:52, 1 August 2009 (UTC)
Eh, wait. That's what the "hidden" option is for, so I guess the answer is "yes". Leaving this here just in case I'm wrong, tho. :) --Conti|✉ 10:54, 1 August 2009 (UTC)

Okay, let me ask one question of implementation. Assume somebody gets wrongly blocked by the abuse filter (not a common occurrence, but it will probably happen at some point). If a standard adminbot does that, I can go and unblock the user and block the adminbot so the problem doesn't happen again until it is fixed (and I'll talk to the adminbot owner about it). What can I do when I find that somebody was wrongly blocked by the abuse filter? I wouldn't be happy if I can't easily disable the offending filter until it is fixed. (That is our standard way to deal with bot problems: disable them quickly, investigate later before more harm has been done). So please make it easy to disable specific features of the abuse filter without waiting until somebody with technical knowledge shows up. Kusma (talk) 16:06, 2 August 2009 (UTC)

This is another reason why I believe that all admins should have the abusefilter-modify permission, so they can quickly react to situations like this. As an admin, you have the ability to modify the edit filters... the workflow is Special:UserRights → fill in your username → check "Edit filter managers" → enter "panic" as the reason → save → Special:AbuseFilter → take action. The first five steps are entirely pointless makework in 'peace', and dangerous timewasters in an emergency. Happy‑melon 16:19, 2 August 2009 (UTC)
These four steps (you don't need to enter a reason) take about 20 seconds or less, if you know what you're doing. If you don't, then you probably shouldn't try and modify a broken filter. --Conti|✉ 20:00, 2 August 2009 (UTC)
I agree, I'm not trying to claim that they represent a difficult hurdle to gaining access to the filters. That is precisely the problem; they do nothing as checks and balances, because they are so trivial to complete, yet they are a noticeable and tedious piece of bureacuracy in the process. You say that a reason is not required. So the addition need not even be justified, requires no human thought whatsoever, it is purely a cookie-crumb trail of button clicks that has to be completed before the filters become accessible. Again, what purpose does that serve? Happy‑melon 20:55, 2 August 2009 (UTC)
As I said above, the modification of a broken filter (which requires technical knowledge) doesn't have to be done immediately, but it has to turned off immediately until it does more damage. Simple really: If a bot misbehaves, it gets immediately blocked, and then it is fixed and unblocked. No reason to treat the edit filter different from other automated systems. (And while I don't want to learn how to program edit filters, I am smart enough to unclick the "enable" button and to click "save" to disable a filter when there seems to be a problem). Kusma (talk) 07:03, 3 August 2009 (UTC)
That's actually a good point. More people being able to disable a filter is certainly a good thing. I'm simply worried about someone messing things up, but instead of halting the editing of the wiki for a few minutes, we'll end up with hundreds of people being blocked, or something similar. We need a clear process/guideline/whatever before we turn this thing on, especially if we add this feature to the editfilter usergroup. --Conti|✉ 10:59, 3 August 2009 (UTC)

Wider discussion requested

I have started a thread at AN to discuss the discrepancy between current blocking policy and practice. I believe that much wider discussion of allowing automated procedures to block users is warranted. Delicious carbuncle (talk) 16:34, 1 August 2009 (UTC)

Another possibility

Why can't we have the filters post to a central page, similar to bot-reported vandalism at Wikipedia:Administrator intervention against vandalism? This way, the filter does not perform the block itself, but with hundreds of admins watchlisting the filters' reports page, we should have a very quick response time. -- Avi (talk) 07:02, 3 August 2009 (UTC)

Special:AbuseLog provides something akin to that, though not in a format or location I think most of our users are familiar with; are there ways in which it might be made more useful? – Luna Santin (talk) 09:36, 3 August 2009 (UTC)
An indication whether an edit caught by the filter was actually made would be a very big step forward. :) --Conti|✉ 11:00, 3 August 2009 (UTC)
User:Mr.Z-bot already does that. Cenarium (talk) 13:43, 7 August 2009 (UTC)

Main page sidebar navbox

I've been advised to post this here as I've tried Main Page discussion and Main Page/Errors discussion which apparently was the wrong place. Just a minor thing but could the main page sidebar navbox titles (navigation, search, interaction etc.) start with an upper case letter to match the contents of the boxes? Just looks 'wrong' to me! The simple English version is the same but other language wikis appear correct. Many thanks for your time. Nimbus (Cumulus nimbus floats by) 08:37, 7 August 2009 (UTC)

They directed you here, because the toolbar is not just present on the Main Page, but it's present everywhere in the same basic state (see it on the side of this page?) That can be changed. You may like to try Beta. The titles are all capitalized in it. hmwitht 17:43, 7 August 2009 (UTC)
The link for "Try Beta" is at the top of your window, just by your username. Thincat (talk) 17:57, 7 August 2009 (UTC)
If you don't like the vector beta, you can do this in monobook with CSS. Algebraist 22:25, 7 August 2009 (UTC)

Add a rich text editor to Wikipedia

I noticed that Wikia sites have the option to switch between the normal text editor and a rich text editor (when you edit a page, the content appears the same as when you view the page - you don't see the raw code). I think this would be a great option to have (especially on the discussion pages) and would give casual editors a much more user friendly option for editing. Any thoughts?--SuaveArt (talk) 09:58, 7 August 2009 (UTC)

They're currently working on the editing window, toolbar, and similar ideas regarding usability (for information about the usability initiative and future releases, see [4]). In the meantime, you can try the the new Beta version or try WP:WIKED for more features. hmwitht 17:37, 7 August 2009 (UTC)

I propose we place interwiki links to the simple English Wikipedia at the top of the "other languages" links. The current practise is to sort them alphabetically by language code, putting them somewhere in the middle to lower area where no-one notices it. Of course this would also have to be implemented technically, but I believe this can be done by just asking the maintainers of the interwiki bots and the interwiki bot framework to move the simple English link whenever they modify an article. —Ruud 17:50, 3 August 2009 (UTC)

I would additionally or alternatively like to propose making the links to the simple English Wikipedia stand out more by, for example, making them appear in bold. This can easily we done by adding a single line of CSS to the stylesheet. —Ruud 17:53, 3 August 2009 (UTC)

The assumption with this, I'm assuming, is that a simplified version of each article is desired by the reader. I don't see why you'd make that assumption; the only time we should highlight an interwiki above any other is when the quality of that article is exceptionally high (which we do with the {{Link FA}} template).
Now, that said, I wouldn't be opposed to SE interwikis being at the top of the list, but isn't there javascript that could affect that change instead? EVula // talk // ☯ // 18:06, 3 August 2009 (UTC)
My reasons are twofold:
  • I indeed believe that the Simple English article is preferable to a lot of readers. A non-native reader of English would probably prefer the articles in his native language(s) and those in the English or Simple English language. Obviously, what the article in his or her native language is would differ for between the readers, but in total a large proportion of them would favour the simple English language article.
  • The second, maybe even more important, reason is that simple English would be unduly disadvantaged by sorting it so arbitrarily. A reader would have a clear incentive to look for his native language in the list, but not for the simple English link as he or she is probably unaware of its existence.
Yes, I could also write a short piece of JavaScript that accomplishes this. It is probably not very preferable to rearrange page elements after is has been loaded with JavaScript, but might do as an interim solution. Actually, it is also possible to use JavaScript to move the articles in the language(s) configured in the user's browser as his or her prefered language(s) to the top. —Ruud 18:28, 3 August 2009 (UTC)
I seems that JavaScript can only figure out the language of browser's interface. The full list of prefered language can only be accessed server-side. —Ruud 18:57, 3 August 2009 (UTC)
I'm afraid that encouraging people to go to Simple English will just increase the nationalism, COI and POV wars on Simple, with fewer eyes to control them. Who then was a gentleman? (talk) 20:10, 3 August 2009 (UTC)
What? I wasn't aware of any serious problems on Simple English. If you want to discourage people from going visiting the simple English Wikipedia, you should seriously consider shutting it down entirely. Of course, this could potentially have the opposite effect if due to increased visibility en adminsactive editors would start keeping an eye on simple? —Ruud 20:47, 3 August 2009 (UTC)
So let's be honest: I'm pretty skeptical of simple both as a concept and as a project as currently implemented. As I understand it, the content is not supposed to be dumbed down; only the language is supposed to be simplified. But these tend to be contradictory goals; the difficult parts of natural language are there, for the most part, because they were needed, not to make people's lives more difficult. I don't think simple is a success or ever will be, so I don't support giving it more prominence.
But no, I have no ambition to shut it down. Let people try, if they want to, to do this very difficult (most likely impossible) thing. Maybe the effort will expose places where the complexity in the enwiki article really isn't ncessary. --Trovatore (talk) 20:54, 3 August 2009 (UTC)
I sceptical of simple for the same reasons, but I'd say that either we'd try to make it successful (or at least pretend it is or will be and give it the prominence that would be justified if it was) or shut it down right away. Keeping it lingeringly active, tucked away in some obscure place doesn't seem an appropriate way to handle this to me. —Ruud 21:09, 3 August 2009 (UTC)
No, there isn't a great deal of controversy at Simple, but if we "advertised" it all over en., then the edit warriors who get shot down here could go there to continue their wars, and there are far fewer admins to deal with them over there. And en admins have no control over Simple, it's its own Wiki. I've never said anything about shutting down Simple, nor do I advocate that. Who then was a gentleman? (talk) 21:01, 3 August 2009 (UTC)

Just as a note, this has been proposed in Bugzilla and declared a WONTFIX. Any solution to do this would need to be in enwiki's site JS. ^demon[omg plz] 14:23, 4 August 2009 (UTC)

It can be added to MediaWiki:Sidebar. According to File:Simple_English_Sidebar3.png it should be put right after the toolbox. Ruslik_Zero 15:06, 4 August 2009 (UTC)
Not only will conflicts come from here to there, but there will be people who will shout IMPERIALISTS! NATIONALISTS! OPPRESSORS! IMPOSERS!, because we're "imposing" the English language (and English-speaking culture_ on other people by advertising the simple english wikipedia. I'm not sure what to think of the latter opinion, but it is worth looking into. I dream of horses (T) @ 01:36, 5 August 2009 (UTC)
I think that promoting the Simple English WP on the English WP over French and Japanese is perfectly understandable. I very seriously doubt that anyone would be upset by it. I completely agree with the above that Simple isn't useful, but as long as we can't close it (it's been tried), we might as well use it. ▫ JohnnyMrNinja 07:44, 9 August 2009 (UTC)

How about using Template:Sister, like with Commons, Wikiquote, etc.? ▫ JohnnyMrNinja 07:44, 9 August 2009 (UTC)

Show redirects on list of watched pages

I'm positive it's been proposed before, but it'd be nice if in your list of watched pages, there were some sort of marker to identify pages that are redirects. I dunno how technically feasible this is, but since the "what links here" shows it, I can't imagine it'd be TOO hard. ♫ Melodia Chaconne ♫ (talk) 20:08, 7 August 2009 (UTC)

If you're satisfied with something that works only for users who activate it, User:Anomie/linkclassifier.js does this, among other things you might want. (I noticed that my colours disappear when I switch to the new Beta though, but I guess that can be solved.) —JAO • T • C 20:24, 7 August 2009 (UTC)
Putting your personal .js in vector.js instead of monobook.js is the first step. Some scripts will need actual rewriting, though. Algebraist 22:28, 7 August 2009 (UTC)
Thanks—works like a charm! —JAO • T • C 08:52, 8 August 2009 (UTC)

Article Launcher

As an improvement to the Article request page, how about an Article Launcher like YKTTW on TV Tropes? It could be useful for allowing I.P.s to start articles whilst limiting the problems that led to Anons not being able to create pages. Thoughts?----Occono (talk) 00:31, 11 August 2009 (UTC)

Maybe I'm missing how that works, but isn't it primarily for issues naming articles? I don't it is the titles that are the issue with anon page creation, but rather the content. Did I misunderstand it's function? ~ Amory (user • talk • contribs) 00:54, 11 August 2009 (UTC)
No, and yes. It's mainly for determining whether something is a genuine Trope, gathering examples, making sure it's not a duplicate etc., though it can be used just for coming up with catchy names. Anyway, the point is that it would be good for improving the content of an article before launching it.----Occono (talk) 01:24, 11 August 2009 (UTC)

Wikipedia_talk:Featured_article_review#Another_FAR_delegate

Is it needed? YellowMonkey (cricket photo poll!) paid editing=POV 03:45, 11 August 2009 (UTC)

Vector more than ready for prime time

After carefully reviewing all the mentions of "Vector" on Village Pump pages and [5], I propose that it replace Monobook as the default skin immediately for a period of one day after which the default shall be reverted, comments shall be examined, and further proposals including either general adoption and/or goals for the usability team will be in order. HowDoIUseUnifiedLogin? (talk) 17:58, 1 August 2009 (UTC) (sock of Nrcprm2026 --Enric Naval (talk) 02:24, 7 August 2009 (UTC))

Has anyone checked the scripts that people now invoke from their monobook.js, for example:
User:Mr.Z-man/closeAFD.js
User:Jnothman/afd_helper/script.js
Do the existing scripts that were written under Monobook continue to work when invoked from the new vector.js in all browsers? What about Twinkle? Checking how many people have tried creating their own Javascript file under the Vector skin, I only see 50-100 people who have created 'vector.js' files for themselves. Blanket usage of the Vector skin sounds premature. EdJohnston (talk) 21:12, 1 August 2009 (UTC)
Most "major" scripts will work in Vector. All gadgets definitely work. This was tested and fixed about a month ago. Everything that does not work can be easily fixed. —TheDJ (talk • contribs) 21:18, 1 August 2009 (UTC)
How do you tell the difference between "using the default skin" and "using Monobook"? Or are all those who prefer Monobook going to have to suffer through your day? Anomie⚔ 21:31, 1 August 2009 (UTC)
You can't; there's no obvious way in preferences of distinguishing between "I use Monobook because I love it" and "I use Monobook because, meh, I haven't bothered changing". A forced change like this would also remove any changes made to a Monobook user's personal css, which would undoubtedly prove unpopular! Shimgray | talk | 21:35, 1 August 2009 (UTC)
This is no longer entirely true. Since a couple of months ago, preferences are only saved in the database when they have been modified; 'default' settings are no longer stored, and so can be changed without affecting users who have saved an explicit preference. However, there is some complication with the huge body of preferences saved before this transition, which won't have this ability. But the default can be changed for logged-out and new users without impacting on users who have specified another skin, including monobook. Happy‑melon 16:09, 2 August 2009 (UTC)
I think this discussion was just had about something less big, but all users that are currently at "default" could conceivably be switched to Monobook, right? ▫ JohnnyMrNinja 03:25, 3 August 2009 (UTC)

There is absolutely no point in performing a one-day test. There's not a whole lot of point in performing a one-week test. The Foundation has poured thousands of dollars into the usability initiative that has created Vector. This skin, or another like it (certainly 'a skin other than monobook') will become the default skin on WMF wikis. What do we gain from yo-yo-ing between the two skins, other than confusion? If we anticipate problems (other than familiarity issues) with the transition, then that's evidence that the transition is premature. But this change is going to happen at some point AFAICT, despite the huge inertia of the projects. There's no point in rushing: if we can't agree that the time is right to transition permanently, then the time is not right to transition at all. Happy‑melon 22:19, 1 August 2009 (UTC)

I agree, the confusion caused from switching the skin back and forth so rapidly would likely overwhelm any useful data. Mr.Z-man 23:18, 1 August 2009 (UTC)
I agree with each of you that Vector is probably ready for mainstream (indefinite) use and that a short test would be confusing, but I'm worried that changes in Vector, or another, newer skin, might cause similar problems to that of a short test. For example, Vector is the "Acai" (A) release, and has open-ended tabs. The "Babaco" (B) release mockup has closed tabs and a different, "soft shiny" look. Given the significant aesthetic differences, I'm wondering how soon we want to make the new skin the public default: if the usability initiative is going to make significant aesthetic differences with each release, it would look odd to the outside world to have Wikipedia's look continually changing, even through the "official" mechanisms of the Usability Initiative. If we implement something, we want it to last at least a couple of months before it is changed. {{Nihiltres|talk|edits}} 23:43, 1 August 2009 (UTC)
Site-wide "Beta" invitation is scheduled to be rolled out to all Wikimedia projects later this week. This invitation is intend for non-logged in users to either create an account or log-in and change their default skin to Vector and enables the enhanced toolbar. People who do not like the new interface can leave "Beta" in one click and provide feedback if they choose to do so. The usability team will share the opt-in/opt-out stats once we have accumulated data. You can check out how the beta invitation is implemented by visiting the prototype site. --Shuhari (talk) 21:05, 3 August 2009 (UTC)

In light of the above I modify my proposal to simply cut everyone over if they have Monobook in preferences, with some kind of a warning in a site notice that they will have to change it back if they want to keep the customizations in their monobook.css or monobook.js file(s). HowDoIUseUnifiedLogin? (talk) 01:54, 2 August 2009 (UTC) (sock of Nrcprm2026 --Enric Naval (talk) 02:24, 7 August 2009 (UTC))

With due respect, that sounds like a terrible idea. Deliberately interfering with someone's preference settings violates every possible expectation of what those setting mean, and would piss most people off to no good end. Moreover, you're not going to get a neutral evaluation of the Vector skin from people who have had it summarily dumped in their laps when they did not want it. — Gavia immer (talk) 02:06, 2 August 2009 (UTC)
Er, that's how the transition will have to work, since we don't have a 'use site default' selection in addition to the "default" monobook.    M   03:12, 3 August 2009 (UTC)
Well no. You could leave all existing accounts as is and only switch IPs and new accounts after some date. Dragons flight (talk) 03:29, 3 August 2009 (UTC)

Out of curiousity, is there a compelling use case for Vector? By which, I mean is there something I can do with Vector that I can't do with Monobook? Maybe I'm old fashioned, but I've played around with Vector and generally find I like the feel of Monobook better, so I plan to continue using it for the foreseeable future. I did install the advanced editing toolbar though, that's nice. Dragons flight (talk) 02:28, 3 August 2009 (UTC)

I agree with DF. I've played with Vector and still prefer Monobook. Also, I think some of VoA's scripts aren't working with Vector, FWIW. -- Avi (talk) 07:12, 3 August 2009 (UTC)
Quite simple. It's what the unregistered readers will see. So I would stick with monobook for writing in user space but will use the new ... novelty for checking page layout when it's ready for release into main space, or making major changes to existing page layout. NVO (talk) 10:30, 3 August 2009 (UTC)
I'm with Dragons flight on this too. Vector is supposed to improve usability, but I see nothing but arbitrary change for the sake of change (which invariably reduces usability for a time). I'm very uncomfortable with the idea that the skin's default implementation is predetermined and inevitable (because of the amount of money invested in it?), regardless of the community's opinion. "We have no choice, so we might as well get it over with" (scare quotes) is far from a compelling rationale. —David Levy 10:59, 3 August 2009 (UTC)
I'm also curious what is so great about it; but then, I have already improved usability for myself by removing the edit toolbar (you shouldn't use the mouse to write code) and switching to Modern. I see as little incentive to use Vector as I see to use Monobook (the incentive for Monobook is mostly "it's the standard"; I sometimes check what pages look like in Monobook so I'll see what others see). Kusma (talk) 14:14, 3 August 2009 (UTC)

I tried out vector, and I see that is wastes more screen area at the top and bottom, making it harder to head articles on small screens. Changing the default skin would also disable all the user scripts people have in their monobook.js files. You would have to copy everyones monobook.js to vector.js, or make the user scripts not connected to the skin. Why is like that anyway? In general I think very few have heard of Vector, even among the most active Wikipedians. You should spread some awareness before you force the switch. --Apoc2400 (talk) 10:17, 3 August 2009 (UTC)

T12183 is related to the idea of a Special:Mypage/common.js. I do think it would be a good idea. (also)Happy‑melon 10:47, 3 August 2009 (UTC)
It does not always work either; I copied my jss/cs to Vector, and the VoA scripts still do not work, at least those that I have tried. -- Avi (talk) 12:43, 3 August 2009 (UTC)
Ew. Vector is ugly! Who then was a gentleman? (talk) 20:07, 3 August 2009 (UTC)
I second that assessment. I thought someone in my family had screwed up the computer’s defaults, but couldn’t find a way to fix it … then I noticed the same “problem” when trying to access WP from work. So, when do we revert? Askari Mark (Talk) 17:06, 7 August 2009 (UTC)


Ok, so, usability point: "use sitewide default" as a skin selection? --Kim Bruning (talk) 23:42, 3 August 2009 (UTC)

Definitely. Oh, and I hadn't realized that they still haven't fixed any of the problems brought up on that feedback page over at usability., especially that huge space at the top of the page. Until they do that and are ready to solve any new problems that come up, we should stick with monobook.    M   00:03, 4 August 2009 (UTC)
  • At the rist of spamming, would it be effective to use a bot to post a note pn the talk page of every user with a custom monobook.css page, warning them of the iminent shift and asking them to copy their scripts to vector.css to check for problems? It could be limited to those who've edited within some reasonable time increment to avoid spamming inactive accoutns.   Will Beback  talk  01:28, 4 August 2009 (UTC)
Excuse me, but what's wrong with monobook? Why fixed something that isn't broken? I dream of horses (T) @ 01:46, 5 August 2009 (UTC)
I too can't see the need for change and certainly don't understand why people should be forced to use vector, if only for a day. I'd welcome a global message notifying people of its existence, and encouraging new users who can't use monobook to employ it, but I can't see why we should change defaults and traditions. It's basically a pimped monobook which doesn't look as functional and has been created and pushed for default implementation without the need being as great as implied by supporters. Greg Tyler (t • c) 23:12, 6 August 2009 (UTC)

I'm assuming "Vector" is the same as the beta. So, how does one, using the beta, "unwatch" a page, please? - Denimadept (talk) 23:38, 6 August 2009 (UTC)

This is a terrible idea, and it's being thrown around by a banned editor who uses socks to bounce around ideas[6]. This guy was just trolling by proposing a preposterous idea. (P.D.: for why it's a preposterous idea, see Usability testing and how testing is done in small groups before rolling huge changes to the world. This idea makes Jakob Nielsen sad) --Enric Naval (talk) 02:24, 7 August 2009 (UTC) P.D.: actually, after seeing other off-wiki proposals by the person behind the account I think that there is the possibility that he is simply clueless to the point where his good-faith proposals are so terribly misguided that they look like trolling. --Enric Naval (talk) 18:54, 8 August 2009 (UTC)

Toolbar

The new toolbar does not work with the editing gadget and Greasemonkey script wikEd, please see Bug 20134. Cacycle (talk) 19:25, 8 August 2009 (UTC)

The toolbar is a part of Extension:UsabilityInitiative; it isn't a part of the Vector skin or MediaWiki 1.16alpha. Go to the Usability Initiative wiki and report the problem. --Michaeldsuarez (talk) 17:02, 10 August 2009 (UTC)

WP:VECTOR

As it was mentioned above that WM spent several thousand dollars on Vector, and this will become our default skin at some point, I have scribbled out WP:Vector. My thinking is that the project page will be for explaining vector in depth. What issues is it addressing? How is it addressing them? How much did we spend and where? And known bugs. The talk page would be for discussion of Vector errors or usability issues or help or whatever. There is never enough on-wiki documentation of our new software. This way there is no digging through talk pages or other wikis for basic info. Obviously I didn't put much info on that page, because I don't have any info on vector. Please assist in building this page. Thanks. ▫ JohnnyMrNinja 13:51, 7 August 2009 (UTC)

It has to be said, the redesign was not worth $0000s. Vector simply has new icons, a moved search box and more irritating tabs (why have a drop-down box for all the things I regularly use? And how is that not my choice?) En plusse, the fade-y tabs look revolting and footer and navigation boxes flow far too easily into one another. If I hadn't known, I would've thought Monobook to be a more straight forward, improved version of Vector. Greg Tyler (t • c) 16:47, 7 August 2009 (UTC)
There is a clear difference between noob usability and editor usability. The whole usability initiative was primarily intended for the first set of users, in an attempt to get them to become part of the second group. That this would have some impact on the current editor group was a given fact in the first place. That does not mean you don't have a say. Give feedback. on the place where you were invited to give it. usability wiki. And also, this is step 1, not final station. I'm personally just amused at how much editors are stuck in their patterns. Any form of change except the one they personally approved is BAD. With so many editors, you can't do a thing correct in changing the interface of course. And judging from the fact that some people still use pre-monobook skins because they didn't like the monobook skin, will tell you that there is simply gonna be a large group at the end, that will not be happy with the result. No matter what the endproduct will be. —TheDJ (talk • contribs) 00:34, 8 August 2009 (UTC)
I've been using Vector all day, and I'd have to say that after a few minutes of reorientation I like it. I don't intend to switch back to the old monobook skin, as I think it's a significant improvement. --Malleus Fatuorum 00:40, 8 August 2009 (UTC)
I see no connection between spending any amount of cash and forcing the users and readers to use an inferior replacement. NVO (talk) 21:00, 8 August 2009 (UTC)
You have something called preferences, and anyone can use them to select their preferred skin. —TheDJ (talk • contribs) 21:51, 8 August 2009 (UTC)
Well of course I do, but readers "from the streets" don't. NVO (talk) 20:53, 9 August 2009 (UTC)
Vector is still in development. And you will (hopefully) be able to customize what menus are open by default. HereToHelp (talk to me) 11:58, 11 August 2009 (UTC)

more comprehensive page history statistics

It would be great if some of the stats from en.wikichecker.com could be incorporated into the History tab of articles. The key ones would be:

  1. total number of edits and editors - to give a perspective of the 'depth' of the article
  2. date of first edit (ie age of article) - this and the above can then be combined to form some sort of average edits/day measure.
  3. top 10 editors (with either the number of edits or proportion of total) - to give a more sophisticated view of the first statistic
  4. edit mix of registered vs anonymous users

I have been using this site to check a number of the articles I watch, and think it would be an incredibly valuable resource for everyone from those who mainly read to those who mainly edit. The best way to expose all this information would be to roll it into Wikipedia officially rather than having an external site do it. Note I am in no way affiliated with wikichecker.com, I just think that the stats it presents are really useful! Cheers Mitsuhirato (talk) 12:14, 10 August 2009 (UTC)

A rather good idea - this one has my support. I did not even know of http://en.wikichecker.com until I read your post! ACEOREVIVED (talk) 20:13, 11 August 2009 (UTC)
The date of the first edit can be found by clicking the "earliest" link and looking at the last entry on the page. EVula // talk // ☯ // 20:21, 11 August 2009 (UTC)

Scottish locator map

Input is required at Wikipedia talk:WikiProject Scotland#Scotland location to come to a consensus on which map best serves the purpose. Dr. Blofeld White cat 10:31, 11 August 2009 (UTC)

Allow users to redirect subpages of WP:K or WP:U to their user or user talk space

There's been many recent RFDs on so-called "vanity" redirects (not to single anyone out, but, for example: WT:SANDY -> User talk:SandyGeorgia).

What about allowing users to create shortcut redirects as subpages of the redirect pages "WP:K" (redirects to WP:Keyboard shortcuts) and "WP:U" (redirects to WP:Username policy).

Example: WP:U/X -> User:Xeno / WT:U/X -> User talk:Xeno
(I realize my name is already pretty short - this is an example only and I'll delete it if this proposal doesn't carry)

Thoughts? –xenotalk 17:12, 10 August 2009 (UTC)

It's also possible to turn U: and UT: into name space aliases of User: and User talk: (like WP: currently is an alias of Wikipedia:). You could then register and redirect User:X (U:X), also elimination the possibility for naming conflict. —Ruud 18:47, 10 August 2009 (UTC)
That's another idea, but then there would be a landgrab for short usernames. (Not that there won't be a landgrab for short subpage names, but this is extensible) –xenotalk 19:12, 10 August 2009 (UTC)
I don't like it. It's quite possible and even likely that we will run into naming conflicts in the future, in which case the shortcut doesn't help any. Further, if a user wants a different link to his page, he should have himself renamed. Each user is an individual, and it would be prudent to leave that the way it is. --Izno (talk) 18:56, 10 August 2009 (UTC)
Agreed. You'd get into the same sort of Trademark issue that exists now with urls. What if X! wants U:X - does he get it or does Xeno get first rights? The logical conclusion is, as you point out, where we are right now. ~ Amory (user • talk • contribs) 00:48, 11 August 2009 (UTC)
Well, he could use WP:K/X. But it's first-come-first-serve. I don't see a particularly compelling reason not to allow users to hijack the subspace of these one letter redirects in WP space. –xenotalk 15:03, 11 August 2009 (UTC)

Please see Wikipedia:Village pump (proposals)/Archive48#Userspace redirect where I proposed this back at the end of June. The discussion apparently went stale so I didn't pursue it. -    allstar▼echo    22:53, 10 August 2009 (UTC)

We could say that anyone can create U:xx redirects to pages they use a lot, just to save them typing in the search box, but that wouldn't give them any permanent right to the redirect (someone else might reuse it for something else at some point). The trouble with programmed aliases is that you make it impossible to create an article beginning with that alias should the need arise. (We ought to have personalized redirects that work only for you, but that would require software development...)--Kotniski (talk) 09:11, 11 August 2009 (UTC)

That would be a pseudo namespace in the mainspace. I would oppose that. –xenotalk 15:03, 11 August 2009 (UTC)
The pseudo-namespaces we have are in the mainspace (P:, T:, CAT:,etc.) Why would this be any different? Or do you oppose all such uses?--Kotniski (talk) 08:51, 12 August 2009 (UTC)
I'm not a fan of them. I don't think they should be extended to user pages. –xenotalk 13:34, 12 August 2009 (UTC)

I'm not really seeing much tangible benefit to this proposal. Most user names are relatively short and easy to type as it is, and I don't see how there is any need for a shorthand method of typing them. Shortcut redirects also exist to help users get to policy/guideline pages whose titles may not be as memorable as their shortcuts; again, this should not be an issue for usernames. It strikes me as little more than a vanity redirect that has the potential to run into ownership issues down the line. Please forgive me if I'm being narrow-minded, but I just don't see how this would really benefit the community as a whole, rather than select users who manage to stake a claim to a short or a "fun" vanity redirect. Shereth 13:19, 12 August 2009 (UTC)

Some folks find them useful. Some people do have longer names to type, e.g. User:Moonriddengirl (luckily she has User:MRG as a handy doppel and redirect). The example above, WT:SANDY was made by someone-other-than Sandy as a shortcut because SandyGeorgia is a valuable and oft-used resource. I just think that allowing users to use the subspace of one-letter redirects wouldn't really be that bad of an idea. I'm sure not many would even bother, but it would keep it out of WP: space proper. –xenotalk 13:38, 12 August 2009 (UTC)
Currently there are only 9 pages that link to WT:SANDY, including this one and the one at RFD. I do not believe they are really that useful. Userpages are, by their very nature, easy to remember; the only argument in favor of this proposal is that it makes for a little less typing. Sure, there are a few examples of long usernames out there, but even then, the benefit is minimal at best in shaving off half a dozen letters. If a user's name is so unweildy that they feel the need to register a shortcut to it, perhaps they should have just used a less unweildy name to begin with. Shereth 14:11, 12 August 2009 (UTC)
You may not find them useful, but what about the folks who do?... those that type them into the search box regularly to navigate to the desired page? (See the pageview statistics for WT:SANDY, it's not huge, but it's being used on a semi-regular basis). What harm would they cause? –xenotalk 16:36, 12 August 2009 (UTC)
To be honest I'm somewhat ambivalent toward the idea. I don't think it's a harmful proposal, but I also do not believe it to be a useful proposal. I don't believe it to be worth implementing but at the same time I'm not going to pitch a fit if it is. Shereth 16:40, 12 August 2009 (UTC)
It requires no implementation other than the understanding that the subpages of single-letter redirects are fair game for users to use as redirects. The benefit is that they stop using WP and WT pages for this and saves time at RFD. –xenotalk 16:42, 12 August 2009 (UTC)
(ec) Why not just register a doppelganger sockpuppet (clearly identified as such) with a short username - if you absolutely must have one. There's not that much difference between typing U:FOO and User:FOO. User:FOO can then contain a redirect to User:FooSmithJonesIII. Yes, there's still the 'land grab' problem, but that would exist with any designated namespace or subpage holding area for these redirects. TenOfAllTrades(talk) 13:42, 12 August 2009 (UTC)
Doppelgangers would work if we could have a namespace-redirect (not pseudo) from UT to User talk:. Otherwise WT:?/ still saves six characters over User talk:. It's also extensible, there's 26 letters and ten single numbers (not to mention symbols). –xenotalk 13:45, 12 August 2009 (UTC)

Is there any way in which we could make link piping such as [[Link, to be piped|]] display itself as [[Link, to be piped|Link]] in references? Currently, the only way that we can pipe a link inside ref tags is to type the text to be displayed; if we simply put the pipe and then the brackets, it displays as if it were inside nowiki tags. For example, search for the words "Hopewell (Union Bridge, Maryland)" and "Mount Airy Historic District (Mount Airy, Maryland)" in the references section of this version of National Register of Historic Places listings in Maryland. Isn't there some way that we could make it work like in normal text, where all text after the first comma or first parenthesis is hidden? Nyttend (talk) 14:19, 12 August 2009 (UTC)

This is bugzilla:2700. Algebraist 15:14, 12 August 2009 (UTC)
Thanks. Nyttend (talk) 16:02, 12 August 2009 (UTC)

Tagging pages containing sexual content

I'd like to propose that pages containing or pertaining to sexual content be added to a Category:Sexual Content. This would make it a lot easier for filters. (I am by no means in favor of any kind of censorship). Any opinions on this? Support? Oppose? I'd like to hear what you think.Smallman12q (talk) 16:02, 10 August 2009 (UTC)

I think a hidden category "Pages containing images which may be considered objectionable" that allowed opt-in scripts to suppress image display might be worthwhile. –xenotalk 16:05, 10 August 2009 (UTC)
A possibility would be PICS, but that hasn't been widely adopted yet.—RJH (talk) 17:27, 10 August 2009 (UTC)
We should not even consider this. Open any encyclopedia and you may see "sexual content", do we put disclaimers on those? What next, Category:Content that may be offensive to (name of some group - Muslims, Christians, Scientologists etc) - no a thoroughly bad idea. – ukexpat (talk) 17:39, 10 August 2009 (UTC)
WP:NOTCENSORED. It should be pretty obvious that navgiating to risque topics such as Anal sex is likely to result in the display of risque images, and users can avoid these topics when at work/school/whatever. Otherwise, the old mantra "Wikipedia is not censored" applies. Shereth 17:40, 10 August 2009 (UTC)
"Wikipedia is not censored" translates pretty easily into "Wikipedia is inflexible." Bus stop (talk) 17:45, 10 August 2009 (UTC)
Providing options is not censorship. This would be strictly opt-in. The pages would be tagged with a hidden category or template and scripts would act on it. –xenotalk 17:46, 10 August 2009 (UTC)
Exactly. There's no need for a knee-jerk anti-censorship reaction here. I don't want to see mandatory censorship, but I would like the option of avoiding articles that are not "office friendly". This can occur, for example, when selecting a random article for a little lunch-time browse/ce.—RJH (talk) 17:45, 11 August 2009 (UTC)

reject early, reject often - rejected every time it comes up for the reasons mentioned above. I might consider it if we also add a category that is called Content that may be offensive to people who are afraid of clowns to all clown related articles. --Cameron Scott (talk) 17:48, 10 August 2009 (UTC)

Could you elucidate what reasons were mentioned above? I support WP:NOTCENSORED but haven't seen any reasons to reject an optional way to not display certain material. –xenotalk 17:53, 10 August 2009 (UTC)
OK then, who decides what constitutes "sexual content"? That's the problem with any censorship, quasi-censorship, or opt-in based on content - it's subjective and will just lead to more, endless, Wikidrama. So, bad idea. – ukexpat (talk) 17:51, 10 August 2009 (UTC)
This is why I suggested "Pages containing images which may be considered objectionable" and I'm sure it could be broadly construed. Users opting in would have to accept that images may be suppressed that they might not themselves find objectionable. Some things that might be hidden: Images containing nudity, depictions of sex, depictions of Muhammad, Rorschach inkblots, etc. –xenotalk 17:53, 10 August 2009 (UTC)
Same problem, who decides? Then there will be endless edit wars adding and deleting the category. Just seems unworkable to me. – ukexpat (talk) 18:01, 10 August 2009 (UTC)
It's opt-in only so there shouldn't be any debate over it. –xenotalk 18:23, 10 August 2009 (UTC)
Of course there will be - there are debates over the most excruciating minutiae on Wikipedia. This will be a fruitful area for debate. – ukexpat (talk) 18:25, 10 August 2009 (UTC)
I resent your position that this undebatable position will be debatable. I ask you to strike it at once, else we will have to engage in further debate. –xenotalk 20:32, 10 August 2009 (UTC)
We could classify it, eg Content likely to be objectionable to small-town Americans, content likely to be objectionable to city-dwelling Americans, content likely to be objectionable to the Swiss, Content likely to be objectionable to nuns, etc, to account for the vast variations in what people find objectionable. DuncanHill (talk) 17:54, 10 August 2009 (UTC)
Perhaps, rather than having this "endorsed" in a sense, by the community as a whole, a userscript could be created with a community-built database of material that will be suppressed. –xenotalk 17:56, 10 August 2009 (UTC)
We'll need "material that may be considered objectionable by some psychiatrists but not by others" for the inkblots. All sexual content? Stamens and pistils? sorry, lost the sigDuncanHill (talk) 18:07, 10 August 2009 (UTC)
(ec, reply to Xeno) If someone wants to create a userscript that employs a third-party database of "objectionable" images, updates that database on their own, and does not start adding tags on Wikimedia sites itself, then I say more power to them. If the community starts doing this, or even implies an endorsement by allowing an article to be tagged, then we set a bad precedent. Shereth 18:04, 10 August 2009 (UTC)
(edit conflict) Reply to Xeno: Now we're getting somewhere. I think the consensus is pretty well-worn that "Categories (metadata) should not be placed in articles if their sole purpose is censorship." So I agree with Shereth's position: a third-party database is fine, whereas no endorsement of solely-censoring categories should be tolerated. But what about the gray area? -- Category:Articles that contain pictures of Mohammed / genitalia / democracy? I would be horrified if such a category were used for censorship purposes, but at the same time, we become the censors if we refuse to permit that kind of information to be added to articles. (As I'm watching this thread develop, I'd like to ask the anti-censorship voices to please restrain their sarcasm and intolerance. That, too, is a form of censorship.) Andrew Gradman talk/WP:Hornbook 18:20, 10 August 2009 (UTC)
So - just for a moment to attempt to take this suggestion seriously:
  • Who would decide what tags were placed on articles?
  • What would happen about edit wars on this?
  • Who would decide what went into this "community-built database"?
  • Would there be a new class of censor bureaucrats?
  • What would their qualifications be?
  • How would they be appointed?
  • Would all of this be in fact a new area for POV editors to waste their time debating the merits of various articles?
Feel free to expand on above. Jezhotwells (talk) 18:06, 10 August 2009 (UTC)
I see that some of the thoughts I have expressed in previous discussions have already been stated. If someone wanted to provide rated lists or scripts of articles and images outside of the Wikipedia environs, then more power to them. ---— Gadget850 (Ed) talk 18:15, 10 August 2009 (UTC)
Someone will eventually end up being offended by an article being included in a "Content that may be offensive to X" category. The cycle will never end. hmwitht 18:18, 10 August 2009 (UTC)

Aw, hell, I had a long post all constructed, and then Xeno makes it obsolete by thinking of a better idea. Yes, rather than upset people by inserting hidden categories into articles, anyone who wanted to could create lists of articles that meet a certain criterion, and then scripts could perform an action based on those lists. There would really be no limit, and no disruption for others, if someone actually did create User:Example/Content that may be offensive to people who are afraid of clowns, and tweaked a master script with their own preferences, so they could see the content but not the images. True phobics could choose to not even be able to load an article listed in it.

Of course this would be inefficient if each user created their own lists, but very quickly people would stop re-inventing the wheel, and start using the same lists. Subpages of WP:Filtered content could be set up by any group interested in taking the time to do so, with absolutely no effect on those of us who don't want to filter anything, or those of us who do want to filter some things, but aren't scared of clowns. Or, less optimally but still possible, something similar to User:UBX could be used, and subpages of User:Filtered content could be used to set up lists of files there. Or something. anyway, this, to me, is the solution.

It would be nice if Wikipedia's community allowed this to be done in a semi-organized way, but I imagine a group of determined users could set something like this up by themselves. But I don't see any need to force it to happen off-wiki. This would be a true service to readers, and since that is our core business, we should help to make it as useful as possible. --Floquenbeam (talk) 18:24, 10 August 2009 (UTC)

I can just imagine all of the Muslims who will want to add all images of women's bare faces to be added to this list. Who then was a gentleman? (talk) 20:29, 10 August 2009 (UTC)

Break 1

To address those concerned with censorship, this would be strictly opt-in. Censorship is defined as "the suppression of speech or deletion of communicative material which may be considered objectionable, harmful, sensitive, or inconvenient to the government or media organizations as determined by a censor." In this case, the censor would be the person themselves; essentially self-censorship.

Ideally, I'm hoping something along the lines of Platform for Internet Content Selection can be created. Currently, you can indeed easily write a script to filter based on categories, so all this fuss regarding Category:Content that may be offensive to (name of some group - Muslims, Christians, Scientologists etc) is misguided.

Perhaps some kind of central list that more broadly categorizes content (based on certain criteria) can be designed.

I'm not looking to censor anything. I'm not here to create a legal disclaimer about content. I'm here to create a kind of central opt-in list that will allow users to better control the content they want to see. We have pop-up blockers and ad blockers, and so I'm hoping to make wikipedia more friendly to various people.Smallman12q (talk) 20:46, 10 August 2009 (UTC)

Opt-in vs censorship isn't the problem, the problem is that someone has to categorise, or add other metadata to, the article to enable the option. The decision to add the category is wholly subjective, and subject to abuse and massive edit warring, with ensuing wikidrama, dispute resolution etc, etc. Then other "offended groups" will come along and say "what about our feelings?" and on it goes. – ukexpat (talk) 21:01, 10 August 2009 (UTC)
ukexpat, I don't agree that the addition of metadata would necessarily be contentious. Suppose you create "Wikiproject Human Genitalia" and tag the talk pages of articles. Let's suppose that, in the beginning, articles of top importance include Anal sex and penis; mid importance includes breast feeding and menstruation; low importance includes gamete and fetus. Suppose further that the Saudi Arabian Government wants to censor menstruation but not breast feeding. They can adopt a policy of censoring the Wikiproject's articles of "top" importance and try to persuade the Wikiproject to move menstruation to that category; or they can just start censoring articles of mid importance as well; or they can start a new WikiProject, WikiProject Islamic blasphemy, whose levels of importance correspond to Islamic theology -- top importance would include anal sex and Mohammed, mid importance would include menstruation and alcohol, low importance would include pictures of exposed female skin.
This outcome would horrify me, but there's nothing I can do about it. Andrew Gradman talk/WP:Hornbook 21:42, 10 August 2009 (UTC)
Of course, Floquenbeam is right that this could be done without adding metadata-- it could be done in a Script. (And it probably is being done with scripts.) But I disagree that it's our job to be writing these scripts. If the National Association of Elementary School Teachers wants to write the script, let them hire someone to do it. Andrew Gradman talk/WP:Hornbook 22:03, 10 August 2009 (UTC)
The problem is that, no matter how you look at it, this is censorship. Whether it's opt-in or mandatory, whether it's 3rd party or done by editors, is all immaterial. It's a restriction of rights (yes, I said the R word; did I hear some gasps?). The only thing that this would do would be to drive away people from Wikipedia, including myself, as WP:NPOV became a laughing matter (Neutral Point of View implies there is no censorship - the reader views what they want, and they don't view what they don't want). What is REALLY required is that all articles have explicit enough titles so the user KNOWS when the would rather not read / see something. This also means that all links have text that works similarly to article titles.
An encyclopedia, in print or online, is a fountain of information. Censorship of any kind would restrict the amount of information perceived, and so the status of Wikipedia would quickly go downhill. Tim Sabin (talk) 22:17, 10 August 2009 (UTC)
Are you trying to elicit some type of emotional outrage? A restriction of rights? It would be strictly opt-in, I don't see vegetarians complaining that they are somehow being restricted by an entity other than themselves.

Well instead of physically marking an article, perhaps a central list could be compiled. (Please Note:It could easily be done off wikipedia).Smallman12q (talk) 22:26, 10 August 2009 (UTC)

As I stated before, I really don't care if some third party wants to compile a list of "offensive" images and create a userscript that would filter these out. Users have an awful lot of leeway with userscripts, this is no different. I would be absolutely opposed to any system that physically tags an article/image with categories or any kind of metadata, visible or otherwise. I'm also fairly opposed to any kind of on-wiki project, or any kind of on-wiki list or database of "offensive" images/articles. Just as we should not be facilitating censorship, we should not be facilitating the labeling of images/articles with subjective descriptions such as "offensive". The maintenance of such a list in userspace would be somewhat more palatable and I would not have such a strong objection to it, but the other solutions being suggested are not acceptable. Shereth 22:43, 10 August 2009 (UTC)
Similarly, I have a friend who is Sudanese and Muslim and actively supporting Lubna al-Hussein, a Sudanese woman facing ten lashes for wearing trousers in public. I imagine she would be gravely offended by any sort of list or category that purports to represent Muslims, Sudanese, or Sudanese Muslims and prevents the viewing of images of women wearing trousers. Any sort of listing that purports to represent a group of individuals who are not actually involved in choosing the contents of that list is an instrument of control, not choice. People are fine to do whatever they want off wiki to shape their and others' viewing experience, but let's not pretend that it's an apolitical act. - BanyanTree 07:25, 11 August 2009 (UTC)
Here, here! Tim Sabin (talk) 11:59, 11 August 2009 (UTC)
Hear, hear, I'll second that! – ukexpat (talk) 15:04, 11 August 2009 (UTC)
What Shereth has said, in general. Count me opposed to anything of this sort. Exploding Boy (talk) 17:49, 11 August 2009 (UTC)
This is a persistent proposal; just wanted to see if anything had changed. So far though, it seems as though most people are opposed.Smallman12q (talk) 15:27, 12 August 2009 (UTC)
No, no, no, no. Although this proposal is nobly attempting to make this metadata have minimal visual impact, the trouble is that standards for what constitutes objectionable sexual content are extremely subjective, and would be the subject of pointless debate. I may not object to a hidden category for "articles containing sexual images", since this is fairly objective, but I would seriously question the misdirected goals of any filtering software that blocks all articles in this category (contrary to popular belief, children do need to learn about sex). Dcoetzee 20:12, 12 August 2009 (UTC)
I don't think "sexual image" is an objective criterion at all. Is File:Closeup of female breast.jpg "sexual"? Or File:Gynecomastia 001.jpg? File:Namibie Himba 0716a.jpg? File:Invertednipple.jpg? What about File:Rocky Horror 2.JPG? File:Pamela_Anderson_2.jpg? --Stephan Schulz (talk) 23:43, 12 August 2009 (UTC)

Moved discussion to Village pump (proposals) as a more relevant forum. --Cybercobra (talk) 22:46, 12 August 2009 (UTC)

Wikipedia:WikiProject Intertranswiki/German

Hey folks! Am I the only one interested in transferring quality referenced articles from German wikipedia into English? The project needs people who understand a bit of German and see the potential in translating quality articles from German wikipedia. I need your help guys! Dr. Blofeld White cat 19:16, 5 August 2009 (UTC)

Hi there. Well, the page was only created about 3 or 4 days ago. *g* Clicking through to your talkpage we learn you held off from posting to the wider audience here for a week, in order to sensibly focus discussion initially. I don't speak German so won't be able to participate, but as there're several other WikiProject Intertranswiki/$lang pages created around the same time my curiousity is piqued ...

You used the phrase "transferring quality referenced articles", Dr. Blofeld. Please could you say below whether the scope of these Intertranswiki projects is restricted to quality in terms of assessed (FA/GA-equivalents) articles or manually selected well-developed longer articles; additionally, could you clarify if stubs (a sometimes ambiguous term, so take it to mean <3–4 sentences, perhaps unref'd), be they geostubs or others, are definitively excluded from these Intertranswiki projects?

As you might know, there was a recent issue of 4,000 unreferenced German politician substub articles created, involving semi-automated tools. Of course that's since been taken care of, and we don't need to revisit specifics; ultimately a mass-deletion was used to deal with the most part. I understand it wasn't you who created them, as well as that the editor had done so in good faith, with blp management aspects seen only later. We've no suggestion biography articles are involved in this new initiative. Let me explain why I've brought it up: It's purely for illustrating considerations involved in large translation initiatives, often involving topics which may stay short for a long time, and even for which scarce English-language sources may exist for easy expansion by those who aren't fluent in the respective languages. I also appreciate your positive effort with this initiative is so as to approach content transfer *proactively*, allowing things to go smoothly.

Will article intertranswikifys be checked by an editor who has mother tongue fluency or is a native speaker, in the respective language? Additionally, do machine translations play a part in the intertranswikifying?

Last, my understanding is that while there's long been a category system to hold articles tagged with language expansion templates, no active accompanying WikiProject existed to collaborate and direct efforts. Looking at a couple of the categories, there're many tagged articles; I've tagged some myself in the past that remain unexpanded. In excess of 750 German and 7,000 French articles, for example, according to the cat pages. Is initial clearing of those by Intertranswiki projects planned, or is broader concentration on articles in foreign language Wikipedias without en-wp counterparts planned? Sorry, that's quite a few questions! Thanks –Whitehorse1 21:09, 5 August 2009 (UTC)

I checked a few candidates from history... these are start-class articles with only referenced to printed books (some from 19th century) - no page numbers, no inline citations. Should I trust these texts, knowing that the very existence of some 12th century prince is debated? If anyone likes to improve Burgruine Petersberg it would be fair and much better to do it from scratch based on reliable, preferably English sources. A German wiki is still a wiki. NVO (talk) 05:06, 6 August 2009 (UTC)
NVO, thank you. While I don't speak German, I have read many references to de-wp here; my understanding is that many things're done differently there and in some cases better. I looked at the en-wp article you wikilinked. It's not even start-class; stub-class is more accurate. Its entire content is "Burgruine Petersberg is a castle in Carinthia, Austria." with zero references. Worse, the de-wp original has the titles listed under References marked "(formal falsche ISBN)", which an online translation tool reports is "(ISBN formally wrong)"; on checking the ISBNs, there is no matching title for one, with the other not even valid syntax for an ISBN. The en-wp article has a See also section wikilinking "List of castles in Austria". I clicked on 3 random list entries:
Burg Oberkapfenberg
Burg Oberkapfenberg is a castle in Styria, Austria. (de-wp: a 1-line & 2-paragraph unreferenced stub)
Burg Obervoitsberg
Burg Obervoitsberg is a castle in Styria, Austria. (de-wp: link to corresponding de-wp article leads to 'page does not exist')
Ruine Burg Schachenstein
Burg Schachenstein is a castle in Styria, Austria. (de-wp: a 1-line & 1-(small) paragraph unreferenced stub)
This is concerning. I am unable to consider any of these "quality referenced articles" as Dr. Blofeld referred to. Those I examined comprise broken links, perhaps an error during creating left unchecked, and sparse content either wholly unreferenced or invalidly (non-verifiably) referenced on the de-wp original. Burg, apparently glosses the English word castle. Burgruine Petersberg, the article you linked, was created on de-wp November, 2007, while Burg Oberkapfenberg was created March, 2004. It is difficult to be confident in the likelihood of their development or improvement on en-wp, when they have remained in that form for some years on their native-wp. At present, I do not know if the article you linked and the related articles I listed above derive from the Intertranswiki/German project Dr. Blofeld describes. It seems best for me to remain with good faith by making no assumptions. My hope is that Dr. Blofeld will respond to the questions I posted in reply above, so everybody can better understand the initiative. –Whitehorse1 20:31, 12 August 2009 (UTC)

Uhhh. This is why I established a wikiproject To improve the quality of transwikying to avoid the creation of weak stubs. Please read the main project page 'carefully before jumping to conclusions. Dr. Blofeld White cat 16:50, 13 August 2009 (UTC)

As I said when replying to your similarly-worded post on my talkpage, when the questions were posted your new project page (permalink) had very little information. For whatever reason, it appears you have taken my interest in your initiative and my desire for its success the wrong way. On that basis, perhaps it is better to simply move on from this thread. I wish you every success with your WikiProject(s), Dr. Blofeld. Thank you. –Whitehorse1 17:34, 13 August 2009 (UTC)

Rollback popup?

I just dropped my keyboard and rolled back this page. I have seen a lot of people accidentally hit the rollback button on their watchlists, some without even noticing. How would people feel about a little JavaScript popup that asks if you yes or no if you want to actually roll something back? ▫ JohnnyMrNinja 04:40, 6 August 2009 (UTC)

I would hate it; rollback is there for one-click rolling back of edits. If you accidentally rollback an edit, it's a sign that you need to be more careful, not that the tool needs to be changed. (and I say that as someone that has accidentally done so) EVula // talk // ☯ // 04:45, 6 August 2009 (UTC)
Perchance a gadget? Would it be possible to give a gadget to just rollbackers? ▫ JohnnyMrNinja 04:56, 6 August 2009 (UTC)
I agree with EVula about the "Rollback" feature existing for instant reverting of edits but I suppose there could be a checkbox in preferences for it. That way, Admins & Rollbackers will have a choice to enable a popup if they wish to. Harlem675 14:01, 6 August 2009 (UTC)
I wouldn't be opposed to a gadget, but it would either be in the way (turned on when you don't want it to) or not be there when you want it to be (turned off when you need it). Since we're talking about accidents, it's hard to predict when you need it (pretty much whenever you're not actively rolling back someone's edits). Perhaps an initial pop-up that only comes up a single time every two minutes (ie: it asks on the first rolledback edit, and assumes you still want to for all subsequent rollbacks for a short period). That'd strike a fair balance between preventing one-off mistaken rollbacks, but not reduce the effectiveness of the tool. EVula // talk // ☯ // 16:19, 6 August 2009 (UTC)
That sounds like a good idea to me. Harlem675 17:58, 6 August 2009 (UTC)
You could also consider disabling rollback links in your watchlist, recentchanges, etc., to limit accidental use. There's a thread in the archives on how to do this. –xenotalk 18:03, 6 August 2009 (UTC)
I threw together a little script in JS that adds a confirmation popup when you click "rollback". You can employ it by adding importScript('User:Greg_Tyler/rollbackprompt.js'); to your monobook.js page. Greg Tyler (t • c) 16:40, 7 August 2009 (UTC)
The whole point of the rollback link is to give one-click access to the feature; a mandatory confirmation click would largely be a waste of time. I don't mind the idea of having an optional confirmation (for the users who are either still getting used to the button, or who are accident prone) either integrated into Mediawiki (if the devs have spare time) or as a plugin/script (per Greg Tyler, above).
A relatively recent change that I very much approve of was the addition of the 'diff' to the 'rollback successful' screen. It makes it much easier to detect when you've rolled back further than you expected, or undone something that you shouldn't have. An ideal enhancement to that screen would be one more link: Rollback this change, or similar wording. If you did accidentally click rollback, you would have the immediate opportunity to undo your action in a single click, hopefully before anyone else notices. :D Thoughts on that? TenOfAllTrades(talk) 14:02, 12 August 2009 (UTC)
I like it! –xenotalk 14:08, 12 August 2009 (UTC)

I absolutely recommend adding the following line to your monobook.js:

importScript('User:Ilmari_Karonen/rollbacksummary.js');

As long as JavaScript is activated (important point! initially I got bitten several times when it wasn't), it opens a popup where you can enter a custom edit summary. If you just enter return or click OK, you get the default summary. If you click Cancel, the rollback is cancelled.

This function allows the use of rollback for non-vandalism reverts, but you need to be verify that you really want to revert all consecutive edits by the last editor. Hans Adler 17:11, 13 August 2009 (UTC)

Recent deaths tag for non-human animals

Please do not laugh at this proposal - this is only a suggestion. Today (August 6 2009), when looking at the "Deaths in 2009" category, I saw reference to this Wikipedia article:

http://wiki.riteme.site/wiki/Sam_(koala)

I saw that earlier today, this had the tag "This article is about a person who has recently died" but this has now been removed - and rightly so, I say, since Sam was a koala, not a person. However, how about introducing a tag which says "This article is about an animal that has recently died?" Wikipedia does list recent deaths of notable non-human animals, so perhaps there should be a tag for recent deaths for them, as there is for human beings who recently entered the pearly gates. ACEOREVIVED (talk) 19:40, 6 August 2009 (UTC)

My apologies; that did make me laugh. But it sounds do-able. --A Knight Who Says Ni (talk) 21:17, 6 August 2009 (UTC)
{{Recent death}} could add a species parameter. There are also notable trees and some of them are getting old... PrimeHunter (talk) 04:20, 7 August 2009 (UTC)
Better to add |alt= parameter, which will replace the word "person" if defined. Ruslik_Zero 19:04, 7 August 2009 (UTC)

Well, many thanks to the Wikipedian who operates under the uesrname "Canadian Paul" - there is now a category called "2009 Animal Deaths"! Perhaps this Wikipedian saw this discussion, or maybe this was just another Wikipedian thinking likewise. This could be the beginning of the type of thing I had in mind. ACEOREVIVED (talk) 20:38, 14 August 2009 (UTC)

Linguistic information template

Imho it's unlucky that the first sentence of an article often contains so much clutter: synonyms, pronunciation, etymology, etc. I feel the beginning, the article's most prominent place, is being wasted in this way.

An example is the Holocaust article:

The Holocaust (from the Greek [ὁλόκαυστον] Error: {{Lang}}: text has italic markup (help) (holókauston): holos, "whole" and kaustos, "burnt"), also known as The Shoah (Hebrew: השואה, Latinized ha'shoah; Yiddish: חורבן, Latinized churben or hurban) is the term generally used to describe ...

The sentence "The Holocaust is the term generally used ..." is ripped apart, interrupted with several lines that do not help me understand what the Holocaust is. Some other bad examples would be Chernobyl, Uruk, or China.

My proposal is a template to put linguistic information above the main text. It would be similar to the disambig templates. Example:

Word origin: Greek ὁλόκαυστον (latinized holókauston): holos "whole" + kaustos "burnt"
Also known as the Shoah from Hebrew השואה (latinized ha'shoah)
Also known as Yiddish חורבן (latinized churben or latinized hurban)

The Holocaust is the term generally used to describe ...

The wiki markup would look something like this. I derived it from the markup on the Holocaust page.

{{lingu|origin|{lang|el|ὁλόκαυστον} ({lang|el-Latn|holókauston})|holos "whole" + kaustos "burnt"}}
{{lingu|aka|the Shoah {{lingu-inline|from|{lang|he|השואה} ({lang|he-Latn|ha'shoah})}}}}
{{lingu|aka|{lang|yi|חורבן} ({lang|yi-Latn|churben} or {lang|yi-Latn|hurban})}}
'''The Holocaust''' is the term generally used to describe ...

How the template would exactly work is to be determined. People who know how to write templates: please weigh in.

Notes

  • The template would be used for:
    • "Word origin:"
    • "Also known as:"
    • "Pronunciation:"
    • Native names, example: the article "Germany" would have "German name: Deutschland"
    • "Transliteration:"
    • Anything else?
  • Is linkifying the language justified? A link from let's say "China" to "Chinese language" makes real sense, but a link from "Holocaust" to "Latin language" seems very far-fetched. Probably we should drop these links to reduce visual clutter.
  • The template would indent its text like the disambig templates
  • I really think a smaller font size (<small>) is appropriate. It identifies the information as secondary, so that you can easily skip over it.
  • The template would have to accept that it can contain other templates ({lang|yi|...}). Is template nesting even techically possible?
  • Note that above for "Shoah", I made up a {{lingu-inline}}

I hope you like the idea. 84.130.125.27 (talk) 03:12, 13 August 2009 (UTC)

The relevant part of the Manual of Style appears to be MOS:BOLDTITLE. The examples given there do not substantially detract from comprehensibility. For subjects which do have etymology and several synonyms, such as this, it might be easier to move the etymology into a separate sentence, paragraph or even section, depending on its complexity. This does not require special templates. The Holocaust article has a separate section on "Etymology and use of the term", so it would appear that the etymology could be dropped from the lede. However, I'm only following your lead of considering Holocaust as an example; please consider raising the matter on the talk page of that article before making changes to it.-gadfium 04:49, 13 August 2009 (UTC)

I believe the main problem is that a lot of editors believe that starting with this etymology clutter makes an article look more official/correct/encyclopedic/.... In my opinion the MOS should strongly discourage long or complicated etymologies in the first sentence, and only allow etymologies there if they actually contribute to an understanding of the topic. An etymology box would be an attempt at a practical solution to the problem, but I am not sure that I like it. Some articles already have too many boxes. Hans Adler 09:20, 13 August 2009 (UTC)

An even worse example of clutter is Kyrgyzstan, which starts off like this:

Kyrgyzstan (pronounced /ˈkɜrɡɪstæn/; KUR-gi-stan; Kyrgyz: Кыргызстан, [qɯrʁɯzstɑ́n]; Russian: Кыргызстан [kˠirɡˠisˈtan]), officially the Kyrgyz Republic, is a country in Central Asia. Landlocked and mountainous, it is bordered by Kazakhstan to the north, Uzbekistan to the west, Tajikistan to the southwest and China to the east. The ethnonym "Kyrgyz", after which the country is named, is thought to originally mean either "forty girls" or "forty tribes", presumably referring to the epic hero Manas who, as legend has it, unified forty tribes against the Khitans.[citation needed] The 40-ray sun on the flag of Kyrgyzstan symbolizes the forty tribes of Manas.[1]

Better than creating a new template, in my opinion, would be moving off the clutter into the infobox. Goodmorningworld (talk) 09:35, 13 August 2009 (UTC)
Technically, infoboxes should not contain information that is not also found elsewhere in the article. Powers T 12:37, 13 August 2009 (UTC)
Why not? Goodmorningworld (talk) 16:12, 13 August 2009 (UTC)
Could have sworn I read that somewhere... Powers T 17:18, 13 August 2009 (UTC)
I think he meant *moving* the clutter to the box, not copying it. 84.130.98.21 (talk) 18:43, 13 August 2009 (UTC)
What's even worse than the way it shows up when you're reading it, is the clutter when you're trying to edit it, and have to parse through all of the various templates and such to actually find, you know, content. Who then was a gentleman? (talk) 18:18, 13 August 2009 (UTC)
As a little summary, it's clear that not just one guy feels irritated. Right now the options seem to be:
  1. Move clutter above main text (template like disambig)
  2. Move to info box
  3. Move down in main text, e.g. end of section 0
Personally, I think that a new template (#1) may be a clearer signal to editors than just a change in the MOS (#3). From a layout/visual standpoint, I think both #1 and #2 fit very well. 84.130.98.21 (talk) 18:43, 13 August 2009 (UTC)
I guess a fourth option would be a separate small box (distinct from the Information Box) for "Etymology and pronunciation", or whatever applies. However, you'd probably want the type in normal size (or maybe 80%-95%) since small type is a real pain on small screens like mine (Compaq FS7600) for long texts and texts in other alphabets, including the International Phonetic Alphabet, especially with accent marks that are sometimes hard enough to distinguish at normal size (e.g. circumflex from umlaut from tilde from macron).
I agree that, if more than half-a-dozen ordinary words, the parenthetical material can become a real obstacle; the little "click this" loudspeaker icon to hear the word pronounced (on browsers and systems equipped to do this) can add to the clutter, where it might fit naturally into a separate box. —— Shakescene (talk) 04:04, 15 August 2009 (UTC)

Destination of link for text "Categories"

Below a page are linked the categories to which it belongs. Clicking on a category name takes one to the category page, which is fine. However, If one clicks on the word "Categories" in front of the category list, one is linked to Special:Categories. I propose this to be changed to Category:Contents. Almost never is one interested in Special:Categories, but it can be interesting/useful to browse Category:Contents. --Gerrit CUTEDH 14:18, 13 August 2009 (UTC)

I think Category:Contents should be mentioned at the top of Special:Categories. Ruslik_Zero 19:06, 13 August 2009 (UTC)
Wikipedia:FAQ/Categories is another possibility (though as the creator of that page I may be biased).--Kotniski (talk) 07:43, 14 August 2009 (UTC)

Tracking substituted templates; {{z number doc}}

No proposal here. Just seems an intuitive place to notify of this. I have made a template series that allows users to track the usage of substituted templates. As far as I know, there was no prior way to do this other than to search for unique text of a template, which was never much use and is now almost impossible since we instituted Google noindexing outside the main namespace. Anyone ever confronted with wanting to track a template that is normally substituted, head on over, create a "z number template" and add it to the syntax of the template you want to track. All the information is on the documentation page link above.--Fuhghettaboutit (talk) 02:48, 14 August 2009 (UTC)

The reason they're substed to begin with is to get rid of the numerous transclusions... why would we add transclusions back in? -_- --Izno (talk) 05:36, 14 August 2009 (UTC)
No. Our reasons for substituting templates has nothing to do with that and numerous templates contain internal transcluding templates (see e.g., {{^}}). Note that the z number templates call no text or code. --Fuhghettaboutit (talk) 12:03, 14 August 2009 (UTC)
He's actually right, when the substitute was introduced it was to make it easier on the servers, and avoid unneeded transclusions. This seems like a step backward. --Mask? 02:53, 15 August 2009 (UTC)
When a template with code and text is transcluded the server must get that material from the separate page for each template used. As far as I know, since these templates have no code or text to call, they will have no or negligible server load affect on the pages in which they are transcluded. I do not claim to be an expert on server load but it appears that the more text and code a template has to call, the larger the load, as implied at Help:Substitution#Partial substitution. But even if the transclusion does have some more than negligible server load effect, that is neither here nor there. See Wikipedia:Don't worry about performance. So stop worrying about performance. (It irks me that this is what I get instead of anything about usefulness).

Despite that it is entirely irrelevant what the original motivation was for starting substitution, out of curiosity I did some digging. This is apparently the very first page where substitution is described, as written on December 6, 2003, which does not appear to support the notion that its first use had anything to do with server load (we could always ask Tim Starling, and then either you or I would be well within our inalienable rights to cry "nah-nah" at each other, but this is such a sidetrack).--Fuhghettaboutit (talk) 05:03, 15 August 2009 (UTC)

Archiving copies of online references

According to WebCite, "[i]n one study published in the journal Science, 13% of Internet references in scholarly articles were inactive after only 27 months." On Wikipedia we can update dead links, but we can't update links where the original page has vanished forever, and sometimes it can take months for someone to notice a link is dead. We also can't rely on archive.org, since it's unpredictable which pages (and which versions of those pages) it will archive. Ideally, Wikipedia should automatically store copies of the webpages it references, at the time that they are referenced, and provide a link to this "archived" version for every reference.

This isn't exactly an urgent matter, since at least in theory all of our web citations ought to include sufficient information to track down the original work if it still exists in some form. Nevertheless it would be really convenient, make fact checking easier, and would help articles be more resistant to the passage of time. I don't believe there's any copyright issue in mirroring exact copies of webpages, since a lot of reputable organisations like archive.org do it, although I'm not sure why this is. Dcoetzee 22:29, 14 August 2009 (UTC)

There was a proposal to automatically have WebCite store copies the contents of URLs in Wikipedia references via a bot. I forget what became of it... --Cybercobra (talk) 22:36, 14 August 2009 (UTC)
Found the bot. --Cybercobra (talk) 22:43, 14 August 2009 (UTC)
Interesting. I think at this point we probably want to run with WebCiteBot. No sense doing ourselves what others are willing and able to do for us. I'll follow up with the author to see if there's anything I can do. Dcoetzee 22:54, 14 August 2009 (UTC)
Yeah, I've also frequently thought of this. It shouldn't be too difficult to write a simple web crawler and have it run on the Toolserver. Disk space might be a bit of a problem, though. —Ruud 22:40, 14 August 2009 (UTC)
There are copy right issues but most of them are somehow swiped away with loop hole for libraries. Anyway I intend to have Checklinks tool automatically submit links dependent on conditions. The tool already can searches and archive pages, but the service tends to crap out if I run faster than ~1 link minute. — Dispenser 09:07, 15 August 2009 (UTC)

New Page Patrol Patrol etc?

There are many new page patrollers. Is there anyone to patrol the patrollers?

There are many vandalism patrollers. Is there anyone to patrol the vandalism patrollers?

There are many rollbackers. Is there anyone to review the rollbacks, and perhaps rollback the bad rollbacks?

NotAnIP83:149:66:11 (talk) 18:50, 15 August 2009 (UTC)

Wanting to watch the watchmen, are we? --Izno (talk) 19:03, 15 August 2009 (UTC)
I and other admins already deal at Speedy Patrol with ones unreasonably nominated for deletion there, and the community with those unreasonably nominated for AfD. But in looking at newish articles I certainly see many examples of both over-tagging & biting new editors, or of under-tagging, of merely placing a tag on an article that really needs to go--and if someone seems to be doing this persistently enough to catch my eye I'll give them some advice. . But I cannot see any way or reviewing this systematically without doing the work twice over. There does remain one check--many people do this with the intention of learning the rules and applying for adminship, and people's histories are look at very intensively there. DGG ( talk ) 00:22, 16 August 2009 (UTC)

Split article discussions and "WikiProject" banners.

I think Talk Page is for actual discussions (and sometimes additional information and links), and "Discussion" links should not become blue just because of "Wikiproject" template. Majority of pages have such useless (for readers) talk pages. May be "WikiProject" templates should be either in main article (in collapsed state, for example) or in some dedicated namespace? _Vi (talk) 20:34, 15 August 2009 (UTC)

Note to readers: See its origin, Wikipedia talk:Talk_page#Redlinks to useless content., for further information/clarification of this proposal. -- Ϫ 23:39, 15 August 2009 (UTC)

MP3s. Or AAC. Again.

The Ogg format is a stupid unfortunate choice. Period.

Reasons not previously discussed:

  1. The Ogg format is not catching on, nor will it. (see #3)
  2. Creating files in the Ogg format requires tools and computer skills that are unfamiliar to most people and, more importantly, unfamiliar to most audio professionals. (This point added later by CharlesGillingham (talk) 23:04, 14 August 2009 (UTC)).
  3. Ogg sounds terrible. The reasons are more subtle than you think. There are two important ones that computer professionals have probably overlooked, but audio professionals (like myself) are aware of:
    1. MP3 sound good because the players make them sound good. Billions of dollars of effort has gone into modern MP3 players, including the ones in your computer. They are specifically designed to make MP3's sound good. When the MP3 format first came out, professionals shunned it, because it sounded like crap. Ten years later it sounded great. What changed? The players. There is no equivalent effort to make Ogg files sound good.
    2. Audio professionals (such as recording artists, like myself) deliberately try to make their products sound good on mp3. So any file that has passed through the hands of audio professional is going to sound best on MP3, AIFF and WAV. These are the formats that professional software products export (or "bounce") to. They are the only formats that we have complete control of. These are the only formats we can make sound good. You need to let us use ProTools or Logic Audio. We can't make it sound good without these tools of this calibre. You need to let us use ears that have been trained to mix for MP3. We can't make it sound good without our ears. At this point in the game, MP3 is like vinyl was: it sounds good because we know how to make it sound good.

Reasons already discussed:

  1. Everybody can hear it.
    1. On your mobile
    2. At the elementary school library
    3. At the airport lounge computer
    4. At a computer owned by someone over thirty by someone over thirty who isn't a computer professional.
  2. Anybody can record it.
    1. On your mobile.
    2. Etc., you get the picture.
  3. MP3 players (in the form of iTunes or WMP) are free.
  4. MP3 represents "free music" to billions of people. If you want to make a political statement, the phrase "MP3" says "rip, mix, burn". (What burned is the music industry.) "Ogg" says "I spend eight hours a day in front of a computer and I have no clue what the weather is outside."
  5. There is no way I'm downloading shareware on to my work computer without a condom. It could screw up my audio driver or worse. (ProTools gets sick very easily.)
  6. I think it's arrogant and insulting to assume that we are all as comfortable dealing with oddball file conversions as computer professionals are.
  7. I think it's arrogant and obnoxious to make Wikipedia worse in order to prove a moot point. MP3 won. Ogg lost. Get over it. The music industry is going down in flames either way. It's over.

Do you want to have professional sounding audio on Wikipedia? Of course we do. Then, please, allow me upload this MP3 file (I just spent two hours recording and mixing). ---- CharlesGillingham (talk) 13:08, 12 August 2009 (UTC)

The only reason MP3 is not used, is due to patent issues. Thomson and Fraunhofer hold important patents on this technology that will not expire in the US till at least 2012, and there are other patents, that will expire at a later time. Though perhaps these "other patents" are invalid, the Foundation will probably not be able to afford proving that in court. Thus using MP3 is either VERY expensive, or if you don't pay, will become even more expensive in a court. We want our information to be free, so that not only we, but everybody can use it, and that plan includes free storage formats. At the moment Ogg is one of the few codecs that does this. Also a grant has been received that will be put to use towards improving upload, playback and online editing of these materials. —TheDJ (talk • contribs) 13:27, 12 August 2009 (UTC)
I've just read that MP4A, or AAC has no patent issues. How about AAC? Does IE play AACs? I know that Safari does. ---- CharlesGillingham (talk) 14:49, 12 August 2009 (UTC)
This is not entirely true. Distribution of content is free, but encoders and decoders are not. So less expensive, but still expensive (with editing and conversion being introduced into the website this year). —TheDJ (talk • contribs) 15:22, 12 August 2009 (UTC)
Maybe I'm being dense here, but doesn't the browser decode it? Wikimedia wouldn't have to write a decoder, would they? If not, then there's no exposure; we're not decoding it, we're distributing it. ---- CharlesGillingham (talk) 15:56, 12 August 2009 (UTC)
We want the information we provide - including our media files - to be usable by anyone. A patent-burdened audio format may require some people in some countries or areas to lack a freely (beer & thought) tool to be able to decode it. Thus, we need to provide the media in a free format that does not have that burden. --MASEM (t) 16:06, 12 August 2009 (UTC)
Okay, I get it. I didn't realize that there were legal issues. Still I argue Ogg is monumentally inconvenient. ---- CharlesGillingham (talk) 06:23, 14 August 2009 (UTC)
That, and the fact that the large majority of complete music files on the site don't exactly have good sound quality in the first place. With sound samples, sound quality is irrelevant. That said, being able to post without transcoding anything (which I imagine most things are) would certainly be a very good thing. Though I have to wonder why any "professional" would actually use Mp3 as the master format. That would be pretty damn stupid. ♫ Melodia Chaconne ♫ (talk) 14:18, 12 August 2009 (UTC)
(1) A bad sample played through a better player sounds better. (2) We agree that easier is better. (3) MP3 isn't the "master format". MP3 is a format that professional tools will produce. ---- CharlesGillingham (talk) 14:49, 12 August 2009 (UTC)
A professional tool will never use MP3, because it is rather lossy. Professional tools output in raw audio or a lossless codec. The goal however is that we look towards the essence. Freedom is good. If freedom means that the tools are too complicated, then we have to improve the tools, because that is where the problem is. This is part of what will be taken on this year. —TheDJ (talk • contribs) 15:22, 12 August 2009 (UTC)
Read the previous. Professional tools will produce MP3s and AACs on request. They don't produce Ogg.---- CharlesGillingham (talk) 15:44, 12 August 2009 (UTC)
Except that it's trivially easy to convert any lossless file to ogg. Yeah maybe it's one extra step, but it's not as if making ogg files is in any way difficult. One other thing -- at the least, they are VERY common in independent computer games, probably for the same reason that WP uses them, though I do believe (I could be wrong), they may be useful for performance issues as well. So while they may not be propagated in the matter of general listening (and how many people actually DL stuff from WP to put on a hardware player?), they certainly aren't the desert wasteland format you claim. ♫ Melodia Chaconne ♫ (talk) 16:15, 12 August 2009 (UTC)
(1) Trivial for whom? As I said, some of us don't like shareware and have had bad experiences with it in the past. (2) The hardware I discussed above is the D/A converter in every personal computer. ---- CharlesGillingham (talk) 06:23, 14 August 2009 (UTC)
There are a lot of open source (note the difference with shareware) converters available. Unlike commercial converters they usually require no installation and device drivers, have no reason to install ad- or spyware on your computer and therefore will have little chance to damage your computer or software configuration. Unjustified technophobia on the uploader's end would probably be a very bad reason to start accepting non-free audio formats on Wikipedia. —Ruud 20:53, 14 August 2009 (UTC)
It's not technophobia, if you don't make a distinction between shareware and open source software, or if you don't like to mix-and-match software from various sources on one machine. I don't have any Microsoft software on my studio computer either. I just can't afford any kind of conflicts. My work computers are mission critical, and I don't have the expertise or the time to fix any problems that might come up. That's not technophobia. That's prudence.
More to the point, it's not technophobia that makes it difficult for the average person to create an .ogg file on the Mac. The "recommended" tool to change .WAV files into .OGG files on the mac is a linux commandline utility! This requires the user to go "under the hood" by opening the "terminal" application and then negotiate the Bash shell. The bash shell is hard to use the first time: it doesn't allow cut and paste, you have to name each file from the root directory, (or use "~" or "." characters) and, if you're filename contains blanks (which it usually does on a Mac), you have to know about the escape character "\" and what it does. All of this would require the average audio professional to have to study a bash manual searching for a clue as to what to do. Is this hard because the user is a technophobe? No. It's hard because we're all not computer professionals. Some have chosen other careers, that don't require knowledge of the bash shell. Assuming that everybody who doesn't know how to use open source software in the bash shell is a technophobe is, frankly, insulting. I'm sorry, no offense, but it is. It's like saying that everyone who doesn't change their own brake fluid is a technophobe. It's just not our job. We hire people to do that sort of thing.
To sum up: Wikipedia's "recommended" method of uploading audio on the mac (the computer used by the vast majority of audio professionals) requires users to know the bash shell. This excludes the vast majority of potential contributors from participating. Computer professionals who claim this situation is "okay" are (If you'll allow me a sporting reply to your accusation of "technophobia") elitist and out of touch with reality. ;) ---- CharlesGillingham (talk) 05:13, 15 August 2009 (UTC)

<Look, maybe I shouldn't have mentioned pro audio because it just seems to have confused you all. My point was supposed to be this Wikipedia should conform to widely used standards because the network effect is very powerful. When something is popular, everyone works together to make it better and more useful. In the case of audio file formats, the effect is that every aspect of digital audio, from the studio to the D/A converter in your computer, is designed with MP3, AAC, WAV and AIFF in mind. This is just one more way that the network effect causes the most popular standard to become the best standard. Does that make sense? At any rate, I'm revising my proposal now that I understand what the actual issue is. See the next section. ---- CharlesGillingham (talk) 06:23, 14 August 2009 (UTC)

Wikipedia is a free content, freely editable encyclopedia accesible free of charge. Wikipedia already does things quite clearly, explicitly and consciously different from the usual standard. So, no, I don't see why it should confirm to widely used standards. In fact given it's goals it should actively fight against vendor lock-in the methods which cause it and allow it to exist. —Ruud 20:40, 14 August 2009 (UTC)
Yes, keeping the encyclopedia free is a core goal of Wikipedia. Unfortunately .Ogg violates the other core goal of Wikipedia: Anyone can edit it. So we need to find a way to have audio files in Wikipedia that satisfies both these goals. Forcing editors to upload .ogg files just doesn't cut it. ---- CharlesGillingham (talk) 06:52, 15 August 2009 (UTC)
By that argument, you could just as easily claim that our requirement here that people write in comprehensible English violates "Anyone can edit", since some people can't manage do that. Or that many of our advanced physics and mathematics articles violate "Anyone can edit" since so many can't even understand the math involved. Anomie⚔ 00:42, 16 August 2009 (UTC)
Okay, fair enough, if you want to be picky. I suppose you're pointing out that Wikipedia's core goal isn't that "anyone can edit", as I said, but that it is "anyone (who has something high quality to contribute) can edit." I still argue that requiring audio be uploaded in the .ogg format prevents "anyone (who has high quality audio to contribute)" from editing, because, on the mac at least, Wikipedia is recommending that users know the bash shell in order to upload audio. A-ight? Sheesh. ;) ---- CharlesGillingham (talk) 05:26, 16 August 2009 (UTC)

Why not .WAV or .AIFF?

These file formats are listed as "free and open" in Audio file formats. Is this correct? If so, why can't Wikimedia allow us to upload these formats, if they are small enough? Wikipedia often needs little snippets of sound, and these files could be compressed later by bots or editors who like doing that kind of thing. What do you say? ---- CharlesGillingham (talk) 06:23, 14 August 2009 (UTC)

I think we already support FLAC? —Ruud 20:30, 14 August 2009 (UTC)
Yes, but creating a file in FLAC, like Ogg, requires tools and computer skills that are unfamiliar to most audio professionals. That's my complaint. ---- CharlesGillingham (talk) 22:50, 14 August 2009 (UTC)
Indeed, automatic conversion would be preferable, but unfortunately this feature has not yet been developed. —Ruud 23:15, 14 August 2009 (UTC)
Agreed. (Did you mean to post that on the next thread?) ---- CharlesGillingham (talk) 06:52, 15 August 2009 (UTC)
Still don't have an answer of why we don't allow .WAV or .AIFF. Are there patent issues? Or is it the size that is the problem? ---- CharlesGillingham (talk) 06:52, 15 August 2009 (UTC)
I think in the past the size was the issue, and that even though this may no longer be an issue, currently the playback integration for those files is missing so it now needs some development work. —TheDJ (talk • contribs) 10:57, 15 August 2009 (UTC)
Note that size is much more of a concern for what our visitors must download; storage space on the servers is fairly cheap. Anomie⚔ 00:42, 16 August 2009 (UTC)

On-the-fly AAC conversion

Here's a potentially useful compromise: since AAC can be redistributed without paying licensing fees, why don't we offer an option to automatically convert any OGG file to AAC on-the-fly for playback or download? This would let people who already own AAC tools take advantage of them, while still making OGG available to people who can't afford them. Likewise, we could accept uploads of AAC audio and automatically convert them to OGG on the server side. Dcoetzee 22:48, 14 August 2009 (UTC)

Well, hopefully the grant that DJ mentioned above will cover automatic conversion of AAC, AIF or WAV into and out of Ogg. DJ, do you have a link to a page about this grant? ---- CharlesGillingham (talk) 22:59, 14 August 2009 (UTC)
So a lot of work, but it's complicated and takes a lot of time and money. Still in the past year a lot of work has been done (even though most has not reached the state of being widely deployed so far). —TheDJ (talk • contribs) 23:39, 14 August 2009 (UTC)
Yes PLEASE anything other than the god-awful OGG. I don't even bother with audio on Wikipedia anymore because OGG is nightmarish. AAC sounds like a good idea, and I for one would willingly convert a half dozen files a day. I think that most other editors with the software to do so would be similarly willing. Cool3 (talk) 05:21, 15 August 2009 (UTC)
Note: since OGG can be a container for FLAC, it would also be handy to have on-the-fly conversion between OGG-FLAC and WAV/AIFF. @Cool3, I'm talking here about automatic conversion being available on every audio file, nothing manual required. Dcoetzee 05:58, 15 August 2009 (UTC)
I was under the impression that the above was to imply that the technology for the automatic conversion wasn't yet quite there? If it is fact available already, then all the better; sounds fantastic to me. Cool3 (talk) 06:05, 15 August 2009 (UTC)
This seems like the best solution: Wikimedia needs to allow editors to upload .WAV or .AIFF files and then convert them (if necessary) into .OGG-FLAC files under the covers. That would satisfy all my complaints. ---- CharlesGillingham (talk) 06:52, 15 August 2009 (UTC)

For anyone who cares there is a Flash Ogg Vorbis software player being developed for fun. — Dispenser 09:32, 15 August 2009 (UTC)

Thanks

Thanks to everyone for helping me to hone my argument. I've entered an enhancement request into bugzilla. See bugzilla 20252. ---- CharlesGillingham (talk) 07:31, 15 August 2009 (UTC)

By the way, I finally did convert my file, using the bash shell and the whole nine yards. I replaced this:
The Wikipedia theme
Problems playing this file? See media help.
with this: (watch out, the level is a lot hotter on my version -- turn down your audio if you turned it up to hear the first one).
The Wikipedia theme
(as five second commercial television cue)
Problems playing this file? See media help.
(It's supposed to be ironic.) ---- CharlesGillingham (talk) 07:48, 15 August 2009 (UTC)
  1. ^ Forty tribes and the 40-ray sun on the flag of Kyrgyzstan, SRAS–The School of Russian and Asian Studies
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_50&oldid=1251587941"