Jump to content

Wikipedia:Village pump (proposals)/Archive 49

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, 215

Would it be possible to tweak this feature so that it always appears immediately at the end of a section header instead of on the right hand side of the page. Currently, the [edit] button has a nasty habit of appearing over text and I feel the suggested tweak would remove this problem. Mjroots (talk) 10:03, 24 May 2009 (UTC)

Agreed, and make it look like a proper button ->   M  19:54, 24 May 2009 (UTC)
Also agreed (to both suggestions). Some other language Wikipedias (French, German, Italian) have the [edit] link just after the section heading, where it is more visible than having it to the far right. On the far right, it often gets tangled up with images and other [edit] links; how many editors have clicked the wrong edit link when there is a cluster? -- John Broughton (♫♫) 20:53, 24 May 2009 (UTC)
An example in another wikipedia (de) is this page.   M  21:01, 24 May 2009 (UTC)
An interesting idea. Where is the code for that kept? Somewhere in MediaWiki: namespace? OrangeDog (talk • edits) 21:56, 24 May 2009 (UTC)
They move the link around with Javascript. Anomie⚔ 23:27, 24 May 2009 (UTC)
This has been a constant problem for those editing articles for New York City, especially pages and sections about demography and elections. You end up making lots of ugly white space, re-sizing images, or moving images around, just in order to keep "[Edit]" in a useful, non-disruptive place without stacking. On the other hand, putting [Edit] right after every heading and sub-heading can be jarring to the eye of ordinary, casual readers, just as too many in-line footnotes can be. —— Shakescene (talk) 23:37, 24 May 2009 (UTC)
Jarring as well they should be - footnotes, because people should get used to wanting to see sources, but the edit link especially, because we'd like more people to notice it, and edit the pages.   M  05:40, 25 May 2009 (UTC)
I notice it's less jarring (while still jarring enough) on that German page by virtue of a smaller font and a subscript effect (and this despite "Bearbeiten" having two-and-a-half times as many characters as "Edit"). PL290 (talk) 09:13, 25 May 2009 (UTC)
So, it looks like the general consensus so far is that this is a desirable feature. Let's hope it gets noticed and taken forward. Mjroots (talk) 15:47, 25 May 2009 (UTC)
I don't like this idea. It's in a standard place now, so you can just flick to the right hand side of the page, and that's where I'd keep looking if it were moved. As for the concerns about bunching and stacking of edit links where images are floated right, that's what {{Fixbunching}} is for. If it ain't broke, don't fix it. Dendodge T\C 16:39, 25 May 2009 (UTC)
FixBunching is a very very poor workaround, and works only in limited conditions. If floating divs are placed in separate sections, or if they have widely different widths, then the result is not really satisfactory. Amalthea 16:44, 25 May 2009 (UTC)
Except it is broke, hence why the template is called FixBunching. Just because one fix exists doesn't mean we shouldn't explore others. Mr.Z-man 17:32, 25 May 2009 (UTC)
You would quickly get used to it. Further, you wouldn't need to get used to it - whenever you click one of those links, you first look at the heading, and the edit link would be right there beside it. You would not even need to track along that line to the right hand side.   M  18:18, 25 May 2009 (UTC)
For my part, I prefer the links where they are. Make a Gadget? Anomie⚔ 16:41, 25 May 2009 (UTC)
Well, this is obviously something that is going to need the input of more than us few editors. If anyone knows how to get this fully debated by the wider wikipedia community please feel free to enable the discussion. Mjroots (talk) 17:47, 25 May 2009 (UTC)
Could you elaborate? Preference is not a reason that I think we should give much consideration to. We should do this to fix bunching, to make the edit link more visible, and to associate a the control with what is being controlled. From the usability study:
"Users often missed the ‘edit’ buttons next to each section, clicking on ‘edit this page’ all the way at the top. This often got them lost if they were editing a particularly long article, as they weren’t easily able to find the section they wanted to edit. Several users also clicked on the wrong ‘edit’ button next to the sections, thinking that the ‘edit’ button below the section referred to the section above."
I think that this overrides preference.   M  18:18, 25 May 2009 (UTC)
We all managed to work it out—maybe the people that can't aren't the kind of people who should be editing a knowledge resource like an encyclopedia. (I don't mean to offend anyone, but it really does seem pretty simple). Dendodge T\C#
That is both offensive and ignorant. Putting 'edit' at the top-right of a section violates the convention of just about every forum on the internet (ever seen edit, reply, quote?). Placing the edit button on the opposite side of the page is like placing a door-handle on the side of the door that has hinges. Abandoning a control that makes no sense rather than continuing to mess with it is perfectly rational behavior. I am not surprised at the reactions, nor at the fact that it takes some getting used to. If you hit a person on the head with a baseball bat every day, pretty soon they'll start making up reasons why getting smacked with a bat is a good thing, and why anyone who doesn't know the exact procedure for the application of ice is an idiot. These people aren't idiots, and thankfully (after how many years?) we finally have a usability study to disprove sentiments like the one you just expressed.   M  20:33, 25 May 2009 (UTC)
You worked it out. I worked it out. Everyone here worked it out. I'm not calling anyone an idiot, I'm just saying that a person who can't work it out may not have the intelligence level required to edit Wikipedia. Dendodge T\C 20:36, 25 May 2009 (UTC)
"Everyone here knows how to apply ice and has gotten used to it, therefore getting clonked with a bat is a good thing" is a terrible argument, and I have no idea how you fail to see that your comments imply that new editors are stupid.   M  20:56, 25 May 2009 (UTC)
No, what I imply is not that new editors are stupid, but that new non-editors are. We need some barriers, to stop people who know very little editing articles. Dendodge T\C 20:59, 25 May 2009 (UTC)
There is no 'non-editors' group, not being able to use our crappy interface has no bearing on contribution quality, and all people are welcome to edit no matter how stupid.   M  01:13, 26 May 2009 (UTC)
There is actually reason to think that there is an inverse relationship (to some extent) between being able to figure out tech issues of editing WP, and quality of content contributions: older people who aren't particularly web tech-savvy are probably more useful contributors than schoolkids, who generally are web tech-savvy. Plus older people are under-represented anyway, so we should care about making it easy. Personally I don't see the Edit button being on the right-hand side being confusing if it appears in the right place; but if the Usability studies say it is, we should consider moving it. Rd232 talk 18:25, 26 May 2009 (UTC)

I'm quite sure this proposal has been made multiple times in the past... Though I would have no clue where to start looking. As a sidenote, moving the edit link will not "Fix" the bunching problem all together, because it applies to all floating elements, so it will just make the problem less common and even more obscure. I have no particular preference either way. —TheDJ (talk • contribs) 19:17, 25 May 2009 (UTC)

It's no big deal if we have to clear the float on images, but for edit links it might push them down several sections. The bunching problem is pretty much limited to the edit links, I think.   M  20:34, 25 May 2009 (UTC)
There is a lot of relevant discussion to these issue on bugzilla:1629. As you can see, after three years there still isn't a good solution, partly, because HTML/CSS just doesn't account for the way we use floating elements like infoboxes and images. :( —TheDJ (talk • contribs) 21:33, 25 May 2009 (UTC)

I would be tempted to be WP:BOLD about it, if I knew how to change it. OrangeDog (talk • edits) 21:13, 25 May 2009 (UTC)

Since I doubt that interface issues could be resolved in any other way, I would support this.   M  01:13, 26 May 2009 (UTC)
The use of Wikipedia is primarily as an encyclopedia. Even those of us who are now active editors here came in most part because we first used it as an information source. The first job of an encyclopedia is to provide information, and the readability of information is a very great virtue. That people can edit is our distinct feature over previous encyclopedias, but what we edit is not a game, and not pure self-expression, but for a purpose. The edit links should be visible, but unobtrusive. And that;'s as they are. Editing should be made easier, but this is not the biggest problem. A much more radical approach than moving links will be needed. The usability survey did find one related problem that can be easily handled: people couldn't figure out how to edit the top section, but this is relatively trivial to fix, they way many of us have fixed it in preferences. Beyond that, altering the basic interface is not the place to be bold. I'd call it the classic example of reckless. DGG (talk) 03:43, 26 May 2009 (UTC)
I notice you recommend unobtrusiveness, seeming to hint that it's for the reason of lessening the likelihood of editing that's merely a game, or pure self-expression, or not for a purpose. But on first viewing an article, users are greeted by some words which invite, in a bold font, "edit this page". Therefore unobtrusive section edit links only go so far in accomplishing the above, while perpetuating the other issue cited earlier: those unaware of section edit links will use "edit this page" unnecessarily, with consequent complications, to which complications I would add the increased potential to damage the article brought by having its entire text open in the editor. I personally feel moving the section edit links to after the section title will indeed go a long way in solving the usability problem identified, and I support this, ideally using a slightly shrunken, subscripted font just like that German page. As to getting used to it, the more prominent link just by the section title should, in my opinion, mean that in practice it won't be hard to get used to, as it will be seen—and seen right at the moment of aligning the eye with where the edit link used to be on the right (remembering that not all section levels are underlined). Lastly, I do feel the "apply ice...clonked with a bat" analogy goes a very long way, not just in this (wider) discussion but in some previous ones too. Far from being critical of anyone by saying that, I do think it's part of human nature that we have this tendency. Could someone please hang that analogy somewhere as a sign, to be cited when necessary in any discussion here? PL290 (talk) 19:57, 26 May 2009 (UTC)

It seems to me that the edit link would get lost if pushed up against the section header. I prefer to keep it out of the way but still associated with the section. Powers T 15:50, 26 May 2009 (UTC)

LTPowers, how so? What I suggested will have the opposite effect. Having the edit link immedately after the heading will make it more visible, avoiding any bunching issues. It would look something like this

Article header [edit]

The discussion is mentioned in the current edition of Signpost, so hopefully we'll get much more discussion. Mjroots (talk) 15:55, 26 May 2009 (UTC)

It means I have to scan to a different horizontal location on the page every time I want to find an edit link, instead of being able to just go to the right margin. Rule #1 of UI design is to keep UI elements in a consistent place. Having it move around (horizontally) reduces efficiency, even if it is attached to the end of the section header. Powers T 18:44, 26 May 2009 (UTC)
Similar arguments were made back when changing the "+" tab text on talk pages to "new section" was discussed; the change went through anyways, and a gadget was quickly written and deployed for use by those who preferred the old text. I see no reason why this same reasoning should *prevent* a change in this case, and why another gadget would not be a satisfactory solution for those of us who prefer the old positioning (and, as if I really have to say it at this point, I support this change). ···「ダイノガイ千？！」? Talk to Dinoguy1000 19:38, 26 May 2009 (UTC)
Finding the section edit links was a problem in the usability study. I support moving it to after the section title. - Peregrine Fisher (talk) (contribs) 16:39, 26 May 2009 (UTC)
I'll apologize up front for my language, but: it really pisses me off when an experienced editor says something like I don't like this idea. I know exactly where to find [feature/function X]. If you change it, I wouldn't like it because I've gotten used to it where it is. And it doesn't help at all when that is followed by Well, we should make Wikipedia editing more difficult, so that less smart people will be discouraged from editing and just stick with reading Wikipedia. For those who may have missed the statistics: total edits here at the English Wikipedia are down more than 10% since the peak in early 2007, and that's not because of decreased vandalism; roughly two-thirds of existing articles are stubs; an average article gets edited less than once every ten days. We're hurting here, folks.
If you're an editor who has "figured out" a feature, that's evidence that the feature needs to be improved. The closer a feature is to intuitive, with little to no learning curve, the better. We should not be discussing what experienced editors need or like for this particular feature, because this isn't a feature that only experienced editors use; we should be having a discussion about what's good for the vast majority of Wikipedia editors, including people who aren't editors yet.
Bottom line: As was pointed out, we had exactly this argument over changing the "+" tab to "new section". All it took was someone to create a gadget for experienced editors to put that tab back the way it was; today novice editors no longer have to deal with such a cryptic tab. Win-win. -- John Broughton (♫♫) 21:13, 26 May 2009 (UTC)
I see the point about horizontal alignment, but your eyes have to slide over to see what the edit link refers to anyway. If you wanted to, you could put [edit] first, though I dislike that idea. I'd like to point out that most vandals either blank the page, or vandalize the lead (i.e. use the edit this page button). So is this because the [edit] buttons aren't visible? I doubt it; vandals want their message to be prominent. Normally they aren't subversive enough to add something a few sections in. So I argue that anyone editing a section is a legitimate editor, and this proposal would increase beneficial edits (often by less-computer savy people). And I flatly reject that we should require technical competency to write an encyclopedia; new users need to bring only knowledge and good faith. Experienced users can clean up grammar, NPOV, organization, citations, and so on--but the article is better off with the anonymous contributions than without. So why not encourage them? That's the founding ideology of Wikipedia. (A gadget for old users would be nice, too, in case we're more trained than we think.) HereToHelp (talk to me) 21:25, 26 May 2009 (UTC)
(ec) That was cryptic—the word "[edit]" could not be less clear. I do not strongly oppose this change, but I don't see a compelling reason to alter the sitewide javascript to make it easier for people to work out to what the word "edit" refers. I believe my first (or maybe second) edit was editing a talk page section, so I worked it out (if there was any working out needed) quickly enough. I don't see what's difficult about it, and I think the German layout looks messy. I made a single throwaway comment while I wa stired, and it was misconstrued (a simple mistake, I admit). So the ain reason for my opposing this is the aesthetics of the proposed solution. Dendodge T\C 21:30, 26 May 2009 (UTC)
It does detract aesthetically; my own support is despite that. However, I think it's likely that that can be improved by subtle changes even with the new positioning. A toned-down greyish graphic instead of square brackets and hyperlink-coloured text, for instance. Or, if preferred, a proper button like someone said. PL290 (talk) 21:51, 26 May 2009 (UTC)
I would support putting it to the left of the header text. Then we can do a proper button, but I think a button would be even worse than a link if hte button appears directly after the text. Dendodge T\C 21:55, 26 May 2009 (UTC)
I did consider that idea but IMO it detracts more by misaligning the heading with the margin. Unless it can be outside the margin. But I wouldn't imagine that can be done without wasting a lot of space. What about after the header, but a faint greyish rectangle graphic (flat, not a button)? PL290 (talk) 22:00, 26 May 2009 (UTC)
Or underneath the header text, aligned at the margin? (Would need to consider what to do about the horizontal line on level 2 headers. Could either push line down slightly, or insert before line start...or probably best below line) PL290 (talk) 22:14, 26 May 2009 (UTC)

AEB

Sample removed due to TOC-breakage

Maybe like that? Though obviously with a working link. OrangeDog (talk • edits) 23:41, 26 May 2009 (UTC)

That is certainly aesthetically pleasing, but does it not go against the original proposal, which was intended to make the button easier to find? Making it grey just makes finding it harder. Dendodge T\C 00:02, 27 May 2009 (UTC)

No, it doesn't go against the original proposal, which was to move the [edit] button to immediately at the end of the section header. Details like aesthetics can be sorted out later. FWIW, I like the grey version. Now there's been a fair bit of input, what's the best way to go from here. Should I make this into a formal proposal under a subsection with voting for/against? Mjroots (talk) 05:14, 27 May 2009 (UTC)

Done a bit more fiddling with positions at User:OrangeDog/Headings. Seems like the simple place-it-immediately-to-the-right version is the only one that solves the bunching problems as well (unless anyone can see how to do the others without divs). Obviously the colour and style can be whatever, but I kind of like the grey. OrangeDog (talk • edits) 05:49, 27 May 2009 (UTC)
Perhaps requesting this proposal be posted via WP:Watchlist notices and/or WP:Centralized discussion would be in order? --Cybercobra (talk) 07:49, 27 May 2009 (UTC)

Raised at WP:CENT Mjroots (talk) 08:39, 27 May 2009 (UTC)

I think you are supposed to add a link to here in the box on Wikipedia:Centralized discussion, not raise the issue on Wikipedia talk:Centralized discussion.  Done
I have to say that I never consciously noticed the difference between de: and en:. Now that I am aware of it, from a technical point of view I much prefer the solution with the link directly after the header - it's always clear which section it refers to, and it always seems to be typeset rationally in any browser, unlike our current solution, where the link often ends up in unintuitive and/or inaccessible locations. --Stephan Schulz (talk) 09:39, 27 May 2009 (UTC)
  • I'm going to be a heretic and say that I like nice, clean, encyclopedic headers, separate from Wikipedia stuff (as in, it's good to have the edit-link away from the section title). If this is introduced using Javascript, will there be an opt-out? ╟─TreasuryTag►hemicycle─╢ 09:42, 27 May 2009 (UTC)
I've removed the proposal from the talk page and added it to the template on CENT. Mjroots (talk) 11:43, 27 May 2009 (UTC)
OrangeDog, thank you for creating those mock-ups to make it possible to see and judge the effect of the different factors. Looking at them confirms my opinion that greying does indeed make the difference aesthetically, and as to positioning, IMO after the title is best as originally suggested. PL290 (talk) 12:13, 27 May 2009 (UTC)
I would point out that, while it may not be intentional, those samples are extremely flawed. The 2, 3, and 4 sample headings should all be possible to do without floats (using margins and position:absolute), and would not have the bunching problem. They could also likely be done purely with CSS, with no JavaScript required. The samples are also constructed differently from how the actual section edit links are made; I'm not sure how they're even usable as a comparison. Mr.Z-man 05:57, 28 May 2009 (UTC)
They are not intended as proposed solutions, just mock-ups of what it would look like. Feel free to modify them (or sandbox your own) if you can make them look the same without introducing the bunching problem. I have no idea how the actual edit links we have now are implemented. OrangeDog (talk • edits) 19:04, 28 May 2009 (UTC)
The problem is that people are basing their opinion about whether solutions fix the bunching issue on the basis of those. The real section edit links are a span inside the heading, before the actual heading text. They're put in the current position by floating them to the right. Something like sample 2 could be accomplished just by setting them to float:none, as that's the position they actually would be in without the float. I tested something like sample 4 using CSS alone,
.editsection {
  float: none !important;
  position: absolute;
  font-size: 60% !important;
  margin: 1.7em 0em 1.5em 0em !important;
}
mostly does it, though I'm not a CSS expert and haven't tested how it looks with different font sizes, browsers, and monitors. Its also optimized for h2's and would need some extra rules for other heading levels. Mr.Z-man 19:17, 28 May 2009 (UTC)

Formal proposal

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.
The result of the discussion was: No consensus. Default to keep as is (outside opinion gained at Wikipedia:Administrators' noticeboard#Discussions need administrator closing). I will implement a JavaScript gadget within a few days for those who want to use the proposed layout. –Drilnoth (T • C • L) 13:48, 20 June 2009 (UTC)

That the [edit] button be moved so that it appears immediately at the end of section headers (default setting). An opt-out to be made available via user preferences for editors who wish it to remain at the right hand side of the page. Any issues about aesthetics/display are not part of this proposal. Mjroots (talk) 11:43, 27 May 2009 (UTC)

Sample available: I have created a working sample of the edit links using almost exactly the code from the German Wikipedia. If you would like to test this proposal (across the entire wiki), just add importScript('User:Drilnoth/sampleeditlinks.js'); to Special:MyPage/monobook.js. Please note that this uses the current font styling, just a different alignment. While testing this, please keep in mind that it would certainly take some getting used to for long-time users who are used to the previous version... please try to look past this while testing it. –Drilnoth (T • C • L) 20:59, 27 May 2009 (UTC)

Well, it's nice that it can be scripted so easily. We're indebted to Drilnoth for drawing that to our attention. So those of us who like it can use it anyway while the debate continues. I confess I'm not personally seeing the suggested "rush to implement" "anything" effect, simply a lot of people who judge that this very thing is a usability and debunching enhancement for newcomers ond oldcomers alike. To those concerned about aesthetics: I recommend adding this line to the script:
     span.style.fontSize = "xx-small";
PL290 (talk) 09:04, 28 May 2009 (UTC)
Agreed; I just wanted to have the sample here use the exact same format as the previous version, so that they could be more easily compared. I'll probably make this code available as a gadget if consensus is against universal implementation, at which point I may allow an option for normal size, normal size but gray, small, and small gray. While people are still just trying it out, I think it should use the previous styling so that "style" isn't involved in this discussion as much as "location". –Drilnoth (T • C • L) 13:31, 28 May 2009 (UTC)
Quite so, you did the right thing. The sample is most helpful in its present form for this discussion. I speak only to any who do feel like copying the mere 14 lines of .js and tweaking their own copy. PL290 (talk) 15:35, 28 May 2009 (UTC)
Question: Any reason why your sample version is working for me on articles, but not on WP:AN/I, WP:AN or WP:RM? Ed Fitzgerald t / c 11:07, 8 June 2009 (UTC)
Can't confirm: I have no issues with those three pages using the script provided by Drilnoth with Firefox 3.0.10/Mac or IE 7.0.5730.13/WinXP. Can you provide details including skin (monobook.css etc), browser, OS and display size (pixel dimensions)? Sswonk (talk) 12:57, 8 June 2009 (UTC)
Actually, it's only working for me on article, not anywhere else, including talk pages in all spaces. IE7 under Windows Vista, monoboook skin, 1280x800. Ed Fitzgerald t / c 06:16, 9 June 2009 (UTC)
Seems to be working everywhere for me using Firefox 3.0.5, Safari 3.1.2 and Google Chrome 2.0.172.30, but not working at all using Opera 9.63. Ed Fitzgerald t / c 06:29, 9 June 2009 (UTC)
Sorry, I didn't see this before. The script probably isn't perfect... I just copied it from the German Wikipedia. Browser support for scripts varies greatly. If Happy-Melon's bug report is done, then this can be done with a single line of CSS. The JavaScript can probably be simplified, too... I'll look into this. –Drilnoth (T • C • L) 16:28, 13 June 2009 (UTC)
My apologies as well, I lost track of this mini-thread. I just tested the script on Opera 9.64 Mac and the pages in question displayed as expected, i.e. like every other page. I don't know what could be wrong there - the only thing I can think of is a conflicting javascript. See if 9.64 makes a difference, although I doubt it will. Sswonk (talk) 01:46, 15 June 2009 (UTC)
  • Support: Having the edit button immediately at the end of the section headers would remove the bunching issue with Mozilla Firefox and other browsers where this is an issue. Having the facility to display it at the right via user preferences allows those who are happy with it at the right hand side to keep it there. Mjroots (talk) 11:48, 27 May 2009 (UTC)
  • Support:There are issues with displaying it where it is on some articles & it hopefully may be more noticeable & encourage editing. dottydotdot (talk) 11:50, 27 May 2009 (UTC)
  • Support: Avoids the {{fixbunching}} hack and hopefully addresses usability problems. OrangeDog (talk • edits) 12:02, 27 May 2009 (UTC)
  • Support: The WikiFairy in me, noticing that the format proposal explicitly excludes aesthetics, whimpers a little, hoping that this aspect can nevertheless be addressed at some point even if not in the immediate implementation. PL290 (talk) 12:11, 27 May 2009 (UTC)
  • As I stated above, I like the look of the light grey [edit] button. I've specifically left that issue out of the proposal to keep people focussed on the main proposal. If someone wants to propose a change in the aesthetics/display of the [edit] button they are quite welcome to post a proposal to that effect. Mjroots (talk) 12:18, 27 May 2009 (UTC)
I think the successful use on the German Wikipedia shows that the placement does not cause serious usability issues. --Stephan Schulz (talk) 20:57, 27 May 2009 (UTC)
And the successful use of the current style on the English Wikipedia shows nothing? Anomie⚔ 23:34, 27 May 2009 (UTC)
Sure. It shows that the current style is functional as well. But take a look at Homo antecessor#Fossil_sites - how do you edit that section (tested in Firefox3Beta5 with reasonably large windows, and in IE8)? Or edit the References and External Link sections in Bellerophon class battleship. Not impossible, but not very intuitive either. --Stephan Schulz (talk) 15:42, 28 May 2009 (UTC)
But they do not currently appear in consistent horizontal locations either -- have you seen an article with right-floating elements? OrangeDog (talk • edits) 23:24, 27 May 2009 (UTC)
But they are: they are at the right edge of the column of text. It doesn't seem to cause a problem (for me, anyway) that that width infrequently changes, as "the edge of the column of text" is still trivially obvious to locate. Anomie⚔ 23:34, 27 May 2009 (UTC)
Is "immediately following the section title" any less trivially obvious? OrangeDog (talk • edits) 00:06, 28 May 2009 (UTC)
Perhaps not less obvious, but still harder to find. The column of text is a very large rectangle taking up most of the page and clearly demarcated from any bordering rectangles (as those normally have borders and distinct background colors), while the section title is typically a narrower rectangle wedged in between larger rectangles with subtle demarcation. Also, BTW, the end of the section title may not actually be at the right edge of the section title rectangle, if the section title is long enough to wrap onto a second line. Anomie⚔ 00:16, 28 May 2009 (UTC)
Sorry, this is simply not true. Relative to the target of the control (the control is the edit link, the target is the heading), the positioning is perfectly consistent - a few pixels to the right. You are confusing style (which would recommend that similar elements are placed in an orderly way) with usability.   M  02:58, 28 May 2009 (UTC)
Unfortunately, "relative to the target of the control" isn't all that helpful, because "the target of the control" changes size arbitrarily. Consider a series of UI windows in Microsoft Windows. If you want to minimize a bunch of them in succession, would you rather have all the windows maximized, or all the windows at various locations around the screen so that you have to search each one for the minimize button? They're all in the same place relative to their targets, but that doesn't make them trivial to find. I realize these edit links are not used in quick succession, but it still illustrates the problem of having to search for the button. With the current layout, one doesn't even need to look at the section header; one can just go to the right margin and find the first [edit] link that appears above the section one was reading. Moving the edit link means one doesn't know where the link will be without first scanning for the header. Powers T 13:28, 28 May 2009 (UTC)
If it is easier to find the link than it is to find the end of a heading, then I agree. Given the close and consistent proximity of the link to the title, I don't believe that 'scanning around' for a link is a problem, so power users would not be substantially affected. There are relatively few power users, and they can change this in prefs. A poor association of the link to the heading, due to the distance, is a problem, though, and this has been demonstrated by the usability study.    M   02:46, 29 May 2009 (UTC)
  • Oppose - per LtPowers. Also, the WMF has nearly US$900,000 to hire professional UI designers and usability specialists to fix the usability issues over the course of a year or so; I can't imagine that a bunch of random Wikipedians deciding in a week that we know best is doing much more than getting in the way. Mr.Z-man 15:42, 27 May 2009 (UTC)
Mr.Z-man, I don't intend this to be over in a week. As it is something that will be Wikipedia wide if brought in, it needs full discussion. I'd expect that to mean at least a month, if not longer. Mjroots (talk) 16:31, 27 May 2009 (UTC)
The poll might last for a month, but the poll is only a binary decision - do this, or don't do it. The discussion about what option to use for the poll only lasted a few days. Mr.Z-man 01:13, 28 May 2009 (UTC)
And Microsoft spent how much money to create Office 2008 and look what they did to that UI. Just because $Some_Large_Sum is being spent on fixing something does not mean that something better will come out of it. Q T C 21:25, 28 May 2009 (UTC)
The exception does not make the rule. But in any case, the issue is not just money. Its effort and expertise. The fact that some people involved in the initial discussion believe gray links with smaller font on a white/light-blue background is a good idea suggests a lack of UI design skills. There was less than 6 hours between when the mockups were created and when the poll started. There's been virtually no testing and almost no discussion of alternatives. The alternatives were dismissed becuase the 1 set of mockups (which are actually useless as testcases) for the other options didn't fix the bunching problem. Mr.Z-man 21:50, 28 May 2009 (UTC)
  • Support. An obvious improvement, agree with other supporters. Sswonk (talk) 16:48, 27 May 2009 (UTC)
    • Adding specificity here: I support the formal proposal that the default position of the edit button be immediately after the heading because I feel it enhances usability, prefer the implementation that is found on the French Wikipedia (example DVD article), cite the default implementations found there and on the German, Spanish, Italian, Japanese and other Wikipedias as working models and recommend a clear preference choice and a clear, easily found explanation of the change and the optional setting available once implemented. Sswonk (talk) 17:42, 8 June 2009 (UTC)
  • Support: There are multiple reasons for this: It fixes up the horrible bunching issues, it just plain looks better (take a look at the German Wikipedia), and it makes it more visible for newcomers who might not notice the "edit this page" tab (which could bring in some more new editors). If this isn't done, making a gadget to allow it to be applied on a user-by-user basis would be good. To mention my view on visuals, having it look just like it is (or maybe a smaller font size) seems fine... in the brackets I doubt that it will disrupt the reading of section headers or anything. Some specific response: LtPowers, I don't believe that the position would be different for each section... every section will have it in the same place, just a different place from where it currently is. I'd also oppose this if it was going to make some edit links be on the left and some on the right, but I don't think that that is the proposal. Mr.Z-man, wouldn't you think that if a group of Wikipedians decides here that the edit button should be moved, that would save the Foundation money and time in doing further studies or polls? I agree that it will take a month or so-long poll, but if there is consensus for the change that will make it much easier on the Foundation (to my knowledge), since all that would have to be done in this case is insert a bit of JavaScript/CSS into the MediaWiki namespace, rather than going through a huge poll or anything like that. –Drilnoth (T • C • L) 16:51, 27 May 2009 (UTC)
    No, because we are not usability experts, we're going by "this looks good" - the usability team will still need to evaluate it to determine if its actually an improvement or works with other things they were considering. Most of the studies are already done, but if we do this, then any data about the section edit links becomes worthless. The money comes from a grant specifically allocated for the usability improvements, so if we don't spend it on usability, we don't spend it at all. Also, what's the difference between "a month or so-long poll" and "a huge poll"? Mr.Z-man 17:12, 27 May 2009 (UTC)
    I'm basing my reasoning on usability as much as ascetics here... my feeling is that if the links are on the other side then they will be more noticeable for new users, would be easier (and faster) to find, and as a result would encourage more readers to start editing. I hadn't been aware that the money was coming from a grant, but if that's so there's still no reason to use it if it isn't required. My feeling is that a "month or so-long poll" is different from "a huge poll" in that it can be set up and implemented by Wikipedians easier, rather than needing some more "official" thing on Meta where it isn't as visible to the average user. Also, as Dinoguy1000 mentions below, this change can both be easily undone if the developers need to, and it would also allow further testing on what the new configuration's usability was in comparison with the old before making a "this is what needs to be done" type of decision that might be a bit more final than what is determined in a !vote here. –Drilnoth (T • C • L) 19:29, 27 May 2009 (UTC)
    Good, now they won't have to spend a few thousand dollars moving the edit link to the left. As for the data being invalidated - this would only give them more data, namely reactions from editors as to the new layout of the button.   M  02:58, 28 May 2009 (UTC)
    The reactions from editors is mostly irrelevant. Editors already know how to use the site. The goal of the usability project is to make the site more usable for others. They can't study that by reading a talk page. They have to do real studies, like the ones they already did 2 months ago. Mr.Z-man 04:07, 29 May 2009 (UTC)
    I categorically reject the assertion that "it just plain looks better". I looked on the German Wikipedia and think it looks horrible. Powers T 13:28, 28 May 2009 (UTC)
  • Support per my reasoning above. Personally, I think Mr.Z-man's argument is just a "don't change what I've gotten used to" masquerading in pretty clothes; this change would have no influence on any usability studies the Foundation has had performed in regards to the section edit link. Au contraire, it would be beyond trivial for the devs to restore the right-hand links if it's necessary, and the findings of such usability studies would include recommendations on new placement of the edit links, which could be implemented quite easily regardless of their then-current placement. I also quite like Drilnoth's suggestion of having a gadget either way, instead of only if the change is decided upon and made. ···「ダイノガイ千？！」? Talk to Dinoguy1000 17:25, 27 May 2009 (UTC)
    The usability studies are mostly already done. I've actually put some thought into my argument, but thanks just dismissing it as crap, I appreciate it. I think we're diving into this with too little thought. We started the poll after only 3 days of real discussion. Alternatives were proposed, but the discussion turned to polling before anyone really had the chance to evaluate them. Mr.Z-man 17:35, 27 May 2009 (UTC)
Alternatives were proposed, and quickly shown not to fix the bunching issue. They are still available to be looked at, and compared to each other. I'm sorry that you think that the 3 days discussion wasn't enough, but the discussion remains open for further comments and suggestions. Mjroots (talk) 19:11, 27 May 2009 (UTC)
I certainly didn't mean to dismiss your argument "as crap", and I'm quite sorry if it sounded that way (I have nothing against you personally). However, I still stand by my own comment. ···「ダイノガイ千？！」? Talk to Dinoguy1000 19:58, 27 May 2009 (UTC)
Mr.Z-man, I certainly don't wish to dismiss your comment either, but I too wonder why this particular proposed change provokes your line of reasoning, and my concern is, are you therefore saying we're wasting our time by discussing any UI change in this forum? PL290 (talk) 20:14, 27 May 2009 (UTC)
Unless the usability team decides against it and reverts it, we aren't wasting our time, just the usability team's. My main concern is really that of LtPowers, that as a usable UI goes, its worse than what we have now. It fixes the bunching problem at the expense of inconsistency. Combined with rushing into a vote with little discussion and even less testing, I just don't think this is a good idea. I just don't see what the rush is. Why is this something that needs to be resolved post-haste all of a sudden? I'm not saying we need to start conducting surveys of our own, but right now the process looks like "We should fix the bunching problem / This fixes the bunching problem / Excellent, let's vote / It fixes it? Okay, Support!" Mr.Z-man 21:27, 27 May 2009 (UTC)
  • Support. Much better visibility and less prone to random up-down float when images, templates etc. interfere. Germans did it again! NVO (talk) 19:33, 27 May 2009 (UTC)
  • Support, per OrangeDog. ParlorGames 19:54, 27 May 2009 (UTC)
  • Support, fixes the very annoying bunching problems; increases visibility of edit link (but not in an annoying way), thus furthering ease-of-editing for new editors --Cybercobra (talk) 21:12, 27 May 2009 (UTC)
  • Oppose The intent of this proposal is to make it slightly easier for absolute newbies to find the edit link, at the cost of making it much slower for everyone else to locate the actual link I tried Drilnoth's script for a few minutes, and verified the speed decrease. With the current style, I can move the mouse pointer to the right edge of the text "automatically" while seeking the appropriate vertical position; with the proposed change, I must seek both horizontally and vertically. Also, with the proposed change it was harder to spot those edit links as they tend to blend into the header when scanning the page.
    I agree with Mr.Z-man that this seems to be a "We have to do something! / This is something! / Let's do this!" discussion; a real usability study involves actually evaluating proposed alternatives for usability instead of just arbitrarily deciding to change things because it might be better. IMO, that should be left to the people being paid to do that sort of thing, instead of a bunch of armchair amateurs. Anomie⚔ 23:34, 27 May 2009 (UTC)
    The same can be said for writing an encyclopedia, but we're doing a damn good job. I'm happy to see more people involved in usability issues. The arguments are hardly arbitrary. Your verified results are suspect, since you've become accustomed to the old interface, and will likely spend some time getting accustomed to the new location. If you can agree that you look at the heading before editing, then showing that this takes a shorter time is relatively simple. You subtract the need to track to the right, and inconsistent link positioning affects nothing since (unlike, say, the scroll bar) you cannot click these links out of the corner of your eye.   M  03:12, 28 May 2009 (UTC)
    For that matter, everything you assert is suspect too, and I certainly do dispute your baseless assertions regarding the tracking time. I see in several discussions here you have been extremely quick to dismiss anyone who disagrees with you, only backing down once consensus is overwhelmingly against you. Here, there are a number of people on each side of the debate so there is not likely to be an overwhelming consensus any time soon, but your closed-mindedness is still not helping the matter. But fortunately, it's not my purpose here to try to argue with the closed-minded, so I'll just say "Have a nice day" and leave you to it. Anomie⚔ 03:24, 28 May 2009 (UTC)
    I gave a reason why your experiment is suspect: single user is accustomed to the old interface. Of course you'll be slower at first. Your criticisms belong on my talk page. 19 support, 4 oppose is a great start on consensus. Please read through parts of this book, Fitts's law, and this selection of citations. I can look up some more (better) information if you're interested, most of this is from a quick google search. If you'd like to have a (cited) argument in terms of usability, I'm up for that, in one of the sections above. In the meantime, I don't want other editors to get the wrong idea when you say 'verified', and I want them to understand that at first, a speed decrease is normal.   M  04:03, 28 May 2009 (UTC)
    Let's all calm down a bit. Obviously if consensus is reached that the edit button should be moved, I'd expect that the issue would be investigated fully before implementation by those who deal with such issues as UI. It may be that the default is kept to the right, but a user preference is granted that allows the [edit] button to appear immediately at the end of the section heading. Mjroots (talk) 05:54, 28 May 2009 (UTC)
    You might expect that, but I certainly wouldn't count on it. Mr.Z-man 06:24, 29 May 2009 (UTC)
    M, you seem particularly eager to get this change implemented, to the point of trying to shoot down every opposing argument. Is it really that important to you? Can't you acknowledge that there may be some valid points on both sides of the issue? Powers T 13:28, 28 May 2009 (UTC)
    Actually, if your overall editing time is significantly affected by searching a (non-bunched) edit button in either style, you must have a much faster brain, faster fingers, and a much faster internet connection than me. For typos, just finding the proper place in the edit box is dominating the edit click, and for real content, thinking and formulating is. Even typing and a preview cycle take longer than to move the mouse pointer hither or thither. --Stephan Schulz (talk) 21:02, 28 May 2009 (UTC)
  • Support I don't know how many times I've seen those edit buttons are place they really shouldn't be, and spent quite a while re-aligning images, tables, etc... so things would line up properly. I'd rather have them on the right, but I'd also rather have them work and not screw up with article layout. Place them on the left by default, and give the monobook.jss code for those who would like to see on the right. Headbomb {ταλκκοντριβς – WP Physics} 00:32, 28 May 2009 (UTC)
  • Support Exactly what Headbomb said, practically to the letter.--Aervanath (talk) 04:47, 28 May 2009 (UTC)
  • Support. I hate bunching and playing the "which section does this edit link belong to?" game. MER-C 13:31, 28 May 2009 (UTC)
It's better than the current situation though. MER-C 04:32, 29 May 2009 (UTC)
So despite there being a possibility of an even better option, we should use this because it was proposed first? Mr.Z-man 06:21, 29 May 2009 (UTC)
  • Strongly Oppose – I've seen the edit links on other language wikis and it really bothered me. The edit link looks very good where it us, and moving it will create unnecessary hassel and disorder. It certainly isn't broken, so there is absolutely no reason to fix (or brake, rather) it. American Eagle (talk) 20:25, 28 May 2009 (UTC)
    • You don't consider the bunching problem to qualify as "broken"? --Cybercobra (talk) 23:20, 28 May 2009 (UTC)
      • Also, did it bother you in other languages because you actually didn't like it or because you just weren't used to it? Remember that change can be hard to adapt to... for a new user, which would be better? Also, if there's a gadget long-time users can keep it the way it is. –Drilnoth (T • C • L) 03:26, 29 May 2009 (UTC)
        • Cybercobra, no, I have never had an issues with it. Drilnoth, in other languages, I found it very distracting when I was looking for sections headers. I'd see "Primeras etapas de la vida [edit]" (for example) and I'd get confused. Although the proposal might save a newbie a half a second (which it may), it will also frustrate many oldbies and distract most readers. If this passes with enough consensus, I won't retire because of it, but I still can't support its implementation. American Eagle (talk) 05:08, 31 May 2009 (UTC)
  • Despite my earlier resistance, I conditionally support this proposal, provided that the opt-out is provided as a gadget as soon as the change is made. Dendodge T\C 20:31, 28 May 2009 (UTC)
  • Weakly Oppose—I can see the attraction for this solution, in part because it is a relatively small incremental change to the current situation. However, the fact that it is an incremental change bothers me. I think something more radical would better serve to facilitate and encourage editing. For instance (this is an off the top of my head suggestion - there are other things that could be tried), if the entire horizontal line on which a section title appears were activated to enable launching an edit session, the would be a great help. What do I mean ... in the image below, the [click to edit section] text would only appear upon mouseover; the shading would be persistent. --User:Ceyockey (talk to me) 01:47, 29 May 2009 (UTC)
  • That probably wouldn't be too hard to do with just a little bit of JavaScript and CSS. I'll try to make a mockup. –Drilnoth (T • C • L) 01:52, 29 May 2009 (UTC)
  • An excellent illustration of why this poll was premature; there may be multiple alternatives, some of which may solve the problems inherent in both current proposals. Powers T 02:04, 29 May 2009 (UTC)
    • This is a bit trickier than I'd thought; I don't have enough experience with JavaScript to code it in any amount of time that it would still be useful for this poll. MediaWiki's setup just isn't quite right to make it easy (the headlines need a class). –Drilnoth (T • C • L) 02:27, 29 May 2009 (UTC)
  • This is a bit too obtrusive. A minimal change is good because we have only one factor to worry about - the position. Adding sizing and color would introduce too many factors and objections. Further, the change is exactly what the second-largest Wikipedia is already using, and has tested (which is why I find the "it's premature" objections hard to swallow).    M   03:12, 29 May 2009 (UTC)
  • Just to clarify, I don't know how I feel on this particular proposal; it could work, but may also have some problems. I was simply offering to try and make a mockup, a task at which I failed miserably. :/ –Drilnoth (T • C • L) 03:25, 29 May 2009 (UTC)
  • Again there are more options. Just because the German Wikipedia is using this one doesn't mean we shouldn't consider others. Its premature because all the other options presented were rejected because the test cases didn't work, despite the test cases being suboptimally designed and completely unrealistic. Then we started a poll 6 hours later. Everything else was rejected before it had time to be properly evaluated or even brought up. Mr.Z-man 04:07, 29 May 2009 (UTC)
  • Mr Z-man, where has everything else been rejected? I think you're maybe misrepresenting the situation, which is this. An idea was floated, it seemed on first appearance to be a good one. A few alternatives were tried and the original idea show to work best. A formal proposal was drafted and consensus sought.
Now, I'm not an expert in the various coding etc needed to achieve the suggested change. It may well be that there are technical reasons why the English Wikipedia can't have it. It may be achieveable and set as the default, or alternatively made available via user preferences. The discussion is still open, if you (or any other editor) has another suggestion, please propose it and let the community state whether or not they support the proposal. This isn't something I'm trying to bring in overnight. It needs the involvement of a large number of editors over a reasonable period of time because the suggested change, if implemented, would affect all users of Wikipedia. Mjroots (talk) 05:18, 29 May 2009 (UTC)
I think you're missing my point entirely. The one option worked best because in the one and only test done, all the other options were done incorrectly, and there was no time for more extensive coding or testing or discussion before the poll started. I never said there are technical reasons why this couldn't be done (though there are technical reasons why other solutions are better, specifically they can be done without JavaScript). Its probably too late at this point to propose something else, especially since the poll has already gained inertia and I prefer to actually test things properly before suggesting them (though I did provide some CSS code above that could be used as a start). This may very well be the best solution, but since there's been no real testing done, we'll never know. Mr.Z-man 06:21, 29 May 2009 (UTC)
I think this would be too easy for readers to click accidentally. --Cybercobra (talk) 04:19, 29 May 2009 (UTC)
  • Pollster Since there haven't been votes for a while (over 12 hours), I counted the votes so far and got 19-For (76%) vs. 6-Against (24%). But keep in mind WP:POLLING and all that. --Cybercobra (talk) 19:28, 29 May 2009 (UTC)
    • I count 5+6+6+3+1=21 support (including the proposer, the unbolded support, and the conditional support), and 6 oppose. There are 4 more supports below, making it 25/6 for this section.    M   15:38, 8 June 2009 (UTC)
  • Comment: I've been using the script that I created so that this can be tested since I created it. At first it was kind of strange, because it's in a different location, but I've found that I'm already growing used to it. I strongly urge anyone who isn't sure of their feeling on this to try out the script for a good amount of time—not just a few minutes or hours—and give it a chance. I'm honestly surprised by how quickly I got used to the location. –Drilnoth (T • C • L) 19:33, 29 May 2009 (UTC)
  • Comment—If someone has access to a software simulation tool, such as iRise (the only one I'm familiar with), then we wouldn't have to wait for resolution of code technicalities in order to have full page mockups of various options. This is true of both the present and other usability discussions. --User:Ceyockey (talk to me) 23:59, 29 May 2009 (UTC)
  • Enthusiastic Support. The stupidly brain-dead postioning and bunching problems with the section edit links have long been an annoyance. older ≠ wiser 21:16, 30 May 2009 (UTC)
    • I am happy for your enthusiasm, but please try not to call other peoples' hard work "stupidly brain-dead". –Drilnoth (T • C • L) 21:56, 30 May 2009 (UTC)
      • I didn't mean to demean anyone -- but whatever hard work may have been involved, the flaws of the section edit link placement have long been an annoyance as well as a usability problem. older ≠ wiser 22:05, 30 May 2009 (UTC)
  • Support with the same enthusiasm, and same disdain for our collective lethargic tolerance of an obviously broken solution, as older/wiser above. The proposal specifically provides an opt-out for those who prefer it the broken way, so "I don't like it" is even less of an argument than it is usually.--Kotniski (talk) 22:20, 30 May 2009 (UTC)
  • Support the general idea, although I understand the objections. Even after a year and several thousand edits, I more-than-occasionally find myself reflexively reaching for the "edit this page" tab at the top of the page when I just want to edit a section. Aesthetically (when there aren't ugly bunching and displacement problems), the current placement has much to recommend it. But the balance of reasons very strongly favours putting the [edit] link next to the (sub)section header, either to its left or more closely to its right. New editors (and new readers who may not even known they could edit) are far more likely to see it (as the usability study showed), and the bunching/displacement issues can be greatly diminished for the overwhelming majority of working editors who have neither the knowledge, the skills, the patience nor the inclination to start fiddling around with Javascript, CSS, monobooks, etc. (If an automated option can be entered into User Preferences, then that becomes a rather different question about default appearances, etc. Maybe the current format could then be offered as an option there.) —— Shakescene (talk) 23:52, 30 May 2009 (UTC)
    • I must have missed the part of the usability study where they actually tested different positions for the section edit link. Where in there are those results hiding? Anomie⚔ 01:56, 31 May 2009 (UTC)
  • Support; this not only takes care of the bunching problem, it also (to me) appears to be more naturally intuitive. I do understand TreasuryTag's objection, but I think we cannot hide the connection between the two aspects of our project here. One question: Will the section edit link be as small as it is now? Certainly it will not match the section heading font size, will it? Unschool 02:32, 31 May 2009 (UTC)
    • I believe the proposal is just to change the position of the edit link and not otherwise modify how it looks. That bit of bikeshed-painting has been left for another discussion. --Cybercobra (talk) 02:43, 31 May 2009 (UTC)
      • Cybercobra is correct; the result of this discussion will just determine whether or not it should be moved. If there is consensus for this, another discusison will be held regarding appearance before the change is actually implemented. –Drilnoth (T • C • L) 02:47, 31 May 2009 (UTC)

Arbitrary break

  • Comment I've just filed T21022, which will make this effect achievable entirely with CSS, no JS needed. Happy‑melon 10:16, 31 May 2009 (UTC)
  • Strong oppose (vote changed to "Support if there is just evidence that readers prefer this structure"). This spoils the readability of the page and only serves to make it easier for certain editors to click on a button. I prefer the button on the right, where it doesn't interfere with the flow of the page, but that's exactly what it is: a preference. I strongly don't believe that the entire 'pedia should be changed just at the preference at certain people. If you desperately want it that way, you can use Javascript or CSS to enforce it, but don't drag the rest of us into it. I also disagree with this "opt-out" scheme. As the problem is is supposedly aesthetics, we would generate more problems than we solve if different editors view the layout of the page in different ways. Greg Tyler (t • c) 17:43, 31 May 2009 (UTC)
    • Many users already view pages differently than say, non-editing readers. Skins drastically change page appearance, and things like User:Drilnoth/rounded.css can drastically alter a page's appearance for certain users. I haven't found this to be a problem. Second, how does it spoil the readability of the page? Just because the edit link is in a more visible location? You can still just read the section headings... I've been testing this for awhile now and at this point don't even notice it. Having three or four edit links bunched up together in places destroys readability more, IMO. Also, at this point there seems to be more consensus for the change, so I'm not sure if saying that "I strongly don't believe that the entire 'pedia should be changed just at the preference at certain people." really applies... if it was a minority trying to make this changed, then yes, but based on the discussion here, it would appear that the minority don't want it changed. –Drilnoth (T • C • L) 18:01, 31 May 2009 (UTC)
      • The problem here is that it's entirely a matter of preference, right? Some people think that changing will improve readability, ease of use and suchlike. Others, such as myself, believe that implementing will lead to a decline in readability, ease of use and suchlike. Hence, the best solution is the make the implementation a simple "Yes I want it" or "No I don't" checkbox in Special:Preferences. I'm completely up for that, but why the proposed structure should be marked as default..? The default should, of course, be the structure that readers prefer. I would believe that to be our current system, but that's entirely subjective...
      • My point is that we're polling the wrong people. We editors can always change our preferences, and the site shouldn't revolve around us. Its primary concern is what the readers think, so it's they who we should be asking. Though how you want to organise a poll amongst readers that isn't bias, disallows any sort of rigging and gives a fair consensus, I know not. Perhaps it's just easier to edit Special:MyPage/monobook.js if there's a part of the design you draw issue with? Greg Tyler (t • c) 18:40, 31 May 2009 (UTC)
        • This is a good point. My feeling is that yes, it is just a matter of preference. Some people would prefer the links in the proposed location, some in the current location. The thing is, if this poll was being held when the wiki was first being started and these were the results, it would be obvious that consensus was to have the link near the header. Consensus can change. In essence, the answer your question of "why the proposed structure should be marked as default..?" would be "Because that's what the consensus is for." Something's having been one way for a long time doesn't really change the consensus.
        • You have a very good point about polling the wrong people. However, do you have any ideas as to how we could ask the readers about this issue? People who have never edited wouldn't really care about it—some don't know that you can edit, some don't have the time, and some want to leave it to other people—and many probably wouldn't fully understand what this was about if they haven't already edited, but moving the link might make some more people (those in the first group) edit. –Drilnoth (T • C • L) 18:51, 31 May 2009 (UTC)
          • You've picked up my point perfectly, thanks. The people who should be polled are, for the majority, not going to answer any of our queries. This means that the entire thing would be on such a small scale that fair and useful consensus simply couldn't be generated. I feel we need to talk to readers about this but personally, yet I have no idea how we can do so successfully. To me, that's the biggest step to overcome in this proposal. Greg Tyler (t • c) 19:00, 31 May 2009 (UTC)
            • That's exactly the sort of polling the usability people are being paid to do. Right now, we have results saying "some absolute newbies missed the section edit button" and people are somehow using that to justify assuming (without any evidence at all) that this proposal will be better and without any other adverse effects. And the worst part is, some of them apparently don't even realize how vastly they're misrepresenting the study. IMO, we should let the usability people do what they're being paid to do, since they have the resources to actually perform the needed studies, and revisit this only if they inexplicably ignore the issue. Anomie⚔ 01:18, 1 June 2009 (UTC)
              • If it's a preference matter, I'd be quite happy for the solution to be having it made available via user preferences instead of an arbitrary change. Even if this proposal is passed up the chain as "consensus is that something needs to be done, what do you think of this, should it be the default, or made into a user preference?"I'd be happy with that as an outcome. Mjroots (talk) 08:23, 1 June 2009 (UTC)
    • This is not about aesthetics. It's in part a response to results of the usability study, which found that
      "Users often missed the ‘edit’ buttons next to each section, clicking on ‘edit this page’ all the way at the top. This often got them lost if they were editing a particularly long article, as they weren’t easily able to find the section they wanted to edit. Several users also clicked on the wrong ‘edit’ button next to the sections, thinking that the ‘edit’ button below the section referred to the section above."
      In addition to the issue of bunching, this provides two reasons why the current implementation is difficult to use. Many editors have expressed support that this will solve these issues. Given that we are acting on the appropriate data, would you consider changing your vote - or perhaps your reason for objecting?   M   19:16, 31 May 2009 (UTC)
      • Perhaps, then, we ought to wait until the usability testing can test this proposed solution and see if it works before we go changing the new-user experience, possibly for the worse? Powers T 12:33, 1 June 2009 (UTC)
  • Support - In many larger articles, the edit buttons freak out - more so in some browers than others. I understand that we cater to readers and not editors too, but I feel having edit buttons appearing in seemingly random places like little ghost buttons completely ruins the flow and readability of many otherwise quality articles. Not only that, but the edit button problem has actually kept me from adding images to articles before, as I was afraid of screwing up the button layout. With that in mind, it can dissuade people to add useful content to articles the way it is now. Cheers! Scapler (talk) 20:54, 31 May 2009 (UTC)
  • Support - As was pointed out above, on de.wiki they are already doing this and they don't seem to have any problems. I agree that the [edit] text should be made small; smaller than the header for sure, and probably smaller than the article text. I would also support making it a separate CSS class (if it isn't already) so that anyone who doesn't like the new setup could simply revert to the old one via a custom entry in their CSS file. Soap Talk/Contributions 01:21, 1 June 2009 (UTC)
  • Information – The following table is provided for informational purposes. Several have mentioned that the German Wikipedia uses the editsection button directly after the h2 header.(^and also all other headers marking an editable section - Sswonk (talk) 01:28, 15 June 2009 (UTC)) This is also the case on other language versions. The strictly arbitrary table shows the top 12 Wikipedia language versions based on article count, a link to a sample article ("DVD", chosen arbitrarily because the title is the same in all languages), and the non-formatted, position-only disposition of the editsection button on that site.
http://meta.wikimedia.org/wiki/List_of_largest_wikis ranked by article count
Wikipedia version DVD article Disposition of edit link
English en:DVD [edit]
German de:DVD [Bearbeiten]
French fr:DVD [modifier]
Polish pl:DVD [edytuj]
Japanese ja:DVD [編集]
Italian it:DVD [modifica]
Dutch nl:DVD [bewerken]
Portuguese pt:DVD [editar]
Spanish es:DVD [editar]
Russian ru:DVD [править]
Swedish sv:DVD [redigera]
Chinese zh:DVD [编辑]
Sswonk (talk) 04:13, 1 June 2009 (UTC)
  • Information – Just a little bit of background to the so called "German solution" (which in my ears sounds a bit weird …):
    I did the first version of the script back in March 2005 for mainly three reasons: The screwed up edit links when they intersect with floated elements, the (in my opinion) better usability, and because back then the edit links where placed before the headings in the HTML code which made no sense to me.
    I used the script just for myself in the beginning, but as the problem with floating edit links came up repeatedly I showed it to others in October 2005.
    When in July 2006 DaB. enabled it for all users in de, about 50 to 60 people were already using it. As DaB. just was bold and did it without any prior discussion (or telling me) the following discussions where quiet fierce. Mainly because the script was meant to be opt-in and so it had no opt-out build in at that time. The rest of the discussion had exactly the same arguments as here.
    In October 2006 the structure of the edit links was changed in MediaWiki from having a div above the heading to a span inside of the heading (but still before the headings text). That made it possible to shrink the script down to a few lines of code, which Marc Mongenet and I did more or less simultaneously (at least I guess so, because his version was online a little prior to mine, but I don't remember looking over to the French Wikipedia.)
    The French version was later modified by Maloq who claims that his version ist 500 times faster … didn't check this, just found it myself today.
    So in the languages Sswonk listed you'll find several different versions of the script, if you plan to try it with js before it gets integrated in MediaWiki itself (won't believe it until its done), choose wisely. I wrote this mostly to make clear that this is not some hasty reaction, lots of people are working on it and with it for years now. --Dbenzhuser (talk) 16:02, 1 June 2009 (UTC)
  • MORE information! :) I think that I mentioned it somewhere above, but it may have gotten lost in the shuffle. I've been testing this out for a few days now and am almost completely used to it... it actually makes much more sense to me than the current stup does and I think that it is easier to use. The first day or two it was kind of weird, though; please try it for awhile before !voting to see if you experience the same effect I did. –Drilnoth (T • C • L) 16:26, 1 June 2009 (UTC)
    • As has been pointed out by M several times, this isn't about how easy it is for us to use this, since there will no doubt be a way for individual registered users to set this as a preference, but rather whether this change makes any difference for new and inexperienced editors who, according to the usability study, had trouble finding the edit links before. If they will still have trouble with the edit links, then this doesn't seem worth implementing, at least not as the default. Powers T 16:31, 1 June 2009 (UTC)
      • I think fixing the bunching problem makes it unequivocally easier to find the edit links when bunching is present. Any usability difference between directly-after-section-name vs. right-aligned is minor compared to the gains of fixing bunching. --Cybercobra (talk) 17:05, 1 June 2009 (UTC)
  • Support either fixing the problem (the stacked edit markers is an identifiable problem) or creating a new way to do it that avoids the stacked ambiguity issue is preferred. I have no preference on either solution, but one of them should be implemented. As for "They spend $900,000 for user interface"...I think they are getting ripped off... — BQZip01 — talk 03:57, 2 June 2009 (UTC)
  • Information – In the Chinese Wikipedia, there is actually a gadget for registered user to choose such that the edit button appears immediately after the heading, similar to German, French, etc Wikipedia. --Quest for Truth (talk) 14:11, 2 June 2009 (UTC)
    • I think it was determined that regardless of the outcome of this discussion, the other version would be available as a gadget in each users' preferences. –Drilnoth (T • C • L) 14:15, 2 June 2009 (UTC)
  • Support if there is just evidence that readers prefer this structure. I was previously unaware such a survey had been undertaken. If it has, then I support this proposal. Greg Tyler (t • c) 16:12, 2 June 2009 (UTC)
    • I for one am not aware of any such study; the "usability study" referred to several times above contained a statement that the new editors in the study often missed the section edit button, and sometimes confused it for editing the section above instead of the section below. There was nothing in there about trying alternative positions to see if they were any better. Anomie⚔ 19:12, 2 June 2009 (UTC)
  • Oppose. I honestly can't see what's to be gained by moving it and I don't see any issues with the current alignment. If it ain't broke, don't fix it. However, if it does go through, I support the idea of an opt-out version. Queenie 20:41, 4 June 2009 (UTC)
Even without considering any usability problems, there's the whole bunching issue. {{FixBunching}} is really quite a messy hack. OrangeDog (talk • edits) 22:49, 4 June 2009 (UTC)
It obviously is broken though. For example, I've had to click on the [edit] link in the Formal Proposal section to edit here. The issues with alignment/bunching are not common to all browser, but it is known to affect some, such as Mozilla Firefox. Mjroots (talk) 06:49, 5 June 2009 (UTC)
  • Oppose- I've never seen this as that much of a problem and moving the link right after the section title is an eye sore and a readability issue. For example, if I reading aloud I would be tempted to read the edit link as well. It would just be in the way. This would only fix a few articles but I would support a different method to prevent it from overlapping.-- penubag  (talk) 17:15, 6 June 2009 (UTC)
  • Support - I prefer to see the edit button immediately following the section header. In my experience, the righthand location tends to screw up from time-to-time, interfering with other texts or even images. Whenever it does this, it seems that fixing the problem for one browser seems to mess it up on another. (I have also suspected there might be a “skin” problem, but I’ve not checked for it.) Askari Mark (Talk) 02:28, 7 June 2009 (UTC)
  • Oppose Click Recent changes some time and tell me if people are having a problem working out how to edit a section. WP is not a forum where we want people to add their opinion. Efforts should aim to make the encyclopedia read well. I don't want any klunky "edit me" text or button inside the article when I am reading it. Sure, new editors are totally lost. That's because they are new – a problem that won't be solved by moving the edit link. It's totally patronizing to imagine someone can't notice the [edit] link where it is. Johnuniq (talk) ]09:49, 7 June 2009 (UTC)
    • Just to clarify - are you seriously suggesting that we should make things harder to edit to prevent a few people from adding opinion? Please see the usability study, quoted several times above, which shows that new editors do in fact have problems with the positioning. Further, this very proposal is one of the designs that the usability team itself is developing.    M   18:09, 7 June 2009 (UTC)
      • One: So let Usability consider it. Two: We haven't changed anything yet, so to say "You're making it harder" is not only a poor choice of words, but also a modest use of hyperbole. Three: Which also depends on point 1. --Izno (talk) 14:19, 8 June 2009 (UTC)
        • Good, let them handle it. Meanwhile, let's not let "well, someone else will take care of it" stop us from making some sorely-needed progress. If this is the sort of opposition that the usability experts will be facing, then I'd like the precedent that this poll sets to be one that is in their favor.    M   15:24, 8 June 2009 (UTC)
          • But it might not come back in their favor, exactly because there are many people supporting this change, and not the change they will recommend. For all we know, they could say "get rid of the editsection links" or "you should make them as obtrusive as possible making them stretch the entire length of the section". Unlikely outcomes, but nonetheless possible. When they come back, we should make the move then to say "Yes, we want to go with your idea here" or "No, we think that's a terrible idea, can you cook something else up for us?". There is no deadline. --Izno (talk) 15:33, 8 June 2009 (UTC)
  • Support. Improves usability (IMHO, at least—it's largely a personal preference issue). AGK 14:10, 8 June 2009 (UTC)
  • Oppose for the aesthetic reasons mentioned. Further, I do not see the reason why we are polling on this when the usability initiative is already doing the same, and they're professionals. We are not. Consistent placement is important. --Izno (talk) 14:19, 8 June 2009 (UTC)
    • I believe this is being discussed here as a stopgap measure until a more permanent solution is implemented as a result of the study. Regardless, as I see it, reliance on a solution arrived at by the initiative crew could be compared to using a crystal ball, as could speculation that such a solution would be widely accepted – or widely rejected. The "reliance on professionals" argument is specious. The current implementation is semi-broken and should be fixed one way or the other. Ideally the position of the editsection button should be an option available under "My preferences". Sswonk (talk) 14:54, 8 June 2009 (UTC)
      • A stopgap measure for which obvious problem? Editsection is obviously not broken in its primary function; what are we trying to fix? We're working on the presumption that what we're doing would "fix" something, but I'm not seeing the "something" and I'm not seeing that it would positively fix it. Usability could decrease from the change! We could close a can of worms and then open up another! In its own way, the support is crystal-balling as well.
        I implore you to explain why you consider it fallacious. They were hired, by Wikimedia, to make the fixes that we don't know that we could. You seem to assume that I would fall trap to the argument from authority (which perhaps you assumed?); usability initiative is there to recommend changes, not force them on us. The change being considered here...
        As for the current implementation, it's not broken enough (from mine, and others' point of view) to expend the energy to fix any possible backlash against the idea once implemented. Its a documented issue, and you're more then welcome to remind the initiative of it, because as pointed out, they are breaking down a wiki-page to see what needs 'fixing'. Let them figure out what they want to say, and then we can take that into consideration. A bug, with CSS and not our own, with floating, isn't enough reason to get ahead of them and ourselves here. We've long had the issue of working with it, and we do have the hacks to deal with it necessarily. Not only that, but if you're getting image bunching problems, that could be a problem with the layout of the article... which I've not seen used as an argument. Consider what the MOS says about image layout: You should attempt to stagger the images instead. --Izno (talk) 15:18, 8 June 2009 (UTC)
        • You exaggerated my points a bit: I did not use the word "obvious" to describe the problem, although I did use it perhaps over-enthusiastically to support the change several days ago for my opinion of usability benefits, and I used the term "semi-broken", not "broken". I don't rest easy with complacency-based solutions anywhere but I'll leave it at that. However, I think your point about backlash is a very important one that deserves recognition. Will you at least agree with me that a preference-based, gadget choice which should be fairly trivial to implement in my estimation is desirable based on the comments here and more importantly on the widespread use across other language versions of a beside-the-header editsection button? BTW, I think we could use another "arbitrary break" after this mini-thread. Sswonk (talk) 15:39, 8 June 2009 (UTC)
        • (responding to Izno): Consistent placement of edit links is important, but right now the bunching problems that come up when you have longer infoboxes, side quotes, and images makes their placement inconsistent, whereas putting them next to the section headers consistently puts them in one place: At the end of the section's titles. I've been using my sample JavaScript for a week now, and I'm actually finding it easier and more natural to find the edit links now than I had before. I also haven't found that they get in the way acestetically... since section headers are bold and given more weight, and the edit links are just plain text, they don't really interrupt the flow of the article any more than they ever did. Also, you say "...the usability initiative is already doing the same, and they're professionals. We are not." If the usability study hadn't been done I think that this still would have come up. So do you feel that because there is currently a study going on, the discussion about and possible improvement of Wikipedia's interface should just stop simply because of their study? That doesn't really make sense to me... if they find that the change is problematic, then it can be undone easily, but why should we stop working to improve something because of a simple study? We wouldn't stop improving content if there was a study on Wikipedia's reliability. –Drilnoth (T • C • L) 15:50, 8 June 2009 (UTC)
          • Sswonk: The javascript is obviously floating around, which is just as good as a gadget. I've no opinion either way.
            Drilnoth: You may be right that people may have opposed it anyway, but that's a non-issue. What I'm saying is that we shouldn't duplicate effort (especially when our "effort" is inferior implicitly), and that's what we're doing. Your comparison is inept, because we would already know the criticisms in that case. It's more like changing the interface when we don't know what those criticism are. --Izno (talk) 00:02, 10 June 2009 (UTC)
  • I briefly considered ignoring this comment, but I've decided it shouldn't go without a rebuttal. A javascript may result in an equivalent format displayed on the screen, but for usability it is not "just as good as a gadget". A gadget provides a front end, GUI method to implementing a javascript. Your statement is like saying "DOS commands are just as good as clickable icons." Xerox PARC, Steve Jobs and Woz and the friendly folks at Microsoft all took a look at that sentiment from the usability persepective and they all disagreed with it many years ago. Sswonk (talk) 16:17, 13 June 2009 (UTC)
  • Pollster For this section, 5 support, 4 oppose, 1 conditional support. Previous section 25:6. This brings the totals to an even 30 support and 10 oppose. This is since 27 May 2009, so 13 days or about two weeks since this poll began. As usual, see WP:POLLING, though I doubt this is a problem here since everyone has had something to say.    M   15:57, 8 June 2009 (UTC)
  • Strong support. There are some good objections which I think have been addressed: the link will no longer be consistent along the right - yes, this looks slightly worse, but is ok; and that we should let the usability people fix this - no, this is up to us to implement. Some other objections are really strange: a few seem as if the editors were aware of neither the points about bunching nor the usability study; at least a couple seem to oppose this because it would make it easier for the technologically inept to edit (right - we want this). The main objection now seems to be readability (that is, aesthetics). This takes a far back seat to usability (incidentally, I have found absolutely no readability problem with the new position while using the script). As for the reasons to do this, they are plenty:
    1. Moving the edit link fixes bunching, which is currently being addressed with the {{fixbunching}} hack. This is a very objective problem.
    2. Our current position violates the convention of making the 'actions' at the bottom (bottom right) of the text. This is the convention of many interfaces and nearly all discussion boards, which most people are familiar with (cf. 'edit, reply, quote'). The usability study has found that the current position causes new editors to click the wrong edit link, and presumably waste time looking for text that won't be there.
    3. Our current link is set too far apart from the heading text, which the study shows makes it easy to miss.
    4. It is clear that bringing the link beside the heading will solve a) bunching, b) wrong section editing, and c) poor visibility.
    5. It is not permanent, if the sky falls we can change it back.
    6. The new position is strange at first, but the editors who have reported back after trying it have given positive feedback.
    7. This is precisely the solution that the usability team is providing here, see a mockup here.
    8. This certainly is not just some new and slightly crazy idea: it has been implemented and tested on the second-largest Wikipedia, and it is working fine.
   M   17:13, 8 June 2009 (UTC)
Most of those would also be true for pretty much any positioning except the current one, but since we never properly tested anything else... Mr.Z-man 17:36, 8 June 2009 (UTC)
I failed to mention that this is another good point, and it would be nice to brainstorm something even better than this solution, but we've had 2 weeks with only one alternative proposed, the usability group has had time, as well as the german wikipedia. This seems to be the best thing we have. Something better and more radical would have died in the archives. At least small and clear steps like this are generating discussion.    M   17:47, 8 June 2009 (UTC)
I don't think 2 weeks is adequate time to develop, test, and vote on a significant interface change. This had the benefit of already being developed and tested on other wikis, so every other possible proposal was way behind from the beginning. The brainstorming should have been done before the poll started, but that part of the discussion only lasted a few days and didn't properly test anything. Its the best thing that's been proposed because its the only thing that's been proposed other than the status quo. There are several things that could be done that would be just as radical as this change, would also keep the links in a consistent horizontal location, and may not require JavaScript to implement, but nobody's willing to give them more than a passing thought, because jumping on the bandwagon of this is easier. Mr.Z-man 18:12, 8 June 2009 (UTC)
  • Support. I tried the css code proposed by Mr.Z-man above (I only changed position to static), which places edit links at the beginning of section titles, and found it rather convenient. So, I support, this proposal, if there is an opt out option, which allows me to keep control over where my edit links are set. Ruslik_Zero 18:51, 8 June 2009 (UTC)
    • CSS and JavaScript will be usable to change the location regardless of the "default". I think that this proposal is to have the edit links immediately after section headers... I don't know if there was a typo in your post or if you wanted to support a version different from what is primarily being discussed right now; just thought I'd mention it. –Drilnoth (T • C • L) 19:36, 8 June 2009 (UTC)
    • Note that what I gave above was not a proposal, merely a start/proof of concept that that could be done while still fixing the bunching issue. It would definitely need more work and testing by someone with more CSS expertise than myself to be viable. My point was merely that there are more options than the one being presented here, that was just one of them. Mr.Z-man 19:59, 8 June 2009 (UTC)
      • Mr Z-man, as I've stated above, I'm open to other suggestions. I've asked above for other suggestions to be posted, but so far there have been none. As I've also stated above, I realise this will be a big change if implemented. It may be that the best way forward with this particular change will be to make it a user preference rather than an arbitrary change. Either way, something needs to be done, and as has been pointed out, the change I suggested is well tried and does work on otherw Wikis. Mjroots (talk) 20:28, 8 June 2009 (UTC)
        • Exactly, all the testing for this idea is done, which means any other proposal needed to do the development, testing, and polling in the time of the polling for this one. There were 3 days between the time the thread started and the poll started. That is not adequate time for development and testing. Mr.Z-man 20:37, 8 June 2009 (UTC)
  • Support moving the edit button to the end of the section header... --candle•wicke 23:34, 9 June 2009 (UTC)
  • Weak oppose I prefer the consistency and unobtrusiveness of having the of the having the edit links on the right side. As for bunching, I do not think that a rendering problem with one browser on a minority of pages should be a factor in determining presentation style. A technical problem warrants a technical solution. Also, I do not believe a change in position would have a significant impact on the ability of a first-time to find an edit link. However, if this is a driving factor for change, I'd suggest an experiment: Write a temporary script that shows the edit links after the header for odd IP addresses and right aligned for even IP addresses, and review IP editing statistics after a day or so. -- Tcncv (talk) 01:17, 10 June 2009 (UTC)
    • I believe that bunching is a problem on every major browser, as well as a problem on most pages with an image. I'm not sure that it makes sense to say both that it would be more obtrusive, and also just as easy to miss. Perhaps you could give the script a try for a week or so?    M   00:42, 11 June 2009 (UTC)
  • Support moving the edit link or button to the end of the section heading. This would improve layout problems on many articles, which ovrrides the unobtrusiveness concern, in my opinion. Finell (Talk) 16:26, 14 June 2009 (UTC)
    • Question Why are many editors talking about this as a proposal for level 2 (h2) headings? The same layout problem applies to all heading levels. I hope no one is thinking that they should jump back and forth (or, right and left) for different levels. Also, please note: we are discussing section headings; a header is something else. Finell (Talk) 16:26, 14 June 2009 (UTC)
What I intended is for all levels to be presented the same, with the [edit] button appearing immediately after the last character in the heading. Mjroots (talk) 18:55, 14 June 2009 (UTC)
  • Strong oppose, but will move to Support if the button is GREY and not bright blue—If I understand correctly, the bright-blue "[edit]" would be shunted so that it's immediately to the right or under the section title. Bad idea from a visual perspective. En.WP has it much better positioned than the French and German projects, which have obstructive blue jostling with every title. It's as though all readers were WPian editors. They're not. About 0.000000001% are. My view is unchanged by the regrettable and occasional tangling of the edit button with images. Perhaps we could fix that problem as a separate issue. Tony (talk) 08:21, 16 June 2009 (UTC)
Tony, you understand the proposal perfectly. The problem of tangling of the edit button with images is precisely what the proposal is trying to fix. See West Kingsdown Windmill, an article I expanded today. Before expansion there were no bunching issues. After expansion, with an additional infobox, there are several. I've imported Drilnoth's script,bypassed the cache, and the bunching problems have disapperared. All edit buttons falling neatly at the end of the heading. Mjroots (talk) 13:41, 16 June 2009 (UTC)
Tony, please understand that this poll is only about the placement of the edit button, not its appearance. It will probably be made smaller than the current button, and perhaps in gray text. That will be decided after this if there is consensus to move the link. –Drilnoth (T • C • L) 19:14, 16 June 2009 (UTC)
Consensus seems to be that the existing situation should be retained, either as a user preference, or by making this proposal accessible via a user preference. Mjroots (talk) 13:47, 16 June 2009 (UTC)
  • Comment Seconding Mjroots. I'm thinking that at 5 support, 4 oppose for the latest section break, with many well established comments on both sides, this proposal has gained a clearer consensus. Can a few editors comment on how difficult it would be to simply add a gadget that loads the Drilnoth javascript? I think that would serve two purposes, that is advertise this proposal as an option to a much larger group of editors that might not know about this thread, and also avoid any backlash against changing default behavior. Is adding a gadget feasible and non-disruptive enough, thoughts? Sswonk (talk) 13:58, 16 June 2009 (UTC)
    Adding a gadget is very easy, it just takes an admin to follow the instructions at WP:Gadget#Installation. Anomie⚔ 14:25, 16 June 2009 (UTC)
    Great. An added advantage to this approach that I neglected to mention is that the gadget would provide a quick and obvious method for new or otherwise interested editors from the non-English wikis such as French, German etc. who maintain accounts here to change the style of the editsection button to something they are familiar and comfortable with. Sswonk (talk) 14:57, 16 June 2009 (UTC)
    A gadget is planned regardless of the outcome of this !vote to allow the other version to be selected in preferences. –Drilnoth (T • C • L) 19:14, 16 June 2009 (UTC)
  • Oppose, per DGG well above. SandyGeorgia (Talk) 15:49, 16 June 2009 (UTC)
Comment DGG has not !voted on the proposal. Mjroots (talk) 16:08, 16 June 2009 (UTC)
DGG commented above (I do hope you understand that consensus is not a "vote"?) SandyGeorgia (Talk) 16:10, 16 June 2009 (UTC)
  • Conditional support only if there is a setting available at the same time that would allow me to move the edit links back to where they are now.--Rockfang (talk) 18:28, 16 June 2009 (UTC)
    • There should be an option in Preferences>Gadgets after this poll ends to allow the version which isn't the default to be used instead. So if consensus is for the change, you'd be able to go back to the current version with about four clicks. –Drilnoth (T • C • L) 20:16, 16 June 2009 (UTC)
  • Support in the other languages where it appears on the left, I got used to it quickly. The en: system of it being on the right makes little sense once you get used to the left-alignment. TheGrappler (talk) 20:13, 16 June 2009 (UTC)
  • Oppose. Mainly on aesthetic grounds (I simply prefer the section heading not to be diluted with functional syntax). If there is no other way of avoiding the technical glitches with a right-aligned "[edit]" link, then okay; but I'd be very surprised if the right-align-initiated problems couldn't be solved in other ways. On a purely practical point: following the left-alignment of the "[edit]" link, be prepared for a sustained larger number of school-kid-type edits on the intellectual level of "wazza was here". In any outcome, I would make the "edit" link much smaller—e.g. [edit] (or an icon of equivalent size).  HWV258  22:45, 16 June 2009 (UTC)
    • I really don't understand these objections on aesthetic grounds. This isn't a proposal based on aesthetics, it's a proposal based on usability. Further, with cleanup boxes, infoboxes, poor layouts, spelling mistakes, paragraphs of fluff, and occasional glaring errors, surely the position of the edit link is the least of our readability concerns. We might as well be arguing about making all of our links not blue. Since these aesthetic oppositions are somewhat common, yet always neglect the usability points, I would like to know what they think about it. And isn't it the point to make wikipedia easy enough for an 8 year old to use?    M   05:55, 18 June 2009 (UTC)
      • Its a proposal to change the UI, while usability is important, we shouldn't totally ignore aesthetics, that's just irresponsible. Mr.Z-man 16:48, 18 June 2009 (UTC)
      • "And isn't it the point to make wikipedia easy enough for an 8 year old to use?"—but not every eight-year-old. Call me a snob, but I'm happy to do away with the services of any eight-year-old who can't find [edit] on the right-hand-side of the screen.  HWV258  01:26, 19 June 2009 (UTC)
  • Support, to fix the bunching issues and for rationality, but allow the user to pick both from settings. feydey (talk) 13:16, 17 June 2009 (UTC)
  • Support Anyone editing a section is almost surely not a vandal. Why not make it easier for good faith anons? HereToHelp (talk to me) 16:37, 18 June 2009 (UTC)
  • Strong Oppose. This misguided proposal confuses readability with usability. Readability for the overwhelming majority of users who have no desire to edit the article must always take precedence over the convenience of the very small number who do. --Malleus Fatuorum 21:39, 18 June 2009 (UTC)
  • Oppose per DGG. –Juliancolton | Talk 21:46, 18 June 2009 (UTC)
  • Oppose per DGG and Malleus. NW (Talk) 23:12, 18 June 2009 (UTC)
  • Oppose Readers come first, always. Dabomb87 (talk) 23:20, 18 June 2009 (UTC)
    • IMO, this is about the readers. We're trying to encourage readers who don't know that the wiki is editable to give it a few copy edits, correct a misspelled word, etc. Additionally, I didn't think that the links interfered with reading the section headers, even when I had just first installed my test script. –Drilnoth (T • C • L) 23:25, 18 June 2009 (UTC)
      • Actually, on testing the script, the edit links on level two headers (==) were not that bad. However, I found the edit links on level three and lower headers very obtrusive. Also, I've enabled the edit link for lead section; I didn't like seeing the edit link right next to the page title. Obviously, that wouldn't affect readers, but it did affect my decision. Dabomb87 (talk) 02:28, 19 June 2009 (UTC)
        • I'm pretty much neutral on the level 3 and lower headers, and I hadn't though about the level 1 head. That could probably be fixed so that it doesn't affect the header without too much difficulty. Also keep in mind that if this passes the edit link will probably be smaller and/or a slightly different color, so it might not be as in the way with level 3 and lower headers. –Drilnoth (T • C • L) 02:34, 19 June 2009 (UTC)
  • Support. The main reasons to support this are both practical and aesthetic (because of the bunching problem, the floating edits are ugly and silly); the main reasons to oppose are aesthetic and a belief that the editing aspects of Wikipedia should not be so obvious. There is little doubt that the aesthetics of the bunched edits are ugly. While it is a matter of opinion that left aligned Edits are less appealing that right aligned Edits. It may well be that those who prefer the way they are now are aesthetically conservative by nature - it is simply a matter of opinion, and those aesthetically in favour of right aligned edits are on the sample of this poll, in the minority. As for "readers over editors", I would agree with that argument if we are talking about not placing tags such as {{Orphan}} and {{Copyedit}} on articles, but we are not - we are simply talking about moving the word Edit from a place where it is impractical and occasionally clearly unaesthetic, to a position where it is useful, helpful, aesthetically acceptable to the majority, and encourages readers to edit. It's a win, win, win situation. SilkTork *YES! 19:23, 19 June 2009 (UTC)
  • And yet, somehow millions upon millions upon millions of edits to WP have somehow happened with right-aligned [edit] hyperlinks. Go figure.  HWV258  09:06, 20 June 2009 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

Gadget

MediaWiki:Gadget-lefteditlinks.js has been created. You can now activate the left edit links as a gadget in Special:Preferences. Please report any bugs at User:Drilnoth/lefteditlinks.js/doc. Thanks! –Drilnoth (T • C • L) 14:29, 20 June 2009 (UTC)

See also: User talk:Drilnoth#Gadget addition without discussion and Wikipedia:Administrators' noticeboard#Discussions need administrator closing, the former about my Gadget addition without a formal proposal and the latter about closing this as no consensus rather than "change". All comments at both are welcome. –Drilnoth (T • C • L) 18:22, 20 June 2009 (UTC)
Last I checked (I didn't count the recent additions), it was 3:1 in favor. Is that not consensus? How is it no-consensus when the issue of whether encouraging editing should be a priority (upon which many oppositions depend) hasn't been adequately discussed? (It is a priority, by the way - why do people think all that money's going to the usability study?) Defaulting to the current interface on usability or aesthetics is often a bad idea (there's that story of ebay having to slowly fade out its (ugly) yellow background because users complained when they got rid of it in one go).    M   08:53, 26 June 2009 (UTC)
I get about 40 support and 19 oppose total (counting the section since the last Pollster and assuming that Pollster was accurate for everything prior). --Cybercobra (talk) 21:41, 26 June 2009 (UTC)

Provide "New Section" header box on virgin talk pages

If you look at many discussion pages, you may have noticed that the first section-heading is often preceded by what looks like disorganized random chatter. The likely reason for that just struck me today. When you visit an empty talk page, for example Talk: Crotona Park, it just invites you to start a discussion.

A new user with a question or comment on her or his mind might just start typing the substance without thinking of giving it a title (or perhaps even knowing how). This is different from what the "New Section" tab shows and similar to what happens with a new article, which we want to start with an untitled lead paragraph (something that doesn't apply to most talk pages). "New Section" does provide a box for section headers, but that's actually slightly less necessary when earlier sections show editors an example and a method. Is there some way we could open empty talk pages with a section-header box, or at least instructions for how to enter "==[title]==" to start the first section? —— Shakescene (talk) 22:08, 2 June 2009 (UTC)

Support I just had to clean up such a talkpage conversation earlier today. --Cybercobra (talk) 22:48, 2 June 2009 (UTC)

[Further info]: This is the greeting at the (now-empty) Talk:Crotona Park:

Editing Talk:Crotona Park

From Wikipedia, the free encyclopedia

Wikipedia does not have a talk page with this exact title. Before creating this page, please verify that a subject page called Crotona Park exists.

* To start a page called Talk:Crotona Park, type in the box below. When you are done, preview the page to check for errors and then save it.

This is a talk page. Please respect the talk page guidelines, and remember to sign your posts by typing four tildes (~~~~).

...Comment: Even should we do nothing further (which I strongly believe we must), at least the last instruction should not be "To start a page called Talk:..., type in the box below" unless the box is changed to something closer to a "New Section" page. Otherwise, eliminate the box and instead direct the user to the "New Section" tab. (For example, "To start a page called Talk:..., please open the "New Section" tab above this panel.") —— Shakescene (talk) 03:09, 3 June 2009 (UTC)

I like the idea: it's definitely a problem; this is a solution. One little thing though - if all to start the page is a WikiProject, then this needs to be taken into account; on the other hand, if there's only WikiProject headers then you'll still need this thing (I think). Good idea generally though. - Jarry1250 (t, c) 20:37, 4 June 2009 (UTC)
I'm sorry, but I don't think I quite understand what you're trying to say. —— Shakescene (talk) 06:17, 11 June 2009 (UTC)
It's a good point about the WikiProject headers, which may have been placed in otherwise empty talk pages: any solution needs to take that into account and not just kick in for "virgin" talk pages per the proposal. PL290 (talk) 19:18, 12 June 2009 (UTC)

Support At minimum, the extensive, yet deficient, instructions that appear, as shown above, should be updated to the requisite effect, but ideally the system should automatically bring about the conditions under which the user, by default, starts a section when none is yet present (while also continuing to provide the means for WikiProject headers etc. to be added without creating a section). True, it would be easy enough for someone in the know to add a single section header later, on encountering the page, but by that time any number of separate conversations may have been jumbled together. PL290 (talk) 19:18, 12 June 2009 (UTC)

Support There should be a button there just like any other talk page. Reywas92Talk 17:52, 11 June 2009 (UTC)

Slightly different proposal - How about instead of just adding a tab (which is a good idea anyways), the default is set to New Section? See http://en.wiki.x.io/w/index.php?title=Talk:Crotona_Park&action=edit&redlink=1&section=new . Adding that &section=new to the default redlink will create the section title. People who are simply adding templates can click back on the edit tab. ▫ JohnnyMrNinja 18:23, 12 June 2009 (UTC)
I think that would quickly get extremely annoying for many users. Happy‑melon 18:40, 12 June 2009 (UTC)
No, that would get really annoying. – iridescent 18:42, 12 June 2009 (UTC)
I hesitate to say it, but no, that would actually get annoying. PL290 (talk) 19:18, 12 June 2009 (UTC)
I'm confused about what's so annoying (regardless of whether this is the best particular solution). Is it that it would greatly complicate the addition of Wikiproject, rating and other tags at the top? —— Shakescene (talk) 19:09, 13 June 2009 (UTC)
I don't see the annoyance either. I mean, talk pages are for talking, right? Wouldn't logic dictate that we should make it as easy as possible for new editors? I admit that I've added a lot of project banners to blank pages (I think my average edit-per-page is like 1.5). I've spent a fair amount of time simply hitting random until I see a page with a redlinked talk page. I can safely say that I wouldn't find it annoying to have to hit edit to add a template to a talk page. That's what you have to do to any other page, right? How would this be different? Maybe I'm confusing the reasoning, but is the feeling that talk pages should be optimized for adding templates rather than comments? ▫ JohnnyMrNinja 05:41, 15 June 2009 (UTC)
Note that the new section tab is already there on new talk pages. Mr.Z-man 05:56, 15 June 2009 (UTC)
  • I do not think that this is particularly important. For example, for, I would say, most new talk pages (Pokemon, BLP, and Stephen what's his name), all you are adding is a talkheader, and there would be considerable confusion if you were given a section heading that you did not want. However, has anyone noticed (duh it is probably in the perennial section), that when you do click the "new section" tab, it is impossible to add an Edit summary, even if you click "Show preview"? 199.125.109.124 (talk) 19:59, 26 June 2009 (UTC)
    • I don't think you fully understand the problem. It's far from the most-urgent issue in Wikipedia but it's still real. A large number of talk pages (perhaps a majority) begin with unorganized clutter, often on several different subjects and in apparently random order, without any indication of their topic. And, unlike a box you can fill in yourself, the "talk header that you did not want" often gets imposed (sometimes years after the original posting) by frustrated editors like me who are trying to make some kind of logical, readable order from the talk page. The absence of an edit summary in new sections is something I've also noticed, and might well merit a separate section on this proposal project page. —— Shakescene (talk) 07:33, 27 June 2009 (UTC)

structuring a straw poll

¶ Just to keep this section from getting bot-archived without resolution, I was thinking of creating a straw poll here, and then using the results to form a more-formal Request for Comment (with attached technical requests). I was going to break the poll into:

  1. leave things as they are,
  2. leave things as they are, but with guidance to the "New Section" tab,
  3. leave things as they are, but with instructions about creating a "==[New section]]==" header,
  4. change the virgin (or open) talk page to include an automatic new section letterbox, as in Johnny's "Slightly different proposal" above,
  5. any other suggestions.

Would this be a good format for a straw poll, or does anyone have other ideas? —— Shakescene (talk) 07:18, 21 June 2009 (UTC)

Quality awareness

In the past I have seen the idea kicked around of putting WikiProject assessment ratings onto the article page, but I don't ever recall what the consensus was, and it has been some time ago. As some editors know, there has been a handy gadget for sometime which allows ratings to be turned on in the mainspace as an option in your preferences:

Display an assessment of an article's quality as part of the page header for each article. (documentation)

I personally find it quite handy to be able to quickly identify the reliability and quality of the article I am reading. Has anyone ever considered turning this on as a default setting to all users? This is not necessarily a proposal, but more of a “have you ever considered this?”

Almost everyone I know has used wikipedia! Even old people! But there is one common theme amongst them all, they always say: “How can I trust what is on there? Everyone edits it.” The most persuasive answer I have always found has been to explain to them the WikiProject rating system, and how certain levels receive peer reviews, and project reviews, and a community review. When they understand what has to take place for an article to get a gold star or a green plus mark, for example, they realize they can have more faith in the article than if it was a C or a B class. When I have told people about this, they are usually amazed that such a thing exists. Most readers (by my conjecture) never go to a discussion page, and very few are aware it exists. I personally believe, IMOSHO, that raising awareness of our rating system among our readers is one of the greatest things we can do to shake the prevailing public image that “you can’t trust Wikipedia.”™

I truly believe our project would benefit from placing article ratings, in some fashion, on the article page. We use the ratings for the CD version of the encyclopedia to identify quality articles. We give FA class articles a gold star, so why not give something for other ratings? Implementing such a thing in the mainspace would of course be of little value unless we also created something to quickly and easily and concisely (meaning in less than 100 words) that would explain to our reader what our rating system means to them. There are many ways such a system could be created, and I have several ideas of my own. —Charles Edward (Talk | Contribs) 18:21, 22 June 2009 (UTC)

Question

My question for the community is this:

Do you support raising awareness of the WikiProject rating system among our readers?

My secondary questions are, what is the best way to do this? and Do you believe this would help in the public's perception of Wikipedia's quality and reliability? I believe this is a discussion worth having.

  • Seems logical to me to do this the same way as with the gadget. It takes up more or less no additional space, and I can't see any negative effects... it might help readers to learn more about our quality guidelines by seeing which articles we rate higher. However, some more intelligible names might be nice on the main page... something like Stub, Start, Average, Above-average, Good, Excellent, Featured, maybe? The current names would be confusing to people who don't even know that we have such a rating system. –Drilnoth (T • C • L) 18:33, 22 June 2009 (UTC) Neutral, after seeing some of the comments below. –Drilnoth (T • C • L) 22:32, 22 June 2009 (UTC)
  • Support - I like the idea, it is helpful and is expanding on the FA icon that is featured on FA articles. --Jeremy (blah blah) 19:16, 22 June 2009 (UTC)
  • Oppose for the same reason this proposal is always opposed. Featured Articles go through a consensus-based process with lots of checks and balances and are under constant scrutiny as long as they're at FA level; every other rating is the result of a single – arbitrary – value-judgement by a single reviewer. Advertising GA or B class articles as "quality" could (and would) give a misleading impression of accuracy and neutrality. – iridescent 19:22, 22 June 2009 (UTC)
  • I would oppose this. Due to the way most pages are rated after only a cursory review, anything below GA is just an arbitrary grade. Mr.Z-man 19:29, 22 June 2009 (UTC)
  • I agree somewhat with Drilnoth: were this to be implemented, the existing gadget does the job well. I started using that gadget as an experiment to see what it was like, and found it to be quite useful. Now, while on the one hand it would be good if more people were aware that we at least have a rating system, I think it might also be confusing to people, since people will confuse completeness and review with accuracy. That confusion might negate the potential for positive PR, since people might get the idea that B-class and lower articles (which form the vast majority of our content) are not entirely accurate (when the reality is that they merely need expansion and review). I support this in theory, but I can certainly accept the status quo. {{Nihiltres|talk|edits}} 22:08, 22 June 2009 (UTC)
  • As nice an idea as this is, the nail in the coffin for me is brought up above - FA is the only quality class that goes through any kind of rigorous evaluation process. Unless and until a more universal process can be adopted for other quality classes, they remain worthless as an indicator of quality to the reader. Shereth 22:41, 22 June 2009 (UTC)
    What about A-Class articles? At least at WP:MILHIST these are comprehensively reviewed in a manner comparable to the FA process? Cool3 (talk) 22:56, 22 June 2009 (UTC)
    Too confusing; AFAIK no project other than MILHIST uses A-class (the sprawling WP:LONDON, for example, has a grand total of one A-class article, and even Category:A-Class United States articles contains only seven entries) – the difference between MILHIST's assessment scale and the rest of Wikipedia is most obvious on articles like American Civil War which are A-class for MILHIST purposes but GA-class for every other project. We can't expect our readers to understand that there's one project that uses a different assessment scale to everyone else, let alone try to depict it via 20-pixel icons. – iridescent 23:05, 22 June 2009 (UTC)
    There's 472 A-class articles, of which 187 (40%) are via MILHIST. This is certainly disproportionate, but it does indicate that other projects are beginning to use it as well. (That said, I've personally never quite got the position of A-class - in many ways, between GA and FA, it seems to be a rating in search of a role...) Shimgray | talk | 23:39, 22 June 2009 (UTC)
    I have to disagree just a bit. While ratings stub through B are somewhat artbitrary, would anyone disagree that articles rated B are on average better quality and reliability that articles rated start? Likewise, on average, are not articles that pass a GA of better quality and more reliable than a C class article? Sure there are exceptions and it is not a perfect system, but in most cases the ratings to demonstrate a valid assessment of the quality of the article. Just because they are arbitrary does render the assessment without value. If the ratings are good enough to help identify the articles going onto the CD version of the wikipedia, then aren't they also good enough display to our average reader? And as long as a reader understands the source of such ratings, B or GA class, then how could we be misrepresenting anything? The point is not say certain ratings are completely trustworthy, it is to say, that some articles are generally more\less trustworthy than others. —Charles Edward (Talk | Contribs) 04:24, 23 June 2009 (UTC)
    I suppose that readers who "understands the source of such ratings" are sufficiently qualified to check talk pages and have their own opinion on the weaknesses of the system. Readers "from the cold" don't have this knowledge; force-feed them all the disclaimers, they still won't feel how it works. NVO (talk) 06:29, 23 June 2009 (UTC)
  • Oppose per Iridescent. –Juliancolton | Talk 23:28, 22 June 2009 (UTC)
  • I've been arguing for what seems ages now in favour of a GA green dot, but I've come to accept that it just ain't gonna happen. GA, whatever its perceived faults, does at at least have a standardised set of criteria, which isn't the case for anything else other than FA. For me, only three ratings make sense: GA, FA, and the rest. Anyone who wants to see article ratings can register an account and switch on the relevant gadget from their preferences. --Malleus Fatuorum 23:36, 24 June 2009 (UTC)
    • I pretty much agree with you there. The GA criteria are well defined and most GAs have a minimum quality level; I don't see why we shouldn't show them to the readers. The other, more subjective, classes, however, should not be shown by default to readers who don't fully understand the system. –Drilnoth (T • C • L) 23:41, 24 June 2009 (UTC)
      • I wouldn't be passionately against a green dot for GAs – although I suspect the end result would be a flood of poor-quality GA nominations and back-scratching, as everyone tried to get recognition for their pet article – but as per my comments above, I'd be very opposed to any of the other (completely arbitrary) ratings being displayed. (Ideally, I'd love to see the GA process restructured to get independent reviews from two separate editors, but that's got a hell/snowball chance.) – iridescent 19:33, 25 June 2009 (UTC)
        • Iridescent hits the nail on the head (if somewhat obliquely) as to why I would be opposed to even GA appearing on an article. For as much as there exists some kind of standard set of criteria, in the end it still boils down to a single judgement call as to whether or not an article actually meets said criteria. I'd like to assume that every volutneer reviewing GA nominations makes a correct assessment every time, but the fact that an assumption is necessary tells me that the use of GA as a reliable criteria that we present to end users is not yet a good idea. Shereth 19:48, 25 June 2009 (UTC)

Default languages

I would like to suggest an option to display languages of preference on top under the languages. This would be very handy because most people use most often their own language and only a few others (most English). It should be an addition, so all the languages are also still displayed in the list.

This is the English Wikipedia, so it is prefered that everything is written in English here. By the way, didn't you forget something? PCHS-NJROTC (Messages) 20:58, 25 June 2009 (UTC)
Much of the interface can be changed by going to Special:Preferences, but most all content on this site should be in English. If you want articles in other languages, look in the sidebar on articles and see if there are any links to other languages there. –Drilnoth (T • C • L) 21:01, 25 June 2009 (UTC)

Obviously, I didn't formulate my question right. So second try: I would like to suggest an option on all the articles on Wikipedia. By example on http://en.wiki.x.io/wiki/Monkey there is a list of many different other languages which could be selected. If your second language is German you have to search the whole list (although it's not that work) for 'German'. If Wikipedia should track the languages you (the individual user) use most often, these could also be placed on top of the language list. Especially when you use Wikipedia a lot this could save some time.

Under My preferences there is indeed an option Internationalisation. By example, it would be handy to be able to add here your second languages which are then placed on top.

The English Wikipedia is off course the most complete. But for people from the Netherlands it's most times more convenient to read first the Dutch Wiki, and afterwards the English one. So especially for the Non-English Wiki's it would be handy. Do all the Wiki's have the same frame and only a different language packet or are they really different (by example they also differ in the options under preferences)?

I hope my question became more clear now. LvD (talk) 07:20, 27 June 2009 (UTC)

Creating redirects with bot

Please, check this Wikipedia:Bots/Requests for approval/BOTijo 2 (again). emijrp (talk) 15:46, 25 June 2009 (UTC)

RE: Disabling "create a book"

Resolved
 – ThemFromSpace 21:33, 26 June 2009 (UTC)

I notice the "Create a book" sidebar is back, although it was removed with strong consensus to do so after a discussion here back in May. Was there ever a discussion on whether to reenable the sidebar? Have any of the concerns at the previous discussion been addressed? ThemFromSpace 21:09, 25 June 2009 (UTC)

Seven sections up, see here. Cenarium (talk) 19:49, 26 June 2009 (UTC)
Thanks for pointing me there. Marked as resolved. ThemFromSpace 21:33, 26 June 2009 (UTC)

Second draft of updated arbitration policy

The Committee has prepared a second provisional draft of an updated arbitration policy for community review. All editors are invited to examine the text and to provide any comments or suggestions they may have via one of the two methods specified on the draft page.

Release of this draft was approved by an 8/1 vote, with no abstentions or recusals:

  • Support: Carcharoth, FloNight, Kirill Lokshin, Newyorkbrad, Rlevse, Roger Davies, Vassyana, Wizardman
  • Oppose: Casliber
  • Abstain: None
  • Recused: None
  • Not voting: Cool Hand Luke, Coren, FayssalF, John Vandenberg, Risker, Stephen Bain

For the Committee, Kirill [talk] [pf] 16:03, 25 June 2009 (UTC)

Create a more nuanced policy towards the use of the {{hidden}} template in articles

I stumbled upon a casual discussion indicating that it's not proper to use the Hidden or Collapse templates to integrate content into articles; this feeling is shared by an experienced editor I spoke with ("Wikipedia never uses show/hide boxes in the middle of articles. Content is either part of the prose properly or shouldn't be included at all."). His position certainly makes sense, but my feeling is that this rule deserves to be broken for certain articles -- generally speaking, articles that perform a thorough close reading of primary sources; more specifically, articles on court cases. I have experimented with this method (somewhat clumsily) here, and (even more clumsily) here.

I have three distinct reasons for desiring this style in articles on legal cases.

1) (least good reason) A reader will find it slightly more efficient than embeded citations using our (otherwise commendable) "ussc" template, 458 U.S. 654.
2) (good reason) Court cases are full of citations, which are readily converted into wikilinks. (Professional services do it automatically; e.g. here); I have done it here.) If we incorporate the text of cases into Wikipedia articles, lawyers will be able to use the "what links here" function to do legal research; they will also be able to jump within wikipedia using these wikilinks.
3) (best reason) The paid, professional legal-aggregation services (Lexis-Nexis & Westlaw) use a system similar to this. On Lexis-Nexis, when you view a case, its body text is preceded with a professionally-written summary; each sentence of that summary includes a hyperlink that drops you down to the paragraph being summarized. (You can see what I'm talking about using their demo at http://web.lexis.com/help/multimedia/case_law_summaries.htm).

I've invited contributors at Wikipedia:WikiProject_Law and Wikipedia:WikiProject_U.S._Supreme_Court_cases to join this discussion.
Thanks. Agradman appreciates civility/makes occasional mistakes 01:56, 25 June 2009 (UTC)

Are you aware of WikiSource, which seems more appropriate for the full copies of these court decisions? Or if they're not free content, we shouldn't be including them wholesale in the article either. Anomie⚔ 03:37, 25 June 2009 (UTC)
Whoever this experienced editor is, I agree with him or her. If content is worth including, it should not be hidden. If it is so tangential that it ought to be hidden by default, there is a high chance it does not belong on an article. Our articles are meant to imitate those of scholarly encyclopedias; long excerpts such as those in [1] are out of place in such a work. Our goal is to summarize these sources and convey the important information; readers who want to read the original need to do so elsewhere. — Carl (CBM · talk) 03:43, 25 June 2009 (UTC)

CBM, the problem is that this content is not "so tangential that it ought to be hidden by default" ... it's not tangential at all, it's all important, because the quotations from primary sources are the essence of credible legal arguments. The problem is that cases are very lengthy, and often deal with multiple issues.
I'm worried that this proposal won't get a fair shake until the legal professionals start arriving ... I've poked some wikipedia lawyers and I'm hoping they'll stop by ... Agradman appreciates civility/makes occasional mistakes 04:59, 25 June 2009 (UTC)
Wait, let me clarify. You also said "if the content is worth including, it should not be hidden." If there were any other way to integrate 50 paragraphs of text into the "Roe v. Wade" article, I'd do it. The problem is that the article would get too choppy. Anomie, I'm aware of Wikisource. but it doesn't serve any of the three advantages I've cited above. Agradman appreciates civility/makes occasional mistakes 05:04, 25 June 2009 (UTC)

I'm not sure I get exactly what it is you are proposing, but I'll chime in to note that all court decisions are in the public domain in the U.S., and that courts frequently give thorough and well-researched explications on the principles of law before them, so we would benefit from copying such sections of court opinions pretty much wholesale as articles on those doctrines. I'd rather supplement the court tendency to cite primarily other court decisions by adding references to legal texts supporting the various points (where this is convenient), but these pieces do come to us otherwise already fully sourced. bd2412 T 05:13, 25 June 2009 (UTC)
Re Agradman: You have not clarified why you must copy long quotations from the sources, instead of simply citing them. Our task is to summarize the cases, not to repeat them verbatim; this is no different than any other field. We are not trying to write a legal textbook.
Regarding Roe v. Wade, I am certain there must be enough published secondary sources that it is not necessary to quote 50 paragraphs of the original decision there. — Carl (CBM · talk) 05:14, 25 June 2009 (UTC)
I feel it is the best policy to avoid extensive hidden templates, footnotes, and information. In other words, appropriate hidden text might include categories and short comments of up to 20 words. Anything other than that needs to have a very strong rationale. An exception I can think of is Harvey Milk, which needs all sorts of hidden templates and longer footnotes, in part because of the nature of the man and his legacy. Bearian (talk) 14:35, 25 June 2009 (UTC)
I agree with Carl on this one. To respond to each of the 3 reasons:
1) I doubt they'll find it so much more efficient if they're on a dialup modem or a mobile browser and have to wait while they download an extra 50 KB or so of text, or if they're using a screen reader.
2) This is best done by Wikisource where they have the full text of the decision and won't "pollute" the whatlinkshere with less-relevant articles. And as Carl said, we are not a legal textbook.
3) We aren't a legal-aggregation service, we're an encyclopedia. A legal aggregation service is a secondary source, we're a tertiary source.
-- Mr.Z-man 16:00, 25 June 2009 (UTC)
I think the only policy we need on the use of the hidden template in articles is "Don't." DreamGuy (talk) 16:06, 25 June 2009 (UTC)

OK, I've linked to this discussion at Template_talk:Hidden#Within_article_text. I'd appreciate it if someone would write a sentence about this in one of the Guidelines pages. Wikipedia:Layout, perhaps.

This problem will have to be solved by the website that's hosting our caselaw. For example, the hyperlink in 386 U.S. 213, 215 (1234) might automatically scroll down to page 215 and highlight that page; same could apply for paragraphs. Agradman appreciates civility/makes occasional mistakes 19:18, 25 June 2009 (UTC)

I really would appreciate if someone would please insert this conclusion into a guideline/policy somewhere, so that it can be viewed by the larger community of Wikipedia editors. Currently we have no policy except the personal preferences of individuals. I don't feel comfortable doing this myself (having recently survived a gauntlet just to change the syntax in Wikipedia:Layout Agradman appreciates civility/makes occasional mistakes 18:42, 26 June 2009 (UTC)
MOS:SCROLL. Happy‑melon 19:31, 28 June 2009 (UTC)

moving the menu

Hi!

I'm Iivari Mokelainen, from Finland - a fan of wikipedia. I was reading wikipedia this one time (i do it tens of times a day) and i noticed that if the article is long enough to span on many pages, there is very much space wasted.

The menu on the left (with languages and other links) is on the side, and there is nothing under it I think its a really big concern, especially for small screen users. Moving the menu on the top, and having the language menu as a drop-down list would make the wikipedia not only more usable, but also more estetic. There would be a lot more space for the article, the page would be less cluttered, and well, lets face it, side panels are really oldfashioned in current modern "web 2.0" internet world.

Thank you, cincerely yours,

iivari.mokelainen

White space on a page is important for readability among other things, so I don't think it should be removed. Perhaps there's a skin that would help people to choose this kind of effect if they desire it? PL290 (talk) 16:21, 26 June 2009 (UTC)
This is a matter of taste and of the size of your monitor. If it's a problem for you, you can solve it when you are logged in: Click on "my preferences" at the top of the page, then choose the "Appearance" tab. Here you can choose between several skins. The "Chick", "MySkin" and "Nostalgia" skins do what you want. Look at WP:Skin, which has screen shots of each skin that make it easy to choose the right one for your taste without too much experimenting. Hans Adler 17:41, 26 June 2009 (UTC)
See Help:Mobile device --Nopetro (talk) 11:50, 29 June 2009 (UTC)

Edit head

I suggest inclede a link in the top of the page to edit the lead section of the article. There are troubles when editing the lead section of an article= the user must edit all the article (cannot edit only the lead section). This causes problem when editing in an iphone or mobile device (i.e. Nokia 5800), because the article can be cut and dissapear some sections, because the entire article is too long (ie can dissapear the external links, references, see also... sections). Also is difficult include a new section (the "enter" or "new paragraph"character does not work and also nor the new paragraph tag ). Can we include a Javascript button in the edition toolbar for this?. Regards.--Nopetro (talk) 10:50, 28 June 2009 (UTC)

Preferences -> Gadgets -> User interface gadgets -> Add an [edit] link for the lead section of a page. Ruslik_Zero 11:37, 28 June 2009 (UTC)
Thank you a lot ;-) --Nopetro (talk) 11:49, 29 June 2009 (UTC)

Most (if not all) wikilinks that lead to a disambiguation page are unintentional. It's all too easy to accidentally create one while editing. Wikipedia has redlinks for non-existent pages; how about introducing a new link appearance for wikilinks that lead to a disambiguation page? Unintentional ones can then be seen and fixed much more quickly, perhaps even during preview before ever being saved. One idea would be amberlinks, as long as they're distinctly different from redlinks. Otherwise, perhaps background shading or some other effect that draws attention. PL290 (talk) 13:16, 25 June 2009 (UTC)

Like this User:Dschwen/HighlightRedirects? OrangeDog (talk • edits) 13:24, 25 June 2009 (UTC)
I'd prefer a message, like the one that is left if you add the first citation to an article before adding a reflist. I don't think users of the article should have to see a new color and wonder what it means - it is intended for the editor. While the proposal above may be nice - it requires every interested editor to install - this should be a MediaWiki funtionality, not something every editor needs to install.--SPhilbrickT 14:07, 25 June 2009 (UTC)
Agree about MediaWiki funtionality, not something every editor needs to install. A warning message sounds like a useful train of thought for the highlighting. Not a message that appears when the saved article is displayed though, such as "Cite Error: Invalid <ref> tag; no text was provided for refs named [...]". Especially since, due to page moves, a title could later become a disambiguation page, causing such error messages to appear in existing pages. I suggest something akin to the optional "missing edit summary" warning; so that when you try to save, you first get a warning if the page contains links to any disambiguation pages. But I still think a different link appearance would be good in addition to the save warning. The user isn't hurt by seeing redlinks and wondering what they are. PL290 (talk) 15:59, 25 June 2009 (UTC)
I agree with your modification of my suggestion - I've always addressed missing Notes sections, so I didn't realize the message would persist if I saved without addressing it - I agree it should be a temporary warning, not permanently saved. As an aside, I do find the redlinks annoying, but try to avoid complaining until I have a plausible solution - I don't yet, but adding yet another color would just make matters worse.--SPhilbrickT 17:00, 26 June 2009 (UTC)
What you are asking for is creation of an additional CSS class: 'mw-disambig'. Currently links to redirects are marked with 'mw-redirect' class, which makes it possible to customize their appearance. If 'mw-disambig' class is added every link to a dab page will generate the following HTML code (for Jupiter (disambiguation)):
<p><a href="/wiki/Jupiter_(disambiguation)" class="mw-disambig" title="Jupiter (disambiguation)">Jupiter (disambiguation)</a></p>
The 'mw-disambig' class can be defined, for instance, as color:cyan, which will make all such links cyan in color. Ruslik_Zero 09:33, 26 June 2009 (UTC)
Or you could just use a user script to add those kind of classes. Anomie⚔ 11:03, 26 June 2009 (UTC)
If links to redirects are already marked with 'mw-redirect' class, then creation of the 'mw-disambig' class is indeed exactly what I'm asking for—plus (which I think Ruslik already intends), for the default css to define it as cyan etc, because the point of the proposal is to bring about the functionality described without editors needing to take special action—be it clicking a new tab to start a checking process per User:Dschwen/HighlightRedirects or customizing their css/javascript. What I am proposing is that it would benefit WP if such errant wikilinks were drawn to the attention of all users, not just those who choose (and remember) to check. Currently this is the case for redlinks and so there appears to be no reason why it should not be the case here too. PL290 (talk) 12:29, 26 June 2009 (UTC)
As an inveterate disambiguator, I love this idea. Anything that makes it more likely that article creators will catch their own errors, without interfering with the experience for our readers, is a good thing. Mlaffs (talk) 15:55, 26 June 2009 (UTC)
I like the idea of being able to highlight links to disambiguation pages. I don't think this is something that should be forced upon every editor (as with some sort of warning message). Repairing links to disambiguation pages, while relatively easy to do, is also not something every editor will be interested in doing. older ≠ wiser 16:09, 26 June 2009 (UTC)
And what about intentional links to disambiguation pages like in hatnotes? And this would not be very easy to implement in the software in an efficient enough way that it would be acceptable for Wikimedia. Mr.Z-man 16:17, 26 June 2009 (UTC)
My own thought about intentional ones is that it would be an enhancement. A different appearance need not equate to an ugly appearance, and can, like that of a redlink, convey information. Re. efficiency, the css approach suggested above by Ruslik sounds efficient, does it not? PL290 (talk) 16:33, 26 June 2009 (UTC)
Changing the outward appearance for links with a CSS class is not the difficult part, determining which links to set the class to is the difficult part. Mr.Z-man 16:51, 26 June 2009 (UTC)
Admittedly not knowing this software myself, I take it for redlinks there's some kind of lookup needed, to determine whether a page exists? A similar look-up could perhaps determine whether a page is in Category:Disambiguation pages? PL290 (talk) 17:01, 26 June 2009 (UTC)
Existence and redirect checks are both done with one simple query on the page table. Joining on the categorylinks table would essentially double the amount of processing needed per link. For a single link it would be a trivial amount, but many pages have thousands of links - existence checking is a very performance-critical code path. I'm also not sure how easily that could be integrated into the batch link checking used for the main body text of articles. If this is done though, I would oppose changing the default appearance of links to disambiguation pages. The vast majority of users don't edit. They care whether or not a link points to an article or nothing, but I can't imagine that they'd care very much that it would take an extra click to get to the correct page. Also, colors should be used sparingly as it can create accessibility issues for visually impaired users. Mr.Z-man 18:17, 26 June 2009 (UTC)
But the system already keeps track of dab pages. It should not be very difficult to check if the page is a dab, should it?. Ruslik_Zero 08:32, 27 June 2009 (UTC)
It doesn't really keep track of them. It uses a list of disambig templates to determine if a page is a disambiguation page whenever the special page is updated. Whether or not a page is a disambiguation page is not stored in the database except indirectly via the categories and templates. Mr.Z-man 19:43, 28 June 2009 (UTC)
But then again, "Currently links to redirects are marked with 'mw-redirect' class" (which is true; I just viewed a page source to check). Doesn't this imply something very similar is already done? PL290 (talk) 12:47, 29 June 2009 (UTC)
The page table contains 'page_is_redirect' field that indicates if a page is a redirect. There is no field to indicate that a page is a dab. Ruslik_Zero 19:13, 29 June 2009 (UTC)

Articles for Deletion needs more automation

The AfD process is still very manual, requiring at least three manual edits per AfD. The "prod" process and the Wikipedia:Requested moves process are now semi-automated - there, one template on the page of interest does the job. All the appropriate list pages are updated automatically.

I'd suggest using the Wikipedia:Requested moves machinery for Wikipedia:Articles for Deletion. One template on the page starts the process, and everything else is updated by a 'bot. This will make the process much simpler for users. --John Nagle (talk) 19:25, 26 June 2009 (UTC)

  • Well, there won't be any way to get around the fact that at least two edits have to be made - one to tag the article in question and one to create and start the actual page. Automating the listing on the actual AfD log wouldn't be too terribly hard to implement at all and I would happily support an effort to do just that. Shereth 21:53, 26 June 2009 (UTC)
  • Twinkle helps very much for creating AfDs. Is there any way the programming behind that could be implemented on Wikipedia? On the other hand, a big "delete this page" button on the top of every page such as what Twinkle produces will encourage misuse of AfDs from editors unfamiliar with the process. Another question would be, can we have a template which, when used, automatically creates a page on Wikipedia? This could have some issues with cleanup since if a user removes the tag and gets reverted, another AfD page would be created. Perhaps a parameter could be added onto the tag, such as {{afd|2}} which specifies a specific page to be created? I'm still not sure if that could work out though. I can imagine scenarios where AfD pages are created on top of one another or out of order if due care isn't given to watch out for those situations. In the end, it seems best to manually create the afd page and tag the article seperatly, unless one chooses to use a script like Twinkle.ThemFromSpace 22:19, 26 June 2009 (UTC)
  • There's a reason that AFD isn't a simple drive-by tagging process. In years gone by, vandals used to enjoy trying to tie us in knots with our own processes with drive-by AFD taggings. The hurdle for a nomination to be complete is deliberately not low and is deliberately higher than a simple drive-by tagging. (A comparison to Proposed Deletion is an ill-chosen one, moreover. Proposed Deletion is intentionally different to AFD.) Moreover: Only one of the three edits adds anything to a list page. The edit to the per-article sub-page includes the nominator's rationale for nomination, which of course cannot be automated. We took to rolling back incomplete AFD nominations by drive-by taggers where no sub-page was created and no rationale given (on a page or in an edit summary), in light of the vandalism.

    On the converse, DumbBOT does a good job of rescuing incomplete nominations that have nomination rationales, but that aren't listed on per-day sub-pages. There's really nothing to do here that isn't already being done. In part, this is because this is a perennial proposal, that has come up before (on the talk pages of the templates as well as at Wikipedia talk:Articles for deletion), along with editors pointing out the past experiences that we have had with abuse by vandals when the hurdle is made too low, either by 'bots or by the actions of well-intentioned editors completing incomplete nominations where only a tag was applied. Uncle G (talk) 11:59, 30 June 2009 (UTC)

"Remember me for __ days"

On the login screen, I want it to "remember me" for only 2 weeks at a time. I'd be curious to see if we can add a drop-down list of some sort to allow people to choose the amount of time they'd like "remember me" to remember them. Would this be possible? iMatthew talk at  01:02, 1 July 2009 (UTC)

It's possible, but the devs are going to want to see some good reasons before they think about implementing it. Algebraist 01:10, 1 July 2009 (UTC)
Well, I often use computers that are not my regular one. I want it to remember me for the time that I'm using it (5 days for example when I stay at my parent's house next week). I want to check "remember me" but that's for 30 days, and I only want it to remember me for 5 days. iMatthew talk at  01:21, 1 July 2009 (UTC)
Why not just log out when you've finished using the computer? Algebraist 01:26, 1 July 2009 (UTC)

usage of pagination + limit on size of pages

This is a suggestion for improvement. It would be good to impose or recommend some limit on the size or length of Wikipedia pages. For mobile users, big pages are problematic. Long articles have to be paginated. Thanks for considering this post. Louenas

Our current guidelines are at WP:SIZE. You can discuss potential changes on the talk page. Algebraist 20:59, 1 July 2009 (UTC)

Pronunciation to foreign place infoboxes

Apologies if this has been posted in the wrong place, but regularly, when I visit an article on a foreign (I mean non-English-speaking country) town or city &c., I look for the native pronunciation of the place concerned. As a simple example, Paris has as its first sentence "Paris (pronounced /ˈpærɪs/ or /ˈpɛrəs/ in English; [paʁi]ⓘ in French) is the capital of France and the country's largest city." But the majority of places do not have such a sentence in the lead. Although it may be a rather tedious process, would it be out of the question to introduce native pronunciations to infoboxes of place articles, with the pronunciations underneath the place name, maybe in a smaller font size so as not to look too conspicuous? 79.71.5.38 (talk) 19:48, 28 June 2009 (UTC)

You probably need to discuss this on some infobox template talk pages. ---— Gadget850 (Ed) talk 19:26, 29 June 2009 (UTC)
That's an interesting idea; I've got to get going, right now, but I'll see if I can find an appropriate talk page later, if no one has by then. – Luna Santin (talk) 23:58, 30 June 2009 (UTC)
Cross-posted to Wikipedia talk:WikiProject Infoboxes#Pronunciation field in infoboxes?. – Luna Santin (talk) 21:07, 1 July 2009 (UTC)

Bots fixing redirects in navboxes

When a navbox contains a redirected link, it is displayed in purple when you are on the page it redirects to, as opposed to bold, black text (not linked) if it had been a direct link. It seems to me that the task of fixing these redirected links in the navboxes to point to the page itself (by piping it) is something that a bot could be able to do. So if such a bot task doesn't already exist, I make a proposal about it. Iceblock (talk) 18:31, 1 July 2009 (UTC)

I'm neutral on this, since I have a userscript that highlights self-redirects anyway. Bringing it here first is a good idea, as such a bot needs a strong community consensus before being approved. Anomie⚔ 02:08, 2 July 2009 (UTC)
I'd really like to see this bot. This is one of the exceptions at WP:R2D that should be fixed, as it causes confusing self-linking-redirects. –Drilnoth (T • C • L) 02:15, 2 July 2009 (UTC)

Three (instead of four) template warnings for users before reporting

Based on my brief vandal-hunting experience I think that the current warning system issues one too many warnings to users before blocks are issued. Once a user gets a L-3 or an L-4 warning for vandalism for instance, that user's (normally a vandal) next target is usually the warner's talk page or user page in the form of userpage vandalism. More often than not, this delays the process in processing persistent vandals for blocking as they normally must receive four warnings for a block. I would propose lowering the number of warnings before sending to an admin-related venue (such as WP:AIV) from four to three along with slight adjustments in the wordings of the templates to accomodate that change. Any thoughts? MuZemike 23:02, 1 July 2009 (UTC)

Counting warnings is simple, but I can't say that I'm personally a fan of it as a primary heuristic for blocking. For quite a long time, now, I've held firmly to the belief that warnings are intended to bridge the gap between our need to assume good faith and our need to protect the project; we can allow users some time to experiment, to get accustomed to our rules and customs, sometimes even to act out negatively and learn the error of their ways, but sometimes (typically with vandals) it becomes clear that the user is intent on egregiously violating good faith to the maximum extent they can think to manage. Once that's clear -- sometimes that takes a few warnings, in rare cases like pattern harassment it's clear from the first edit -- I say block away. – Luna Santin (talk) 23:42, 1 July 2009 (UTC)
Per Luna Santin's comment, there's never been an obligation to give a certain specific number of warnings prior to issuing a block. Not four, not three — in egregious cases, not even one. We use common sense. I don't spend much (any) time at WP:AIV, but I certainly hope that they're not insisting on four warnings before blocking obvious vandals. The reason why we have four different warning templates is to allow us to 'tune' the warning message to the circumstances, not to compel vandal fighters to issue all four warnings. TenOfAllTrades(talk) 23:55, 1 July 2009 (UTC)
It is true, the degrees of warning are to deal with the different situations. Warnings are not required, just often the best way to go. Some admins at AIV will remove reports that don't have a full set of warnings, but AIV does things its own way. Chillum 23:56, 1 July 2009 (UTC)
¶ I don't think I've ever used one of those templates, because either
  1. (as with the nearly-identical IP attacks on Michael Bloomberg last month), there just didn't seem to be any point, other than procedural, to issuing such warnings, or
  2. when a warning was warranted, I preferred to wrap it into a general explanation of why I'm reverting something. The official authoritative style of the templates succeeds sometimes in scaring away malefactors, but just as often provokes a defiant rebelliousness that simply escalates the situation and wastes lots of time and heartache.
In a couple of cases of spamming, it seemed worth taking half an hour to compose an explanation of why a newcomer's well-intended contributions didn't fit Wikipedia. This stopped the edit war without the need for administrative action, and left us with someone who was well-intentioned towards Wikipedia instead of hostile. [Half an hour is a lot of wiki-time (especially for those working from a library or Internet café), but almost as much time would have been spent in posting warnings notifying administrators, arguing cases, stopping sock-puppets, etc.] See User talk:69.132.178.111 and User talk:Shakescene#Thank you. —— Shakescene (talk) 00:37, 2 July 2009 (UTC)
Of course, one doesn't necessarily need to go through lvl1, lvl2, lvl3, lvl4 and lvl4im warnings. It depends on the nature of the vandalism and the editors' edit history and block history. General experimenting of the "can I really do this" type as a first edit warrents a lvl 1 warning. If a first edit is adding a string of obscenities or similar I tend to issue a lvl 3 warning (yes, a bit harsh, but better to stamp it out early). Those with lots of previous blocks are likely to get a lvl4 or lvl4im warning. Further vandalism is then reported at WP:AIV for admin action. Mjroots (talk) 06:08, 2 July 2009 (UTC)
IMO the templates are useless because their wording is wimpish and inflexible. I use my own "template" which I paste in, with changes as needed:
==Vandalism warning==
[(diff) This edit] to [[(page)]] was [[wp:vandalism|vandalism]] - stop it or you will be blocked. --~~~~
Then whether I report it depends on the vandal's previous record as shown by his / her Talk page and contribs, and by the severity of the incident I'm dealing with. If I report, I may summarise the Talk page and link to contribs. --Philcha (talk) 06:20, 2 July 2009 (UTC)
"wimpish" is a good description for the spirit of our "esteemed vandal" templates. Perhaps they need an optional paramenter "testosterone=yes"? :) --dab (𒁳) 06:36, 2 July 2009 (UTC)

Change search message, please

If you search for a term that is not the title of an article (as in this), you get that remarkably chirpy message Create the page "Paradiso girls" on this wiki!. In bold. With an exclamation point. Phrased as a command. All this, despite the fact that the article has been deleted seven times and is create-protected. Can someone tone down the message to something more like There is no article by that name. Look over the search results below, and if you feel our coverage is inadequate, consider creating an article about the search term .—Kww(talk) 04:05, 3 July 2009 (UTC)

MediaWiki:Searchmenu-new is the relevant page. Algebraist 04:09, 3 July 2009 (UTC)
  • Changed to "You may create the page "[name]", but consider checking the search results below to see whether it is already covered." Stifle (talk) 08:16, 3 July 2009 (UTC)
I was going to say that given the number of deleted articles, that message which was there before seemed too encouraging to newcomers.Vchimpanzee · talk · contributions · 17:11, 3 July 2009 (UTC)
Well caught, I've thought about this before but never thought about actually trying to get something done about it. Dougweller (talk) 17:56, 3 July 2009 (UTC)

Do not delete before the New Pages Patrol has reviewed an article

Proposal: This is a request to allow the New Pages Patrol (NPP) to review an article before it is deleted and/or moved without a disambiguation. This means that the page cannot be marked as patrolled, and stays in the system for much longer, requiring a longer wait for articles that need to be reviewed. --Gosox5555 (talk) 12:48, 2 July 2009 (UTC)

Can't the problems be addressed by technical improvements to the patrolling feature? Deleted pages obviously don't need to be reviewed any more, so it's pretty pointless to mark them as patrolled. Kusma (talk) 13:10, 2 July 2009 (UTC)
NPP is just regular editors and admins. There's no real difference between the page being reviewed by someone on the list and someone who isn't. Mr.Z-man 14:20, 2 July 2009 (UTC)
Wouldn't the easiest thing to do just to be changing the software so deletion automatically counts as patrolling? I think it's safe to call a deleted page patrolled no matter what. Changing the patrolling software itself would probably be a lot more hassle. JohnnyMrNinja 19:31, 2 July 2009 (UTC)
Its all the same software. Whether or not a page is patrolled only means anything on Special:Newpages, and its removed from there once its deleted. Mr.Z-man 19:51, 2 July 2009 (UTC)
I thought the point was that these pages aren't being removed from the list? ▫ JohnnyMrNinja 19:54, 2 July 2009 (UTC)
They aren’t removed until they are clicked as reviewed on the pages. Most of the time these pages are just moved, not deleted.--Gosox5555 (talk) 21:23, 2 July 2009 (UTC)
A deleted page cannot be marked as patrolled because there's nothing to patrol. The "patrolled" status is only recorded in the recentchanges table (which is what newpages uses). When a page is patrolled, the page itself is not patrolled, just the recentchanges entry for the page creation. Mr.Z-man 00:38, 3 July 2009 (UTC)
Maybe my wording was confusing. I'm not saying that they should. If there was a way to mark a page as patrolled from Special:NewPages, that would solve my problem. Or if you didn't have to be coming directly from Special:NewPages to click the button. Is this possible? Gosox5555 (talk) 14:24, 3 July 2009 (UTC)


Even an admin on NPP should probably tag for CSD (except in obvious circumstances which I will not go into here) and allow another admin to carry out the article's deletion. The same goes for any other user, regardless of user rights. That's my take. MuZemike 07:22, 3 July 2009 (UTC)

Why is that necessary? NPPatrollers tag the article with a CSD tag and an admin reviews it later. An admin has the technical ability to delete it straight away. If an admin is pretty sure and not certain, tagging for a second review is fine, but to enforce a rule that all admins tag articles they patrol is a bit pointless in my opinion. PeterSymonds (talk) 07:43, 3 July 2009 (UTC)
MuZemike: you might want to gain consensus to change CSD then. "The criteria for speedy deletion specify the limited cases in which administrators may, at their discretion, bypass deletion discussion and immediately delete Wikipedia pages or media."
Gosox5555: I don't see any real benefit from this, and plenty of drawbacks. Stifle (talk) 08:12, 3 July 2009 (UTC)
(edit conflict) That's what I was getting at the clearly blatant stuff (such as copyvios, attack pages, or most things under the "G" criteria). I think I was more referring to the other CSD criteria, such as A7, R3, stuff that may possibly be more debatable. You're right that it would not be anything enforceable, as that's how the nature of CSD is. However, I think that the role of "CSD tagger" should not be intertwined with "CSD deleter"; that is, you're simply CSD tagging or you're simply CSD deleting without overlap (the WP:ADMIN policy is clear in that you obviously cannot do both to the same article). That's what I hope I mean, MuZemike 08:16, 3 July 2009 (UTC)
That is, not in close proximitity or in which the admin may be involved, of course. MuZemike 08:18, 3 July 2009 (UTC)
(ec)Well, on the limited occasions when I get to do NPP any more, I delete pages straight away when I'm clear that they are CSD-eligible, and tag them if I'm not all that sure. I don't tag a page and then delete it, but only because it'd be a waste of time. Stifle (talk) 08:19, 3 July 2009 (UTC)
And indeed, I don't (or try not to) do speedy deletions in the (limited) areas where I could be considered impartial. Stifle (talk) 08:20, 3 July 2009 (UTC)
To veer back on topic, I don't think NPP should be able to patrol before a deletion occurs, as many articles fall through the cracks anyway. Furthermore, many users to tag NewPages for CSD also use Twinkle which automatically patrols the page right there. Assuming good faith, the tagger has already effectively patrolled that article. I cannot see what else that would need to be done besides go on regular editing/improvement of the article should the CSD be made in error which does happen occasionally. MuZemike 08:24, 3 July 2009 (UTC)
The proposal doesn't even make much sense. Anyone can do NPP (though only autoconfirmed users can mark pages as patrolled). If the page is deleted, then that means someone reviewed it. Who cares if they've self-identified as a new page patroller? Mr.Z-man 16:14, 3 July 2009 (UTC)
Agree with Mr.Z-man. Do you think members of NPP are granted some magic power that makes them more qualified than the original tagger and the deleting admin to judge the merits of the page? – iridescent 16:28, 3 July 2009 (UTC)
The problem, again, is that the pages cannot be marked as "patrolled" on the recent changes table once they have been deleted. So every person at NPP sees an article to be patrolled, clicks on it, can't find it, and figures out that it's already gone. It is a very small waste of time, but if you consider how many people do NPP, and how many new articles are speedied, it amounts to a fair chunk. This is time they are wasting not catching other problem articles. The only quick fix I can think of would be JS. Does twinkle automatically mark any page as patrolled that is tagged for CSD, or only if that person is doing NPP? Also, would it be possible to write a script that would mark a page as patrolled on the recent changes table when the admin deleted it? ▫ JohnnyMrNinja 19:59, 3 July 2009 (UTC)
No, that's not a problem, all entries a page (except log entries) are deleted from the recentchanges table when the page is deleted.

Admins able to block while blocked?

I just came off a short block (violated 3RR, wasn't paying attention), during which I explored what an admin can do while blocked. Not to my surprise, I couldn't protect or delete pages, but I found myself able to block users and unblock myself (neither of which I did, mind you :-). What possible benefit is there of admins being able to do this while blocked? I'd like to see the block/unblock feature disabled during a block, partially because it would prevent someone like me from having the annoying little temptation to unblock myself and be vindictive by blocking the guy who blocked me, but more significantly because it doesn't do anything to stop someone who really doesn't care about the rules. If blocking suspended all the tools rather than leaving this — in my mind, the most powerful of all the tools — we'd not need to worry as much about rogue admins. Keep in mind that case a year or two ago when the guy hacked an admin's account, blocked Jimbo and several other people, deleted the main page, and vandalised tons of pages — he was blocked several times, but simply unblocked himself and kept on going until somebody called a bureaucrat to do an emergency desysopping. If my proposal were accepted, someone else would have had to unblock Jimbo, but the hacker would have done far less damage overall. Nyttend (talk) 02:29, 24 June 2009 (UTC)

We've had a few cases of admin accounts being compromised or even admins going bat shit crazy and blocking a bunch of people, including other admins. In such cases, the blocked admins should be able to unblock themselves. Imagine the mess that would happen if someone decided to block all other admins and they couldn't unblock themselves. --Ron Ritzman (talk) 03:38, 24 June 2009 (UTC)
Unless all active admins were blocked, this wouldn't be as big of a problem; and if all were, somehow, couldn't we then call in the bureaucrats or someone else? Perhaps make it so that bureaucrats etc. (including Jimbo) would be able to unblock themselves, but not admins? If we got into the emergency of which you speak, surely it wouldn't be that hard (although somewhat tedious, admissably) to go through all the admins and unblock them; and I expect that it would be far more likely that the rogue would get caught before blocking all of the others. Nyttend (talk) 06:19, 24 June 2009 (UTC)
Minor point but I take it you mean when the stewards came in to desysop not bureacrat as the bureaucrats don't have that power. Davewild (talk) 18:28, 24 June 2009 (UTC)

I don't think it at all likely that a rogue could block all 915 active admins without being spotted, Ritzman. ╟─TreasuryTag►co-prince─╢ 18:51, 24 June 2009 (UTC)

Why not? I think with a user script it is possible to block at least 10 per second. So it will take only 1.5 minutes. Ruslik_Zero 19:18, 24 June 2009 (UTC)
Thanks for the tips :P ╟─TreasuryTag►stannary parliament─╢ 19:21, 24 June 2009 (UTC)
There is also this. Ruslik_Zero 19:26, 24 June 2009 (UTC)
<_< PeterSymonds (talk) 23:20, 24 June 2009 (UTC)

The ability of admins to self-unblock is considered an important safety value to prevent a rogue from blocking everyone else and taking over. On enwiki this is unlikely given the large size of the admin corps, but many other projects have 25 admins or fewer and so a coup is far more possible, so Mediawiki is designed to allow such self-unblocks. This was discussed some years ago. I suppose one could add a Mediawiki configuration to allow this to be disabled in communities like en, but no dev was interested in doing that the last time it was discussed. Dragons flight (talk) 23:32, 24 June 2009 (UTC)

  • The thing is, I would think that having administrators not being able to unblock themselves would be safer for Wikipedia. Though this seems paradoxical, think of what would happen currently if an administrator were to go rogue and block all active admins with a script. Even if someone were to just block him, nothing really would change; you would still need a steward to perform the desysopping (I think I remember that a sockpuppet admin account once deleted the Main Page while there were no stewards around because of Wikimania). However, if they couldn't unblock themselves, all someone would have to do is block them, and the whole issue would be solved while a steward came around. However, this whole discussion is rather academic, and I see no reason to waste developer time on this issue. As Werdna said when I brought this up months and months ago (at Wikipedia:Village_pump_(proposals)/Archive_40#mw:Extension:EmergencyDeSysop), "...[a]nd for what? A minute or two of saved admin time every few months/years. This is, of course, an excellent example of a systemic focus on the dramatic things like rogue administrators. In reality, there are very few rogue administrators on Wikipedia who would warrant an emergency desysop in sub-minute timing, these events being the sorts of things that happen once or twice a year, at maximum. More time is probably spent creating this proposal than will be spent on fixing up vandalism by 'rogue administrators' over the next year or two...Honestly, we need to deal with real content problems – not dramatic things like rogue administrators." NW (Talk) 00:07, 25 June 2009 (UTC)
    • I agree with Werdna. This is an example of a focus on a dramatic thing, that hasn't yet occurred to my knowledge on any Foundation wiki, rather than on real problems that occur every day. Uncle G (talk) 12:22, 30 June 2009 (UTC)
  • On small wikis coups generally occur, in my experience, not by sysops blocking one another but by one person gaming the system to get almost all other administrators de-sysopped through the usual channels. The system is surprisingly easy to game, it turns out. Uncle G (talk) 12:22, 30 June 2009 (UTC)
  • If an admin is blocked for say 3RR and they decide to unblock themselves then the safety valve would be desysoping them. Or if they're compromised and blocked it's likely they'd be desysoped anyhow and thus wouldn't be able to unblock. Thus there's no reason to make a big deal out of this. Nja247 09:35, 5 July 2009 (UTC)

New category for promotional articles

I recently had an observation about Category:Wikipedia articles needing style editing. All articles tagged with {{Advert}} are being lumped there with many other "style" issues, such as {{essay-like}}, {{colloquial}}, {{textbook}}, etc. These "advert" articles are potential spam—and from my experience, often much worse than "not-perfect" articles that need tone editing. There is a difference between prose/style issues, and articles which may need heavy whacking or sometimes speedy deletion.

For this reason, I'm proposing that a new category be created for the {{advert}} tag, such as "Category:Wikipedia articles that are possibly promotional". Spam is a problem, and this would separate Wikipedia's scum from style issues of lesser-importance.

Objections, thoughts? Thanks, Jamie☆S93 01:30, 1 July 2009 (UTC)

Don't know if "scum" is the best term, but it's a sound idea. Possibly Category:Articles with a promotional tone (hidden, of course). ▫ JohnnyMrNinja 05:41, 1 July 2009 (UTC)
Yes, something like that. :-) I'm not usually one to put labels on articles, but those {{advert}} pages are sometimes kind of bad, and it may help to distinguish them. Jamie☆S93 14:59, 1 July 2009 (UTC)
There's probably a few other templates that would use this new category as well: {{Newsrelease}}, etc. I like Category:Articles with a promotional tone (the 2nd suggestion) because it assumes the article is valid, but the tone needs to be edited, vs. saying the article is suspected to be inherently promotional (and possibly could never be un-promotional) - the domain of {{db-spam}}.Cander0000 (talk) 11:46, 5 July 2009 (UTC)

Maps could be much better

For some time, I've been thinking that the maps in Wikipedia could and should be much better. Good technology exists but we're still using "ancient" technology. Instead of a static picture we should have dynamic maps that users can pan and zoom. Inside the maps we should have links from geographical names to articles.

Today, when Honduras was in the news I looked up WP's Honduras article. Then I wondered what were its neighboring countries. The text has the names of neighbors but the map does not. The first map is a very small scale map that shows country boundaries but does not name them. Later in the article there is another small scale topographical map. If clicked, you can finally see the names of neighboring countries. Then I wondered what were the other countries of Central America. By clicking around in text I eventually found what I was looking for but my curiousity kept creating other questions that good mapping technology could have made faster and easier.

If we used mapping technology such as MapQuest, Google, etc. use, then in the Honduras article, I could have expanded the first map in the Honduras article, zoomed in, panned around, and could have quickly seen the names of other countries. With good technology, I could click on the map and go to the WP article about a country, city, river, etc.

While I was navigating around via typing into the search box, and clicking from one link to another to another to another, one of the maps I saw (this one) showed part of the Mississippi river with a tributary heading toward Washington, DC. I wondered what river that was. With good technology, I could have zoomed and panned until the name showed up. Instead I typed Mississippi River into the search box, where there weren't any good maps, but at least the text eventually let me find the answer (Ohio River) to my curiousity.

Good mapping technology would be a great improvement to the WP experience. (And yes, I know that in a few places, I can click a geographical icon to get to a modern mapping site, but that is not well integrated into WP, and does not allow clicking from a map back to a WP article.) Sbowers3 (talk) 18:49, 29 June 2009 (UTC)

But are any of them free? ♫ Melodia Chaconne ♫ (talk) 20:07, 29 June 2009 (UTC)
It's a nice idea, but ultimately one that I think surpasses the scope of this project. At best we can provide links to Google Maps, but based on the current limitations of the project we just have to make do with static maps. Shereth 20:11, 29 June 2009 (UTC)
Indeed. I'm not too big on the technical side of things, but that sounds like quite a load on the servers, and difficult to work into the mediawiki software. Perhaps the technical pump would be a better place to query? Ironholds (talk) 08:28, 30 June 2009 (UTC)
Support for Open Street Maps is current mid-range development goal. Dragons flight (talk) 08:41, 30 June 2009 (UTC)
See Meta:OpenStreetMap for more information. --seav (talk) 05:52, 1 July 2009 (UTC)
A very honourable vision. One I imainge everyone would support. Thanks, Dragons flight/Seav for the link to OpenStreetMap. Excellent idea. --rannṗáirtí anaiṫnid (coṁrá) 18:12, 5 July 2009 (UTC)

Clicking on contribution history should lead to section

If a person posted on a help desk or village pump, you can imagine how hard it is to get back to the specific section where the post was. Where the section is in the user's contribution history, the section name should be blue so you can click on it and go right to the section.Vchimpanzee · talk · contributions · 17:09, 3 July 2009 (UTC)

You already can do that. Click on the → symbol at the beginning of the edit summary. --Floquenbeam (talk) 17:12, 3 July 2009 (UTC)
Thanks. I didn't know that.Vchimpanzee · talk · contributions · 18:22, 3 July 2009 (UTC)
I only just found out from this (after 15 months on Wikipedia) that you can do the same thing in watchlists and histories. I didn't realize (or had perhaps forgotten) that the arrow is a link rather than just punctuation. But as with the mysterious "cur" and "prev", this is something that perhaps one editor in ten or twenty or fifty understands. I'm sure if I'd read, digested and remembered the dozens of help pages that are offered, I could have learned much sooner, but like most people I haven't had the inclination or patience to do so. So I wonder what the solution is? —— Shakescene (talk) 18:29, 5 July 2009 (UTC)

Fix to "Pixelization"

I made those Engrish words a redirect to Pixelization: Mosaic censoring and Censoring mosaics.

Can someone fix the words "mosaic censoring" and "censoring mosaics" in some articles to "pixelization", "pixelized" or whatever? -- JSH-alive talk • cont • mail 10:03, 6 July 2009 (UTC)

Rebooting Wikiproject Spotlight

The Spotlight was a simple project where users choose an article for collaboration and work on its improvement in realtime via IRC on #wikipedia-spotlight. The project seized however a while ago and after a discussion on IRC we were thinking starting collaboration via the Spotlight again. If anyone's interested just login to #wikipedia-spotlight and where we will choose the next article to work on.--Diaa abdelmoneim (talk) 17:18, 5 July 2009 (UTC)

In the spirit of WP:BOLD, we have decided to try it; the channel is now active, and we are working on Marco Polo.
Please help - join the IRC channel.  Chzz  ►  15:05, 6 July 2009 (UTC)

Last night I spent a few hours pasting public-domain sources into talk pages. To get people's attention, I created a section entitled "encyclopedic, public domain source(s)! Please assimilate!", and listed the hyperlinks there. E.g., Talk:Economy of Israel Talk:Au pair Talk:Estuary. (My next step is to make a single list of the 100 pages I've done this to, for wide circulation.)

My proposal is that we sanction this practice on one of the Guidelines pages, so that more people get involved in creating such lists: "Discussion pages may include a list of relevant, encyclopedic, public-domain hyperlinks in a permanent, designated, box, which should then be linked to on a separate outside page." Is this something you guys think would be useful? Agradman talk/contribs 17:58, 1 July 2009 (UTC)

WP:Avoid instruction creep. Just do it, and if people complain discuss it. IIRC, when this sort of proposal has been made in the past people have suggested just putting it in {{todo}} or the like, if for some reason a normal talk page section isn't good enough (most articles' talk pages are seldom if ever archived, so it's not like the talk page section is all that likely to disappear). Anomie⚔ 18:20, 1 July 2009 (UTC)
Creating a box for that is an excellent idea, so I went ahead and created {{Refideas}}. It has a wider use... in addition to listing things like PD resources, other references which may be useful in the future can be included. –Drilnoth (T • C • L) 20:09, 1 July 2009 (UTC)
oooh, that's classy. Here are a few suggestions:
1) Somehow, it should draw attention to Public Domain sources, because they can be adapted with a minimum effort.
2) Wikipedia will improve even quicker if there were a list of "pages containing non-integrated PD sources", where people could go to mindlessly integrate PD content. (e.g. it took me 20 minutes last night to create "House Minority Leader", which was previously a redirect to a list of party leaders, using a government research report.) That's one reason why I, personally, would prefer the template to focus on PD sources -- such a list will be generated from the pages it's on. (Otherwise, the box will just be moving things from "external links" to the talk page, which is somewhat useful but less so.)Agradman talk/contribs 20:21, 1 July 2009 (UTC)
Hmm... I see your reasoning. I need to log off for awhile but will add this to the template later today in a way that makes both of these possible. –Drilnoth (T • C • L) 20:28, 1 July 2009 (UTC)
 Done. See the documentation for details. –Drilnoth (T • C • L) 21:57, 1 July 2009 (UTC)
Wow I'm stunned. Not only have you done beautiful work, but you did it really quickly, and you made my idea feel welcome. I'll wait until we hear feedback from a few other editors before I start slapping this on pages, but in the meantime, I'm going barnstar shopping. Agradman talk/contribs 22:16, 1 July 2009 (UTC)
Thanks. :) Anyway, I think it would be safe to just start using the template... mentioning it in a guideline or policy would need a good bit of consensus, but using the template seems to make more sense then just making new sections on talk pages, so why not? –Drilnoth (T • C • L) 22:35, 1 July 2009 (UTC)
(outdent) Agree with Drilnoth; finding reliable sources is already a laudable goal, and I highly doubt that anyone will object to you providing sources for them, since that saves them the work of going out and finding them. Be bold!--Aervanath (talk) 03:41, 7 July 2009 (UTC)

Wikipedia:Automatic Adminship

Wikipedia:Automatic Adminship is an idea to offer an alternate path to adminship for long standing and highly rated content contributors. Your thoughts and ideas would be most welcome :-) Privatemusings (talk) 04:37, 7 July 2009 (UTC)

Proposing a re-design of the editing toolbar

Hi folks! Okay, before I begin, I understand this is going to be potentially controversial, as the current design has stood for many years now. But what I would like to do — bear with me here — is propose that we alter (purely in aesthetic terms) the way those handy buttons above every edit window look. Currently, I feel they are not pretty at all; a sort of throwback to the Netscape era, and it seems odd to me they've existed in their current form as long as they have. Many of them were designed at different times (possibly by different people?) and so have a real mish-mash of graphical styles.

Apart from their (admittedly highly subjective) ugliness, many of images are a little confusing given what they are meant to represent. The bold and italic buttons make sense, sure, but what's with the 'small' button?! The gallery button does not at all suggest a selection of pictures (the same could be said for the quote button), and mine only ever be a guess as to what that trumpet is supposed to be signalling (that button brings up videos..?). What's the big 'A' for? In my opinion, the best buttons are those that give their function in words on the button. The <ref> button is marvellous, and I wonder, why can't the rest be designed in its image? Thus, I am proposing that the following re-design be considered:

Proposed redesign of editing buttons (with current above, for contrast)

In my example above, if you look closely, you can see that the buttons in my proposal are of the exact same height and in the exact same order as the buttons before (so that hopefully should lessen the impact on the various scripts users use to alter their positions and whatnot). They also use the Wikipedia standard colour palette in their borders and individual backgrounds, and so sit more comfortably in the website design. They are also wider, as I feel it seems silly to have them all shoved together in the corner, when there's even room to spare with my design on non-widescreen computer screens. This gives more room-per-button to explain what they do, and makes it easier for the pointer to meet with its desired destination.

I understand we might need to convince the developers to help if this were to be implemented, and that is always a hurdle. And before you all hurriedly say, I know that a quick mouse-over will elucidate each button's function, but why should we have to work to suss out the interface? It makes sense, given our utter reliance on new people being attracted to edit, that this encyclopaedia be as user-friendly as possible. Anxietycello (talk) 02:22, 2 July 2009 (UTC)

There's a new editing toolbar option that was just enabled for testing, see the "Enable enhanced editing toolbar" option in preferences. Mr.Z-man 02:47, 2 July 2009 (UTC)
Oh, darnit. It's really quite good... Hmph. Anxietycello (talk) 02:53, 2 July 2009 (UTC)
I see some improvements, but it's really not quite intuitive enough for me. Examples are subscript, superscript, redirect, footnote. Anything that makes it clear that the wikilink button won't underline has to be counted a vast improvement. —— Shakescene (talk) 04:47, 2 July 2009 (UTC)
Can I ask, where was the editing toolbar that's now being previewed discussed? And when is it likely to be rolled out for all users? Anxietycello (talk) 19:38, 2 July 2009 (UTC)
Someone donated $890k to improve the editing interface, so the WMF made it so. It's already rolled out, but you have to opt in. It is still experimental software, so not available to IPs yet. As for feedback, go to [3]. MER-C 03:42, 3 July 2009 (UTC)
I surely hope that that $890k is going to better use than swapping out toolbar icons – preferably something like a WYSIWYG mode editor for the less technically inclined. Personally, I prefer the existing icons in general. First, they look like buttons. Second, many of them are similar to what I'm used to in other applications. For example, why change the bold and italic icons, when the existing icons are almost universally recognized? There are a few that could use some tweaking, such as the title and small text buttons, but I would keep the general look.
As for the new icons, I think a few need work – particularly the line break, comment, and table buttons, which show markup code that is more recognizable to an experienced editor or a programmer than a new user. I think we are going in the wrong direction with those. A line break icon that looks the the symbol on your enter key and a table icon that looks like a table (I'd add a couple of cell divisions) both seem natural to me. As for the comment icon, I'm not sure what a good icon would be, but "!com" does not seem intuitive to me. I do prefer the new title and block quote icons over the old though. -- Tcncv (talk) 01:21, 8 July 2009 (UTC)
  • I'm all for a facelift of the toolbar, but not one where it's larger in size. I'd like a few mockups to choose from to be honest. Also don't forget about the additional buttons some of us use, eg the "cite" button, etc. Nja247 09:29, 5 July 2009 (UTC)

Instead of adding the rel="nofollow" attribut value to every external link, you could add a timestamp for every external link that is placed in an article and if its timestamp is older than one year, you remove the nofollow attribut value. Every time a link is removed the timestamp is refreshed. This avoids spam and supports external sites we trust.

I'm not sure how viable that is, but it'd need to go to bugzilla:. Stifle (talk) 08:17, 3 July 2009 (UTC)
It won't be a big challenge to realize. bugzilla: One of the wikimedia foundation staff advised me by email, to publish this feature (its not a bug) here. Marc 11:37, 3 July 2009 (UTC)
Why would this be a good idea? The purpose of wikipedia is not to "support external sites we trust", it's to create a free encyclopedia free from the influence of self-motivated parties, which includes SEOs and spammers. We don't need to give them the hope that, if they spam a sufficiently obscure and insignificant page with their links, they might last long enough to be registered by google. That's asking for trouble. Happy‑melon 13:34, 3 July 2009 (UTC)
It's not the sense to support science and research? Everyone is self-motivated. WP too as it won't have visitors without the search engines and other pages linking to it. It would be possible, that spammers look for obscure articles, but it would be possible to add such a feature to very popular / moderated articles only. At the moment WP is a dead-end-construction that isn't supported by many webmaster who know the definition of nofollow and I don't think that search engines will support such constructions infinite as it is selfish/unnatural to support only internal sites. Counter question: Why use external links at all? Marc, seowriter.de (not a typical "linkbuilding" SEO) 16:41, 7 July 2009 (UTC)
  • Strong Oppose - Unclear benefit with obvious encouragement of even more bad behaviour by those who would use WP as an SEO and promotional opportunity. Delicious carbuncle (talk) 13:39, 3 July 2009 (UTC)
  • Oppose as having no valid justification that conforms with Wikipedia's goals and because it would increase amount of stealth spam added. DreamGuy (talk) 14:42, 3 July 2009 (UTC)
  • Oppose per Happy-melon. This would have the effect of generating large amounts of spam on minor-topic pages. It would also be apt to break if there is page- or section-blanking vandalism at any point during the year, substantial article revision, article merges/redirects, or conversions to summary style. This feature would only work 'properly' on pages which were both heavily-watched and seldom edited. That's a pretty small pool of articles. (It might work on Featured Articles, but I don't really want to impose link evaluation and endorsement as another criterion for the FA reviewers.) TenOfAllTrades(talk) 15:28, 3 July 2009 (UTC)
  • Definite oppose. We're not here as a service to PageRank. A proposal with no merits whatsoever and plenty of glaring drawbacks. – iridescent 16:30, 3 July 2009 (UTC)
  • Oppose - Plenty of drawbacks and minimal, if any, benefit to Wikipedia. Mr.Z-man 16:45, 3 July 2009 (UTC)
  • Sounds great, but won't happen now. Eventually Google will start ignoring our nofollows, and the we'll have to deal with it. --Apoc2400 (talk) 10:34, 5 July 2009 (UTC)
    Google has nothing to gain from ignoring our nofollows. They are search engine, their commercial viability comes from selling all that advertising. What's the point in SEOs paying for all those pay-per-click sponsored listings when they can just spam Wikipedia with links and jump straight to the top of the listings anyway? Google hates SEOs and spammers as much as we do. Happy‑melon 11:03, 5 July 2009 (UTC)
    Google also need to provide good search results, or they wont have any viewers and no ad impressions to sell. Web pages linked from Wikipedia are probably in general quite good. I think Wikipedia should work with Google and other search providers to help them get the best use of Wikipedia. Something like the original idea here. --Apoc2400 (talk) 13:59, 5 July 2009 (UTC)
    Links from wikipedia are going to be biased in bad ways. It would be impose the bias of WP:RS onto general search results. Google doesn't want some obscure academic article about Fig Newton manufacturing to be higher than the actual corporate Fig Newton site. It's bad enough that Wikipedia often gets high ranks on search results, I get the feeling that google has actually reduced wikipedia's overall pagerank so that it isn't the top link on as many results. Gigs (talk) 00:09, 9 July 2009 (UTC)
    Some years ago, Google explicitly encouraged WMF to adopt rel=nofollow. Dragons flight (talk) 18:11, 6 July 2009 (UTC)
    Google says: "If you want to recognize and reward trustworthy contributors, you could decide to automatically or manually remove the nofollow attribute on links posted by members or users who have consistently made high-quality contributions over time.", too. Marc 16:49, 7 July 2009 (UTC)
  • Oppose Insufficient reward for risk required. MBisanz talk 18:18, 6 July 2009 (UTC)
  • Oppose per everyone else. I don't think Google et al would want this, and I think they would probably re-enable it on their end if we stopped doing it. Gigs (talk) 00:11, 9 July 2009 (UTC)

"What links here" on requested articles page

I'd like to propose the creation of a bot that automatically inserts a "what links here?" hyperlink directly to the right of any item that appears in a "requested articles" list. That way, people who are interested in creating new articles off the list will be encouraged to check to see which articles are in the highest demand. Agradman talk/contribs 17:53, 8 July 2009 (UTC)

If you go to Wikipedia:Requested articles/Applied arts and sciences#Engineering and click on, say, 5% Rule, you'll find the "What links here" link in the toolbar as usual. (In this case, nothing links there.) You can also use Special:WhatLinksHere to look up any pages on the fly. This seems adequate to me.
I'm not following your proposal 100%, but if you're asking for a WLH link to be added in the list (my first link) then you're just cutting out one click, adding extra baggage to the page and opening a can of worms of what else we can put there. Sorry if that's not what you proposed, in which case I'm sorry, and further explanation would probably put me on the right track! Greg Tyler (t • c) 23:36, 8 July 2009 (UTC)

Userspace redirect

I propose that a namespace be implemented specifically for userspace redirects. There's currently no policy that forbids redirecting pseudo-namespace to user pages but it's certainly enforced as a policy. To deal with this, I propose setting up U:/UT: redirects as allowable shortcuts for user pages. U: to the user page and UT: to the user talk page. I don't know if this requires anything special other than saying "these are OK" somewhere such as wp:csd#r2 or Wikipedia:Pseudo-namespace or if something has to be done on the backend software wise but this is my proposal. - ALLST✰R▼echo wuz here 20:41, 28 June 2009 (UTC)

What good reason is there for anyone to need a redirect to their userspace? "I want one" and "It makes my sig shorter" are IMO not good reasons. Anomie⚔ 22:40, 28 June 2009 (UTC)
Obviously the same reason we have redirects to everything else: shortcut. - ALLST✰R▼echo wuz here 07:37, 29 June 2009 (UTC)
You just said "A good reason for having a shortcut is because it's a shortcut". That tautology doesn't actually answer the question: Why is such a shortcut necessary? Anomie⚔ 12:26, 29 June 2009 (UTC)

I don't think that this is a good idea at all. WP:DRAMA and Wikipedia:Drama used to redirect to different pages, and then when WP: became a proper redirect namespace, it caused problems. What would happen if people essentially got to choose a "second username" (or more than one) for themselves (I could be U:TAG)... chaos. ╟─TreasuryTag►ballotbox─╢ 07:40, 29 June 2009 (UTC)

WP:CSD#R2 forbids redirects from mainspace (so, from all pseudo-namespaces) to the user namespace, and has always. When I became an admin, userspace was the only explicitly forbidden target, and this policy has always been enforced. I see no need to change it, and if your username is too long, you can try to change it at WP:CHU. Kusma (talk) 08:51, 29 June 2009 (UTC)
  • I wouldn't mind a proper WP: style alias being created for User talk: (UT:) but User: seems unnecessary (removing three characters). Anyhow, I've previously suggested to ASE that he register User:ASE, seems like a nice short redirect and good doppelganger because people call him that anyway. –xenotalk 17:42, 29 June 2009 (UTC)
  • Doesn't seem to be a worthwhile change, to be honest. Stifle (talk) 13:13, 30 June 2009 (UTC)
  • From a technical perspective, setting up of a proper namespace alias, like WP and WT are now, is a doddle. Regards U/UT, there is a precedent in the sense that on de.wp, BD can be used instead of the rather long (and longer that on en) "Benutzer Diskussion". - Jarry1250 [ humourous – discuss ] 15:41, 30 June 2009 (UTC)
  • U and UT would be cool. Less typing as a good thing should not be underestimated. - Peregrine Fisher (talk) (contribs) 00:13, 1 July 2009 (UTC)
  • Yeah, since we've already got User: and User talk:, I see no reason why there shouldn't be a related pseudo-namespace such as U: and UT:. - ALLST✰R▼echo wuz here 07:28, 2 July 2009 (UTC)
  • I can vaguely see the argument of shortcutting "User talk:" with "UT:". It's shorter and linked to a fair bit. That said, I really can't see the need for a shortcut. Sure, it's a few extra characters to type but is it really that difficult? It seems to be more of a personal request than something that will improve Wikipedia. In some ways I'm saying IDONTLIKEIT, but I feel the proposal is purely based on the fact that ILIKEIT. Greg Tyler (t • c) 10:41, 2 July 2009 (UTC)
  • Do I understand this right? I've a fairly long user name (Rannpháirtí anaithnid). Right now to link to my talk page I have to link to User_talk:Rannpháirtí anaithnid. What you are proposing is that I could like to it by UT:Rannpháirtí anaithnid. Or are you saying that I could have a shortcut like UT:RA? In the first case, I don't really see the point. For the sake of seven letters there really is no great advantage to it - how often do you find yourself typing this out so what is the great need? Besides the fact that there is already the {{U}} and {{UT}} templates that do practically the same thing. In the latter case, I think that that would be a really bad idea. I could see a land run for "vanity" user names. And gods know what would happen to after a user deceased or apparantly stopped editing - would we have squatters and ownership wars over user name redirects? --rannṗáirtí anaiṫnid (coṁrá) 17:51, 5 July 2009 (UTC)
  • If this is about just having U: as a shortcut for typing User: and UT: as a shortcut for typing User talk:, then it sounds okay to me. I see some minimal utility. (Minimal, yes, but minimal != none.) • Since we're here: I also think T: as an alias for Talk: would be useful in the same way. Yah, we're only saving a few keystrokes, but over time it adds up. • If this is about actual shortcuts, e.g., U:DH redirecting to User:DragonHawk, then no. No way. As Rannpháirtí anaithnid said, it will just mean people fighting over shortcuts. We don't need the drama, or the confusion if they change in the future. —DragonHawk (talk|hist) 21:44, 6 July 2009 (UTC)
  • Problematic entries: U:, U:Nee, and UT:XMP. --Cryptic C62 · Talk 20:55, 7 July 2009 (UTC)
  • I'm in favor of discussion of this topic, because I believe such redirects were discussed at the XfD pages for the past several weeks. Personally, I find that I'm content with the search suggestions (or autocomplete, or query expansion – I'm not sure what exactly they're called) in Wikipedia's search box to quickly go to a user page. I agree with DragonHawk: "If this is about just having U: as a shortcut for typing User: and UT: as a shortcut for typing User talk:, then it sounds okay to me"; however, Cryptic C62's entries need to be discussed. On the other hand, "if this is about actual shortcuts" (borrowing DH's language), there could be problematic situations. If two editors had similar usernames and wanted shortcuts to their user pages, at best, they'd have a friendly discussion and come up with some compromise; at worst, they'd argue and possibly war on the redirect page – as Rannpháirtí anaithnid brought up earlier. In addition, some hypothetical situations…
    1. What if I redirected U:SD3 to my user page, but then SD3 signed up? Well, in that case, all users who want redirects would be required to first create accounts – in my case, I'd have to register the SD3 account before using U:SD3. But what if the redirect I wanted was already registered?
    2. Say a well-known user uses a redirect that other editors also start using. Vandals could easily change the page to redirect to an impersonating account or an inappropriate page. The solution here would be to constantly watch the redirect page for vandalism. My 2¢ and some points to think about. Cheers, [sd] 04:36, 11 July 2009 (UTC)

Straw Poll on modifying <ref>

I have created a straw poll on proposed software changes to <ref> aimed at improving the way references are organized within wikicode. Please comment at the referenced page. Dragons flight (talk) 11:43, 11 July 2009 (UTC)

Redirects in search history

I was just doing a search and a couple of items came up where the title of the article is followed by (redirect Title of second article)". Since the name of the article is already a link to that article, why not have the redirected article's name be a link to the original article before redirecting? I was curious to see the pre-redirect history of the redirected article, and it would make that a little easier.Vchimpanzee · talk · contributions · 18:49, 10 July 2009 (UTC)

So, extra work for the devs just to save you one click. Somehow I don't think anyone is going to be very receptive to this idea. --LP talk 01:48, 11 July 2009 (UTC)
The two links are sometimes different because the redirect goes to a section of the article. PrimeHunter (talk) 02:31, 11 July 2009 (UTC)
That second part does make it more trouble to figure out what's going on. I suppose it's just a matter of scrolling up and remembering that second click.
I do redirects to sections a lot, so I guess that's a valid way of doing it.Vchimpanzee · talk · contributions · 16:48, 11 July 2009 (UTC)

RfC on Wikipedia:Advisory Council on Project Development

The community's views are needed at Wikipedia:Requests for comment/Advisory Council on Project Development. Many thanks, SlimVirgin talk|contribs 17:22, 11 July 2009 (UTC)

Reorder quotation marks in "editpage-specialchars" DIV

The toolbar for inserting special characters has quotation marks listed in two sections: "Insert" and "Symbols". Currently the quotation marks are listed in the following order: 

‘ “ ’ ” «»

while I suggest that they should be listed as 

‘’ “” «»

The symbols by themselves are quite tiny so it's not too easy to click them with a mouse, especially when they are interspersed. However if we group them so that opening and closing quotation marks are inserted simultaneously (similarly to how «» works now), editing of articles might become somewhat easier. // Stpasha (talk) 01:17, 8 July 2009 (UTC)

Er, isn't usage of these sorts of quotation marks discouraged? Why would you need to use them anyway? - Jarry1250 [ humourous – discuss ] 17:01, 10 July 2009 (UTC)
This should be proposed at MediaWiki talk:Edittools. See/point-to Wikipedia:MOSQUOTE#Quotation marks (in the subsection "Quotation characters") for confirmation that curly-quotation marks are deprecated/not-recommended.
See also this older thread on the same topic: MediaWiki_talk:Edittools/Archive_5#Curly_quotes_problematic? which got them removed in 2007.
I've asked User:Random832 to comment on why he added them back in again, though. Perhaps they have an alternate common-usage in some subfield? (I can't see anything, after a quick glance through Quotation mark glyphs). HTH. -- Quiddity (talk) 21:28, 11 July 2009 (UTC)

Using Wikipedia as a forum for peer-review

If this is in the wrong section, I apologize.

So, I was thinking, since we don't like original research, and it's very difficult for someone like me (a virtual unknown high-school student with no Ph.D, which is practically necessary to get any sort of recognition in a scientific journal. Or at least I think it is.)to get any of their evidence-based ideas and thoughts published on a reliable source, to put our evidence-based thoughts on some special group of pages (or perhaps even another Wikimedia project) where they would be peer-reviewed, and maybe recognized by well-known scientists. Then, when/if it gets published in a third-party source, we can use it on an article. Note the bolded evidence-based up there. I'm not saying we should give every little bit of speculation and rumor a chance, just people who have done their research. For example, I have several sources (CIFOR, et al.) that indicate that cattle ranching is the main cause of the Brazilian Amazon Rainforest's destruction. I also have mention in them that the EU buys heavily from this region, thus, I could claim that the EU is indirectly supporting the rainforest's destruction. But I can't do that, because I am not some internationally recognized scientist/sociologist/economist with the community around my little finger. Thus where my proposal comes in. Now then, I'd be happy to take your thoughts on this so that I might improve upon this idea, and if it is not to be, at least know why. --ArchabacteriaNematoda (talk) 20:12, 10 July 2009 (UTC)

I could not say quite where you would take this type of contribution to achieve the desired result, but I can say pretty confidently that Wikipedia is would not be the place. --User:Ceyockey (talk to me) 02:10, 11 July 2009 (UTC)
Sounds interesting, but it wouldn't be Wikipedia. It could certainly be a wiki (using the same MediaWiki software perhaps), on another website. It may even exist. The problem of course would be getting enough traffic to make it work. Really it would need to be attached to an existing high-traffic site to stand a chance. You could try pitching the idea to a few, you might be lucky and get someone to bite. Rd232 talk 19:44, 11 July 2009 (UTC)
The example you offer might get deleted, rather than discussed, as Original Research under WP:SYNTHESIS. I'm not 100% happy with the Original Research policy, which is one of the Five Pillars of Wikipedia, but the idea is that a plausible (or at least arguable) connection has to have been posited somewhere outside the (usually-anonymous) Wikipedian's mind, and thus be verifiable, for example the science writer for a major newspaper or a quotable advocate for some position. The exception (similar to that in scholarly practice) is for unchallengeable or trivial connections that can be instantly and intuitively grasped by the reader. —— Shakescene (talk) 21:56, 11 July 2009 (UTC)
I believe you're looking for Wikiversity, which is a Wikimedia project. --Izno (talk) 22:09, 11 July 2009 (UTC)

Language articles

Hi all - just been looking at Tajik language, and wonder whether it might be worth adding a block of identical text to each article on a language. Often you get a feel for how a language appears from a simple block of text. If we could come up with a standard short paragraph in English and add it in both English and the subject language to each article, it might be worthwhile. (Of course, that raises the question "what would the paragraph be?"...) Grutness...wha? 01:41, 5 July 2009 (UTC)

Believe it or not, the "lord's prayer" is commonly used for this purpose, see examples. — CharlotteWebb 02:44, 5 July 2009 (UTC)
I wondered about that, but thought it might be inappropriate to use a religious text (I can imagine the speakers of some Middle Eastern languages might object to the use of the Lord's prayer, for instance). Perhaps something like the preamble to the United Nations Charter might be more neutral. Grutness...wha? 01:35, 6 July 2009 (UTC)

Definite Support: for the reasons listed above, this would be extremely useful. Asdfhgjgiewiuweroiuwer (talk) 09:34, 5 July 2009 (UTC)

  • This seems like a good idea. In the search for a neutral block of text, I think it's important to keep in mind that this is an English encyclopedia. What this means is that we shouldn't bend over backwards trying to find a paragraph to suit the needs of every human, but instead we should find one that English speakers will be somewhat familiar with or will be comfortable reading. The other language WPs can come up with their own texts if they choose to adopt this practice. Perhaps Twinkle, Twinkle, Little Star?
Good idea, but I am not sure whether rhymes are the most appropriate to get a feel for a foreign language. I guess the Lords Prayer or quotes from the bible have the advantage that translations for allmost all languages exist, whereas virtually all poems, novels etc. have been translated in only a relatively smal number of languages. 76.117.1.254 (talk) 19:46, 9 July 2009 (UTC)

How about

as the text to translate into as many languages as possible?-gadfium 00:20, 10 July 2009 (UTC)

Jimbo quotes are unlikely to be widely available in reliable sources for most languages. OrangeDog (talk • edits) 05:00, 10 July 2009 (UTC)

Support - although I agree with Grutness that it is inappropriate to use the lord's prayer - a more neutral text should be used. Also, for many languages it wouldn't be difficult to locate fellow wikipedians who could translate a line or two of text. Shimawa zen (talk) 07:20, 12 July 2009 (UTC)

There's a difference between describing something in a foreign language (editor's translation) and stating that a particular text is an accurate translation (source required per WP:NOR) OrangeDog (talk • edits) 21:08, 12 July 2009 (UTC)

On it.wiki we use the Article 1 of the Universal Declaration of Human Rights. It has been translated to quite a great many languages. --A. di M. (talk) 21:15, 12 July 2009 (UTC)

That sounds good - it's got the sort of universality I was searching for when I suggested part of the UN charter. And if it's been translated into a wide number of languages, that's a big help. Grutness...wha? 23:10, 12 July 2009 (UTC)

Indenting

Is there a reason I have to indent every paragraph separately? Couldn't an entire edit be indented once the indenting is done as long as no other indenting takes place?Vchimpanzee · talk · contributions · 17:16, 10 July 2009 (UTC)

Because indentation is a property of paragraphs, not of edits. What if you wanted different indentation for different bits of text - force a separate edit for every paragraph? OrangeDog (talk • edits) 21:31, 10 July 2009 (UTC)
I think what VChimp is getting at is the behavior of some computer code and most word processing composition environments. The editing environment in Wikipedia is based on ASCII and unicode characters placed in a raw text edit window. The edit window does not presently support things like auto-complete or auto-application of formatting rules (e.g. numbered list auto-adds next number in series for next paragraph). The buttons that add boilerplate act outside the edit environment to feed raw text into the edit window. Your proposal would be best considered as an enhancement request for the Wikimedia software via the Meta wiki. --User:Ceyockey (talk to me) 02:21, 11 July 2009 (UTC)

A world map for all ages

As I was using wikipedia a couple of days ago I thought struck. What if there was a world map, were you could enter a year and date to see how the world looked like at that specific time? As I see it it's nothing either hard or expensive to create. All that is needed for the user is a map without borders and three diffrent fields to enter the year, the month, and the day in. For the person who is doing the inputs of all these dates it'll be a bit harder. As that person need to be able to draw the borders at each specific date.

I'm don't know very much about programming (I've only taken 2 basic courses), but as I see it this can't be very hard for someone that knows what he's doing. —Preceding unsigned comment added by Kgjohnsson (talk • contribs) 12:33, 11 July 2009

It would be a bit of a nightmare. Historically, Western Europe and the northern boundary of China have been the only territories with clearly defined borders until 19th century colonialism and improved surveying techniques; most of the world has historically been populated by nomadic or semi-nomadic tribes with ever-shifting borders. Even Europe has traditionally been a mess of overlapping jurisdictions; consider the 348 independent electorates, principalities, bishoprics, kingdoms etc than made up the Holy Roman Empire after 1648, and the numerous disputed claims, many of which persist to this day (do we include Transnistria? North Cyprus? Of which country is the West Bank a part? How about Northern Ireland? When do we show the English claim on France as ending?). It can (and has) been done for the histories of countries with strictly defined borders – take the animated File:USA territorial growth.gif or File:Breakup of Yugoslavia.gif maps, for example – but how would you treat pre-Columbian North America, or pre-colonial Africa? – iridescent 17:35, 11 July 2009 (UTC)
It's being attempted on limited scales; see Territorial evolution of the United States, Territorial evolution of the Caribbean, Territorial evolution of Canada, etc. As for pre-colonial times, when borders weren't as firm, there's still methods, but they can't really be tied down to specific moments in time; you can just give an overall view. --Golbez (talk) 17:49, 11 July 2009 (UTC)
Also, for future reference as a programmer: Never say, "It can't be very hard to do." That universal response will be, "Then do it yourself, if it's so simple." --Golbez (talk) 17:51, 11 July 2009 (UTC)
From a programming standpoint, it is easy. It's the data collection that's hard, and as a programmer, that's not my job. --Carnildo (talk) 20:16, 12 July 2009 (UTC)
Google earth#Historical Imagery might be what you are looking for. -- Quiddity (talk) 21:30, 11 July 2009 (UTC)

Add External Wiki Searches and Encapsulated External Wiki Pages

Wikipedia exists to give information on a broad range of topics, however, in order to get more specific information on subjects I often have to leave Wikipedia and visit Wikis which deal with very specific types of information. I believe my concept will help to connect this information, and will make finding more specific information easier for the user, without distracting the user who is searching for less specific information. This will also save storage as it removes the need for Wikipedia to copy information from smaller Wikis.

Let's say, for example I visit the Linux page on Wikipedia. Instead of see what is there today, I would see this:

Notice the search bar next to the page title












The search bar allows me to search through the Linux Wiki from Wikipedia, and will take me to Linux Wiki pages embedded within Wikipedia pages. (Shown later.)

Let's say I begin reading the article, and eventually come to the word 'Ubuntu':

The Link to Ubuntu is green rather than blue












Notice the green tint of the Ubuntu link. This green tint indicates that, rather than sending me to an internal, Wikipedia page, or sending me to a completely external web page, this link will send me to a page hosted on another Wiki, but displayed through Wikipedia. (Note, that this would probably not be used for something like Ubuntu, but instead would be used for more esoteric information, such as information about obscure video game characters which are deemed too esoteric for Wikipedia.)

Now, in my quest to learn more about this 'Ubuntu' thing, I click the link, and I'm brought to this page:

File:Wiki Embed Concept.PNG
I would see this same page if I were to type 'Ubuntu' into the search bar at the top of the first image.












As you can see, the Linux Wiki page for Ubuntu is embeded within a Wikipedia page. As the actual content of this page is stored on the Linux Wiki no extra storage is being used to hold this page on Wikipedia. Held within the shell is:

  • The Logo of the Linux Wiki to the top left. Clicking this links to the Linux Wiki
  • A search box under the Linux Wiki logo for searching the Linux Wiki
  • A link to the Wikipedia page for Ubuntu on the top right (Would not be present if there wasn't a Wikipedia page for that topic)
  • The standard Wikipedia panel affair to the left and above
  • A notification to the right of the page title informing me that this page is from the Linux Wiki
  • The embedded Linux Wiki page in the center

The discussion and edit tabs would of course lead to embeded discussion and edit pages from Linux Wiki.

The design ideas, such as the location of objects, the color of the Wiki links, etc... are less what I'm pitching than the functionality of this change. 8bit (talk) 04:45, 7 July 2009 (UTC)

A couple of things. Firstly, the embedded pages wouldn't be editable by Wikipedia editors unless the Linux Wiki used the same unified login technique with equal accounts (I doubt the 'pedia would be up for this). As editors and readers can't directly edit the pages, this doesn't seem quite right.
Secondly, the embedded pages could contain malcode. For this reason, Wikipedia would need to specifically select which Wikis to integrate with and rigorously ensure that the content produced is safe and suitable for its readers. Furthermore, any external integrated Wikis would need the same copyright as Wikipedia and the same fact-checking. Some Wikis are full on totally unverified information (admit: including some bits of Wikipedia) which doesn't have a place on the 'pedia.
I can see the point you're making, that we could extend Wikipedia's information. But wouldn't it be a lot easier to just integrate the necessary information from Linux Wiki by hand rather than effectively provide advertising for an unaffiliated site? Myeh, it's a nice idea and obviously something you've thought through, but I can't much see it happening. Greg Tyler (t • c) 10:32, 7 July 2009 (UTC)
"Firstly, the embedded pages wouldn't be editable by Wikipedia editors unless the Linux Wiki used the same unified login technique with equal accounts (I doubt the 'pedia would be up for this). As editors and readers can't directly edit the pages, this doesn't seem quite right."
No, however, almost every wiki I've ever been to outside of Wikipedia uses the Wikia software, which I believe defaults to the same editing and account privlidges as Wikipedia, meaning that most Wikia wikis will allow any user to edit most pages, and most will allow any user to create an account. While this means that your Wikipedia account isn't linked to the embeded page, I don't see this as much of an issue, as most will allow anyone to edit pages.


"Secondly, the embedded pages could contain malcode. For this reason, Wikipedia would need to specifically select which Wikis to integrate with and rigorously ensure that the content produced is safe and suitable for its readers."
As stated above, most non-Wikipedia Wikis seem to use the Wikia software, which is very similar to the Wikimedia wiki software. Is malicious code possible on Wikipedia? If not, why would it be possible with other similar software? If so, don't we see the same risk when ever any Wikipedia page is edited anyway? If anything, this would help to alert Wiki owners of malcode quickly, considering the size and power of the Wikipedia community. The arrangement would be mutually benificial.


"any external integrated Wikis would need the same copyright as Wikipedia"
From the Wikia Central Wiki:

Except where otherwise specified, the text on Wikia sites is licensed under the Creative Commons Attribution-Share Alike License 3.0 (Unported) (CC-BY-SA).


"Some Wikis are full on totally unverified information (admit: including some bits of Wikipedia) which doesn't have a place on the 'pedia."
I see your point, however, I'm not advocating implementing completely liberally. The implementation is at the descression of the collective Wikipedia editors, and thus, we should only implement this in conjunction with quality wikis. Finding quality wikis, I assure you, will be the least of our issues.


"But wouldn't it be a lot easier to just integrate the necessary information from Linux Wiki by hand rather than effectively provide advertising for an unaffiliated site?"
Yes, and I wholeheartedly support the expansion of Wikipedia, however, I've noticed that the Wikipedia community can be quite conservative when it comes to what pages they believe should remain intact, and which should not, based on obscurity of the subject manner. For example, take the Zork character, Ryker. While Wikipedia has a general Article on Zork, and an article on each Zork game, I doubt the community would support the creation of a page for an obscure Zork character, such as Ryker, as it would arguably fall within the eighth type of bad article ideas as defined by the Wikipedia:List of bad article ideas however, the Zork Wiki has an in-depth page for Ryker.
Furthermore, the objective of this change would not be to advertise for an unaffiliated site, as it brings added information and power to the Wikipedia user. This is as much of an advertisement as citations which link to external sources.
As I've said, nearly every wiki I've seen has used the Wikia software, and the few that didn't used the MediaWiki software, which would be even less of an issue, as it's the same software Wikipedia uses. Those two types of wiki software probably make up around 99% of all wikis. Thus, quality, security, and licensing isn't much of an issue. 8bit (talk) 14:55, 7 July 2009 (UTC)
No. We're an encyclopedia, not a search portal. If they want to search a wiki for a particular topic, they can go to that wiki (and there should be a link to the site in the External links section). If nothing else, we'd be placing an inappropriate emphasis on wikis versus official websites. EVula // talk // ☯ // 15:11, 7 July 2009 (UTC)

This isn't an attempt to turn Wikipedia into anything it's not. As you said, the core functionality already exists within Wikipedia. There are links to external Wikis when deemed necessary. What we have now is essentially a much clunkier, much less fluid, and less powerful version of what I have proposed.

This is an idea based on a very real issue I encounter frequently with Wikipedia. I often visit Wikipedia, only to frustratingly discover that I need to search for the specific wiki for that specific subject. This would smooth that out quite a bit. 8bit (talk) 15:29, 7 July 2009 (UTC)

If you need to search a specific wiki, go to that specific wiki. Integrating non-WMF sites into Wikipedia like this is a bad idea; people will, regardless of fact, assume that we're "blessing" the content, when it's entirely separate from the Foundation (people perpetually think that Wikia is a WMF project). I'm not trying to shoot you down here, I just don't think this is a good idea.
That said, links to other sites that are in the Interwiki map are already colored differently from regular wikilinks; it'd require just a minor tweak to your monobook.css file from them to become green. EVula // talk // ☯ // 16:39, 7 July 2009 (UTC)

Wikipedia is simply intended to be a collection of well sourced information to be easily accessed by it's users, so, within the same mindset, why does Wikipedia exist? If you need that specific information, go to that specific source. Wikipedia, however, offers an easy to use, easy to edit, database of that information- using this database is much easier than hunting down each independent source.

We would, in a way, be "blessing" content, as we would only include wikis with reliable and in-depth information. I don't see why that's a bad thing. 8bit (talk) 17:28, 7 July 2009 (UTC)

  • Absolutely oppose. Quite aside from concerns about "easter egg" external links where our readers would assume they're being directed to Wikipedia pages, we are are not a tool for Wikia to boost their site traffic. – iridescent 20:06, 7 July 2009 (UTC)
I also think it's a bad idea. Wikipedia has quality control and referencing standards, while Wikia doesn't. This might trick people into thinking Wikia is part of Wikipedia, and integrating Wikipedia with Wikia on a hyperlink level wouldn't be any different than integrating with, say, Encyclopedia Britannica (which actually has more quality control).--ZXCVBNM (TALK) 05:35, 13 July 2009 (UTC)

Show if only bot edits when determining "(top)"

I like to check my contributions list to see if I have been reverted or someone has made an addition to an article I just edited (sometimes the additions are inappropriate). This is made harder when "top" no longer appears by my edit of the article just because of SmackBot. And I found an unusually large number of articles I had edited had SmackBot at the top of the history, meaning I had to do a lot of checking of articles for no reason.

Is there a way to see if the article is still the way I left it, meaning only "real" edits cause "top" to disappear?Vchimpanzee · talk · contributions · 20:08, 9 July 2009 (UTC)

If you date your tags (which I assume is the problem) then SmackBot won't have to tidy up after you and would be free to hound some other poor soul. OrangeDog (talk • edits) 04:29, 10 July 2009 (UTC)
I have no idea what that means. Now it becomes a policy problem. Please follow me over there.Vchimpanzee · talk · contributions · 15:04, 10 July 2009 (UTC)
Never mind. User:Jarry1250 confirmed what I had always believed was true. So now I'm back to asking if we can somehow still see "top" beside our contributions if SmackBot has been there?Vchimpanzee · talk · contributions · 15:36, 10 July 2009 (UTC)
Not being a WP dev (yet?) my answer is only in terms of the principle, but since bot edits (and it's not only SmackBot you're talking about of course) are identified as such to the system (which can thereby display "b" in watchlist etc.) it should theoretically be possible to vary the "(top)" indicator in the scenario you describe (perhaps substituting "(top-b)" etc.). Let's see what the devs have to say about the practicalities of implementing such a change. PL290 (talk) 15:49, 10 July 2009 (UTC)
The fact remains, that if you dated you maintainance tags yourself then SmackBot isn't going to do anything. If you don't know what that means then look at the edits that SmackBot is making. OrangeDog (talk • edits) 16:48, 10 July 2009 (UTC)
I understand, but I'd never get anything done if I had to think about all that stuff. It has only been recently that I even put URLs with sources unless that was all I put there.
And User:Jarry1250 says I shouldn't. Go here to discuss that. [5]Vchimpanzee · talk · contributions · 17:16, 10 July 2009 (UTC)
I used to leave all the clean up to bots, but it's really not difficult to remember what the current month is. If you really want to speed up your tagging, try WP:Friendly. OrangeDog (talk • edits) 21:28, 10 July 2009 (UTC)
Did anybody mention that this is what your watchlist is for? If you put the pages you want to watch in your watchlist, you'll be able to see at a glance if the last edit was done by Smackbot. --LP talk 01:45, 11 July 2009 (UTC)

(outdent) I've taken the liberty of renaming this section to reflect what's being proposed. I think it's a good suggestion and I want to ensure it's aired sufficiently. The original section name, albeit amusing (at dear SmackBot's expense!) risks the real discussion being overlooked by interested parties who may not even have read it. PL290 (talk) 09:25, 11 July 2009 (UTC)

Thank you, PL290. I should have named it better myself, but I couldn't resist. I'm pleased that two of my suggestions out of the three made over the weekend are worth considering, even if none of them make the grade. And especially pleased that one of the three is regarded as worthwhile.
Lord Pistachio is right. Certain articles I edit so frequently I should just put them on my watchlist.Vchimpanzee · talk · contributions · 17:05, 13 July 2009 (UTC)

Merge two templates

I'd like to have your input on the proposed merge of two template: {{Technical}} and {{Technical (expert)}}. Please visit Wikipedia_talk:Make_technical_articles_accessible#Merge. Debresser (talk) 11:05, 13 July 2009 (UTC)

Add Uploader to the list of rights admins can assign

{{resolved}} The manually assignable 'confirmed group' with userrights identical to those of the 'autoconfirmed group' has been created. The 'Uploader group' has been removed. Ruslik_Zero 19:13, 21 July 2009 (UTC)

The following discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
bugzilla:19535 superceded by bugzilla:19611

Wikipedia:Uploaders is a rarely used usergroup that only ever had one member since its inception in November 2008. Nevertheless, I had to flag down a steward to remove the right from the now inactive user it was created for. Lar suggested that it be added into the list of rights grantable/retractable by admins. At the very least, bureaucrats should be able to assign and remove it. This is a precursor to a bugzilla (that I hope someone else will file) to ensure consensus exists for this. –xenotalk 02:55, 5 July 2009 (UTC)

  • Support (since I suggested it be made such a right on my talk) The uses of this right are fairly limited, since it's a way to jumpstart autoconfirmed status, but having to find a steward to add it and then again to remove it make it even less useful. As for filing a Bugzilla , it's not that scary, but I'll either mentor Xeno on it or do it myself (or laze, and someone else will :) ... my usual strategy ) if this meets with sufficient approval. Hopefully this is fairly low controversy... ++Lar: t/c 03:08, 5 July 2009 (UTC)
    Oh, I'm sure I could figure it out. I'm just quite lazy, as well. It might be a good idea to discuss whether adding "edit semi protected pages" to this user group and make it into a true "autoconfirmed starter kit" is a good idea - to make it slightly more useful and less rarely used. –xenotalk 03:13, 5 July 2009 (UTC)
    I've split this into a subsection below: #add edit-semi as a feature to "Uploader"?. There seems to be consensus at least to add "Uploader" as-is to the rights grantable/retractable by admins, so I'll file a bugzilla shortly unless someone else does/already has. –xenotalk 15:12, 5 July 2009 (UTC)  Done bugzilla:19535 –xenotalk 17:58, 5 July 2009 (UTC)
  • Comment From the linked page, Normally when a user signs up they have to wait four days and make ten edits before they become autoconfirmed. Autoconfirmed users have the ability to edit semi-protected pages and upload files. So it seems anyone with a registered account gets this automatically after 4 days and 10 edits. So what's being asked here beyond just leaving it alone and registered accounts auto-getting it after the said 4 days/10 edits? - ALLST✰R▼echo wuz here 03:25, 5 July 2009 (UTC)
    The main proposal is to give the ability to assign the right to admins. The secondary proposal, as an aside, is whether we should add the ability to edit semi protected pages in there. As to why we didn't just tell the person to wait four days and make ten dummy edits - you got me. However, I think with the edit-semi added in there, the right would be more useful. I have, at least once, lowered semi on a page so a brand new user could edit it. Instead, I could've just granted him the right for the first four days. –xenotalk 03:28, 5 July 2009 (UTC)
But why do admins need the ability to assign the right to upload/edit semi-protected pages, if the user automatically gets that right anyway after 4 days/10 edits? Shouldn't this be more about giving the admins the right to remove these features from users who are abusing them (copyvios, etc.)? - ALLST✰R▼echo wuz here 03:35, 5 July 2009 (UTC)
The right exists, it should be grantable by admin staff, be it an admin, or a bureaucrat. Stewards are supposed to be for-emergencies-only. Luckily Lar has a few hats so I knew he could use his en.wiki admin hat to come to the conclusion it was reasonable to remove it from the one user who held it, and his global steward hat to actually do it. But it was sub-optimal. Just to be clear: this won't change the way admins can act on users who are autoconfirmed, and we won't be able to remove an autoconfirm'd users' ability to upload files. It is just about giving us the ability to grant and retract the "Uploader" userright (which becomes redundant and useless once someone has autoconfirmed). –xenotalk 03:39, 5 July 2009 (UTC)
@Allstarecho: Brion created this right last year, in order to circumvent the delay for a given user to be able to upload (for good reason, as I understand it). If this sort of circumvention would be useful in the general case, then having stewards required to grant it and remove it, reduces its usefulness. I can think of situations where time is of the essence... someone from a museum, ad agency, PR outfit, charity, etc., contacts us, hot to make content contributions, (perhaps of something urgent) and then has to wait 4 days. It would be useful for an admin to be able to evaluate the request and enable them right then. As it stands now, the difference is that it requires a steward. This ISN'T about taking the uploader right away, it's about who can grant it. ++Lar: t/c 03:32, 5 July 2009 (UTC)
@Xeno: I don't favor that. ++Lar: t/c 03:32, 5 July 2009 (UTC)Let me clarify this a bit... I think the idea is not bad (your example of enabling a particular user instead of "dropping the fence" on an article, is a good one) but I'd rather stay focused on who can grant the existing right, as it's constituted, and consider changing it separately. We seem to have a problem with focus of the request as it is. ++Lar: t/c 03:55, 5 July 2009 (UTC)
So basically circumventing the 4 day/10 edits rule which I'm sure was put in place for a good reason as well, no? - ALLST✰R▼echo wuz here 03:35, 5 July 2009 (UTC)
Correct. Circumventing a rule when in the considered judgment of (someone) it makes sense to do so. The rule is circumventable now. If you think it shouldn't be, go talk to Brion. We're talking about who (someone) should be. Right now it's me and other stewards, which is cool by me but I figured why just stewards. ++Lar: t/c 03:46, 5 July 2009 (UTC)
And further, if an admin were to grant this userright they would be reasonably expected to look over the user's uploads and ensure they met image policy. –xenotalk 03:48, 5 July 2009 (UTC)
Exactly. It's on the admin's head to make sure it was used wisely. ++Lar: t/c 03:55, 5 July 2009 (UTC)
I'm not married to the idea of adding edit-semi in there, but I figured I would throw it out there. –xenotalk 03:39, 5 July 2009 (UTC)
  • I can't really think of a situation where I would want to assign this right. Obviously that means I'm not terribly creative, because a situation assuredly exists, but I'm straining. I guess if I knew the human behind the account name and they had some file they needed to upload. But apart from that I'm straining to see the purpose. I mean, the feature itself isn't unwise or deleterious. Just not terribly necessary. But that isn't a resounding vote of opposition, more of a comment. Protonk (talk) 04:51, 5 July 2009 (UTC)
    Allowing users who have emailed permissions to OTRS to upload rather than doing it for them springs to mind. BJTalk 06:22, 5 July 2009 (UTC)
They couldn't just wait the 4 days/10 edits? - ALLST✰R▼echo wuz here 06:26, 5 July 2009 (UTC)
I'm wondering how many times this needs to be explained to you. The right exists now. I can go create a brand new account, and grant it this right... right this very second. But xeno can't. That's because he's not a steward. This discussion is about broadening who can grant the right. It is NOT whether the right should exist or not, or whether waiting 4 days is an acceptable alternative. Please address your concerns to why admins should not be able to grant this right (given that stewards can). Thanks. ++Lar: t/c 16:22, 5 July 2009 (UTC)
If somebody is willing to release an image they own the rights to in order to improve one of our articles, but otherwise has no interest in making content adjustments, it seems rather odd to tell them that they cannot add the image or that they must jump through hoops by waiting 4 days/changing content 10 times before they can contribute their image. That said, I doubt I'll ever add this usergroup but that doesn't mean having the ability would be a bad thing. --auburnpilot talk 14:10, 5 July 2009 (UTC)
  • Support uploader though semi-edit unneeded: It's (ie the uploader flag) useless otherwise. The requests could be made as they are now at requests for userrights and evaluated on a per need basis, just as rollback, IP block exemptions and other admin assignable rights are currently done. The fact that they can wait 4 days changes nothing when there's a legit need to do something earlier and I don't really see the issue since it will require admin discretion on whether to assign it or not, and as is the flag is useless (ie practically no one can assign or remove it). Abuse may well happen on occasion, but that's why we have close to 2,000 admins and many vigilant volunteers to spot it and report it to the proper noticeboard for blocks to be issued and/or removal of the flag. Nja247 08:36, 5 July 2009 (UTC)
  • Usecase: new bots. Very often a BRFA is filed for an interesting new task, discussion occurs, a trial is approved... and then the process stalls for four days because the bot operator registered a new account. 'uploader' will always be a temporary flag: it would be granted in these circumstances, and then replaced with the full bot flag when the bot is approved. Ditto for admins creating alternate accounts for use on holiday or whatever, and various other situations like this where the account is new, but the owner is trusted. As such, the permission should (to be of maximum use) exactly duplicate the functionality of 'autoconfirmed', and it should definitely be assignable (and removable once it has been superceded by the autoconfirmed autopromote ticker) by admins. It is a much less volatile group of permissions than groups like 'rollbacker' and 'ipblock-exempt', which admins are already trusted with. Happy‑melon 11:13, 5 July 2009 (UTC)
  • Support for the purpose of bots, announced socks, things like that. I can't see the need to give this out to genuinely new users very often at all, but it would be nice to be able to bypass the formalities with a new account, but an old user. J Milburn (talk) 11:27, 5 July 2009 (UTC)
  • Support, seems highly useful. Stifle (talk) 13:41, 5 July 2009 (UTC)
  • Comment. An ideal solution would be to have an option to "force autoconfirmation" of a particular account. If it is not possible, than the creation of 'confirmed' usergroup with exactly the same userrights as 'autoconfirmed' would suffice. The last idea has already been discussed before. The 'uploader' is group is quite useless. Ruslik_Zero 15:02, 5 July 2009 (UTC)
    The below subsection seeks to expand "Uploader" (to the point where a rename might be useful, but that's extra grunt work) to include edit-semi. The other rights in autoconfirmed aren't really "first four-day critical" and would also make the right much more attractive to vandals and in turn force us to be stricter with granting the right. –xenotalk 15:07, 5 July 2009 (UTC)
    I read this discussion and as I understand removing 'autoconfirmed' group from '$wgImplicitGroups' will allow (for instance) administrators to assign this group manually to accounts that do not satisfy autoconfirmation conditions (but not to remove it from accounts that do). Ruslik_Zero 15:37, 5 July 2009 (UTC)
    Yes, and giving a new user full autoconfirmed will allow a vandal to immediately go on a page-move vandalism spree. On the balance, I would rather grant the "autoconfirmed-lite" offered up by the below. –xenotalk 15:40, 5 July 2009 (UTC)
    One would hope that we trust administrators with more judgement than to flag a vandal account. We're not talking about granting this to every man and his dog, here. Happy‑melon 15:50, 5 July 2009 (UTC)
    It would still increase the number of bad-faith requests we would have to deal with, and admins aren't immune to social engineering. I could see the value in doing it this way if we didn't already have a minimalist userright to tag it onto. –xenotalk 16:34, 5 July 2009 (UTC)
    So for a budding pagemove vandal, option 1 is to convince an administrator that they are a bot account, a legitimate sock, or some other account owned by an already-trusted user, which we'd probably expect to be confirmed with cross-editing, or that they are an eager-beaver contributor whose uploads are going to be so amazing that everyone is going to be watching; while option 2 is to wait four days and make ten dummy edits? I know which option I would choose. Happy‑melon 17:11, 5 July 2009 (UTC)
    If you want to make an alternate proposal that would allow us to do away with the Uploader userright altogether by allowing admins to grant autoconfirmed, I'll support it - I just think it will be far easier to attain consensus to give us the ability to grant the expanded "Uploader" (at which point it should probably be renamed). –xenotalk 18:01, 5 July 2009 (UTC)
  • Support uploader. This comes up at the help desk occasionally. A new user has created an article and wants to upload an image for use in it but is stymied. By visiting the article we can easily determine whether granting the right is a good idea in the particular circumstance, and can question the user right there as to whether their image is free, and if not, whether it qualifies as fair use. Because of the immediacy of granting the right, whereas most users are left swimming even after they make their 4 days/10 edits threshold, if a user uploads shortly thereafter we can follow the upload, fix the FUR, etc. This type of natural follow-up is unlikely to be done after we've told them to wait four more days.--Fuhghettaboutit (talk) 16:55, 5 July 2009 (UTC)
  • Support Seems like a good idea, and no one really seems to be against it (don't see why anyone would), so why not? hmwithτ 17:18, 5 July 2009 (UTC)
  • Support, provided the right is removed once a user reaches auto-confirmed status. Nakon 17:35, 5 July 2009 (UTC)
  • Support Yes it will be rarely needed, but right now the WP:BURO involved with assigning it makes it totally unhelpful whereas this small change would simply make it an obscure yet helpful feature, sort of like the global blocking whitelist and the flood flag at meta. MBisanz talk 18:05, 5 July 2009 (UTC)
  • commentOne obvious use would be when an admin is teaching a new user in meatspace how to edit wikipedia.Genisock2 (talk) 18:24, 5 July 2009 (UTC)
  • I think we should instead spend our effort into allowing users to be set as autoconfirmed by admins, rather than assigning individual rights from the autoconfirmed group. I oppose this proposal for that reason. See the subsection below - it has already started. Soon we'll be having polls on a regular basis to add random rights to the uploader group. Just allow admins to set a user as autoconfirmed. No need for individual rights. - Rjd0060 (talk) 18:27, 5 July 2009 (UTC)
    While that would be ideal, the rights remaining in autoconfirmed would be usable only in the minority of scenarios (saving books to user pages, anyone?), with the exception of the move right, which was the reason the autoconfirmed group was created in the first place. Titoxd(?!? - cool stuff) 21:43, 5 July 2009 (UTC)
    I still see no reason to break up random rights when there is an alternate solution. - Rjd0060 (talk) 13:45, 6 July 2009 (UTC)
    The alternate solution gives the brand new user the right that the autoconfirm delay was specifically tailored for, namely, the ability to move pages. Brand new users rarely need to move pages and if they do, they can ping an administrator (or any autoconfirmed user) to do the move directly, or make a request at Wikipedia:RM#Requesting uncontroversial moves rather than applying for "force" autoconfirmed. –xenotalk 13:55, 6 July 2009 (UTC)
    Indeed. However, that same argument works for the uploader rights too. Brand new users rarely need to upload files. I'm still in the thought that we should be able to set the autoconfirmed group (which I'd prefer) or make no changes and all users will need to wait to become autoconfirmed themselves. - Rjd0060 (talk) 14:01, 6 July 2009 (UTC)
    Just because it's rare doesn't mean it doesn't have occasional value. If you really want the ability to assign autoconfirmed, please propose it and I will support. –xenotalk 14:08, 6 July 2009 (UTC)
  • Support per MBisanz. –Juliancolton | Talk 18:36, 5 July 2009 (UTC)
  • Support, it is a potentially-useful feature that already exists, but whose implementation obstructs its use. Titoxd(?!? - cool stuff) 21:43, 5 July 2009 (UTC)
  • Strong oppose – the current time-base and edit-threshold for becoming autoconfirmed were carefully set, after much discussion, and I see no reason why users should be able to leapfrog that probationary period. Patience (new users waiting to be able to upload etc.) has always worked in the past. ╟─TreasuryTag►consulate─╢ 21:48, 5 July 2009 (UTC)
  • The right already exists. I can, as a steward, go give it to you right now (not that it would have any meaning to do so since you're already autoconfirmed, but I could), and then take it away again (not that taking it away would change by one iota what you can do). So your opposition is misplaced, you need to instead explain why you think stewards should be the only users to be able to grant it. Alternatively, you could start a different proposal to say you want the Uploaders group to go away entirely, but that isn't this proposal. Hope that helps, this seems to be a somewhat confusing point. ++Lar: t/c 23:15, 5 July 2009 (UTC)
  • Given that it was created by a sysadmin for use by one account (and I know that was the case) I would assume that they just forgot to clean up after the user was done with the rights. There never was discussion to see if we even wanted or needed an uploader group. Yeah, stewards can assign it. So? They won't assign it so I don't really understand why that matters. - Rjd0060 (talk) 13:45, 6 July 2009 (UTC)
  • Eh? I'm a steward... your argument doesn't follow. Unless a clear proposal comes down the pike and gains consensus (that this right is never to be assigned), any new user who turns up on my talk page and asks for the right, along with a good reason why, will get it from me. ++Lar: t/c 14:29, 6 July 2009 (UTC)
No they won't, see my talk, that's probably going too far, with a proposal afoot to approve this. ++Lar: t/c 15:26, 7 July 2009 (UTC)
  • I don't think that would be appropriate for a number of reasons and policies that you as a steward are expected to follow. But that is unrelated to this discussion so I won't elaborate. - Rjd0060 (talk) 17:48, 6 July 2009 (UTC)
  • This is pretty much exactly why I proposed admins be able to assign this; because Lar, wearing his global steward hat, isn't supposed to be granting rights without direction from an en.wiki admin. Which of course, he is as well. So while he's "judge, jury, and executioner", it would be nice for him to just wear the one hat when granting or revoking this right. Of course, you want the right to go away altogether, but I still don't think that opposing this proposal is really a constructive way to go about that. –xenotalk 18:24, 6 July 2009 (UTC)
  • Wasted time? Not only our time, but that of the system administrators who surely have better things to do than fulfill requests from the English Wikipedia who can't make up their mind. But thanks for the feedback. - Rjd0060 (talk) 14:03, 6 July 2009 (UTC)
  • I'm told both of these sister proposals are very simple fixes. And other than your procedural oppose, and one from someone who apparently didn't read the several good reasons presented to issue this (both as-is and expanded) right, our mind is made up. –xenotalk 14:39, 6 July 2009 (UTC)
  • Support any way we can manually let people contribute before they are autoconfirmed. Chillum 14:03, 6 July 2009 (UTC)
  • Oppose: You want to use an uploader group as a hack for an autoconfirmed group? I'd much rather see this hastily-implemented group removed altogether and possibly replaced at a future date with a proper solution for bypassing autoconfirmed status (essentially what Rjd0060 said above). --MZMcBride (talk) 14:43, 6 July 2009 (UTC)
    This seems to belong in the below section... That being said, would you still oppose if it was renamed "semiconfirmed" (or something)? Because it seems like "a solution for bypassing autoconfirmed status" by any other name would still smell as sweet. –xenotalk 14:48, 6 July 2009 (UTC)
    Rollbacker, account creator, autopatroller, now uploader... they're all different ways of creating a trusted user group. If that's what you want, make that. (Though I'll note that this idea of a trusted user group is likely politically infeasible, which is why people resort to hacks like this.) These single-right user groups are getting ridiculous. --MZMcBride (talk) 15:06, 6 July 2009 (UTC)
  • Oppose - if anything, the uploader group should be removed. Free images should be uploaded to commons, which doesn't have the autoconfirm restriction on uploads (primarily for this reason IIRC). So the only use case for this would be a new bot or a new user who already has non-free image experience from somewhere else, who has a pressing need to upload non-free images, both of which seem like kind of a stretch. Mr.Z-man 15:27, 6 July 2009 (UTC)
    ...and what of expanding and renaming it per the below? (I agree as it stands, it's close to useless) –xenotalk 15:42, 6 July 2009 (UTC)

add edit-semi as a feature to "Uploader"?

Somewhat related previous discussion: Wikipedia:Village pump (proposals)/Archive 38#Allowing administrators to grant autoconfirmed status

So we can be sure what people are supporting. I also support adding edit-semi to "Uploader".

Potential uses: newly created bots approved for trial1, legitimate socks2, jump-starting a verified good-faith IP's new account onto a semi-protected page (i.e. to avoid having to lower semi)3, allowing brand new temporary accounts to bypass edit filters if large-scale cleanup projects are tripping good faith IPs up (think algae)4, ...

It would make it a much more useful usergroup, assignable at admin discretion for reasons to be determined at WT:PERM, to "jumpstart" autoconfirmed and removed after the autoconfirmed period ends. –xenotalk 14:54, 5 July 2009 (UTC) potential uses added at 15:29, 5 July 2009 (UTC)

  • Support, providing this is given only to "new" users who aren't actually new- there's no reason to wait before bots and legitimate socks can edit semi-protected articles. J Milburn (talk) 15:04, 5 July 2009 (UTC)
  • Neutral; I don't see a compelling need for it, but there's nothing especially bad about it either. Stifle (talk) 15:06, 5 July 2009 (UTC)
  • Support a useful tool that has very minimal associated risks. Much less of a big deal than some of the other flags admins are already entrusted to assign. Happy‑melon 15:53, 5 July 2009 (UTC)
  • On reflection I support this. It's the right slice of rights to be able to grant temporarily. ++Lar: t/c 16:17, 5 July 2009 (UTC)
  • Support Seems like a good idea to me. hmwithτ 17:19, 5 July 2009 (UTC)
  • Since it seems to be coming out in favour, I've made note of this proposal in bugzilla:19535 filed for the above proposal with a caveat to check back for objections. –xenotalk 17:58, 5 July 2009 (UTC)
  • Oppose - for the same reason I opposed the uploader group all together. See here. - Rjd0060 (talk) 18:28, 5 July 2009 (UTC)
  • Support, as this is effectively bypassing autoconfirmed, as I wrote above. Titoxd(?!? - cool stuff) 21:43, 5 July 2009 (UTC)
  • Strong oppose – the current time-base and edit-threshold for becoming autoconfirmed were carefully set, after much discussion, and I see no reason why users should be able to leapfrog that probationary period. Patience (new users waiting to be able to edit semi-protected pages etc.) has always worked in the past. ╟─TreasuryTag►consulate─╢ 21:48, 5 July 2009 (UTC)
    There's four good reasons listed above. –xenotalk 02:13, 6 July 2009 (UTC)
    If an admin sees a productive user who is not auto-confirmed, then the admin can help the user be more productive and the encyclopedia grows. If a users fucks around with the exception, then they can be blocked and have the exception removed. I see no good reason put forth to no do this. I don't think the threshold was carefully set either, it may have been carefully set at first but it has not changed in years. Chillum 14:12, 6 July 2009 (UTC)
  • Support very good idea. — Jake Wartenberg 00:20, 6 July 2009 (UTC)
  • Support any way we can manually let people contribute before they are autoconfirmed. Chillum 14:03, 6 July 2009 (UTC)
  • Oppose: Listen to Rjd. Stop the spread of bad hacks. --MZMcBride (talk) 14:46, 6 July 2009 (UTC)
    I have read the code that handles this stuff. It is actually very elegant. What do you mean by bad hack? Chillum 14:54, 6 July 2009 (UTC)
    If it's a "trusted user" group, call it that. But right now it's an "uploader" group with the purpose of bypassing the upload restrictions. Manipulating the software like this is a bad hack. --MZMcBride (talk) 15:06, 6 July 2009 (UTC)
    The autoconfirmed and upload userrights are explicitly granted to administrators so they can, in principle, perform these actions without the implicit 'autoconfirmed' group. Is this also a "bac hack"?? The whole permissions system was designed to allow a many-many mapping between permissions and groups, so that rights could be bundled up and parcelled out any which way. While I agree that the group is improperly named, that doesn't magically transform an entirely correct use of the software - to create a group with particular permissions that can be assigned to users - into a horrible hack. I also agree that the option to manually grant and revoke the implicit 'autoconfirmed' group is preferable. Once again (I remember you taking exactly the same stance with the edit-lead JS), just because a better solution could, at some distant and indeterminate point, be realised doesn't mean we should not make any movement to implement an intermediate solution. Happy‑melon 15:37, 6 July 2009 (UTC)
    Your logic is flawed. By allowing hacks to be implemented and used in place of proper solutions, all incentive to implement a proper solution is lost. Necessity is the mother of invention, as the saying goes. You're suggesting we use a bad hack to (seemingly) remove the necessity. When local bureaucrats can create (and modify) custom user groups and adding new groups doesn't require sysadmin intervention, and when there's a coherent proposal for a "trusted user" user group, I'll gladly support. Until then, I'm not going to settle for half-baked half-measures. Sorry. --MZMcBride (talk) 19:59, 6 July 2009 (UTC)
    This is not a hack, this is how the software was designed to work. This feature is already available with the regular software, this is about if we should use it. Chillum 22:34, 6 July 2009 (UTC)
  • Oppose - the use case for this, while better than having "upload" alone, is still pretty questionable. For bots, if the bot account is created at the same time as the BRFA, chances are 4 days will pass before it starts a trial and unless its only going to be editing semi-protected pages, the odds of it needing to edit one in its first 10 edits are pretty small (only about 0.1% of all pages are semiprotected). For legitimate socks, people can just wait; just saying "legitimate socks" doesn't make it a use case - why would brand new legitimate socks need to edit semiprotected pages? The good-faith IP's new account is really the only use case that's somewhat sensible but it happens so infrequently, I really don't think it justifies it. For allowing new accounts to bypass some abuse filters, the abuse filter should be fixed or disabled so that it doesn't block edits that aren't bad. Either way, the filter would still need a temporary edit, to either exempt individual users, or exempt the group. We shouldn't set all the filters to ignore people in the temporary group as it would just be adding extra conditions that would have no effect 99.99% of the time. Additionally, the implementation is poor. Uploading files has even less use than editing semiprotected pages, so tacking this onto the "uploader" group is just silly (since it has nothing at all to do with uploading files). Mr.Z-man 15:54, 6 July 2009 (UTC)
    If this were carried, I would suggest a rename to "semiconfirmed" or something. –xenotalk 15:57, 6 July 2009 (UTC)
  • Oppose. I've read the stated rationales for this and I'm not convinced. FWIW, you cannot set an account to 'autoconfirmed' in any way, there's simply no part of the software that allows it. All of the groups based on autopromotion are this way. You would have to make a normal user group and give it the appropriate rights similar to how autoconfirmed is set up. ^demon[omg plz] 18:39, 6 July 2009 (UTC)
    That's what I assumed would have to be done. Thanks for the info. - Rjd0060 (talk) 19:02, 6 July 2009 (UTC)
    That is not strictly true: by removing 'autoconfirmed' from $wgImplicitGroups, it becomes visible (and hence assignable) in Special:UserRights. However, it is also still implicitly assigned by the software, so whether a user has the group is determined on a highest-takes-precedence basis; so it's still not possible to remove the permission in this way. And it also makes the group visible on Special:ListUsers, etc, which can be a bit of a clutter. Happy‑melon 13:13, 7 July 2009 (UTC)
  • Oppose - I would not support adding this userright to the rights admins can add; in fact, quite the opposite. I would prefer that it is actually removed. This group is just a hack added to bypass the autoconfirmed right. The better solution for this case is actually allow admins to add the autoconfirmed right. That way, it reduces the whole bureaucracy of an additional usergroup. If a person (or bot) can be trusted with the uploader userright, can't they be trusted with the edit-semi right too? It just seems like too much trouble for what it's worth. (X! · talk)  · @265  ·  05:21, 7 July 2009 (UTC)
    This is what this section seeks to do. Semiconfirmed without the ability to move pages. But again, if folks think this right should be torpedoed in favour of having the ability to grant full autoconfirmed status, why hasn't anyone proposed it? –xenotalk 05:23, 7 July 2009 (UTC)
    It had been proposed here, the discussion ended up in no real consensus. May be proposed again. Cenarium (talk) 13:23, 7 July 2009 (UTC)
    13 to 6 in favour? Plus the above supporters (and the "opposers" who opposed in favour of grantable full autoconfirmed)? Seems to have consensus now... –xenotalk 15:01, 7 July 2009 (UTC)
    Note you can make it 14 in favour, as I fully support any such flag for when there's a legit need to do so, ie the potential uses noted above. Assignment would require admin discretion and we have close to 2,000 admins and many vigilant volunteers to spot and report any potential abuse, as with rollback, ip block exemption, abuse filter editor flags, etc. Nja247 10:19, 8 July 2009 (UTC)
    I won't be available for the next few days. If you feel there's sufficient consensus, go request a bugzilla. This principle is: the autoconfirmed implicit usergroup is deprecated, and replaced by an (explicit) usergroup "confirmed", which can be added by admins, and is automatically assigned by the software to users with 10 edits and 4 days since registration. The autopromotion system is the one used by the Extension:FlaggedRevs. Still the undecided issue on whether admins should be allowed to remove the confirmed usergroup. Cenarium (talk) 02:06, 11 July 2009 (UTC)

bugzilla:19611 creates "confirmed" usergroup

FYI Brion has pre-empted the bug report I filed to expand uploader, instead filing a bugzilla to create an assignable "confirmed" usergroup. I believe this has been implemented and will be seen in the near future. –xenotalk 19:24, 14 July 2009 (UTC)

And now it works. It's identical to autoconfirmed and 'uploader' has been deep-sixed. FWIW, I think "move pages" shouldn't be in there, but we'll cross that bridge if we need to. –xenotalk 16:46, 21 July 2009 (UTC)
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made on the appropriate discussion page, such as the current discussion page. No further edits should be made to this discussion.

Edit summary and What's this?

In the edit window, there's a link at the bottom labeled "Editing help", which opens in a new window. There are two other links that should open new windows: "Edit summary" and "What's this?" (next to the minor edit box). Some browsers don't save information in text boxes once you navigate away from the page. This will help prevent lost information. --Cryptic C62 · Talk 18:51, 7 July 2009 (UTC)

I seem to remember this having once been the case, but that the MediaWiki messages controlling them were migrated to use wikitext instead of raw HTML, which meant that it was no longer possible to force the link to open in a new window. Can someone confirm this? {{Nihiltres|talk|edits}} 20:46, 7 July 2009 (UTC)
Perhaps pages should note that navigation (and clicking those links) may cause users to lose text in browsers such as IE. hmwithτ 13:44, 14 July 2009 (UTC)

Talk page formatting suggestion

Talk pages currently function in exactly the same way as articles, even though they are usually used solely for message-board-like discussion. This leads to formatting that's all over the place, the need to use colons to indent text, constant adding of tildes, messy code, and edit conflicts whenever multiple people try to comment on the same section. I propose that the software be modified so that sections on non-article pages can be delineated as "message sections", in which people are able to post in a delineated, message board format with automatic indents or de-indents, as well as support for expandable boxes, automatic dates/signatures, and separate, edit conflict-free posts. This would speed up and make the message posting process much easier, especially for inexperienced users, removing the need for bots to add signatures, date tags and such.--ZXCVBNM (TALK) 21:24, 9 July 2009 (UTC)

I am not sure what you meant when you said that talk pages oftenr read like "message-board discussion". What has struck me is that, despite a tag that sometimes appears reminding us that the purpose of the talk pages is to discuss the article as it appears in Wikipedia, not the subject in general, many people do use these talk pages as a means to discuss the subject(indeed, I was guilty of this when I first started editing Wikipedia, some years ago). How would your proposal meet this problem? The worst of the talk pages I have seen are those which are used where people express personal views on television or radio programmes or pop groups - Wikipedia is not meant to be fan club. ACEOREVIVED (talk) 23:04, 9 July 2009 (UTC)
It's already in the works: m:LiquidThreads --Cybercobra (talk) 05:25, 10 July 2009 (UTC)
That project started three years ago now and hasn't gotten very close to adoption yet. Rmhermen (talk) 02:29, 11 July 2009 (UTC)
This is something the usability initiative is looking at. --Izno (talk) 02:45, 11 July 2009 (UTC)
Yes, that LiquidThreads project is EXACTLY what I mean. That really should be sped up and instituted across Wikipedia, as the talk pages are extremely counterintuitive and have no standard message board tools. Have there been any votes or discussions about that, or would it be possible to create some kind of poll? It seems to still be unstable and in development right now, but if it could be pre-approved, that would make the adoption process faster.
@ACEOREVIVED: A message board does not mean a fan forum, it's a message board dealing with Wikipedia. Of course, discussions about personal views are unavoidable, but on popular pages they will probably be shot down. I don't think it matters THAT much, and this would be for major usability reasons rather than actually making Wikipedia into some kind of forum.--ZXCVBNM (TALK) 07:17, 11 July 2009 (UTC)
See my standard rant at User:Dcoetzee/Why_wikithreads_are_bad. I've offered to contribute to LiquidThreads on several occasions but I usually get spurned or ignored. Dcoetzee 09:42, 11 July 2009 (UTC)

LiquidThreads is in development, and the Wikimedia Foundation recently contracted Andrew Garrett, the freelance programmer responsible for the AbuseFilter, to polish off the extension in the hope of getting it enabled on WMF wikis by the end of this year. Andrew has been doing a lot of work on it in the past few weeks; I have no idea how close it is to completion, but it is significantly closer than many other features. Happy‑melon 10:16, 11 July 2009 (UTC)

If installed, is it optional or mandatory? In other words, would it still be possible to see and use discussions as they are now, or would one be stuck with that formatting (which looks rather annoying in the demonstration page linked on Mediawiki.org)? Dragons flight (talk) 10:32, 11 July 2009 (UTC)
Wikieducator is using build 1.1 of LiquidThreads. Andrew's clocked it up to 2.0α (via 1.12 I believe!). Happy‑melon 10:53, 11 July 2009 (UTC)
Well yes, it is being improved..., but you didn't actually answer my question. Does the adoption of LQT totally displace the current talk page system (so that we could no longer see or edit the pages using the formatting and interface they have now), or does it merely add a new interface on top of the current system. Dragons flight (talk) 11:10, 11 July 2009 (UTC)
I don't know, not having an installation of the latest version to test on. I would hope not. Happy‑melon 11:28, 11 July 2009 (UTC)
To my understanding, LiquidThreads is applied directly to the Wiki itself. I really don't see why editors should be able to choose between LiquidThreads and Wikithreads, seeing as Wikithreads have some fundamental flaws, especially for anon users who can't be expected to choose to use LiquidThreads. I think that there should be a number of skins for LiquidThreads to change the formatting to a user's liking, however, all users should have to use the system for reasons stated by User:Dcoetzee, such as being able to screw up other peoples' posts and the problem with certain posts not being properly formatted. It's good to see that progress is being made: I can't see why one would want to keep the Wikithreads system from a purely functional standpoint.--ZXCVBNM (TALK) 18:01, 11 July 2009 (UTC)
"such as being able to screw up other peoples' posts": Does that mean admins will have to be bugged to take care of pages like this? Anomie⚔ 20:27, 11 July 2009 (UTC)
You have a point, where advertisements and spam are concerned. While vandals can change others' messages, vandals can also post them. Right now, it's easy to delete that kind of thing from pages, and since Wikipedia is so large, it would be a chore for that kind of thing to be done by admins. I still don't think the ability to change others' messages is a good idea, so how about some kind of "mark as spam" option that would be attributed to a certain user and could only be used by registered users? (ex. "Zxcvbnm marked this message as spam" in the history), so that if it wasn't spam, someone could revert it and block the user if they are abusing it? It would have the dual function of increasing transparency (since you could only delete an entire message at a time) and preventing users from editing others' messages, while still allowing it to be reverted.--ZXCVBNM (TALK) 21:29, 11 July 2009 (UTC)

←It's not just spam that's a problem. For instance, I've been dealing with a persistent individual on a rotating IP who keeps adding nonsense crap to Talk:Mothman and Talk:Satan. I and others have been removing it as "off-topic" and disruption (as it's been explained to the user multiple times that gibberish isn't helping improve the article). Plus, removing his comments from my User Talk page, as is my right. What happens to that with Liquid? — The Hand That Feeds You:Bite 15:42, 13 July 2009 (UTC)

I think that a "delete as spam" button would be easier than manually deleting all instances of disruptive posts and vandalism. If only users could delete others' posts, it would be easy to block a user who is continually deleting them. Anons would be able to comment, but not delete posts. Since it's already possible to delete posts now, nothing would change except the inability to edit posts.--ZXCVBNM (TALK) 07:41, 14 July 2009 (UTC)

Exclude protected pages from rel="nofollow"

The purpose of rel="nofollow" is to deter untrusted contributors to a site from using it for link spam. But administrators are trusted contributors to Wikipedia. Since we don't give adminship to spammers, and since spam is removed when a page is protected, we can trust protected pages not to have spam on them. I suggest, therefore, that rel="nofollow" not be applied to links on fully protected pages (by which I mean pages that one must be an admin to edit). NeonMerlin 20:15, 31 July 2009 (UTC)

Uh... something tells me this is a bad idea. --Izno (talk) 20:32, 31 July 2009 (UTC)
"since spam is removed when a page is protected"[citation needed] - I don't believe every admin reviews every external link on a page when protecting it, especially if the reason for protection has nothing to do with external links. Also, what would the purpose be? How would Wikipedia benefit from this? Mr.Z-man 23:34, 31 July 2009 (UTC)
"Remove rel=nofollow..." is not, IMO, ever going to be a viable proposal on a website available for open editing. What benefits does this change bring to this encyclopedia? (also)Happy‑melon 12:28, 1 August 2009 (UTC)
How about if admins could choose to exclude a protected page from rel=nofollow as long as it remained protected? @Mr.Z-man The benefits would be two-fold: First, we'd be helping readers find other relevant content via Google, and second, we'd probably incur fewer retaliatory nofollows from other webmasters and thus get higher search-engine rankings ourselves. NeonMerlin 23:50, 4 August 2009 (UTC)
Okay, so what if the admins' account is somehow compromised? What if the admin has immatured since his/her RfA, and can no longer be trusted?
What if a subtle piece of spam isn't removed?
There's too many problems with this proposal. I dream of horses (T) @ 01:54, 5 August 2009 (UTC)
We help readers find other relevant information by putting it in the external links sections. Google's results for 3rd party sites are not our concern, SEO's abusing our site for their own gain is. As for "retaliatory nofollows," that article is the first I've ever heard of someone doing that; Wikipedia articles are typically in the top 5 or 10 search results, so they obviously haven't had much of an effect. We only have a few dozen fully protected articles, it wouldn't really make much of a difference. Mr.Z-man 02:33, 5 August 2009 (UTC)
Retrieved from "http://en.wiki.x.io/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_49&oldid=1243247320"