Wikipedia:Village pump (proposals)/Archive 49

Add links
Source: 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

The [edit] link for sections

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

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". –
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. –
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)
  • Oppose as I feel that the encyclopedic and editing elements of Wikipedia should not be moved so close together, however, the opt-out will mean that I wouldn't be affected in any case... ╟─TreasuryTag►hemicycle─╢ 12:15, 27 May 2009 (UTC)
  • Support, as per my comment in the preceding section. --Stephan Schulz (talk) 12:24, 27 May 2009 (UTC)
  • Support, per useability study. -- Avenue (talk) 12:35, 27 May 2009 (UTC)
  • Support, in principle; there are technical caveats, of course (and some aesthetics :D). Happy‑melon 12:44, 27 May 2009 (UTC)
  • Support. Thank you for separating the aesthetics/display issue from the location issue, and noting that there can be an opt-out provision via a preference/gadget. -- John Broughton (♫♫) 13:11, 27 May 2009 (UTC)
  • Support. Anything that can help the newcomers. Rettetast (talk) 13:21, 27 May 2009 (UTC)
  • support, per Fisher (usability study) and Broughton. R. Baley (talk) 13:52, 27 May 2009 (UTC)
  • Oppose. Having the edit link in a different horizontal position for every section is counter-intuitive and inhibits efficient use of the UI. New users encountering a UI for the first time are best served by having UI elements in consistent locations—standards in the field of usability testing are, AFAIK, quite clear on this point. Including an "opt-out" for experienced users is thus no panacea; it is new users about whom I'm concerned with this change. Powers T 13:53, 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
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)
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.
    WP Physics
    } 00:32, 28 May 2009 (UTC)
    • This is the problem with rushing directly into polling without adequate time for development or testing. There are more alternatives than the one here in the poll. Mr.Z-man 06:00, 28 May 2009 (UTC)
      • Erm, there was testing, see User:OrangeDog/Headings (which was mentioned above) --Cybercobra (talk) 09:05, 28 May 2009 (UTC)
        • And as I pointed out above, those tests are flawed to the point of uselessness. Also, there were only 6 hours between the time when the test page was linked here and when the poll started. That is not adequate time for testing a major change to the interface. Mr.Z-man 16:02, 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)
    • There are other ways to fix the issue besides this one. Mr.Z-man 16:02, 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)
  • 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)
  • 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. –
    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)
  • 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. –
        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
      T • C • L
      ) 18:01, 31 May 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!
    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)
  • 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. –
      T • C • L
      ) 14:15, 2 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 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)

Edit links arbitrary break 2
   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)
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. –
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. –
    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)
  • 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

T • C • L
) 14:29, 20 June 2009 (UTC)

See also:
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.wikipedia.org/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.

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
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.wikipedia.org/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

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
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.--

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 ;-) --
talk
) 11:49, 29 June 2009 (UTC)

Highlight wikilinks to disambiguation pages

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: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)

"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?

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

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
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."
    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.
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.
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.
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.
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)
  • Admins need to be able to unblock themselves just in case they fail hard like this noob did: [2]. –xenotalk 19:25, 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.
    247
    09:35, 5 July 2009 (UTC)

New category for promotional articles

I recently had an observation about

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: {{
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

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

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)

Designate a place (colored box?) on discussion pages for hyperlinks to relevant, encyclopedic, public-domain sources

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)

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 {{
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. –
T • C • L
) 20:28, 1 July 2009 (UTC)
 Done. See the documentation for details. –
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? –
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.
    247
    09:29, 5 July 2009 (UTC)

External Links and "nofollow"

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

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:CHU. Kusma (talk
) 08:51, 29 June 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
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
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
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
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: {{

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.
    Talk
    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.
    247
    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.
    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.
    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.
    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)
  • FWIW, opposing a minor proposal because you'd rather a major one doesn't make any sense to me. Baby steps. –xenotalk 13:59, 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.
    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.
    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. ^
    [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.
    247
    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 "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(proposals)/Archive_49&oldid=1180252831"