Jump to content

Wikipedia:Village pump (proposals)/Archive 49

From Wikipedia, the free encyclopedia

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 (talkedits) 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 (talkcontribs) 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 (talkcontribs) 21:33, 25 May 2009 (UTC)

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

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

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

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

Article header [edit]

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

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

AEB

Sample removed due to TOC-breakage

Maybe like that? Though obviously with a working link. OrangeDog (talkedits) 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 (talkedits) 05:49, 27 May 2009 (UTC)
Perhaps requesting this proposal be posted via WP:Watchlist notices and/or WP:Centralized discussion would be in order? --Cybercobra (talk) 07:49, 27 May 2009 (UTC)

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

I think you are supposed to add a link to here in the box on Wikipedia:Centralized discussion, not raise the issue on Wikipedia talk:Centralized discussion.  Done
I have to say that I never consciously noticed the difference between de: and en:. Now that I am aware of it, from a technical point of view I much prefer the solution with the link directly after the header - it's always clear which section it refers to, and it always seems to be typeset rationally in any browser, unlike our current solution, where the link often ends up in unintuitive and/or inaccessible locations. --Stephan Schulz (talk) 09:39, 27 May 2009 (UTC)
  • I'm going to be a heretic and say that I like nice, clean, encyclopedic headers, separate from Wikipedia stuff (as in, it's good to have the edit-link away from the section title). If this is introduced using Javascript, will there be an opt-out? ╟─TreasuryTaghemicycle─╢ 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 (talkedits) 19:04, 28 May 2009 (UTC)
The problem is that people are basing their opinion about whether solutions fix the bunching issue on the basis of those. The real section edit links are a span inside the heading, before the actual heading text. They're put in the current position by floating them to the right. Something like sample 2 could be accomplished just by setting them to float:none, as that's the position they actually would be in without the float. I tested something like sample 4 using CSS alone,
.editsection {
  float: none !important;
  position: absolute;
  font-size: 60% !important;
  margin: 1.7em 0em 1.5em 0em !important;
}
mostly does it, though I'm not a CSS expert and haven't tested how it looks with different font sizes, browsers, and monitors. Its also optimized for h2's and would need some extra rules for other heading levels. Mr.Z-man 19:17, 28 May 2009 (UTC)

Formal proposal

Gadget

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

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

Provide "New Section" header box on virgin talk pages

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

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

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

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

Editing Talk:Crotona Park

From Wikipedia, the free encyclopedia

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

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

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

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

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

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

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

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

structuring a straw poll

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

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

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

Quality awareness

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

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

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

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

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

Question

My question for the community is this:

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

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

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

Default languages

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

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

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

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

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

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

Creating redirects with bot

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

RE: Disabling "create a book"

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

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

Second draft of updated arbitration policy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

moving the menu

Hi!

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

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

Thank you, cincerely yours,

iivari.mokelainen

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

Edit head

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

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

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

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

Articles for Deletion needs more automation

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

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

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

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

"Remember me for __ days"

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

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

usage of pagination + limit on size of pages

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

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

Pronunciation to foreign place infoboxes

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

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

Bots fixing redirects in navboxes

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

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

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

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

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

Change search message, please

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

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

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

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

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


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

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

Admins able to block while blocked?

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

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

I don't think it at all likely that a rogue could block all 915 active admins without being spotted, Ritzman. ╟─TreasuryTagco-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 ╟─TreasuryTagstannary parliament─╢ 19:21, 24 June 2009 (UTC)
There is also this. Ruslik_Zero 19:26, 24 June 2009 (UTC)
<_< PeterSymonds (talk) 23:20, 24 June 2009 (UTC)

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

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

New category for promotional articles

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

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

Objections, thoughts? Thanks, JamieS93 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. JamieS93 14:59, 1 July 2009 (UTC)
There's probably a few other templates that would use this new category as well: {{Newsrelease}}, etc. I like Category:Articles with a promotional tone (the 2nd suggestion) because it assumes the article is valid, but the tone needs to be edited, vs. saying the article is suspected to be inherently promotional (and possibly could never be un-promotional) - the domain of {{db-spam}}.Cander0000 (talk) 11:46, 5 July 2009 (UTC)

Maps could be much better

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

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

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

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

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

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

Clicking on contribution history should lead to section

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

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

Fix to "Pixelization"

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

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

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

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

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

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

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

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

Proposing a re-design of the editing toolbar

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

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

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

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

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

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

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

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

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

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

Userspace redirect

I propose that a namespace be implemented specifically for userspace redirects. There's currently no policy that forbids redirecting pseudo-namespace to user pages but it's certainly enforced as a policy. To deal with this, I propose setting up U:/UT: redirects as allowable shortcuts for user pages. U: to the user page and UT: to the user talk page. I don't know if this requires anything special other than saying "these are OK" somewhere such as wp:csd#r2 or Wikipedia:Pseudo-namespace or if something has to be done on the backend software wise but this is my proposal. - ALLSTRecho 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. - ALLSTRecho 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. ╟─TreasuryTagballotbox─╢ 07:40, 29 June 2009 (UTC)

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

Straw Poll on modifying <ref>

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

Redirects in search history

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

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

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

Reorder quotation marks in "editpage-specialchars" DIV

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

‘ “ ’ ” «»

while I suggest that they should be listed as

‘’ “” «»

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

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

Using Wikipedia as a forum for peer-review

If this is in the wrong section, I apologize.

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

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

Language articles

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

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

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

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

How about

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

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

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

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

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

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

Indenting

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

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

A world map for all ages

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

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

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

Add External Wiki Searches and Encapsulated External Wiki Pages

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

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

Notice the search bar next to the page title












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

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

The Link to Ubuntu is green rather than blue












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

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

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












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

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

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

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

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


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


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

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


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


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

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

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

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

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

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

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

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

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

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

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

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

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

Merge two templates

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

Add Uploader to the list of rights admins can assign

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

Edit summary and What's this?

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

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

Talk page formatting suggestion

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

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

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

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

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

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

Exclude protected pages from rel="nofollow"

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

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