Wikipedia:Village pump (proposals)

From Wikipedia, the free encyclopedia

Contents 1 Watched counter 1.1 A recent changes page for unwatched articles 1.2 Recent unwatched changes straw poll 2 The [edit] link for sections 2.1 AEB 2.2 Formal proposal 2.2.1 Arbitrary break 2.2.2 Edit links arbitrary break 2 2.3 Gadget 3 Provide "New Section" header box on virgin talk pages 3.1 structuring a straw poll 4 Quality awareness 4.1 Question 5 Admins able to block while blocked? 6 Create a more nuanced policy towards the use of the {{hidden}} template in articles 7 Default languages 8 Highlight wikilinks to disambiguation pages 9 Creating redirects with bot 10 RE: Disabling "create a book" 11 Second draft of updated arbitration policy 12 moving the menu 13 Articles for Deletion needs more automation 14 Edit head 15 Pronunciation to foreign place infoboxes 16 Userspace redirect 17 Maps could be much better 18 "Remember me for __ days" 19 New category for promotional articles 20 Move all Wikipedia pages in (disambiguation) format to /subpage format 21 Designate a place (colored box?) on discussion pages for hyperlinks to relevant, encyclopedic, public-domain sources 22 Bots fixing redirects in navboxes 23 usage of pagination + limit on size of pages 24 Three (instead of four) template warnings for users before reporting 25 Proposing a re-design of the editing toolbar 26 Do not delete before the New Pages Patrol has reviewed an article 27 Change search message, please 28 External Links and "nofollow" 29 Clicking on contribution history should lead to section 30 Language articles 31 Add Uploader to the list of rights admins can assign, add edit-semi as a feature?

Centralized discussion Proposals Discussions Recurring proposals Review: Provisional draft #2 of the new arbitration policy. Proposal: Proposal to create user-space redirects. Poll: Should WP:NOT#PLOT be reworded, moved, removed, or kept the same? RFC: Is there community support to change the constitutional relationship between ArbCom and Jimmy Wales? Poll: How does the community feel regarding how the civility policy is applied and enforced on Wikipedia? Discussion: Should notability criteria for pornographic actors be rolled back? RFC: Naming guidelines for Macedonia Preliminary (userspace) discussion on Wikipedia governance issues. RFC: Should Wikipedia prevent Google and other search engines from searching User pages? RFC: Should a bot unlink dates? RFC. Outside opinions are solicited on self electing groups. RFC: What is the community's opinion on using {{Italictitle}} to italicise certain articles' titles? RFC: What is the community's view of paid editing? Poll: About the preferred usage names as a result of WP:RFAR/West Bank - Judea and Samaria Discussion: Ordering and general presentation of talk page templates. RFC: Simplifying speedy deletion policy A new page to keep track of discussions throughout Wikipedia has been created: Wikipedia:Coordination A new noticeboard has been created: Wikipedia:Content noticeboard Note: inactive discussions, closed or not, should be archived. archive • talk • edit • history • watch

[edit] Watched counter

[edit] A recent changes page for unwatched articles

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

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

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

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

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

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

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

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

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

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

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

You could just use variables, like

"Recent Changes on Village pump (proposals): Lar, on 7/5/2009"

But it would be a good idea for rollback

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

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

[edit] Recent unwatched changes straw poll

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

• Support. –M^T 04:28, 5 May 2009 (UTC)
• Support. -- John Broughton (♫♫) 18:24, 9 May 2009 (UTC)
• Support sounds good to me. It does provide a route for vandals to find unwatched articles, but I think the benefits outweigh that. Rd232 ^talk 18:34, 9 May 2009 (UTC)
  • While technically true, any such vandalism would land the vandal with a kick to the pants, since their edit would float to the very top of this slow-moving list. –M^T 19:46, 10 May 2009 (UTC)
• Support. Mark Hurd (talk) 15:05, 10 May 2009 (UTC)
• Comment - Just file a bug. If its a good idea and technically feasible, someone will do it. The existence of a straw poll will likely have no effect. Mr.Z-man 15:26, 10 May 2009 (UTC)
  • Isn't a bug with a supportive straw poll more likely to be implemented soon than the same bug without? Rd232 ^talk 19:35, 10 May 2009 (UTC)
  • When people voice their support for a proposal, others become more inclined to try to see it implemented. This may include filing a bug report, searching documentation, speaking with devs directly, changing the relevant code, and submitting a patch. "Well, someone else will get to it eventually" is not the approach that we should take at this page. Even if the devs were entirely blind to community requests, your support would nevertheless encourage other editors (like me) to try to see this implemented. –M^T 19:46, 10 May 2009 (UTC)
    • With this specific proposal, it may, but only because the schema change would need approval from Brion. With the amount of work required to do this, I doubt a little straw poll is going to have a significant effect on any developer's motivation. Mr.Z-man 18:58, 13 May 2009 (UTC)
      • Then let's hope that it grows to become a much bigger straw poll :) as this might demonstrate a need for better tracking of unwatched pages   M  20:29, 13 May 2009 (UTC)
• Support - I really like this idea. I know from personal experience that non-obvious vandalism on poorly watched pages can go undetected... I have a couple such pages on my watch list & when I took a month off, I cam back to find some vandalism on one of them that had been sitting for 2+ weeks. --ThaddeusB (talk) 18:34, 13 May 2009 (UTC)
• Support - Great idea. Kevin Baas^talk 20:34, 13 May 2009 (UTC)
• Strong support: The admins can't do this alone. I love the idea. Dendodge _T\^C 20:38, 13 May 2009 (UTC)
• Bug 18790 has been created. Suggesting improvements (or establishing that there is a clear need for this) here is what will help with implementation, though voting at bugzilla in addition to here should help make it more noticed. At bugzilla, only 55 wp enhancements have 10+ votes, 19 have 20+, and 8 have 30+, out of over 1300. Registration is easy, and the vote link is at the bottom-right of the bug page, under 'related actions'. (Please use this feature to vote instead of leaving a comment at bugzilla, as comments are relayed to mailinglists).   M  22:31, 13 May 2009 (UTC)
• Support - Makes a lot of sense and fills a great need. J04n(talk page) 09:58, 22 May 2009 (UTC)
• Support - If this can be done without overloading the system, then by all means please do. (Every little bit helps in targeting vandalism.) --Ckatz^chat_spy 17:18, 26 May 2009 (UTC)
• Support per above proposal --unsigned by Assasin Joe
• Support per all the other comments that I read. This would be very useful to find vandalism in more hidden pages. –Drilnoth (T • C • L) 17:02, 27 May 2009 (UTC)
• Support – Wow, this is a really good idea. As long as it can be configured in software, I think it would be very useful. American Eagle (talk) 06:36, 31 May 2009 (UTC)
• Support If implementable, it's an ingenious solution to the problem of vandalism to unwatched pages. --Cybercobra (talk) 08:52, 31 May 2009 (UTC)
• Support only for admin, oppose otherwise - It would be simple enough for a vandal to watch a page, and then it would fall off of everyone's radar. That would turn a good thing into a very bad one. ▫ JohnnyMrNinja 06:57, 5 June 2009 (UTC)
  • Restricting the page to admins is one solution, but I don't think that there's a problem. We would count only autoconfirmed watchers active in the past 7 (or 60) days, and the implementation would also give us recent-changes for pages with 1 watcher, or under 5 watchers, and so on. The sort of coordinated vandalism to 'get around' this is rather visible and is more difficult to deal with if we keep the pages admin-only.    M   01:14, 6 June 2009 (UTC)
    • Isn't that going to be a gigantic strain on the servers? Right now, our watchlists are the biggest strain (right?), so wouldn't a watchlist that watches thousands of pages that are selected from every page on EN based on a series of checks on each page and every user that watches any pages at all... Wouldn't that slow our WP down to the barest crawl? Even if the list of articles matching the criteria were only updated every other day or so, a watchlist that big is a massive beast. Of course you could limit the number of pages that show up, but it would still check the entire list for the 100 most recent changes (right?). I'm certainly no expert on how Mediawiki works, so maybe I'm wrong. Limiting it to admins is a better solution, I would think, if even that is feasible. If it's between having an even-more unstable connection to WM projects or having the fact that Franklin Township, Wright County, Minnesota is referred to as a "gaylord" for two weeks, I'm okay with the latter. But, again, maybe I'm mistaken about the strain. ▫ JohnnyMrNinja 09:12, 10 June 2009 (UTC)
      • No - actually, it might speed things up. The proposal is not to put every unwatched page onto a global watchlist, but to record the watcher count in the recent changes table. This is extremely fast compared to a global watchlis, and is fast in general (see Bug 18790). If the page causes people to reduce their overburdened watchlists (which it should), it may actually increase performance.    M   00:27, 11 June 2009 (UTC)
        • If that's the case then it could be workable, and it is a good idea. With the inclusion requirements you've specified, the list would actually pick up far more pages than the regular unwatched pages list. But I must stress that launching it for everybody is a bad idea, because if something goes wrong and it is deactivated, we will have provided a complete list of un-and-hardly-watched pages, and then removed our ability to protect them. I am not a fan of segregating access normally, but I still feel that it should only be accessed by admin (maybe rollbackers?) until such time that it shown to not contain bugs and we decide we're going to keep it permanently. The only thing you need to be Autoconfirmed is to not have been blocked yet. ▫ JohnnyMrNinja 02:25, 11 June 2009 (UTC)
          • Right, it wouldn't be the same, though this means it would pick up more unwatched pages and not false positives. It wouldn't be a complete list, since it would only record edits made in that short period of time (no doubt those articles would be gobbled up into watchlists by our editors). I do think that these points deserve attention, but it might be early to decide how we want to deploy the feature.    M   18:29, 16 June 2009 (UTC)
            • A few comments. This almost certainly won't speed anything up. Watchlists are not the biggest strain and the slow part of watchlist generation is generating the HTML, not the 1 database query to get the list. You're calculating something that's not currently calculated and not removing anything else. You say in one comment that people would "reduce their overburdened watchlists" then in another that pages would be "gobbled up into watchlists by our editors." That can only affect performance in one way. The question is just will the extra calculation on every edit be fast enough to be usable. Blocking a user does not remove the autconfirm right. A blocked, autoconfirmed user could still do anything that requires autoconfirmed, as long as it doesn't also require editing rights. Even if they're blocked before becoming autoconfirmed, their account doesn't stop aging, and most blocked users can still edit their talk page; so they could even become autoconfirmed while blocked. Mr.Z-man 20:36, 16 June 2009 (UTC)
              • A reduction in the size of watchlists and perhaps the need to check them might reduce some of the burden. It's not important whether it will or not, just that it definitely won't bog down the server. In the long term, this will allow editors to reduce their watchlists. In the short term, editors will tend to add these articles to their lists until they see that it's unnecessary. If something went wrong, which is entirely unlikely, we'd have no problems watching the small list of recent unwatched articles. Dedicated vandals will always get through to some extent, but checking for autoconfirmed is something cheap, relatively accurate, and effective for the majority of cases.    M   00:23, 22 June 2009 (UTC)
                • Restricting it to autoconfirmed would be trivially simple to bypass. Vandals wouldn't even need to create new sleeper accounts to see the list, they could just use existing, blocked ones. If you're not concerned with dedicated vandals, then it shouldn't be restricted at all, as only dedicated vandals would likely even take the time to check such a list. Mr.Z-man 03:28, 22 June 2009 (UTC)
                  • Misunderstanding, I think. It's safe to let everyone see it; I think the concern was a vandal registering 5 accounts, watchlisting many articles, and then vandalizing them. Autoconfirmed would be for whether the editors are counted as watchers, which makes this strategy not worth the effort.    M   08:11, 26 June 2009 (UTC)
• Support the unwatched list it too big to do anything useful with by admins. Perhaps proven vandal fighters would get blocks of these unwatched pages to add to their watchlists. Talk to me if you are interested in this idea. The article names could be emailed to those who want to change them to watched articles. Graeme Bartlett (talk) 02:16, 6 June 2009 (UTC)
• Support Sounds like a good idea. Dream Focus 09:35, 6 June 2009 (UTC)
• Support Graeme two posts up says it well. Casliber (talk · contribs) 05:29, 25 June 2009 (UTC)
• Yep, definitely a good idea. –Juliancolton | ^Talk 22:07, 2 July 2009 (UTC)

[edit] 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)

[edit] 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. Y 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)

[edit] Formal proposal

The following discussion is archived. Please do not modify it. Subsequent comments should be made in a new section.

The result of the discussion was: No consensus. Default to keep as is (outside opinion gained at Wikipedia:Administrators' noticeboard#Discussions need administrator closing). I will implement a JavaScript gadget within a few days for those who want to use the proposed layout. –Drilnoth (T • C • L) 13:48, 20 June 2009 (UTC)

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

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

Well, it's nice that it can be scripted so easily. We're indebted to Drilnoth for drawing that to our attention. So those of us who like it can use it anyway while the debate continues. I confess I'm not personally seeing the suggested "rush to implement" "anything" effect, simply a lot of people who judge that this very thing is a usability and debunching enhancement for newcomers ond oldcomers alike. To those concerned about aesthetics: I recommend adding this line to the script:

     span.style.fontSize = "xx-small";

PL290 (talk) 09:04, 28 May 2009 (UTC)

Agreed; I just wanted to have the sample here use the exact same format as the previous version, so that they could be more easily compared. I'll probably make this code available as a gadget if consensus is against universal implementation, at which point I may allow an option for normal size, normal size but gray, small, and small gray. While people are still just trying it out, I think it should use the previous styling so that "style" isn't involved in this discussion as much as "location". –Drilnoth (T • C • L) 13:31, 28 May 2009 (UTC)

Quite so, you did the right thing. The sample is most helpful in its present form for this discussion. I speak only to any who do feel like copying the mere 14 lines of .js and tweaking their own copy. PL290 (talk) 15:35, 28 May 2009 (UTC)

Question: Any reason why your sample version is working for me on articles, but not on WP:AN/I, WP:AN or WP:RM? Ed Fitzgerald _{t / c} 11:07, 8 June 2009 (UTC)

Can't confirm: I have no issues with those three pages using the script provided by Drilnoth with Firefox 3.0.10/Mac or IE 7.0.5730.13/WinXP. Can you provide details including skin (monobook.css etc), browser, OS and display size (pixel dimensions)? Sswonk (talk) 12:57, 8 June 2009 (UTC)

Actually, it's only working for me on article, not anywhere else, including talk pages in all spaces. IE7 under Windows Vista, monoboook skin, 1280x800. Ed Fitzgerald _{t / c} 06:16, 9 June 2009 (UTC)

Seems to be working everywhere for me using Firefox 3.0.5, Safari 3.1.2 and Google Chrome 2.0.172.30, but not working at all using Opera 9.63. Ed Fitzgerald _{t / c} 06:29, 9 June 2009 (UTC)

Sorry, I didn't see this before. The script probably isn't perfect... I just copied it from the German Wikipedia. Browser support for scripts varies greatly. If Happy-Melon's bug report is done, then this can be done with a single line of CSS. The JavaScript can probably be simplified, too... I'll look into this. –Drilnoth (T • C • L) 16:28, 13 June 2009 (UTC)

My apologies as well, I lost track of this mini-thread. I just tested the script on Opera 9.64 Mac and the pages in question displayed as expected, i.e. like every other page. I don't know what could be wrong there - the only thing I can think of is a conflicting javascript. See if 9.64 makes a difference, although I doubt it will. Sswonk (talk) 01:46, 15 June 2009 (UTC)

• Support: Having the edit button immediately at the end of the section headers would remove the bunching issue with Mozilla Firefox and other browsers where this is an issue. Having the facility to display it at the right via user preferences allows those who are happy with it at the right hand side to keep it there. Mjroots (talk) 11:48, 27 May 2009 (UTC)
• Support:There are issues with displaying it where it is on some articles & it hopefully may be more noticeable & encourage editing. dottydotdot (talk) 11:50, 27 May 2009 (UTC)
• Support: Avoids the {{fixbunching}} hack and hopefully addresses usability problems. OrangeDog (talk • edits) 12:02, 27 May 2009 (UTC)
• Support: The WikiFairy in me, noticing that the format proposal explicitly excludes aesthetics, whimpers a little, hoping that this aspect can nevertheless be addressed at some point even if not in the immediate implementation. PL290 (talk) 12:11, 27 May 2009 (UTC)

• As I stated above, I like the look of the light grey [edit] button. I've specifically left that issue out of the proposal to keep people focussed on the main proposal. If someone wants to propose a change in the aesthetics/display of the [edit] button they are quite welcome to post a proposal to that effect. Mjroots (talk) 12:18, 27 May 2009 (UTC)

• 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 Homo antecessor#Fossil_sites - how do you edit that section (tested in Firefox3Beta5 with reasonably large windows, and in IE8)? Or edit the References and External Link sections in Bellerophon class battleship. Not impossible, but not very intuitive either. --Stephan Schulz (talk) 15:42, 28 May 2009 (UTC)

But they do not currently appear in consistent horizontal locations either -- have you seen an article with right-floating elements? OrangeDog (talk • edits) 23:24, 27 May 2009 (UTC)

But they are: they are at the right edge of the column of text. It doesn't seem to cause a problem (for me, anyway) that that width infrequently changes, as "the edge of the column of text" is still trivially obvious to locate. Anomie⚔ 23:34, 27 May 2009 (UTC)

Is "immediately following the section title" any less trivially obvious? OrangeDog (talk • edits) 00:06, 28 May 2009 (UTC)

Perhaps not less obvious, but still harder to find. The column of text is a very large rectangle taking up most of the page and clearly demarcated from any bordering rectangles (as those normally have borders and distinct background colors), while the section title is typically a narrower rectangle wedged in between larger rectangles with subtle demarcation. Also, BTW, the end of the section title may not actually be at the right edge of the section title rectangle, if the section title is long enough to wrap onto a second line. Anomie⚔ 00:16, 28 May 2009 (UTC)

Sorry, this is simply not true. Relative to the target of the control (the control is the edit link, the target is the heading), the positioning is perfectly consistent - a few pixels to the right. You are confusing style (which would recommend that similar elements are placed in an orderly way) with usability.   M  02:58, 28 May 2009 (UTC)

Unfortunately, "relative to the target of the control" isn't all that helpful, because "the target of the control" changes size arbitrarily. Consider a series of UI windows in Microsoft Windows. If you want to minimize a bunch of them in succession, would you rather have all the windows maximized, or all the windows at various locations around the screen so that you have to search each one for the minimize button? They're all in the same place relative to their targets, but that doesn't make them trivial to find. I realize these edit links are not used in quick succession, but it still illustrates the problem of having to search for the button. With the current layout, one doesn't even need to look at the section header; one can just go to the right margin and find the first [edit] link that appears above the section one was reading. Moving the edit link means one doesn't know where the link will be without first scanning for the header. Powers ^T 13:28, 28 May 2009 (UTC)

If it is easier to find the link than it is to find the end of a heading, then I agree. Given the close and consistent proximity of the link to the title, I don't believe that 'scanning around' for a link is a problem, so power users would not be substantially affected. There are relatively few power users, and they can change this in prefs. A poor association of the link to the heading, due to the distance, is a problem, though, and this has been demonstrated by the usability study.    M   02:46, 29 May 2009 (UTC)

• Oppose - per LtPowers. Also, the WMF has nearly US$900,000 to hire professional UI designers and usability specialists to fix the usability issues over the course of a year or so; I can't imagine that a bunch of random Wikipedians deciding in a week that we know best is doing much more than getting in the way. Mr.Z-man 15:42, 27 May 2009 (UTC)

Mr.Z-man, I don't intend this to be over in a week. As it is something that will be Wikipedia wide if brought in, it needs full discussion. I'd expect that to mean at least a month, if not longer. Mjroots (talk) 16:31, 27 May 2009 (UTC)

The poll might last for a month, but the poll is only a binary decision - do this, or don't do it. The discussion about what option to use for the poll only lasted a few days. Mr.Z-man 01:13, 28 May 2009 (UTC)

And Microsoft spent how much money to create Office 2008 and look what they did to that UI. Just because $Some_Large_Sum is being spent on fixing something does not mean that something better will come out of it. Q ^{T C} 21:25, 28 May 2009 (UTC)

The exception does not make the rule. But in any case, the issue is not just money. Its effort and expertise. The fact that some people involved in the initial discussion believe gray links with smaller font on a white/light-blue background is a good idea suggests a lack of UI design skills. There was less than 6 hours between when the mockups were created and when the poll started. There's been virtually no testing and almost no discussion of alternatives. The alternatives were dismissed becuase the 1 set of mockups (which are actually useless as testcases) for the other options didn't fix the bunching problem. Mr.Z-man 21:50, 28 May 2009 (UTC)

• Support. An obvious improvement, agree with other supporters. Sswonk (talk) 16:48, 27 May 2009 (UTC)
  • Adding specificity here: I support the formal proposal that the default position of the edit button be immediately after the heading because I feel it enhances usability, prefer the implementation that is found on the French Wikipedia (example DVD article), cite the default implementations found there and on the German, Spanish, Italian, Japanese and other Wikipedias as working models and recommend a clear preference choice and a clear, easily found explanation of the change and the optional setting available once implemented. Sswonk (talk) 17:42, 8 June 2009 (UTC)
• Support: There are multiple reasons for this: It fixes up the horrible bunching issues, it just plain looks better (take a look at the German Wikipedia), and it makes it more visible for newcomers who might not notice the "edit this page" tab (which could bring in some more new editors). If this isn't done, making a gadget to allow it to be applied on a user-by-user basis would be good. To mention my view on visuals, having it look just like it is (or maybe a smaller font size) seems fine... in the brackets I doubt that it will disrupt the reading of section headers or anything. Some specific response: LtPowers, I don't believe that the position would be different for each section... every section will have it in the same place, just a different place from where it currently is. I'd also oppose this if it was going to make some edit links be on the left and some on the right, but I don't think that that is the proposal. Mr.Z-man, wouldn't you think that if a group of Wikipedians decides here that the edit button should be moved, that would save the Foundation money and time in doing further studies or polls? I agree that it will take a month or so-long poll, but if there is consensus for the change that will make it much easier on the Foundation (to my knowledge), since all that would have to be done in this case is insert a bit of JavaScript/CSS into the MediaWiki namespace, rather than going through a huge poll or anything like that. –Drilnoth (T • C • L) 16:51, 27 May 2009 (UTC)

  No, because we are not usability experts, we're going by "this looks good" - the usability team will still need to evaluate it to determine if its actually an improvement or works with other things they were considering. Most of the studies are already done, but if we do this, then any data about the section edit links becomes worthless. The money comes from a grant specifically allocated for the usability improvements, so if we don't spend it on usability, we don't spend it at all. Also, what's the difference between "a month or so-long poll" and "a huge poll"? Mr.Z-man 17:12, 27 May 2009 (UTC)

  I'm basing my reasoning on usability as much as ascetics here... my feeling is that if the links are on the other side then they will be more noticeable for new users, would be easier (and faster) to find, and as a result would encourage more readers to start editing. I hadn't been aware that the money was coming from a grant, but if that's so there's still no reason to use it if it isn't required. My feeling is that a "month or so-long poll" is different from "a huge poll" in that it can be set up and implemented by Wikipedians easier, rather than needing some more "official" thing on Meta where it isn't as visible to the average user. Also, as Dinoguy1000 mentions below, this change can both be easily undone if the developers need to, and it would also allow further testing on what the new configuration's usability was in comparison with the old before making a "this is what needs to be done" type of decision that might be a bit more final than what is determined in a !vote here. –Drilnoth (T • C • L) 19:29, 27 May 2009 (UTC)

  Good, now they won't have to spend a few thousand dollars moving the edit link to the left. As for the data being invalidated - this would only give them more data, namely reactions from editors as to the new layout of the button.   M  02:58, 28 May 2009 (UTC)

  The reactions from editors is mostly irrelevant. Editors already know how to use the site. The goal of the usability project is to make the site more usable for others. They can't study that by reading a talk page. They have to do real studies, like the ones they already did 2 months ago. Mr.Z-man 04:07, 29 May 2009 (UTC)

  I categorically reject the assertion that "it just plain looks better". I looked on the German Wikipedia and think it looks horrible. Powers ^T 13:28, 28 May 2009 (UTC)

• Support per my reasoning above. Personally, I think Mr.Z-man's argument is just a "don't change what I've gotten used to" masquerading in pretty clothes; this change would have no influence on any usability studies the Foundation has had performed in regards to the section edit link. Au contraire, it would be beyond trivial for the devs to restore the right-hand links if it's necessary, and the findings of such usability studies would include recommendations on new placement of the edit links, which could be implemented quite easily regardless of their then-current placement. I also quite like Drilnoth's suggestion of having a gadget either way, instead of only if the change is decided upon and made. ···「ダイノガイ千？！」^{? Talk to Dinoguy1000} 17:25, 27 May 2009 (UTC)

  The usability studies are mostly already done. I've actually put some thought into my argument, but thanks just dismissing it as crap, I appreciate it. I think we're diving into this with too little thought. We started the poll after only 3 days of real discussion. Alternatives were proposed, but the discussion turned to polling before anyone really had the chance to evaluate them. Mr.Z-man 17:35, 27 May 2009 (UTC)

Alternatives were proposed, and quickly shown not to fix the bunching issue. They are still available to be looked at, and compared to each other. I'm sorry that you think that the 3 days discussion wasn't enough, but the discussion remains open for further comments and suggestions. Mjroots (talk) 19:11, 27 May 2009 (UTC)

I certainly didn't mean to dismiss your argument "as crap", and I'm quite sorry if it sounded that way (I have nothing against you personally). However, I still stand by my own comment. ···「ダイノガイ千？！」^{? Talk to Dinoguy1000} 19:58, 27 May 2009 (UTC)

Mr.Z-man, I certainly don't wish to dismiss your comment either, but I too wonder why this particular proposed change provokes your line of reasoning, and my concern is, are you therefore saying we're wasting our time by discussing any UI change in this forum? PL290 (talk) 20:14, 27 May 2009 (UTC)

Unless the usability team decides against it and reverts it, we aren't wasting our time, just the usability team's. My main concern is really that of LtPowers, that as a usable UI goes, its worse than what we have now. It fixes the bunching problem at the expense of inconsistency. Combined with rushing into a vote with little discussion and even less testing, I just don't think this is a good idea. I just don't see what the rush is. Why is this something that needs to be resolved post-haste all of a sudden? I'm not saying we need to start conducting surveys of our own, but right now the process looks like "We should fix the bunching problem / This fixes the bunching problem / Excellent, let's vote / It fixes it? Okay, Support!" Mr.Z-man 21:27, 27 May 2009 (UTC)

• Support. Much better visibility and less prone to random up-down float when images, templates etc. interfere. Germans did it again! NVO (talk) 19:33, 27 May 2009 (UTC)
• Support, per OrangeDog. ParlorGames 19:54, 27 May 2009 (UTC)
• Support, fixes the very annoying bunching problems; increases visibility of edit link (but not in an annoying way), thus furthering ease-of-editing for new editors --Cybercobra (talk) 21:12, 27 May 2009 (UTC)
• Oppose The intent of this proposal is to make it slightly easier for absolute newbies to find the edit link, at the cost of making it much slower for everyone else to locate the actual link I tried Drilnoth's script for a few minutes, and verified the speed decrease. With the current style, I can move the mouse pointer to the right edge of the text "automatically" while seeking the appropriate vertical position; with the proposed change, I must seek both horizontally and vertically. Also, with the proposed change it was harder to spot those edit links as they tend to blend into the header when scanning the page.
  I agree with Mr.Z-man that this seems to be a "We have to do something! / This is something! / Let's do this!" discussion; a real usability study involves actually evaluating proposed alternatives for usability instead of just arbitrarily deciding to change things because it might be better. IMO, that should be left to the people being paid to do that sort of thing, instead of a bunch of armchair amateurs. Anomie⚔ 23:34, 27 May 2009 (UTC)

  The same can be said for writing an encyclopedia, but we're doing a damn good job. I'm happy to see more people involved in usability issues. The arguments are hardly arbitrary. Your verified results are suspect, since you've become accustomed to the old interface, and will likely spend some time getting accustomed to the new location. If you can agree that you look at the heading before editing, then showing that this takes a shorter time is relatively simple. You subtract the need to track to the right, and inconsistent link positioning affects nothing since (unlike, say, the scroll bar) you cannot click these links out of the corner of your eye.   M  03:12, 28 May 2009 (UTC)

  For that matter, everything 'you assert is suspect too, and I certainly do dispute your baseless assertions regarding the tracking time. I see in several discussions here you have been extremely quick to dismiss anyone who disagrees with you, only backing down once consensus is overwhelmingly against you. Here, there are a number of people on each side of the debate so there is not likely to be an overwhelming consensus any time soon, but your closed-mindedness is still not helping the matter. But fortunately, it's not my purpose here to try to argue with the closed-minded, so I'll just say "Have a nice day" and leave you to it. Anomie⚔ 03:24, 28 May 2009 (UTC)

  I gave a reason why your experiment is suspect: single user is accustomed to the old interface. Of course you'll be slower at first. Your criticisms belong on my talk page. 19 support, 4 oppose is a great start on consensus. Please read through parts of this book, Fitts's law, and this selection of citations. I can look up some more (better) information if you're interested, most of this is from a quick google search. If you'd like to have a (cited) argument in terms of usability, I'm up for that, in one of the sections above. In the meantime, I don't want other editors to get the wrong idea when you say 'verified', and I want them to understand that at first, a speed decrease is normal.   M  04:03, 28 May 2009 (UTC)

  Let's all calm down a bit. Obviously if consensus is reached that the edit button should be moved, I'd expect that the issue would be investigated fully before implementation by those who deal with such issues as UI. It may be that the default is kept to the right, but a user preference is granted that allows the [edit] button to appear immediately at the end of the section heading. Mjroots (talk) 05:54, 28 May 2009 (UTC)

  You might expect that, but I certainly wouldn't count on it. Mr.Z-man 06:24, 29 May 2009 (UTC)

  M, you seem particularly eager to get this change implemented, to the point of trying to shoot down every opposing argument. Is it really that important to you? Can't you acknowledge that there may be some valid points on both sides of the issue? Powers ^T 13:28, 28 May 2009 (UTC)

  Actually, if your overall editing time is significantly affected by searching a (non-bunched) edit button in either style, you must have a much faster brain, faster fingers, and a much faster internet connection than me. For typos, just finding the proper place in the edit box is dominating the edit click, and for real content, thinking and formulating is. Even typing and a preview cycle take longer than to move the mouse pointer hither or thither. --Stephan Schulz (talk) 21:02, 28 May 2009 (UTC)

• Support I don't know how many times I've seen those edit buttons are place they really shouldn't be, and spent quite a while re-aligning images, tables, etc... so things would line up properly. I'd rather have them on the right, but I'd also rather have them work and not screw up with article layout. Place them on the left by default, and give the monobook.jss code for those who would like to see on the right. Headbomb {^ταλκ_{κοντριβς} – WP Physics} 00:32, 28 May 2009 (UTC)
  • 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)

• Strongly Oppose – I've seen the edit links on other language wikis and it really bothered me. The edit link looks very good where it us, and moving it will create unnecessary hassel and disorder. It certainly isn't broken, so there is absolutely no reason to fix (or brake, rather) it. American Eagle (talk) 20:25, 28 May 2009 (UTC)
  • You don't consider the bunching problem to qualify as "broken"? --Cybercobra (talk) 23:20, 28 May 2009 (UTC)
    • Also, did it bother you in other languages because you actually didn't like it or because you just weren't used to it? Remember that change can be hard to adapt to... for a new user, which would be better? Also, if there's a gadget long-time users can keep it the way it is. –Drilnoth (T • C • L) 03:26, 29 May 2009 (UTC)
      • Cybercobra, no, I have never had an issues with it. Drilnoth, in other languages, I found it very distracting when I was looking for sections headers. I'd see "Primeras etapas de la vida [edit]" (for example) and I'd get confused. Although the proposal might save a newbie a half a second (which it may), it will also frustrate many oldbies and distract most readers. If this passes with enough consensus, I won't retire because of it, but I still can't support its implementation. American Eagle (talk) 05:08, 31 May 2009 (UTC)
• Despite my earlier resistance, I conditionally support this proposal, provided that the opt-out is provided as a gadget as soon as the change is made. Dendodge _T\^C 20:31, 28 May 2009 (UTC)
• Weakly Oppose—I can see the attraction for this solution, in part because it is a relatively small incremental change to the current situation. However, the fact that it is an incremental change bothers me. I think something more radical would better serve to facilitate and encourage editing. For instance (this is an off the top of my head suggestion - there are other things that could be tried), if the entire horizontal line on which a section title appears were activated to enable launching an edit session, the would be a great help. What do I mean ... in the image below, the [click to edit section] text would only appear upon mouseover; the shading would be persistent. --User:Ceyockey (talk to me) 01:47, 29 May 2009 (UTC)
  

• That probably wouldn't be too hard to do with just a little bit of JavaScript and CSS. I'll try to make a mockup. –Drilnoth (T • C • L) 01:52, 29 May 2009 (UTC)
• An excellent illustration of why this poll was premature; there may be multiple alternatives, some of which may solve the problems inherent in both current proposals. Powers ^T 02:04, 29 May 2009 (UTC)
  • This is a bit trickier than I'd thought; I don't have enough experience with JavaScript to code it in any amount of time that it would still be useful for this poll. MediaWiki's setup just isn't quite right to make it easy (the headlines need a class). –Drilnoth (T • C • L) 02:27, 29 May 2009 (UTC)
• This is a bit too obtrusive. A minimal change is good because we have only one factor to worry about - the position. Adding sizing and color would introduce too many factors and objections. Further, the change is exactly what the second-largest Wikipedia is already using, and has tested (which is why I find the "it's premature" objections hard to swallow).    M   03:12, 29 May 2009 (UTC)

• Just to clarify, I don't know how I feel on this particular proposal; it could work, but may also have some problems. I was simply offering to try and make a mockup, a task at which I failed miserably. :/ –Drilnoth (T • C • L) 03:25, 29 May 2009 (UTC)
• Again there are more options. Just because the German Wikipedia is using this one doesn't mean we shouldn't consider others. Its premature because all the other options presented were rejected because the test cases didn't work, despite the test cases being suboptimally designed and completely unrealistic. Then we started a poll 6 hours later. Everything else was rejected before it had time to be properly evaluated or even brought up. Mr.Z-man 04:07, 29 May 2009 (UTC)

• Mr Z-man, where has everything else been rejected? I think you're maybe misrepresenting the situation, which is this. An idea was floated, it seemed on first appearance to be a good one. A few alternatives were tried and the original idea show to work best. A formal proposal was drafted and consensus sought.

Now, I'm not an expert in the various coding etc needed to achieve the suggested change. It may well be that there are technical reasons why the English Wikipedia can't have it. It may be achieveable and set as the default, or alternatively made available via user preferences. The discussion is still open, if you (or any other editor) has another suggestion, please propose it and let the community state whether or not they support the proposal. This isn't something I'm trying to bring in overnight. It needs the involvement of a large number of editors over a reasonable period of time because the suggested change, if implemented, would affect all users of Wikipedia. Mjroots (talk) 05:18, 29 May 2009 (UTC)

I think you're missing my point entirely. The one option worked best because in the one and only test done, all the other options were done incorrectly, and there was no time for more extensive coding or testing or discussion before the poll started. I never said there are technical reasons why this couldn't be done (though there are technical reasons why other solutions are better, specifically they can be done without JavaScript). Its probably too late at this point to propose something else, especially since the poll has already gained inertia and I prefer to actually test things properly before suggesting them (though I did provide some CSS code above that could be used as a start). This may very well be the best solution, but since there's been no real testing done, we'll never know. Mr.Z-man 06:21, 29 May 2009 (UTC)

I think this would be too easy for readers to click accidentally. --Cybercobra (talk) 04:19, 29 May 2009 (UTC)

• Pollster Since there haven't been votes for a while (over 12 hours), I counted the votes so far and got 19-For (76%) vs. 6-Against (24%). But keep in mind WP:POLLING and all that. --Cybercobra (talk) 19:28, 29 May 2009 (UTC)
  • I count 5+6+6+3+1=21 support (including the proposer, the unbolded support, and the conditional support), and 6 oppose. There are 4 more supports below, making it 25/6 for this section.    M   15:38, 8 June 2009 (UTC)

• Comment: I've been using the script that I created so that this can be tested since I created it. At first it was kind of strange, because it's in a different location, but I've found that I'm already growing used to it. I strongly urge anyone who isn't sure of their feeling on this to try out the script for a good amount of time—not just a few minutes or hours—and give it a chance. I'm honestly surprised by how quickly I got used to the location. –Drilnoth (T • C • L) 19:33, 29 May 2009 (UTC)
• Comment—If someone has access to a software simulation tool, such as iRise (the only one I'm familiar with), then we wouldn't have to wait for resolution of code technicalities in order to have full page mockups of various options. This is true of both the present and other usability discussions. --User:Ceyockey (talk to me) 23:59, 29 May 2009 (UTC)
• Enthusiastic Support. The stupidly brain-dead postioning and bunching problems with the section edit links have long been an annoyance. older ≠ wiser 21:16, 30 May 2009 (UTC)
  • I am happy for your enthusiasm, but please try not to call other peoples' hard work "stupidly brain-dead". –Drilnoth (T • C • L) 21:56, 30 May 2009 (UTC)
    • I didn't mean to demean anyone -- but whatever hard work may have been involved, the flaws of the section edit link placement have long been an annoyance as well as a usability problem. older ≠ wiser 22:05, 30 May 2009 (UTC)
• Support with the same enthusiasm, and same disdain for our collective lethargic tolerance of an obviously broken solution, as older/wiser above. The proposal specifically provides an opt-out for those who prefer it the broken way, so "I don't like it" is even less of an argument than it is usually.--Kotniski (talk) 22:20, 30 May 2009 (UTC)
• Support the general idea, although I understand the objections. Even after a year and several thousand edits, I more-than-occasionally find myself reflexively reaching for the "edit this page" tab at the top of the page when I just want to edit a section. Aesthetically (when there aren't ugly bunching and displacement problems), the current placement has much to recommend it. But the balance of reasons very strongly favours putting the [edit] link next to the (sub)section header, either to its left or more closely to its right. New editors (and new readers who may not even known they could edit) are far more likely to see it (as the usability study showed), and the bunching/displacement issues can be greatly diminished for the overwhelming majority of working editors who have neither the knowledge, the skills, the patience nor the inclination to start fiddling around with Javascript, CSS, monobooks, etc. (If an automated option can be entered into User Preferences, then that becomes a rather different question about default appearances, etc. Maybe the current format could then be offered as an option there.) —— Shakescene (talk) 23:52, 30 May 2009 (UTC)
  • I must have missed the part of the usability study where they actually tested different positions for the section edit link. Where in there are those results hiding? Anomie⚔ 01:56, 31 May 2009 (UTC)
• Support; this not only takes care of the bunching problem, it also (to me) appears to be more naturally intuitive. I do understand TreasuryTag's objection, but I think we cannot hide the connection between the two aspects of our project here. One question: Will the section edit link be as small as it is now? Certainly it will not match the section heading font size, will it? Unschool 02:32, 31 May 2009 (UTC)
  • I believe the proposal is just to change the position of the edit link and not otherwise modify how it looks. That bit of bikeshed-painting has been left for another discussion. --Cybercobra (talk) 02:43, 31 May 2009 (UTC)
    • Cybercobra is correct; the result of this discussion will just determine whether or not it should be moved. If there is consensus for this, another discusison will be held regarding appearance before the change is actually implemented. –Drilnoth (T • C • L) 02:47, 31 May 2009 (UTC)

[edit] Arbitrary break

• Comment I've just filed bug 19022http://bugzilla.wikimedia.org/show_bug.cgi?id=19022, which will make this effect achievable entirely with CSS, no JS needed. Happy‑melon 10:16, 31 May 2009 (UTC)
  • Update bug 19022http://bugzilla.wikimedia.org/show_bug.cgi?id=19022 was closed as repeat of bug 11555http://bugzilla.wikimedia.org/show_bug.cgi?id=11555, which was reopened for consideration of this issue. Finell (Talk) 16:04, 14 June 2009 (UTC)
    • Actually, it was reopened in 2007, because the patch that "fixed" it in r28517 was reverted in r28630. Anomie⚔ 17:35, 14 June 2009 (UTC)
• Strong oppose (vote changed to "Support if there is just evidence that readers prefer this structure"). This spoils the readability of the page and only serves to make it easier for certain editors to click on a button. I prefer the button on the right, where it doesn't interfere with the flow of the page, but that's exactly what it is: a preference. I strongly don't believe that the entire 'pedia should be changed just at the preference at certain people. If you desperately want it that way, you can use Javascript or CSS to enforce it, but don't drag the rest of us into it. I also disagree with this "opt-out" scheme. As the problem is is supposedly aesthetics, we would generate more problems than we solve if different editors view the layout of the page in different ways. Greg Tyler ^{(t • c)} 17:43, 31 May 2009 (UTC)
  • Many users already view pages differently than say, non-editing readers. Skins drastically change page appearance, and things like User:Drilnoth/rounded.css can drastically alter a page's appearance for certain users. I haven't found this to be a problem. Second, how does it spoil the readability of the page? Just because the edit link is in a more visible location? You can still just read the section headings... I've been testing this for awhile now and at this point don't even notice it. Having three or four edit links bunched up together in places destroys readability more, IMO. Also, at this point there seems to be more consensus for the change, so I'm not sure if saying that "I strongly don't believe that the entire 'pedia should be changed just at the preference at certain people." really applies... if it was a minority trying to make this changed, then yes, but based on the discussion here, it would appear that the minority don't want it changed. –Drilnoth (T • C • L) 18:01, 31 May 2009 (UTC)
    • The problem here is that it's entirely a matter of preference, right? Some people think that changing will improve readability, ease of use and suchlike. Others, such as myself, believe that implementing will lead to a decline in readability, ease of use and suchlike. Hence, the best solution is the make the implementation a simple "Yes I want it" or "No I don't" checkbox in Special:Preferences. I'm completely up for that, but why the proposed structure should be marked as default..? The default should, of course, be the structure that readers prefer. I would believe that to be our current system, but that's entirely subjective...
    • My point is that we're polling the wrong people. We editors can always change our preferences, and the site shouldn't revolve around us. Its primary concern is what the readers think, so it's they who we should be asking. Though how you want to organise a poll amongst readers that isn't bias, disallows any sort of rigging and gives a fair consensus, I know not. Perhaps it's just easier to edit Special:MyPage/monobook.js if there's a part of the design you draw issue with? Greg Tyler ^{(t • c)} 18:40, 31 May 2009 (UTC)
      • This is a good point. My feeling is that yes, it is just a matter of preference. Some people would prefer the links in the proposed location, some in the current location. The thing is, if this poll was being held when the wiki was first being started and these were the results, it would be obvious that consensus was to have the link near the header. Consensus can change. In essence, the answer your question of "why the proposed structure should be marked as default..?" would be "Because that's what the consensus is for." Something's having been one way for a long time doesn't really change the consensus.
      • You have a very good point about polling the wrong people. However, do you have any ideas as to how we could ask the readers about this issue? People who have never edited wouldn't really care about it—some don't know that you can edit, some don't have the time, and some want to leave it to other people—and many probably wouldn't fully understand what this was about if they haven't already edited, but moving the link might make some more people (those in the first group) edit. –Drilnoth (T • C • L) 18:51, 31 May 2009 (UTC)
        • You've picked up my point perfectly, thanks. The people who should be polled are, for the majority, not going to answer any of our queries. This means that the entire thing would be on such a small scale that fair and useful consensus simply couldn't be generated. I feel we need to talk to readers about this but personally, yet I have no idea how we can do so successfully. To me, that's the biggest step to overcome in this proposal. Greg Tyler ^{(t • c)} 19:00, 31 May 2009 (UTC)
          • That's exactly the sort of polling the usability people are being paid to do. Right now, we have results saying "some absolute newbies missed the section edit button" and people are somehow using that to justify assuming (without any evidence at all) that this proposal will be better and without any other adverse effects. And the worst part is, some of them apparently don't even realize how vastly they're misrepresenting the study. IMO, we should let the usability people do what they're being paid to do, since they have the resources to actually perform the needed studies, and revisit this only if they inexplicably ignore the issue. Anomie⚔ 01:18, 1 June 2009 (UTC)
            • If it's a preference matter, I'd be quite happy for the solution to be having it made available via user preferences instead of an arbitrary change. Even if this proposal is passed up the chain as "consensus is that something needs to be done, what do you think of this, should it be the default, or made into a user preference?"I'd be happy with that as an outcome. Mjroots (talk) 08:23, 1 June 2009 (UTC)
  • This is not about aesthetics. It's in part a response to results of the usability study, which found that
    "Users often missed the ‘edit’ buttons next to each section, clicking on ‘edit this page’ all the way at the top. This often got them lost if they were editing a particularly long article, as they weren’t easily able to find the section they wanted to edit. Several users also clicked on the wrong ‘edit’ button next to the sections, thinking that the ‘edit’ button below the section referred to the section above."
    In addition to the issue of bunching, this provides two reasons why the current implementation is difficult to use. Many editors have expressed support that this will solve these issues. Given that we are acting on the appropriate data, would you consider changing your vote - or perhaps your reason for objecting?   M   19:16, 31 May 2009 (UTC)
    • Perhaps, then, we ought to wait until the usability testing can test this proposed solution and see if it works before we go changing the new-user experience, possibly for the worse? Powers ^T 12:33, 1 June 2009 (UTC)
• Support - In many larger articles, the edit buttons freak out - more so in some browers than others. I understand that we cater to readers and not editors too, but I feel having edit buttons appearing in seemingly random places like little ghost buttons completely ruins the flow and readability of many otherwise quality articles. Not only that, but the edit button problem has actually kept me from adding images to articles before, as I was afraid of screwing up the button layout. With that in mind, it can dissuade people to add useful content to articles the way it is now. Cheers! Scapler (talk) 20:54, 31 May 2009 (UTC)
• Support - As was pointed out above, on de.wiki they are already doing this and they don't seem to have any problems. I agree that the [edit] text should be made small; smaller than the header for sure, and probably smaller than the article text. I would also support making it a separate CSS class (if it isn't already) so that anyone who doesn't like the new setup could simply revert to the old one via a custom entry in their CSS file. Soap ^Talk/_{Contributions} 01:21, 1 June 2009 (UTC)
• Information – The following table is provided for informational purposes. Several have mentioned that the German Wikipedia uses the editsection button directly after the h2 header.(^and also all other headers marking an editable section - Sswonk (talk) 01:28, 15 June 2009 (UTC)) This is also the case on other language versions. The strictly arbitrary table shows the top 12 Wikipedia language versions based on article count, a link to a sample article ("DVD", chosen arbitrarily because the title is the same in all languages), and the non-formatted, position-only disposition of the editsection button on that site.

http://meta.wikimedia.org/wiki/List_of_largest_wikis ranked by article count

Wikipedia version	DVD article	Disposition of edit link
English	en:DVD	[edit]
German	de:DVD	[Bearbeiten]
French	fr:DVD	[modifier]
Polish	pl:DVD	[edytuj]
Japanese	ja:DVD	[編集]
Italian	it:DVD	[modifica]
Dutch	nl:DVD	[bewerken]
Portuguese	pt:DVD	[editar]
Spanish	es:DVD	[editar]
Russian	ru:DVD	[править]
Swedish	sv:DVD	[redigera]
Chinese	zh:DVD	[编辑]

Sswonk (talk) 04:13, 1 June 2009 (UTC)

• Info The bunching problem is actually an FAQ on WP:Village pump (technical). --Cybercobra (talk) 04:39, 1 June 2009 (UTC)

• Information – Just a little bit of background to the so called "German solution" (which in my ears sounds a bit weird …):
  I did the first version of the script back in March 2005 for mainly three reasons: The screwed up edit links when they intersect with floated elements, the (in my opinion) better usability, and because back then the edit links where placed before the headings in the HTML code which made no sense to me.
  I used the script just for myself in the beginning, but as the problem with floating edit links came up repeatedly I showed it to others in October 2005.
  When in July 2006 DaB. enabled it for all users in de, about 50 to 60 people were already using it. As DaB. just was bold and did it without any prior discussion (or telling me) the following discussions where quiet fierce. Mainly because the script was meant to be opt-in and so it had no opt-out build in at that time. The rest of the discussion had exactly the same arguments as here.
  In October 2006 the structure of the edit links was changed in MediaWiki from having a div above the heading to a span inside of the heading (but still before the headings text). That made it possible to shrink the script down to a few lines of code, which Marc Mongenet and I did more or less simultaneously (at least I guess so, because his version was online a little prior to mine, but I don't remember looking over to the French Wikipedia.)
  The French version was later modified by Maloq who claims that his version ist 500 times faster … didn't check this, just found it myself today.
  So in the languages Sswonk listed you'll find several different versions of the script, if you plan to try it with js before it gets integrated in MediaWiki itself (won't believe it until its done), choose wisely. I wrote this mostly to make clear that this is not some hasty reaction, lots of people are working on it and with it for years now. --Dbenzhuser (talk) 16:02, 1 June 2009 (UTC)

• MORE information! :) I think that I mentioned it somewhere above, but it may have gotten lost in the shuffle. I've been testing this out for a few days now and am almost completely used to it... it actually makes much more sense to me than the current stup does and I think that it is easier to use. The first day or two it was kind of weird, though; please try it for awhile before !voting to see if you experience the same effect I did. –Drilnoth (T • C • L) 16:26, 1 June 2009 (UTC)
  • As has been pointed out by M several times, this isn't about how easy it is for us to use this, since there will no doubt be a way for individual registered users to set this as a preference, but rather whether this change makes any difference for new and inexperienced editors who, according to the usability study, had trouble finding the edit links before. If they will still have trouble with the edit links, then this doesn't seem worth implementing, at least not as the default. Powers ^T 16:31, 1 June 2009 (UTC)
    • I think fixing the bunching problem makes it unequivocally easier to find the edit links when bunching is present. Any usability difference between directly-after-section-name vs. right-aligned is minor compared to the gains of fixing bunching. --Cybercobra (talk) 17:05, 1 June 2009 (UTC)

• Support either fixing the problem (the stacked edit markers is an identifiable problem) or creating a new way to do it that avoids the stacked ambiguity issue is preferred. I have no preference on either solution, but one of them should be implemented. As for "They spend $900,000 for user interface"...I think they are getting ripped off... — BQZip01 — ^talk 03:57, 2 June 2009 (UTC)

• Information – In the Chinese Wikipedia, there is actually a gadget for registered user to choose such that the edit button appears immediately after the heading, similar to German, French, etc Wikipedia. --Quest for Truth (talk) 14:11, 2 June 2009 (UTC)
  • I think it was determined that regardless of the outcome of this discussion, the other version would be available as a gadget in each users' preferences. –Drilnoth (T • C • L) 14:15, 2 June 2009 (UTC)

• Support if there is just evidence that readers prefer this structure. I was previously unaware such a survey had been undertaken. If it has, then I support this proposal. Greg Tyler ^{(t • c)} 16:12, 2 June 2009 (UTC)
  • I for one am not aware of any such study; the "usability study" referred to several times above contained a statement that the new editors in the study often missed the section edit button, and sometimes confused it for editing the section above instead of the section below. There was nothing in there about trying alternative positions to see if they were any better. Anomie⚔ 19:12, 2 June 2009 (UTC)
• Oppose. I honestly can't see what's to be gained by moving it and I don't see any issues with the current alignment. If it ain't broke, don't fix it. However, if it does go through, I support the idea of an opt-out version. Queenie 20:41, 4 June 2009 (UTC)

Even without considering any usability problems, there's the whole bunching issue. {{FixBunching}} is really quite a messy hack. OrangeDog (talk • edits) 22:49, 4 June 2009 (UTC)

It obviously is broken though. For example, I've had to click on the [edit] link in the Formal Proposal section to edit here. The issues with alignment/bunching are not common to all browser, but it is known to affect some, such as Mozilla Firefox. Mjroots (talk) 06:49, 5 June 2009 (UTC)

• Oppose- I've never seen this as that much of a problem and moving the link right after the section title is an eye sore and a readability issue. For example, if I reading aloud I would be tempted to read the edit link as well. It would just be in the way. This would only fix a few articles but I would support a different method to prevent it from overlapping.-- penubag  (talk) 17:15, 6 June 2009 (UTC)

• Support - I prefer to see the edit button immediately following the section header. In my experience, the righthand location tends to screw up from time-to-time, interfering with other texts or even images. Whenever it does this, it seems that fixing the problem for one browser seems to mess it up on another. (I have also suspected there might be a “skin” problem, but I’ve not checked for it.) Askari Mark (Talk) 02:28, 7 June 2009 (UTC)
• Oppose Click Recent changes some time and tell me if people are having a problem working out how to edit a section. WP is not a forum where we want people to add their opinion. Efforts should aim to make the encyclopedia read well. I don't want any klunky "edit me" text or button inside the article when I am reading it. Sure, new editors are totally lost. That's because they are new – a problem that won't be solved by moving the edit link. It's totally patronizing to imagine someone can't notice the [edit] link where it is. Johnuniq (talk) ]09:49, 7 June 2009 (UTC)
  • Just to clarify - are you seriously suggesting that we should make things harder to edit to prevent a few people from adding opinion? Please see the usability study, quoted several times above, which shows that new editors do in fact have problems with the positioning. Further, this very proposal is one of the designs that the usability team itself is developing.    M   18:09, 7 June 2009 (UTC)
    • One: So let Usability consider it. Two: We haven't changed anything yet, so to say "You're making it harder" is not only a poor choice of words, but also a modest use of hyperbole. Three: Which also depends on point 1. --Izno (talk) 14:19, 8 June 2009 (UTC)
      • Good, let them handle it. Meanwhile, let's not let "well, someone else will take care of it" stop us from making some sorely-needed progress. If this is the sort of opposition that the usability experts will be facing, then I'd like the precedent that this poll sets to be one that is in their favor.    M   15:24, 8 June 2009 (UTC)
        • But it might not come back in their favor, exactly because there are many people supporting this change, and not the change they will recommend. For all we know, they could say "get rid of the editsection links" or "you should make them as obtrusive as possible making them stretch the entire length of the section". Unlikely outcomes, but nonetheless possible. When they come back, we should make the move then to say "Yes, we want to go with your idea here" or "No, we think that's a terrible idea, can you cook something else up for us?". There is no deadline. --Izno (talk) 15:33, 8 June 2009 (UTC)
• Support. Improves usability (IMHO, at least—it's largely a personal preference issue). AGK 14:10, 8 June 2009 (UTC)
• Oppose for the aesthetic reasons mentioned. Further, I do not see the reason why we are polling on this when the usability initiative is already doing the same, and they're professionals. We are not. Consistent placement is important. --Izno (talk) 14:19, 8 June 2009 (UTC)
  • I believe this is being discussed here as a stopgap measure until a more permanent solution is implemented as a result of the study. Regardless, as I see it, reliance on a solution arrived at by the initiative crew could be compared to using a crystal ball, as could speculation that such a solution would be widely accepted – or widely rejected. The "reliance on professionals" argument is specious. The current implementation is semi-broken and should be fixed one way or the other. Ideally the position of the editsection button should be an option available under "My preferences". Sswonk (talk) 14:54, 8 June 2009 (UTC)
    • A stopgap measure for which obvious problem? Editsection is obviously not broken in its primary function; what are we trying to fix? We're working on the presumption that what we're doing would "fix" something, but I'm not seeing the "something" and I'm not seeing that it would positively fix it. Usability could decrease from the change! We could close a can of worms and then open up another! In its own way, the support is crystal-balling as well.
      I implore you to explain why you consider it fallacious. They were hired, by Wikimedia, to make the fixes that we don't know that we could. You seem to assume that I would fall trap to the argument from authority (which perhaps you assumed?); usability initiative is there to recommend changes, not force them on us. The change being considered here...
      As for the current implementation, it's not broken enough (from mine, and others' point of view) to expend the energy to fix any possible backlash against the idea once implemented. Its a documented issue, and you're more then welcome to remind the initiative of it, because as pointed out, they are breaking down a wiki-page to see what needs 'fixing'. Let them figure out what they want to say, and then we can take that into consideration. A bug, with CSS and not our own, with floating, isn't enough reason to get ahead of them and ourselves here. We've long had the issue of working with it, and we do have the hacks to deal with it necessarily. Not only that, but if you're getting image bunching problems, that could be a problem with the layout of the article... which I've not seen used as an argument. Consider what the MOS says about image layout: You should attempt to stagger the images instead. --Izno (talk) 15:18, 8 June 2009 (UTC)
      • You exaggerated my points a bit: I did not use the word "obvious" to describe the problem, although I did use it perhaps over-enthusiastically to support the change several days ago for my opinion of usability benefits, and I used the term "semi-broken", not "broken". I don't rest easy with complacency-based solutions anywhere but I'll leave it at that. However, I think your point about backlash is a very important one that deserves recognition. Will you at least agree with me that a preference-based, gadget choice which should be fairly trivial to implement in my estimation is desirable based on the comments here and more importantly on the widespread use across other language versions of a beside-the-header editsection button? BTW, I think we could use another "arbitrary break" after this mini-thread. Sswonk (talk) 15:39, 8 June 2009 (UTC)
      • (responding to Izno): Consistent placement of edit links is important, but right now the bunching problems that come up when you have longer infoboxes, side quotes, and images makes their placement inconsistent, whereas putting them next to the section headers consistently puts them in one place: At the end of the section's titles. I've been using my sample JavaScript for a week now, and I'm actually finding it easier and more natural to find the edit links now than I had before. I also haven't found that they get in the way acestetically... since section headers are bold and given more weight, and the edit links are just plain text, they don't really interrupt the flow of the article any more than they ever did. Also, you say "...the usability initiative is already doing the same, and they're professionals. We are not." If the usability study hadn't been done I think that this still would have come up. So do you feel that because there is currently a study going on, the discussion about and possible improvement of Wikipedia's interface should just stop simply because of their study? That doesn't really make sense to me... if they find that the change is problematic, then it can be undone easily, but why should we stop working to improve something because of a simple study? We wouldn't stop improving content if there was a study on Wikipedia's reliability. –Drilnoth (T • C • L) 15:50, 8 June 2009 (UTC)

• • • • • Sswonk: The javascript is obviously floating around, which is just as good as a gadget. I've no opinion either way.
          Drilnoth: You may be right that people may have opposed it anyway, but that's a non-issue. What I'm saying is that we shouldn't duplicate effort (especially when our "effort" is inferior implicitly), and that's what we're doing. Your comparison is inept, because we would already know the criticisms in that case. It's more like changing the interface when we don't know what those criticism are. --Izno (talk) 00:02, 10 June 2009 (UTC)

• I briefly considered ignoring this comment, but I've decided it shouldn't go without a rebuttal. A javascript may result in an equivalent format displayed on the screen, but for usability it is not "just as good as a gadget". A gadget provides a front end, GUI method to implementing a javascript. Your statement is like saying "DOS commands are just as good as clickable icons." Xerox PARC, Steve Jobs and Woz and the friendly folks at Microsoft all took a look at that sentiment from the usability persepective and they all disagreed with it many years ago. Sswonk (talk) 16:17, 13 June 2009 (UTC)

• Pollster For this section, 5 support, 4 oppose, 1 conditional support. Previous section 25:6. This brings the totals to an even 30 support and 10 oppose. This is since 27 May 2009, so 13 days or about two weeks since this poll began. As usual, see WP:POLLING, though I doubt this is a problem here since everyone has had something to say.    M   15:57, 8 June 2009 (UTC)

[edit] Edit links arbitrary break 2

• Strong support. There are some good objections which I think have been addressed: the link will no longer be consistent along the right - yes, this looks slightly worse, but is ok; and that we should let the usability people fix this - no, this is up to us to implement. Some other objections are really strange: a few seem as if the editors were aware of neither the points about bunching nor the usability study; at least a couple seem to oppose this because it would make it easier for the technologically inept to edit (right - we want this). The main objection now seems to be readability (that is, aesthetics). This takes a far back seat to usability (incidentally, I have found absolutely no readability problem with the new position while using the script). As for the reasons to do this, they are plenty:
  1. Moving the edit link fixes bunching, which is currently being addressed with the {{fixbunching}} hack. This is a very objective problem.
  2. Our current position violates the convention of making the 'actions' at the bottom (bottom right) of the text. This is the convention of many interfaces and nearly all discussion boards, which most people are familiar with (cf. 'edit, reply, quote'). The usability study has found that the current position causes new editors to click the wrong edit link, and presumably waste time looking for text that won't be there.
  3. Our current link is set too far apart from the heading text, which the study shows makes it easy to miss.
  4. It is clear that bringing the link beside the heading will solve a) bunching, b) wrong section editing, and c) poor visibility.
  5. It is not permanent, if the sky falls we can change it back.
  6. The new position is strange at first, but the editors who have reported back after trying it have given positive feedback.
  7. This is precisely the solution that the usability team is providing here, see a mockup here.
  8. This certainly is not just some new and slightly crazy idea: it has been implemented and tested on the second-largest Wikipedia, and it is working fine.

   M   17:13, 8 June 2009 (UTC)

Most of those would also be true for pretty much any positioning except the current one, but since we never properly tested anything else... Mr.Z-man 17:36, 8 June 2009 (UTC)

I failed to mention that this is another good point, and it would be nice to brainstorm something even better than this solution, but we've had 2 weeks with only one alternative proposed, the usability group has had time, as well as the german wikipedia. This seems to be the best thing we have. Something better and more radical would have died in the archives. At least small and clear steps like this are generating discussion.    M   17:47, 8 June 2009 (UTC)

I don't think 2 weeks is adequate time to develop, test, and vote on a significant interface change. This had the benefit of already being developed and tested on other wikis, so every other possible proposal was way behind from the beginning. The brainstorming should have been done before the poll started, but that part of the discussion only lasted a few days and didn't properly test anything. Its the best thing that's been proposed because its the only thing that's been proposed other than the status quo. There are several things that could be done that would be just as radical as this change, would also keep the links in a consistent horizontal location, and may not require JavaScript to implement, but nobody's willing to give them more than a passing thought, because jumping on the bandwagon of this is easier. Mr.Z-man 18:12, 8 June 2009 (UTC)

• Support. I tried the css code proposed by Mr.Z-man above (I only changed position to static), which places edit links at the beginning of section titles, and found it rather convenient. So, I support, this proposal, if there is an opt out option, which allows me to keep control over where my edit links are set. Ruslik_Zero 18:51, 8 June 2009 (UTC)
  • CSS and JavaScript will be usable to change the location regardless of the "default". I think that this proposal is to have the edit links immediately after section headers... I don't know if there was a typo in your post or if you wanted to support a version different from what is primarily being discussed right now; just thought I'd mention it. –Drilnoth (T • C • L) 19:36, 8 June 2009 (UTC)
  • Note that what I gave above was not a proposal, merely a start/proof of concept that that could be done while still fixing the bunching issue. It would definitely need more work and testing by someone with more CSS expertise than myself to be viable. My point was merely that there are more options than the one being presented here, that was just one of them. Mr.Z-man 19:59, 8 June 2009 (UTC)
    • Mr Z-man, as I've stated above, I'm open to other suggestions. I've asked above for other suggestions to be posted, but so far there have been none. As I've also stated above, I realise this will be a big change if implemented. It may be that the best way forward with this particular change will be to make it a user preference rather than an arbitrary change. Either way, something needs to be done, and as has been pointed out, the change I suggested is well tried and does work on otherw Wikis. Mjroots (talk) 20:28, 8 June 2009 (UTC)
      • Exactly, all the testing for this idea is done, which means any other proposal needed to do the development, testing, and polling in the time of the polling for this one. There were 3 days between the time the thread started and the poll started. That is not adequate time for development and testing. Mr.Z-man 20:37, 8 June 2009 (UTC)
        • Well, even if this does go through, what's stopping the development, testing and proposal of another method at some time in the future. Absolutely nothing, that's what! Mjroots (talk) 21:11, 8 June 2009 (UTC)
          • People are generally resistant to change, even more resistant to frequent change. Mr.Z-man 21:19, 8 June 2009 (UTC)
• Support moving the edit button to the end of the section header... --candle•wicke 23:34, 9 June 2009 (UTC)
• Weak oppose I prefer the consistency and unobtrusiveness of having the of the having the edit links on the right side. As for bunching, I do not think that a rendering problem with one browser on a minority of pages should be a factor in determining presentation style. A technical problem warrants a technical solution. Also, I do not believe a change in position would have a significant impact on the ability of a first-time to find an edit link. However, if this is a driving factor for change, I'd suggest an experiment: Write a temporary script that shows the edit links after the header for odd IP addresses and right aligned for even IP addresses, and review IP editing statistics after a day or so. -- Tcncv (talk) 01:17, 10 June 2009 (UTC)
  • I believe that bunching is a problem on every major browser, as well as a problem on most pages with an image. I'm not sure that it makes sense to say both that it would be more obtrusive, and also just as easy to miss. Perhaps you could give the script a try for a week or so?    M   00:42, 11 June 2009 (UTC)
• Support moving the edit link or button to the end of the section heading. This would improve layout problems on many articles, which ovrrides the unobtrusiveness concern, in my opinion. Finell (Talk) 16:26, 14 June 2009 (UTC)
  • Question Why are many editors talking about this as a proposal for level 2 (h2) headings? The same layout problem applies to all heading levels. I hope no one is thinking that they should jump back and forth (or, right and left) for different levels. Also, please note: we are discussing section headings; a header is something else. Finell (Talk) 16:26, 14 June 2009 (UTC)

What I intended is for all levels to be presented the same, with the [edit] button appearing immediately after the last character in the heading. Mjroots (talk) 18:55, 14 June 2009 (UTC)

• Strong oppose, but will move to Support if the button is GREY and not bright blue—If I understand correctly, the bright-blue "[edit]" would be shunted so that it's immediately to the right or under the section title. Bad idea from a visual perspective. En.WP has it much better positioned than the French and German projects, which have obstructive blue jostling with every title. It's as though all readers were WPian editors. They're not. About 0.000000001% are. My view is unchanged by the regrettable and occasional tangling of the edit button with images. Perhaps we could fix that problem as a separate issue. Tony (talk) 08:21, 16 June 2009 (UTC)

Tony, you understand the proposal perfectly. The problem of tangling of the edit button with images is precisely what the proposal is trying to fix. See West Kingsdown Windmill, an article I expanded today. Before expansion there were no bunching issues. After expansion, with an additional infobox, there are several. I've imported Drilnoth's script,bypassed the cache, and the bunching problems have disapperared. All edit buttons falling neatly at the end of the heading. Mjroots (talk) 13:41, 16 June 2009 (UTC)

Tony, please understand that this poll is only about the placement of the edit button, not its appearance. It will probably be made smaller than the current button, and perhaps in gray text. That will be decided after this if there is consensus to move the link. –Drilnoth (T • C • L) 19:14, 16 June 2009 (UTC)

• Support, it is far too easy to click the wrong [edit] link with the current setup. The workaround we use against bunched-up editing links is a wrong way to address the issue (we should not change the page layout to make non-reader elements (the edit links) appear correctly). Keeping the edit links with the section headers is much cleaner. Kusma (talk) 08:48, 16 June 2009 (UTC)
• Oppose per User:Anomie and User:Mr.Z-man. This poll is extremely premature. Garion96 (talk) 10:52, 16 June 2009 (UTC)
• Oppose per Tony. Also, in defence of {{fixbunching}}, it fixes other text layout too. If this does go ahead, an opt-out will be needed (and thus {{fixbunching}} won't be going away). Mark Hurd (talk) 13:43, 16 June 2009 (UTC)

Consensus seems to be that the existing situation should be retained, either as a user preference, or by making this proposal accessible via a user preference. Mjroots (talk) 13:47, 16 June 2009 (UTC)

• Comment Seconding Mjroots. I'm thinking that at 5 support, 4 oppose for the latest section break, with many well established comments on both sides, this proposal has gained a clearer consensus. Can a few editors comment on how difficult it would be to simply add a gadget that loads the Drilnoth javascript? I think that would serve two purposes, that is advertise this proposal as an option to a much larger group of editors that might not know about this thread, and also avoid any backlash against changing default behavior. Is adding a gadget feasible and non-disruptive enough, thoughts? Sswonk (talk) 13:58, 16 June 2009 (UTC)

  Adding a gadget is very easy, it just takes an admin to follow the instructions at WP:Gadget#Installation. Anomie⚔ 14:25, 16 June 2009 (UTC)

  Great. An added advantage to this approach that I neglected to mention is that the gadget would provide a quick and obvious method for new or otherwise interested editors from the non-English wikis such as French, German etc. who maintain accounts here to change the style of the editsection button to something they are familiar and comfortable with. Sswonk (talk) 14:57, 16 June 2009 (UTC)

  A gadget is planned regardless of the outcome of this !vote to allow the other version to be selected in preferences. –Drilnoth (T • C • L) 19:14, 16 June 2009 (UTC)

• Oppose, per DGG well above. SandyGeorgia (Talk) 15:49, 16 June 2009 (UTC)

Comment DGG has not !voted on the proposal. Mjroots (talk) 16:08, 16 June 2009 (UTC)

DGG commented above (I do hope you understand that consensus is not a "vote"?) SandyGeorgia (Talk) 16:10, 16 June 2009 (UTC)

• Conditional support only if there is a setting available at the same time that would allow me to move the edit links back to where they are now.--Rockfang (talk) 18:28, 16 June 2009 (UTC)
  • There should be an option in Preferences>Gadgets after this poll ends to allow the version which isn't the default to be used instead. So if consensus is for the change, you'd be able to go back to the current version with about four clicks. –Drilnoth (T • C • L) 20:16, 16 June 2009 (UTC)
• Support in the other languages where it appears on the left, I got used to it quickly. The en: system of it being on the right makes little sense once you get used to the left-alignment. TheGrappler (talk) 20:13, 16 June 2009 (UTC)
• Oppose. Mainly on aesthetic grounds (I simply prefer the section heading not to be diluted with functional syntax). If there is no other way of avoiding the technical glitches with a right-aligned "[edit]" link, then okay; but I'd be very surprised if the right-align-initiated problems couldn't be solved in other ways. On a purely practical point: following the left-alignment of the "[edit]" link, be prepared for a sustained larger number of school-kid-type edits on the intellectual level of "wazza was here". In any outcome, I would make the "edit" link much smaller—e.g. [edit] (or an icon of equivalent size).  HWV258  22:45, 16 June 2009 (UTC)
  • I really don't understand these objections on aesthetic grounds. This isn't a proposal based on aesthetics, it's a proposal based on usability. Further, with cleanup boxes, infoboxes, poor layouts, spelling mistakes, paragraphs of fluff, and occasional glaring errors, surely the position of the edit link is the least of our readability concerns. We might as well be arguing about making all of our links not blue. Since these aesthetic oppositions are somewhat common, yet always neglect the usability points, I would like to know what they think about it. And isn't it the point to make wikipedia easy enough for an 8 year old to use?    M   05:55, 18 June 2009 (UTC)
    • Its a proposal to change the UI, while usability is important, we shouldn't totally ignore aesthetics, that's just irresponsible. Mr.Z-man 16:48, 18 June 2009 (UTC)
    • "And isn't it the point to make wikipedia easy enough for an 8 year old to use?"—but not every eight-year-old. Call me a snob, but I'm happy to do away with the services of any eight-year-old who can't find [edit] on the right-hand-side of the screen.  HWV258  01:26, 19 June 2009 (UTC)
• Support, to fix the bunching issues and for rationality, but allow the user to pick both from settings. feydey (talk) 13:16, 17 June 2009 (UTC)
• Support Anyone editing a section is almost surely not a vandal. Why not make it easier for good faith anons? HereToHelp ^{(talk to me)} 16:37, 18 June 2009 (UTC)
• Strong Oppose. This misguided proposal confuses readability with usability. Readability for the overwhelming majority of users who have no desire to edit the article must always take precedence over the convenience of the very small number who do. --Malleus Fatuorum 21:39, 18 June 2009 (UTC)
• Oppose per DGG. –Juliancolton | ^Talk 21:46, 18 June 2009 (UTC)
• Oppose per DGG and Malleus. NW (Talk) 23:12, 18 June 2009 (UTC)
• Oppose Readers come first, always. Dabomb87 (talk) 23:20, 18 June 2009 (UTC)
  • IMO, this is about the readers. We're trying to encourage readers who don't know that the wiki is editable to give it a few copy edits, correct a misspelled word, etc. Additionally, I didn't think that the links interfered with reading the section headers, even when I had just first installed my test script. –Drilnoth (T • C • L) 23:25, 18 June 2009 (UTC)
    • Actually, on testing the script, the edit links on level two headers (==) were not that bad. However, I found the edit links on level three and lower headers very obtrusive. Also, I've enabled the edit link for lead section; I didn't like seeing the edit link right next to the page title. Obviously, that wouldn't affect readers, but it did affect my decision. Dabomb87 (talk) 02:28, 19 June 2009 (UTC)
      • I'm pretty much neutral on the level 3 and lower headers, and I hadn't though about the level 1 head. That could probably be fixed so that it doesn't affect the header without too much difficulty. Also keep in mind that if this passes the edit link will probably be smaller and/or a slightly different color, so it might not be as in the way with level 3 and lower headers. –Drilnoth (T • C • L) 02:34, 19 June 2009 (UTC)
• Support. The main reasons to support this are both practical and aesthetic (because of the bunching problem, the floating edits are ugly and silly); the main reasons to oppose are aesthetic and a belief that the editing aspects of Wikipedia should not be so obvious. There is little doubt that the aesthetics of the bunched edits are ugly. While it is a matter of opinion that left aligned Edits are less appealing that right aligned Edits. It may well be that those who prefer the way they are now are aesthetically conservative by nature - it is simply a matter of opinion, and those aesthetically in favour of right aligned edits are on the sample of this poll, in the minority. As for "readers over editors", I would agree with that argument if we are talking about not placing tags such as {{Orphan}} and {{Copyedit}} on articles, but we are not - we are simply talking about moving the word Edit from a place where it is impractical and occasionally clearly unaesthetic, to a position where it is useful, helpful, aesthetically acceptable to the majority, and encourages readers to edit. It's a win, win, win situation. SilkTork *^YES! 19:23, 19 June 2009 (UTC)

• And yet, somehow millions upon millions upon millions of edits to WP have somehow happened with right-aligned [edit] hyperlinks. Go figure.  HWV258  09:06, 20 June 2009 (UTC)

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.

[edit] Gadget

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

See also: User talk:Drilnoth#Gadget addition without discussion and Wikipedia:Administrators' noticeboard#Discussions need administrator closing, the former about my Gadget addition without a formal proposal and the latter about closing this as no consensus rather than "change". All comments at both are welcome. –Drilnoth (T • C • L) 18:22, 20 June 2009 (UTC)

Last I checked (I didn't count the recent additions), it was 3:1 in favor. Is that not consensus? How is it no-consensus when the issue of whether encouraging editing should be a priority (upon which many oppositions depend) hasn't been adequately discussed? (It is a priority, by the way - why do people think all that money's going to the usability study?) Defaulting to the current interface on usability or aesthetics is often a bad idea (there's that story of ebay having to slowly fade out its (ugly) yellow background because users complained when they got rid of it in one go).    M   08:53, 26 June 2009 (UTC)

I get about 40 support and 19 oppose total (counting the section since the last Pollster and assuming that Pollster was accurate for everything prior). --Cybercobra (talk) 21:41, 26 June 2009 (UTC)

[edit] 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. Reywas92^Talk 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)

[edit] 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)

[edit] 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)

[edit] Question

My question for the community is this:

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

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

• Seems logical to me to do this the same way as with the gadget. It takes up more or less no additional space, and I can't see any negative effects... it might help readers to learn more about our quality guidelines by seeing which articles we rate higher. However, some more intelligible names might be nice on the main page... something like Stub, Start, Average, Above-average, Good, Excellent, Featured, maybe? The current names would be confusing to people who don't even know that we have such a rating system. –Drilnoth (T • C • L) 18:33, 22 June 2009 (UTC) Neutral, after seeing some of the comments below. –Drilnoth (T • C • L) 22:32, 22 June 2009 (UTC)
• Support - I like the idea, it is helpful and is expanding on the FA icon that is featured on FA articles. --Jeremy (blah blah) 19:16, 22 June 2009 (UTC)
• Oppose for the same reason this proposal is always opposed. Featured Articles go through a consensus-based process with lots of checks and balances and are under constant scrutiny as long as they're at FA level; every other rating is the result of a single – arbitrary – value-judgement by a single reviewer. Advertising GA or B class articles as "quality" could (and would) give a misleading impression of accuracy and neutrality. – iridescent 19:22, 22 June 2009 (UTC)
• I would oppose this. Due to the way most pages are rated after only a cursory review, anything below GA is just an arbitrary grade. Mr.Z-man 19:29, 22 June 2009 (UTC)
• I agree somewhat with Drilnoth: were this to be implemented, the existing gadget does the job well. I started using that gadget as an experiment to see what it was like, and found it to be quite useful. Now, while on the one hand it would be good if more people were aware that we at least have a rating system, I think it might also be confusing to people, since people will confuse completeness and review with accuracy. That confusion might negate the potential for positive PR, since people might get the idea that B-class and lower articles (which form the vast majority of our content) are not entirely accurate (when the reality is that they merely need expansion and review). I support this in theory, but I can certainly accept the status quo. {{Nihiltres|talk|edits}} 22:08, 22 June 2009 (UTC)
• As nice an idea as this is, the nail in the coffin for me is brought up above - FA is the only quality class that goes through any kind of rigorous evaluation process. Unless and until a more universal process can be adopted for other quality classes, they remain worthless as an indicator of quality to the reader. Shereth 22:41, 22 June 2009 (UTC)

  What about A-Class articles? At least at WP:MILHIST these are comprehensively reviewed in a manner comparable to the FA process? Cool3 (talk) 22:56, 22 June 2009 (UTC)

  Too confusing; AFAIK no project other than MILHIST uses A-class (the sprawling WP:LONDON, for example, has a grand total of one A-class article, and even Category:A-Class United States articles contains only seven entries) – the difference between MILHIST's assessment scale and the rest of Wikipedia is most obvious on articles like American Civil War which are A-class for MILHIST purposes but GA-class for every other project. We can't expect our readers to understand that there's one project that uses a different assessment scale to everyone else, let alone try to depict it via 20-pixel icons. – iridescent 23:05, 22 June 2009 (UTC)

  There's 472 A-class articles, of which 187 (40%) are via MILHIST. This is certainly disproportionate, but it does indicate that other projects are beginning to use it as well. (That said, I've personally never quite got the position of A-class - in many ways, between GA and FA, it seems to be a rating in search of a role...) Shimgray | talk | 23:39, 22 June 2009 (UTC)

  I have to disagree just a bit. While ratings stub through B are somewhat artbitrary, would anyone disagree that articles rated B are on average better quality and reliability that articles rated start? Likewise, on average, are not articles that pass a GA of better quality and more reliable than a C class article? Sure there are exceptions and it is not a perfect system, but in most cases the ratings to demonstrate a valid assessment of the quality of the article. Just because they are arbitrary does render the assessment without value. If the ratings are good enough to help identify the articles going onto the CD version of the wikipedia, then aren't they also good enough display to our average reader? And as long as a reader understands the source of such ratings, B or GA class, then how could we be misrepresenting anything? The point is not say certain ratings are completely trustworthy, it is to say, that some articles are generally more\less trustworthy than others. —Charles Edward ^{(Talk | Contribs)} 04:24, 23 June 2009 (UTC)

  I suppose that readers who "understands the source of such ratings" are sufficiently qualified to check talk pages and have their own opinion on the weaknesses of the system. Readers "from the cold" don't have this knowledge; force-feed them all the disclaimers, they still won't feel how it works. NVO (talk) 06:29, 23 June 2009 (UTC)

• Oppose per Iridescent. –Juliancolton | ^Talk 23:28, 22 June 2009 (UTC)
• I've been arguing for what seems ages now in favour of a GA green dot, but I've come to accept that it just ain't gonna happen. GA, whatever its perceived faults, does at at least have a standardised set of criteria, which isn't the case for anything else other than FA. For me, only three ratings make sense: GA, FA, and the rest. Anyone who wants to see article ratings can register an account and switch on the relevant gadget from their preferences. --Malleus Fatuorum 23:36, 24 June 2009 (UTC)
  • I pretty much agree with you there. The GA criteria are well defined and most GAs have a minimum quality level; I don't see why we shouldn't show them to the readers. The other, more subjective, classes, however, should not be shown by default to readers who don't fully understand the system. –Drilnoth (T • C • L) 23:41, 24 June 2009 (UTC)
    • I wouldn't be passionately against a green dot for GAs – although I suspect the end result would be a flood of poor-quality GA nominations and back-scratching, as everyone tried to get recognition for their pet article – but as per my comments above, I'd be very opposed to any of the other (completely arbitrary) ratings being displayed. (Ideally, I'd love to see the GA process restructured to get independent reviews from two separate editors, but that's got a hell/snowball chance.) – iridescent 19:33, 25 June 2009 (UTC)
      • Iridescent hits the nail on the head (if somewhat obliquely) as to why I would be opposed to even GA appearing on an article. For as much as there exists some kind of standard set of criteria, in the end it still boils down to a single judgement call as to whether or not an article actually meets said criteria. I'd like to assume that every volutneer reviewing GA nominations makes a correct assessment every time, but the fact that an assumption is necessary tells me that the use of GA as a reliable criteria that we present to end users is not yet a good idea. Shereth 19:48, 25 June 2009 (UTC)

[edit] 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]. –xeno^talk 19:25, 24 June 2009 (UTC)

<_< PeterSymonds (talk) 23:20, 24 June 2009 (UTC)

• • (Semi-serious) Should noobs really be admins? Would it really have been so bad for that admin to have to ask another admin (or buro, whatever) to unblock them? --Cybercobra (talk) 19:40, 24 June 2009 (UTC)
    • Some kind of a virtual walk to Canossa you mean? :-D SoWhy 19:54, 24 June 2009 (UTC)
    • It's not just noobs. --Floquenbeam (talk) 20:06, 24 June 2009 (UTC)
      • Don't forget my personal favorite. J.delanoy^gabs_adds 23:29, 24 June 2009 (UTC)
        • Win. –Juliancolton | ^Talk 23:33, 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)

[edit] 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 [3] 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)

[edit] Default languages

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

This is the English Wikipedia, so it is prefered that everything is written in English here. By the way, didn't you forget something? PCHS-NJROTC ^(Messages) 20:58, 25 June 2009 (UTC)

Much of the interface can be changed by going to Special:Preferences, but most all content on this site should be in English. If you want articles in other languages, look in the sidebar on articles and see if there are any links to other languages there. –Drilnoth (T • C • L) 21:01, 25 June 2009 (UTC)

Obviously, I didn't formulate my question right. So second try: I would like to suggest an option on all the articles on Wikipedia. By example on http://en.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)

[edit] 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)

[edit] Creating redirects with bot

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

[edit] 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)

[edit] 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)

[edit] moving the menu

Hi!

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

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

Thank you, cincerely yours,

iivari.mokelainen

White space on a page is important for readability among other things, so I don't think it should be removed. Perhaps there's a skin that would help people to choose this kind of effect if they desire it? PL290 (talk) 16:21, 26 June 2009 (UTC)

This is a matter of taste and of the size of your monitor. If it's a problem for you, you can solve it when you are logged in: Click on "my preferences" at the top of the page, then choose the "Appearance" tab. Here you can choose between several skins. The "Chick", "MySkin" and "Nostalgia" skins do what you want. Look at WP:Skin, which has screen shots of each skin that make it easy to choose the right one for your taste without too much experimenting. Hans Adler 17:41, 26 June 2009 (UTC)

See Help:Mobile device --Nopetro (talk) 11:50, 29 June 2009 (UTC)

[edit] Articles for Deletion needs more automation

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

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

• I see that we are playing tag here. The bot for RM came from RFC, and the 7 days at RM from AFD. 199.125.109.124 (talk) 20:06, 26 June 2009 (UTC)

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

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

[edit] Edit head

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

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

Thank you a lot ;-) --Nopetro (talk) 11:49, 29 June 2009 (UTC)

[edit] Pronunciation to foreign place infoboxes

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

You probably need to discuss this on some infobox template talk pages. ---— Gadget850 (Ed) ^talk 19:26, 29 June 2009 (UTC)

That's an interesting idea; I've got to get going, right now, but I'll see if I can find an appropriate talk page later, if no one has by then. – Luna Santin (talk) 23:58, 30 June 2009 (UTC)

Cross-posted to Wikipedia talk:WikiProject Infoboxes#Pronunciation field in infoboxes?. – Luna Santin (talk) 21:07, 1 July 2009 (UTC)

[edit] Userspace redirect

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

What good reason is there for anyone to need a redirect to their userspace? "I want one" and "It makes my sig shorter" are IMO not good reasons. Anomie⚔ 22:40, 28 June 2009 (UTC)

Obviously the same reason we have redirects to everything else: shortcut. - ALLST✰R▼^echo _{wuz here} 07:37, 29 June 2009 (UTC)

You just said "A good reason for having a shortcut is because it's a shortcut". That tautology doesn't actually answer the question: Why is such a shortcut necessary? Anomie⚔ 12:26, 29 June 2009 (UTC)

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

WP:CSD#R2 forbids redirects from mainspace (so, from all pseudo-namespaces) to the user namespace, and has always. When I became an admin, userspace was the only explicitly forbidden target, and this policy has always been enforced. I see no need to change it, and if your username is too long, you can try to change it at WP:CHU. Kusma (talk) 08:51, 29 June 2009 (UTC)

• I wouldn't mind a proper WP: style alias being created for User talk: (UT:) but User: seems unnecessary (removing three characters). Anyhow, I've previously suggested to ASE that he register User:ASE, seems like a nice short redirect and good doppelganger because people call him that anyway. –xeno^talk 17:42, 29 June 2009 (UTC)
• Doesn't seem to be a worthwhile change, to be honest. Stifle (talk) 13:13, 30 June 2009 (UTC)
• From a technical perspective, setting up of a proper namespace alias, like WP and WT are now, is a doddle. Regards U/UT, there is a precedent in the sense that on de.wp, BD can be used instead of the rather long (and longer that on en) "Benutzer Diskussion". - Jarry1250 ^{[ humourous – discuss ]} 15:41, 30 June 2009 (UTC)
• U and UT would be cool. Less typing as a good thing should not be underestimated. - Peregrine Fisher (talk) (contribs) 00:13, 1 July 2009 (UTC)
• Yeah, since we've already got User: and User talk:, I see no reason why there shouldn't be a related pseudo-namespace such as U: and UT:. - ALLST✰R▼^echo _{wuz here} 07:28, 2 July 2009 (UTC)
• I can vaguely see the argument of shortcutting "User talk:" with "UT:". It's shorter and linked to a fair bit. That said, I really can't see the need for a shortcut. Sure, it's a few extra characters to type but is it really that difficult? It seems to be more of a personal request than something that will improve Wikipedia. In some ways I'm saying IDONTLIKEIT, but I feel the proposal is purely based on the fact that ILIKEIT. Greg Tyler ^{(t • c)} 10:41, 2 July 2009 (UTC)

[edit] 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)

[edit] "Remember me for __ days"

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

It's possible, but the devs are going to want to see some good reasons before they think about implementing it. Algebraist 01:10, 1 July 2009 (UTC)

Well, I often use computers that are not my regular one. I want it to remember me for the time that I'm using it (5 days for example when I stay at my parent's house next week). I want to check "remember me" but that's for 30 days, and I only want it to remember me for 5 days. iMatthew ^talk at  01:21, 1 July 2009 (UTC)

Why not just log out when you've finished using the computer? Algebraist 01:26, 1 July 2009 (UTC)

[edit] New category for promotional articles

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

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

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

Don't know if "scum" is the best term, but it's a sound idea. Possibly Category:Articles with a promotional tone (hidden, of course). ▫ JohnnyMrNinja 05:41, 1 July 2009 (UTC)

Yes, something like that. :-) I'm not usually one to put labels on articles, but those {{advert}} pages are sometimes kind of bad, and it may help to distinguish them. Jamie^☆S93 14:59, 1 July 2009 (UTC)

[edit] Move all Wikipedia pages in (disambiguation) format to /subpage format

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

By using disambiguators, we're matching our naming conventions for articles, which I don't think is a particularly bad thing. You already mention the "it ain't broke" argument, but really, that's what it comes down to. Your arguments aren't particularly compelling (the "search criteria" bit is a total non-issue, since it doesn't affect how one searches for anything in either direction). *shrug* I wouldn't be upset if it happened, but I just don't feel that passionate about it one way or the other. :) EVula // talk // ☯ // 21:05, 1 July 2009 (UTC)

My search comment was rather half-formed; they do affect the search when using a prefix: search, like in the box at the top of this page, although the two options (when properly titled) are very similar for this. This was more of a comment of support for subpages in general. The ethnic and religious conflicts is a great example of a page that has benefited form being moved to a subpage of WP:AN (from an unrelated title), with much increased traffic because of the clear association, which also falls under the same search parameters as WP:AN and WP:AN/I.

You mention that we would be using a different convention for WP page than article pages. This is a very good point. The use of parenthesis down-plays a word. There is no game called Conan (2007 video game), it is a game called Conan that we have disambiguated. Conan/2007 video game would be improper, putting undue weight on the made-up qualifier. Wikipedia-namespace pages are totally different. These pages are 100% self-referential. Wikipedia:Manual of Style (biographies) is called Wikipedia:Manual of Style (biographies). There is no reason to down-play the thing that makes a WP page unique, and that particular page would sit better at Wikipedia:Manual of Style/Biographies. ▫ JohnnyMrNinja 04:32, 2 July 2009 (UTC)

How is that going to work where the disambiguation page itself is not located at the primary topic, and other pages naturally located on the disambiguation page do not have disambiguators - e.g. George Washington (disambiguation) and George Washington University, which is certainly ambiguous, but is the official name of the institution, making it inappropriate to locate it at "George Washington (University)" for example. bd2412 T 04:43, 2 July 2009 (UTC)

There is no need to move most of the pages in that format. Keep in mind that I am only talking about project pages here, not articles. I don't think that WP:Administrators' noticeboard should be a subpage of WP:Administrators even though they start with the same word. Some articles with different titles would do well as subpages, but those should really be handled on a case-by-case basis. For now I am only talking about pages that actually have disambiguators. If you are talking about articles, I think that subpages for articles are a very bad idea. ▫ JohnnyMrNinja 13:25, 2 July 2009 (UTC)

I agree with JohnnyMrNinja - This page, for example, isn't a disambiguated page from Village pump, it's a subpage of it. George Washington (disambiguation) isn't a subpage of George Washington. עוד מישהו Od Mishehu 07:11, 2 July 2009 (UTC)

[edit] 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)

WP:Avoid instruction creep. Just do it, and if people complain discuss it. IIRC, when this sort of proposal has been made in the past people have suggested just putting it in {{todo}} or the like, if for some reason a normal talk page section isn't good enough (most articles' talk pages are seldom if ever archived, so it's not like the talk page section is all that likely to disappear). Anomie⚔ 18:20, 1 July 2009 (UTC)

Creating a box for that is an excellent idea, so I went ahead and created {{Refideas}}. It has a wider use... in addition to listing things like PD resources, other references which may be useful in the future can be included. –Drilnoth (T • C • L) 20:09, 1 July 2009 (UTC)

oooh, that's classy. Here are a few suggestions:

1) Somehow, it should draw attention to Public Domain sources, because they can be adapted with a minimum effort.

2) Wikipedia will improve even quicker if there were a list of "pages containing non-integrated PD sources", where people could go to mindlessly integrate PD content. (e.g. it took me 20 minutes last night to create "House Minority Leader", which was previously a redirect to a list of party leaders, using a government research report.) That's one reason why I, personally, would prefer the template to focus on PD sources -- such a list will be generated from the pages it's on. (Otherwise, the box will just be moving things from "external links" to the talk page, which is somewhat useful but less so.)Agradman ^talk/_contribs 20:21, 1 July 2009 (UTC)

Hmm... I see your reasoning. I need to log off for awhile but will add this to the template later today in a way that makes both of these possible. –Drilnoth (T • C • L) 20:28, 1 July 2009 (UTC)

Y Done. See the documentation for details. –Drilnoth (T • C • L) 21:57, 1 July 2009 (UTC)

Wow I'm stunned. Not only have you done beautiful work, but you did it really quickly, and you made my idea feel welcome. I'll wait until we hear feedback from a few other editors before I start slapping this on pages, but in the meantime, I'm going barnstar shopping. Agradman ^talk/_contribs 22:16, 1 July 2009 (UTC)

Thanks. :) Anyway, I think it would be safe to just start using the template... mentioning it in a guideline or policy would need a good bit of consensus, but using the template seems to make more sense then just making new sections on talk pages, so why not? –Drilnoth (T • C • L) 22:35, 1 July 2009 (UTC)

[edit] Bots fixing redirects in navboxes

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

I'm neutral on this, since I have a userscript that highlights self-redirects anyway. Bringing it here first is a good idea, as such a bot needs a strong community consensus before being approved. Anomie⚔ 02:08, 2 July 2009 (UTC)

I'd really like to see this bot. This is one of the exceptions at WP:R2D that should be fixed, as it causes confusing self-linking-redirects. –Drilnoth (T • C • L) 02:15, 2 July 2009 (UTC)

[edit] 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)

[edit] 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)

[edit] 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 [4]. MER-C 03:42, 3 July 2009 (UTC)

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

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

Can't the problems be addressed by technical improvements to the patrolling feature? Deleted pages obviously don't need to be reviewed any more, so it's pretty pointless to mark them as patrolled. Kusma (talk) 13:10, 2 July 2009 (UTC)

NPP is just regular editors and admins. There's no real difference between the page being reviewed by someone on the list and someone who isn't. Mr.Z-man 14:20, 2 July 2009 (UTC)

Wouldn't the easiest thing to do just to be changing the software so deletion automatically counts as patrolling? I think it's safe to call a deleted page patrolled no matter what. Changing the patrolling software itself would probably be a lot more hassle. JohnnyMrNinja 19:31, 2 July 2009 (UTC)

Its all the same software. Whether or not a page is patrolled only means anything on Special:Newpages, and its removed from there once its deleted. Mr.Z-man 19:51, 2 July 2009 (UTC)

I thought the point was that these pages aren't being removed from the list? ▫ JohnnyMrNinja 19:54, 2 July 2009 (UTC)

They aren’t removed until they are clicked as reviewed on the pages. Most of the time these pages are just moved, not deleted.--Gosox5555 (talk) 21:23, 2 July 2009 (UTC)

A deleted page cannot be marked as patrolled because there's nothing to patrol. The "patrolled" status is only recorded in the recentchanges table (which is what newpages uses). When a page is patrolled, the page itself is not patrolled, just the recentchanges entry for the page creation. Mr.Z-man 00:38, 3 July 2009 (UTC)

Maybe my wording was confusing. I'm not saying that they should. If there was a way to mark a page as patrolled from Special:NewPages, that would solve my problem. Or if you didn't have to be coming directly from Special:NewPages to click the button. Is this possible? Gosox5555 (talk) 14:24, 3 July 2009 (UTC)

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

Why is that necessary? NPPatrollers tag the article with a CSD tag and an admin reviews it later. An admin has the technical ability to delete it straight away. If an admin is pretty sure and not certain, tagging for a second review is fine, but to enforce a rule that all admins tag articles they patrol is a bit pointless in my opinion. PeterSymonds (talk) 07:43, 3 July 2009 (UTC)

MuZemike: you might want to gain consensus to change CSD then. "The criteria for speedy deletion specify the limited cases in which administrators may, at their discretion, bypass deletion discussion and immediately delete Wikipedia pages or media."

Gosox5555: I don't see any real benefit from this, and plenty of drawbacks. Stifle (talk) 08:12, 3 July 2009 (UTC)

(edit conflict) That's what I was getting at the clearly blatant stuff (such as copyvios, attack pages, or most things under the "G" criteria). I think I was more referring to the other CSD criteria, such as A7, R3, stuff that may possibly be more debatable. You're right that it would not be anything enforceable, as that's how the nature of CSD is. However, I think that the role of "CSD tagger" should not be intertwined with "CSD deleter"; that is, you're simply CSD tagging or you're simply CSD deleting without overlap (the WP:ADMIN policy is clear in that you obviously cannot do both to the same article). That's what I hope I mean, MuZemike 08:16, 3 July 2009 (UTC)

That is, not in close proximitity or in which the admin may be involved, of course. MuZemike 08:18, 3 July 2009 (UTC)

(ec)Well, on the limited occasions when I get to do NPP any more, I delete pages straight away when I'm clear that they are CSD-eligible, and tag them if I'm not all that sure. I don't tag a page and then delete it, but only because it'd be a waste of time. Stifle (talk) 08:19, 3 July 2009 (UTC)

And indeed, I don't (or try not to) do speedy deletions in the (limited) areas where I could be considered impartial. Stifle (talk) 08:20, 3 July 2009 (UTC)

To veer back on topic, I don't think NPP should be able to patrol before a deletion occurs, as many articles fall through the cracks anyway. Furthermore, many users to tag NewPages for CSD also use Twinkle which automatically patrols the page right there. Assuming good faith, the tagger has already effectively patrolled that article. I cannot see what else that would need to be done besides go on regular editing/improvement of the article should the CSD be made in error which does happen occasionally. MuZemike 08:24, 3 July 2009 (UTC)

The proposal doesn't even make much sense. Anyone can do NPP (though only autoconfirmed users can mark pages as patrolled). If the page is deleted, then that means someone reviewed it. Who cares if they've self-identified as a new page patroller? Mr.Z-man 16:14, 3 July 2009 (UTC)

Agree with Mr.Z-man. Do you think members of NPP are granted some magic power that makes them more qualified than the original tagger and the deleting admin to judge the merits of the page? – iridescent 16:28, 3 July 2009 (UTC)

The problem, again, is that the pages cannot be marked as "patrolled" on the recent changes table once they have been deleted. So every person at NPP sees an article to be patrolled, clicks on it, can't find it, and figures out that it's already gone. It is a very small waste of time, but if you consider how many people do NPP, and how many new articles are speedied, it amounts to a fair chunk. This is time they are wasting not catching other problem articles. The only quick fix I can think of would be JS. Does twinkle automatically mark any page as patrolled that is tagged for CSD, or only if that person is doing NPP? Also, would it be possible to write a script that would mark a page as patrolled on the recent changes table when the admin deleted it? ▫ JohnnyMrNinja 19:59, 3 July 2009 (UTC)

No, that's not a problem, all entries a page (except log entries) are deleted from the recentchanges table when the page is deleted.

[edit] Change search message, please

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

MediaWiki:Searchmenu-new is the relevant page. Algebraist 04:09, 3 July 2009 (UTC)

• Changed to "You may create the page "[name]", but consider checking the search results below to see whether it is already covered." Stifle (talk) 08:16, 3 July 2009 (UTC)

I was going to say that given the number of deleted articles, that message which was there before seemed too encouraging to newcomers.Vchimpanzee · talk · contributions · 17:11, 3 July 2009 (UTC)

Well caught, I've thought about this before but never thought about actually trying to get something done about it. Dougweller (talk) 17:56, 3 July 2009 (UTC)

[edit] 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 bugzilla:. Stifle (talk) 08:17, 3 July 2009 (UTC)

It won't be a big challenge to realize. bugzilla: One of the wikimedia foundation staff advised me by email, to publish this feature (its not a bug) here. Marc 11:37, 3 July 2009 (UTC)

Why would this be a good idea? The purpose of wikipedia is not to "support external sites we trust", it's to create a free encyclopedia free from the influence of self-motivated parties, which includes SEOs and spammers. We don't need to give them the hope that, if they spam a sufficiently obscure and insignificant page with their links, they might last long enough to be registered by google. That's asking for trouble. Happy‑melon 13:34, 3 July 2009 (UTC)

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

[edit] 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)

[edit] 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)

[edit] Add Uploader to the list of rights admins can assign, add edit-semi as a feature?

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. –xeno^talk 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. –xeno^talk 03:13, 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. –xeno^talk 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). –xeno^talk 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. –xeno^talk 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. –xeno^talk 03:39, 5 July 2009 (UTC)