Knowledge:Village pump (proposals)/Archive 68

10058:@MBelgrano: Of course, but that's not the point. The whole point is that some messages need to be read and acted upon as quickly as possible. If I'm editing or reading for a long time in one spot, I'm not getting the urgent message. Sometimes I'm working on complicated edits with lots of refs and I may even leave the PC and do something else, then come back and continue. There can go 15 - 45m. easily. I often work on very controversial stuff and long, heated discussions on talk pages are the rule of the day. I can read something on the talk page justifying an edit, go and work on it, and in the meantime the consensus has changed. Someone might wish to discuss it with me on my talk page, but I'm not getting their message. What happens is that I end up making a non-consensus edit, or maybe one that could be misunderstood as edit warring. I wouldn't deliberately do that, but it could appear that way. I understand from your comments that you haven't walked in my shoes and that you therefore consider my concerns to be illegitimate, but maybe you should just AGF and recognize that we all have different experiences and needs here. The change I'm suggesting wouldn't hurt anybody, not even you. -- 2366:

way of recording them that stays current and up-to-date. I'm thinking of a suggestion thread or feature request system that actively solicits votes that do not expire. For example currently there are perennial proposals that supposedly do not have community consensus. How do we know? Because of one or two votes held three years apart participated in by at best a couple hundred of people? How about the opinions of all those people that may have become interested in the issue since but were not part of the active debate? How do they weigh in? Will they still be around the next time someone is able to organize and active push to clarify the issue or would they have long since abandoned the project because it was not addressed when they were available to provide input?

3319:

we have to talk about them if we believe that they are notable enough, whatever our opinion on the leaking is. Also those who believe that WikiLeaks should not have leaked them should be interested in showing what the leaks' contents are and why spreading them was harmful (the leak already happened, we cannot stop it just by censoring information about it on Knowledge! and the WikiLeaks critics never said that the problem with the leaks is that ordinary people can read them... They hold it that the problem is with political bodies and armed groups reading them, and they do not need Knowledge to read them). --

14057:

may not the best strategy. There's a number of different tools for this purpose: WikiCite, ProveIt, RefTools, Universal Reference Formatter, RefLinks,etc. These are all good attempts and each have different uses,strengths and weaknesses. Is Reftools that much better than the rest? Has it been bug-tested more than the others and in all situations? Is it compatible with all browsers, other userscripts, slow bandwidth, etc. Is it supported by the most actively coders or being developed by someone? I think those questions need to be ironed out before putting it on everyone's editing page.

3913:

really compensate that. Regardless of this "usual meaning", it's also usual that each major web site has its own interface, which may or may not be similar to others. I think that web surfers should be already aware that they shouldn't take functions or namings for granted, and categories are already enough intuitive so that the casual web surfer can understand or at least suspect whaat are they about. I mean: Barack Obama has, at the end of his entry, the links "Categories: 1961 births, 21-st century presidents of the United States, African american academics", and so on. What

9136: 9144: 9891:(I hate edit-conflicts...) To be able to pull that off, you would need some sort of script that constantly pings the server to determine whether or not you have a new message. Implementing that on the server side, (i.e. for everybody,) would be a bad idea, because it would terribly increase the load on the servers. You might be able to write a monobook.js/vector.js script that pings the server every X seconds, and gives a "You Have Mail" style popup. That way only the people who want/need that feature would be hammering on the servers, kinda like how 13356:

don't know how difficult this would be to fix. Some of the error checks are buggy, but that shouldn't be too difficult to fix. As for multiple citation styles, that should be no problem as it can be customized for use with almost any template, though it won't work well with the Harvard templates at the moment, and it doesn't support plain text references. I'm currently working on a version that can autofill citation details given an ISBN, PMID, or DOI. Its basically done, I just haven't had the time to finish it.

12304:

people who don't use the tools B) require "regulars" to learn the new template and C) significantly lengthen the name of the parameters (in some cases by more than 4x, or adding named parameters where none previously existed). I think this could be better if it didn't rely so heavily on named parameters. It would probably be safe to assume that the first parameter is always the page being discussed. Most of the rest could be shortened by not having separate parameters for different processes and either using the

2541:. Everybody is allowed to copyedit, but the people at GOCE are the ones wo will do it more often. That's the idea: everyone would be allowed to contribute to a collaboration, but the members of the project are the ones who actively work on the articles, as well as run the technical processes. I also have ideas (barnstars for edits, guidelines on nominated articles, active recruitment, etc) which I think would be easier to "get right the first time" than to implement on an existing set of rules and procedures. 9518:

was there, but is no longer. The situation has changed during that time. I'd sure like to have received an alert before saving an open edit window. I often have up to twenty tabs open at once, some with open editing windows, and while on another page I could have received that alert, looked at the message on my talk page, and then either altered my proposed edit or not made it at all since it's out of date. Even though it's often innocent, with no bad feelings, it's still irritating and a waste of time. --

14123:

less polished than reftools (for example proveit doesn't play nice with wikied, whereas afaik reftools does). Adding reftools as a default option makes sense and would help a little bit towards simplfying one of the most damaging examples of complexity on wikipedia with no real cost, technical users who dislike it can always disable the functionality, while it is easy to see it being potentially helpfull to editors (new or less new) who have not yet explored the gadget options and features.

10305: 9919:

One solution is, whenever a user checks his talk page, store the date/time in a cookie/usersubpage (cookie isn't good because then you'll invariably get a newmessage box on a new computer). That way, all non-self edits to the talkpage after that time can be regarded as a new message. This shouldn't be too hard, except my AJAX is rusty and I've never used it on Knowledge. But it's a bit extreme. There really is no need of having an auto-edit happening every time you

10517: 10471: 14630:. I've been using it for so long that I was recently shocked to realize that it was a gadget that new users had to enable. Lack of references is one of the biggest issues I see on Knowledge today. Anything we can do to point new and inexperienced editors in the right direction is an enormous help in tackling this problem. Citing sources is one of our most basic values, but it's a ridiculously complicated and non-discoverable procedure without RefTools. 13067: 4135: 4237:

The Chinese and Russian news sources should be trusted for a variety of facts, not necessarily on opinions of national matters or for accurate estimates, but they can be trusted for a variety of non self-serving material. A basic reference list for what a source is and who publishes would be better than a list of who is partisan and therefore can't be trusted which will only waste time by generating long, non-consensus gaining discussions. --

10493: 10447: 5428:

in leaving some of the main articles rather desolate (obviously not something we want). Also, since I'm neither a biologist/doctor/veterinarian/etc. nor having English as my first language, writing articles on highly technical matters such as anatomy can prove to be both quite challenging and time-consuming, but I'll probably give it a go anyway. I guess I'll just have to rely on people correcting my mistakes as they are spotted.

14138:

features and deal with support issues; 4) check with the Usability team to make sure we're not duplicating or missing better integration opportunities; 5) run this through Village Pump technical, the Foundation tech team, the Tech-mailing list, and either the Knowledge-list or the Foundation-list (misplaced there, but would get worthwhile attention). If those things can be put in place then I think this is a great idea.

4332:, and writing about it in your own words. For example, in the early days of my involvement here, 2004-2005, I spent a lot of time correcting some outrageous musicological errors imported from the hundred-year-old Catholic Encyclopedia and 1911 Encyclopedia Britannica, and often wished we'd never imported those articles. You can still find traces of them, or maybe even wholesale dumps in out-of-the-way places. 13059: 10545: 4832:(ec) The new puzzle piece logo I think is more suitable - it's more descriptive of the event. IMHO, it's not saying we're finishing the puzzle either, as it's a single piece, and there are clearly more missing. If anything, it's showing we're adding another piece to the puzzle. It's suitable for the event, more so than the balloons logo. The original logo I think will just confuse people even more. 2815:

succeeding. The end result is going to be a dozen different proposals, none of which gets more than 10-30% community support. If you want to actually get the majority of the community behind something, you have to present a limited number of options, ideally no more than 2 or 3, where one is the default of "no change." And a simple majority is never going to be accepted, it would need at least 60%.

8663: 4934: 2277: 5525:- seen this problem a lot. Some anatomical articles deal exclusively with human anatomy, some throw in a mixture of human and comparative, some are primarily written in the general perspective with a little mention of human thrown in. It's that inconsistency that's the problem, not the anthropocentricity. The obvious solution would be to emphasise the distinction (e.g. as is done with 10321: 10409:

something like the category bar, but ones specifically for portals, books, and interWikis. As it stands, portals are rarely linked within articles, resulting in very low hit counts for portals that are not displayed on the main page every day. maybe if we had a consistent place for them (as well as books and interWikis), they would be included more often and get more traffic. –

10505: 10459: 11054:, and think "Why has this article been marked with an NA assessment?", and then you click on the article tab, and then you click on the talk tab, you are in a different place. I know that the redirect text is there, that is aimed at people using wikilinks, not tabs. Being redirected by a tab is non-standard and unexpected. You can read the text of a link and see that it says 13285:. Many styles of citation are acceptable in Knowledge, and this tool only supports one of the styles. Editors are responsible to use the style that already exists in an article. Turning this tool on by default will give editors the impression that this is the official style and it is ok to barge into an article and change all the citations to the cite xxx style. 14075:

is a standalone program that only works on Windows and does not appear to be actively developed. Reftools is the only tool that I know of where the available citation templates are not hardcoded into the script itself. I designed it so that users can add templates in their personal JS pages with a minimal amount of JavaScript knowledge required.

3017:. It's a case similar to other sets of multiple items... the set itself is surely notable, perhaps not all individual items are; but in order to give a coherent presentation of a large collection of structured information, we can create a series of articles linked to each other. Silly examples: check how many detailed articles are linked from 3696:

the accepted methods of researching community consensus. Jumping straight to "what do people want to replace RfA with" is skipping too many stages and is certain to result in no conclusive outcome. You want to be a lot more methodical in asking first what people feel is wrong with RfA, a discussion which is best suited to an RfC format.

10762:, are you talking about another floating box? If so, again you run into the problem of making a potentially large floating box fit within a potentially small section of an article, once again causing formatting issues. This is why I think bars are better. If you want, we can try to devise a more unified "bar" to contain all three... – 3433:(not "terribly helpful" either :-) ): the informational content is the names of the things. Moreover, it has navigational purposes, which also applies to the cables' list for those cables that may be regarded as notable. However, I do not suggest a mere list of IDs but a table with relevant information for each cable, like 10646:

footer by most people and will skip them , and they'll be as ignored as categories. Also, personally I would place books above portals as in my experiences books are generally a bit more directly related to the article, if not, they are roughly of equal relevance. For example, a Canadian Prime Minister will often have a

3553:

has? None. If they refuse to listen you, they get the same block as if you left a template, but for those users that don't deserve a block, they get the impression that Knowledge is populated by real people who care about them rather than mindless bots that drop incomprehensible form letters on their talk page. --

12184:". But is it really so? I am afraid that users will use the wrong parameters more often than they are using the wrong templates... Also, in many cases the "unified" template is going to be more complex and harder to edit than each of the previously existing templates. Thus I doubt if the change will result in " 15869: 15567: 14074:

Of the tools you listed, only Reftools and Proveit are integrated into the editing interface. Universal Reference Formatter and RefLinks are Toolserver tools. Reflinks only expands plain URLs into citations, its not really the same type of tool. URF seems to mainly support journal citations. WikiCite

10645:

I'm not too keen on this. If the goal is to generate traffic to portals and books, that probably won't work. The lower something is in the article, the less clicks it gets. The "see also" section is where people go to when they want related links. It you move it at the bottom, they'll be considered a

9990:

hasmsg seems correct. Could you just write the Ajax code for me? I'll write the rest. I propose we make the timeout five minutes for normal pages, and a bit less for edit pages, as you only linger long on edit pages, which is where this tool is required. I don't know about you, but I don't stay on an

9955:

I believe you can use uiprop=hasmsg from the api to check if a user has an unread message. Not 100% sure. And polling should be kept to a minimum, cause if many users do such polling, you'll bring the servers down (or rather, your tool will be blocked by the sysadmins). Hopefully one day in HTML5, it

9517:

Of course, but that's after the fact. Edit conflicts constantly occur, and in efforts to help each other we sometimes alert each other to changes or things that are happening elsewhere. That information, if received in time, will help us alter our behavior so we don't make an edit in response to what

9323:

Life is a hack. And Vector is here to stay, whether you like it or not. If it looks awful on other skins, then we could implement it for Vector only. TBH, the current border looks nothing like a book. Plus, we aren't a book. I doubt it will break stuff, until you can prove it. The text is aligned and

8471:

No, it won't work. Ratings work for comments, but not for pagehistories as we use them. Nobody is gonna read every edit in a page history and rate them like they do comments on youtube videos. If there is a problem with a particular edit you talk to or warn the editor in question, if you think a edit

5288:

Apparently it revolves around the need for Jimmy to plaster his face all over the 4th busiest site on the internet. I never expected this to go anywhere, WP is far too mired in it's hateful bureaucracy to ever respond to the needs of it's individual citizens. You're right, of course, "HandThatFeeds",

4356:

for an extinct Scottish peasant musical instrument. I could also see covering musicians and groups (opera companies, etc) of interest in the period. I'll look to comb through the OCR of 1909 Groves and see if I can wholesale pluck a few articles that are specific enough that they are unlikely to have

4272:

are near their respective ends of the political spectrum, but both try to be rather scrupulous with the facts. On the other hand, the publications put out by the followers of Lyndon LaRouche are minefields: independent of the opinions expressed, they are liable to be 90% factual, with a few outright,

4236:

Information needs more than just a reliable source to be considered reliable, and should be handled on a case-by-case basis. Including MSNBC next to Fox News would at least remove the appearance of partisanship. Saying that Fox news isn't mainstream though, and not including MSNBC is just neglectful.

3695:

The previous incarnation of this process is still on this page with hat templates, and there is no reason for this incarnation to behave any differently, except that the userspace page will just be ignored rather than archived. The meta-process that you're working with is fundamentally juxtaposed to

3610:

was another case where the media incorrectly reported someone as dead. Several people, myself included, updated the article trusting that the media was correct. To through a L4 warning template at good faith editors is not advisable. In most cases, there will be no remarkable drama about the death

3552:

Here's a novel, untested idea. You could, you know, try to maybe communicate with editors and ask them questions, direct them to policies and guidelines, and attempt to converse with them. You know what advantage that has? They learn more about how Knowledge works. You know what disadvantage that

3191:

Thank you for your collaborative attitude, Protonk. Fortunately in a brief interval of sanity between my frequent phases of folly, I had already tried to address concerns like yours; please read the whole discussion above. BTW, notice that even during my hilarious deliria I have just asked whether it

2873:

No, just... No. We don't have a vote on the request to have a motion to form an exploratory committee to determine if there is an issue which needs investigating. Just... Look, if you have a proposal for a change to the RFA system, propose that change. There's no need to seek permission to do so.

2687:

is broken, there is no reason to go through with this. The community is already totally confused on what to fix. We don't need to document that indecision. This also seems to propose that Knowledge runs on votes. It doesn't. I would be wholly opposed to any "solution" to this (non-)problem which does

1003:

Please understand that simply repeating your viewpoint is not going to garner more support. Several editors have stated that your proposal is completely redundant to the existing method of creating HTML based lists, and that your method breaks normal HTML semantics that is essential to accessability.

587:

If we want to change spacing around lists, we can do that with a change to the global CSS. Requiring people to manually use bullet symbols and put HTML line breaks to make a list, when we have simpler syntax to accomplish almost the exact same thing is asinine. Its not a style preference, its using a

14107:

I've used ProveIt a little bit, but not a lot. My impression is that it is pretty functional, but a bit intrusive. It actually puts a panel outside of the editing box that scrolls with you when you move. Perhaps someone else who has used it more can chime in with a better comparison between RefTools

13964:

Using RefTools would be completely optional and collapsed by default. The only way it would ever show up is if you uncollapse the Cite toolbar and select one of the citation templates to insert. You would still be free to write citations manually in the WikiEditor if you like (if for example you had

13355:

The only significant technical issue that I know of is that it doesn't work correctly in IE. It functions, but it just inserts the ref in some random place. I was hoping this might just fix itself in IE9, but it still seems to do it in the current IE9 beta. I haven't had time to investigate it, so I

13164:

With the caveat others have expressed of "provided there are no major technical problems likely to be caused, I'm changing to "support". It's a fantastic (kudos is not a good enough word) tool and will increase the quality of our footnoting (it's already going to increase the quality of mine). I can

12981:

I currently have 5,398 items on my watchlist, plus their talk pages, and I run into this constantly. I'm sure it's usually carelessness or just because people, especially newbies, aren't aware of the MoS. A bot could catch lots of these errors and that would lessen the load significantly for editors

11264:

I'm unclear about this proposal. Do you mean a thank-you message on the talk page or simply a text in the interface (e.g. "...See the Terms of Use for details. Thanks for your contribution to the sphere of free knowledge.")? The first would double the number of entries in the data base. In any case,

11084:

I would redirect that particular talk page. But I really like the idea of colour-coding or marking tabs if they are a redirect. I tend to experience the same sort of thing; many talk pages redirect to a more centralised talk page, so I inadvertantly click to go back to the article/page, only to find

10851:

I wasn't going to do it right away. And anyway, consensus requires people to actually respond. That's partly my fault, though. I'm getting closer to having a working template that integrates all three potential bars. (See the new demo above.) Once it's ready, I should probably start over with a

10576:

Thank you very much for your offer to help code the template. I will definitely need help, particularly with the style sheets. (Let's put it this way: I aspire to being a novice at style sheets.) For the moment, though, if you are good at style sheets, I would greatly appreciate help in making the

8413:

Knowledge is not facebook, and things that are useful at one site are not so useful at the other. "I like it" s a highly informal feature, and suits very well a site that is precisely meant for informal activities, such as sharing vacation photos or making groups such as "Bender rules!" or "Join the

6792:

I think that this merits exposure, since it has the potential to improve Knowledge (indirectly), and Wikipedians might be interested in it. But I would disagree to any proposal for "official" WP support of this, unless Stack Overflow Internet Services Inc. handed it over to the Wikimedia Foundation.

6555:

I checked out the proposal site. "My MediaWiki based site is getting hit by spam. What should I do to deal with it?" has nothing to do with Knowledge (and the answer would probably be to install an anti-spam extension and change the usergrouprights/registration process). Yet this is marked as "great

6415:

Not at you specifically, Fences, although I think your response above along with Mono's are both somewhat indicative of the kind of impatience I'm referring to. I'll gladly take my own advice, in terms of being welcoming to people who come here to make suggestions; I feel I do pretty well there, but

5647:

It's technically possible to put your talk page under PC protection, yes. But I wouldn't do it since it doesn't really help you. If your talk page is regularly vandalized by non-autoconfirmed accounts then I'd just go straight to semi-protection, I would think that with the history of your talk page

5427:

Interesting to see that this issue has been presented several times before, albeit met with such mixed opinions. I suppose you're right about the sources detailing non-human anatomy being somewhat sparse(r), which, if we move mostly everything specific to humans into their own articles, could result

4106:

The only way I could see this happening is something like a Firefox extension installed on your browser that keeps your highlights in your computer's memory. In fact if you did it right, it wouldn't necessarily have to be specific to Knowledge, but would work on whatever website you wanted to use it

3318:

Finally, I (and Knowledge's legal advisors) do not see any legal issue in providing links to the leaks or listing them. What do you mean? Etichal issues are more personal than legal ones, but I still do not believe that there is any ethical issue involved here, it's a fact that these leaks exist and

2555:

Fine. My point is that the main concern is the amount of effort put into designing and then promoting the collaboration. As experience shows, it needs to be done well to be sustainable (though I guess even a shortlived attempt might be worthwhile, and achieve something, even if it just nudges people

2501:

The principle is well established from previous examples; the question is how would a new incarnation be better. Whether that's "from scratch" or a revival of something existing, or something new with old things merged in doesn't matter so much. One thing such a Collaboration could do is make use of

2365:

The problem with the current setup here at the village pump is that the data is disorganized. Someone expresses an opinion on an issue and then after a brief discussion the opinion or view gets sent into a black hole of oblivion. To better account for these views there needs to be a more permanent

2046:

Because that defeats the purpose. The shortcuts are designed to be quick and easy to remember, and easy to type. Moving them to another namespace would require people to learn all new shortcuts. It would break all the existing links to the shortcuts. And for templates, "--:T" only saves 4 characters

1648:

I would absolutely love this. In fact, I was rather surprised when I first discovered it wasn't possible to just use "T:"(as "WP:" and "WT:" are). It becomes infuriating when you have to navigate between several different templates, and type the prefix for every single one. Also, simply omitting the

1619:

Assuming you have "Search in all namespaces by default" checked in your preferences, searching on the name of a template will turn it up without having to specify the namespace prefix. The "go" functionality always prefers the main namespace, so when there's an article by that name it will go there,

1464:

We have "WP:" and "WT:" because many people use those all the time; few people would have much real use for these other shortcuts. Also, people would think that "U:" goes to a namespace that has something to do with the letter U, i.e. the User namespace. And pointing "U:" to the User namespace saves

1153:

That would be nice, but I don't think we have the mechanisms to make it happen. I have made similar suggestions for the medal tables at Olympic Games and similar events. They always remain a mess during the Games because of fans adding the results of their own heroes and ignoring others. A number of

589:

in the HTML, so there's also more semantic value than plain bullet points and line breaks. We should be making editing easier, not harder. Even with a simple-ish way to insert them, its still significantly more inconvenient than typing a character that exists on standard keyboards. In this case, the

14976:

This should have been a default a long time ago. When I started to try to edit, it was one of the things that dumbfounded me, along with many other functions of course. Really, turning referencer on by default should allow some bored wiki-browsers to add their own references at any time and not get

14749:

provided there are no technical issues. I've always thought the number-one-most-ridiculous-thing about Knowledge is that we are very strict about citations, and yet offer no straightfoward way of adding them at all (by default). This is an absolutely fantastic and logical idea, and in my opinion we

14322:

The issues with IE should be fixed now. The version for the new toolbar, but with dialogs disabled, was broken in IE. This version of the script used the same form as the one for the old toolbar (the newest one requires the dialogs to be enabled), which still broke edittools, but this should now be

14056:

Maybe I'm missing something, since I don't use RefTools, but I think there are some issues here. As much as I support the desperately needed improvement of our editing interface, including easier references, hard-coding a particular solution to a problem that currently has many competing solutions

9918:

Well, that wouldn't be a problem, except for one thing: How do we determine if a user has read the messages or not? I mean, to show a 'new message' box, you must know that the message is new. I don't think there's an open (available to us) server request that can tell you if there are new messages.

6827:

keep a page for each user pair makes little sense, as prior history is often irrelevant to new discussions and discussions can often involve multiple parties. It is an interesting idea however to make a page for every discussion. Feel free to try it out: Just create a user talk subpage for each new

6675:

Let me just say that taking help offwiki is not a good idea. We can't control who answers questions and we can't control the quality of the answers. We see this issue on the IRC help channel, too—you have new users trying to help but they end up misleading people all over the place. There's nothing

5108:

Jayron that's not exactly an easy fix. Sure, it's doable, but presumably other readers will have the same problem as the OP, and we can't expect them all to register accounts and change their settings, just to get rid of the banner. There are arguments for the banner, but the effect on readers with

4041:

And more: the fact that "Knowledge must say this" does not equal "All readers must read this". Some people is already aware of what can be expected from a web page or not, and what risks may be in their usage. I don't need a wikipedia disclaimer (or any web page disclaimer, for that matter) to know

2941:

The problem with this is that a lot of the news coverage is not really about the cables themselves, but their content. The cable is the source for the news article, not the subject. The content is mostly what's newsworthy and where most of the coverage is. The fact that the articles may mention the

2489:

Because I think that the format could be greatly improved and it could be much better advertised if it was created from scratch. The existing projects are known for going inactive every so often, so I think that discourages some editors from participating at all. On the other hand, if a new project

1649:

prefix and relying on the search results is often more time-consuming than simply typing the prefix out in the first place. I don't see any real reason not to do it, provided the kinks can be worked out (which I am sure they easily can). Something like "TP:" might be better than just "T:" though. --

772:

in regular editing. There is a direct wikisyntax equivalent for it. So far the only reasons you have been able to give are for one particular type of templates, which represent only a tiny fraction of the editing done on Knowledge, and to make lists in a way contrary to the way lists have been made

14122:

I've used both a little bit, prove-it is more "powerful" with its support for readding references and automatic detection of references on a page, but its much more of an "add-on" whereas reftools is smoothly integrated with the user interface and simpler. Prove-IT is also a lot newer and probably

14078:

Its been tested on every major browser. Its currently only semi-compatible with Internet Explorer; it works, but not ideally so. Other than that, there are a few minor bugs that should be easily fixable. It should be compatible with all user scripts and should be no slower than the rest of the new

12670:

I think "anonymously" or "anonymous contribution" is misleading for new users, who presumably make up a large proportion of IP editors. Because it's not anonymous in the layperson's sense of the word - the system stores your IP address, and people can work out where that's registered to. Having an

12303:

I saw this on the idea lab, but it's still not really clear to me how the benefits (which seem really minor) justify the (seemingly major) change in usage. I agree that it shouldn't be more difficult, but it will A) Require all existing tools that use these templates (Twinkle) to be fixed, and for

10741:

It's fine if you don't care for it. I don't expect everyone to like it. But unless someone can provide some tangible alternative solutions, we might as well attempt to develop this. Also, I have no problem putting books before portals. The part about increased traffic was just speculation, and

9841:

I support the idea of making a change that allows editors to be alerted at once to a message on their talk page. The side is also a good idea. FaceBook does this on one's active threads, for example, though it fades away after 10-15 seconds. I'm not programmer so I can't help with the coding, I'm

9608:

If I may suggest it is probably possible to program a skin change of somekind that would allow the user to opt to recieve it on the side or the bottom rather than the top! That programming is a bit above my skill level but if they can make things like twinkle and the various other scripts it seems

9490:

It appears only at the top and isn't visible when one is further down on a page, including when writing in the editing box. Sometimes important updates or messages directly related to what one is writing aren't seen until the page has been saved, which means the message gets read too late. Several

6373:

Wow. I see the whole jaded response thing hasn't gotten any better since I left (to put it lightly). It's been pointed out before, but friendly reminder, those users who are too sick of responding to bad ideas to be nice or dare I say civil about it might feel rejuvenated after having stepped away

4301:

Not to rain on your parade, but why not write your own text and just cite the source? Most of the text dumbs from Britannica 1911 and other PD works date from the VERY early days of Knowledge to give the encyclopedia some content. This isn't much of a problem anymore, so I don't see the pressing

3164:

This is a hilariously bad idea. Unlike towns, these cables don't inherently represent anything of persistent interest (despite the importance of the overall leak and of a small fraction of the individual cables). So the very best way to sensibly ration the articles we have on the cables is to at

2721:

While I agree that this is a totally un-wiki way of tackling the issue, this oppose rationale makes no sense at all. You agree that the community is confused and undecided about how best to fix RfA, yet claim that that's not a problem?!? This is certainly completely the wrong way of tackling the

159:

I would oppose this. Using an extra blank line looks cleaner and is more intuitive. We should only use HTML when there's no equivalent wikisyntax. As for putting blank lines in a list, why would you do that? It just makes it inconsistent from all other other lists in articles. It probably violates

14591:

implementing Reftools asap. The new autofill option makes it the perfection companion for everyday editing (together with Zotero). Keep on the good work. One suggestion though: trim automatically white spaces before and after the ISBN. Zotero-like reference sharing within a Wikiproject or between

13313:

Articles which are standardized to alternate citation styles are relatively rare these days on Knowledge. I think the number of articles this change would positively affect (not to mention improving the newbie learning curve) would far outweigh the potential cost of correcting citation style in a

12593:

While it's true that this can easily be accomplished with client-side javascript or personal styling, it's not a bad idea to do it site-wide. It doesn't have to be white-on-green; something subtler would probably do the trick. Or perhaps just change the text of the button to "Save page (anonymous

12225:

Another minor advantage, which is not related to this proposal: Currently, all other wikis are trying their best to get separate venues (FFD, RFD, ect) like en.wiki, but they either don't have the resources (templates), nor do they are able to translate the contents there to use. And oddly, these

12221:

Also, this template will not be any harder to edit than trying to edit these current separate template. It'll only be longer. Like the benefits of other templates, a unified template greatly improves ease of maintenance and protection; one has to edit one template to make a wide change (vandalism

9460:

I'm all for re-thinking the thumbnail design, but keep in mind that Wikinews doesn't get near our traffic or editors. Meaning that people there are more likely to know how to place images so the text does not confuse readers, and the readers know what to expect. We need something more fool-proof.

3402:

the cables themselves then the question becomes even more superfluous. If there is extant news coverage of a specific cable sufficient to meet WP:N and our other inclusion guidance then we can be doubly sure that normal editing will give us something approaching the "right" number of articles on

2814:

While I'm not sure I entirely comprehend all the stuff there about amendments and seconding, it looks to be at the same time overly bureaucratic (due to the over-reliance on votes) and chaotic (since any 2 people can put a proposal through to the full community vote). This has almost no chance of

1771:

per Anomie who summed up my concerns. Also because of the fact that it would restrict possible future article titles, and because existing pseudo-namespace shortcuts already do the job in cases where a shortcut would be needed such as high-traffic pages. The majority of pages in the Portal talk:,

864:

It is more than the default way, it is the accepted, correct way. Your suggestion may be a slight style improvement, but its a huge loss in every other area. You're losing a lot of usability by having people use HTML line breaks and manual bullets/numbering rather than a simple asterisk or number

10408:

external links. In other words, these things belong in this general area, but not in that section. Moreover, if you have two or three right-floating boxes, they take up a lot more space than the list of links, creating a lot of white-space. The best way that I can think of doing it is to offer

3912:

The problem is not only that at this site we use the name "categories", but also that the word "tag" is already used for something else (maintenance and copyright licence templates, informally known as "tags"). To change the words would be highly chaotic, and I'm not sure if the trivial benefits

3271:

Hi Pointillist, I'm not sure I got your point. Of course this material has been already published elsewhere, actually it's been published in several places and this is precisely why it is encyclopedic. We never publish "new" stuff, we always republish information that can be found elsewhere. The

3063:

BTW, I never heard that the cables were released in order of importance. So far, this has not been the case. They are just clustered with unknown criteria (apparently, according to their subjects) and released cluster by cluster to avoid overwhelming the public with raw data and give time to the

2946:

deserve an article – written by a human – but all 250k of them are certainly not inherently notable. We don't even know the content of 99% of them. For all we know, they're being released in order of most interesting and 200,000 of them will be so boring they'll barely get coverage. And the last

2437:

It's not at all obvious to readers and brand new editors how to give feedback, so discussions end up skewed towards the views of more established editors. Many discussions of policy, eg. vandalism, article protection, deletion policies, have large effects on occasional editors but it seems their

1103:

I can understand where you are coming from, but I doubt anyone would want to compare the displacement of two ships or compare the power capacity of two power stations. I can only see this feature getting used as a shopping feature, which in turn might force editors to add more unless data to the

14137:

Thanks for the thoughtful response Apoc, and for working on RefTools. My concerns are that we: 1) make sure the code plays nice with other browsers, userscripts, and add-ons; 2) don't discourage ProveIt's development, since it's a great thing too; 3) get some help for you (Apoc) to bolster the

10033:

Exactly. You don't sit reading subsections for long. Only when you're editing will you be stuck there for a long time without opening any new pages. Then how about this? The above script will be used on all non-edit pages (maybe with a bigger icon), and the AJAX-ping method will be used on edit

3834:

Personally I get the impression that "tags" are seen as more informal than "categories"—you don't hear people talking about "tag hierarchies"—but I don't think the way we name the metadata is preventing us from thinking about the possibilities. If you're talking about being able to search using

1168:

Agreed. Short of having a cadre of admins watching every sporting event and semi-protecting it during the event, the best thing to do is just accept that, when something is occurring - be it breaking news, a sporting event, or an election - there will be a certain amount of chaos. Just like the

12175:

OK, I guess I understand the proposal (more or less)... Essentially, in each case you want to take several templates that perform similar functions and create a new template that would perform all those functions depending on parameters, right? That doesn't seem to be very difficult to do (for

8542:

Although I also oppose the proposal, you shouldn't reject it simply as "it's against policy", try to elaborate it a little more. And notice that "Arguments to avoid in deletion discussions" is not policy, but an essay. Personal points of view are discouraged and likely to be dismissed, but not

3397:

Glad I could help. If you've eliminated the idea of creating the articles en masse with a bot then that still leaves the question of whether the articles should be created at all. In that case the question is really not one which can be solved via centralized discussion as the role of normal

10133:

It's pointless to remind me to assume good faith, because I'm not accusing anyone of anything. My point is simply that the interface and processes of Knowledge allow to do things at one's pace, without needing to rush. Consensus can hardly change in mere minutes, if it does, it means that the

9441:

I don't like it either. Unfortunately the latest example only shows (to me anyway) how much easier it is to distinguish the caption on the current thumbnail boxes than the proposed ones. I wouldn't be opposed though if someone removes the inner border, and changes it so that the box is merely

13375:

Actually, on IE9 at least, it seems to depend on compatibility mode settings. With one setting, it inserts it in (almost) the correct spot. I can't tell whether compatibility mode is on or off though since the interface is too vague (its the one where the squiggly rectangular thing is blue).

1729:

The question was whether "TT:" as a shortcut prefix would conflict with "TT:" as the interlanguage prefix for the Tatar Knowledge. There is no prefix conflict at the moment with "t:" as a prefix, although there are two articles/article redirects that would have to be moved. But how often are

6556:

on-topic example". Similarly, "What is a wiki champion? What do they do? Do you need one?" seems like nonsense to me, and "As a website administrator, what steps are to be taken, to stop misusing public wikis?" is another example of a "great example" that is actually irrelevant to Knowledge.

5123:

Thanks Physics. Even if I did go the register route, I would have to login on all the different devices I use every time I visit the site. It's very annoying. A text only banner would be better, or main page only, but regardless it seems the giant java script powered banner is here forever.

6218:

A semi related thought: We should have a way of inserting an infobox from the edit bar. It should allow you to type the links, images, etc in appropriate fields. Just the problem is, for that, we need a mass drive to create huge lists of parameters, accepted input, and comments on input in

1852:

Typing "Template:" in full is a pain, and the shortcut WP: also saves "only" seven characters but is nonetheless useful. There are many commonly used templates for which shortcuts could be made. Although this would not be much help for linking to templates, it would make searching easier.

10098:

That's what I'm saying. The above script does not hit the servers. It only detects if there's a newmessage bar and accordingly generates an exclamation mark sign on the side which floats with the scroll. I'll write the editpage pinging part once someone gives me the API request AJAX code.

6969:

I'm not saying to notify the other user. I'm saying that multiple watchlists can solve this problem. I have a talkback script already (no AJAX, tho). It adds a talkback tab to user and user_t pages, which, when clicked, preloads the tb template into the editpage. You just have to replace

5405:, but people weren't tremendously interested. I obviously completely agree, but I think one problem we face is that relatively few sources address these topics from a non-human perspective which can make it difficult to create articles that give an overview. I guess it's really a case of 14237:

both the edittools and "enhanced" toolbar don't work consistantly - for example - they appear to work as I am typing here and now, but if I edit another page then they don't. The default should be the option that works for everyone, all the time, not an option that doesn't work for some

13435:

No one is saying you have to stop using Wikicite. Pretty much every function of WikiEditor is also available through other tools, but that doesn't negate their usefulness or the fact that having them all in one place without having to install a lot of separate tools is quite convenient.

3403:

cables. If you want to make a list of cables on some specific subject where the only real unifying characteristic is that the cables were A: leaked and B: cover the same basic subject, godspeed. I doubt that such a list will be terribly helpful, but it is a (relatively) free country.

336:

lines, when the lines are separate and complete on their own. If you must have different spacing for list items, approach it with CSS properties like padding and margin in mind; please don't try to add inappropriate markup to an already complex system. This is a hack in search of a

10898:

Well, I do use the portals when doing research... But I don't think most non-editors know of their existence. Anyways, thats kind of unrelated. Here, we're trying to remove the ugliness from the floating boxes. Anyways, I've opened up a section below to ask for a change of format.

4107:

on. That way, there's no server-side changes that would have to be made, or any extra load on the servers. It sounds like a useful idea, and I hope you can find a programmer willing to do it, but it's not something we would want to implement here on the server side of Knowledge. --

5788:

No, we shouldn't have a cleanup template whereby the number of keystrokes to enter the template exceeds the fix. If all you need to do is remove a single, 4-word phrase, from the lead of the article, then do it. If the problem is more pronounced than a few words, then there is

14307:

The problem still persists on another computer, where edittools doesn't work and the reftools button does nothing - however, if the general opinion is like that expressed by User:Manishearth - i.e that people who use IE don't matter, then feel free to try and drive me away from

11179:

The second proposal is clearly better from a user perspective. I was also wondering why infoboxes appear on the screen in parallel with the text, but the book creator seems to change that layout to centering them on the page. Perhaps it is a result of the difference in fonts.

4031:

No. The use of disclaimers at the bottom is an internet standard. That's where anyone would seek it. Besides, once someone has read it and accepted it, there's no longer any reason to read it again, that's why they are always left at some remote and unobstrusive section of the

8503:

article, giving more detail about some overlooked topic of his administration, carefully keeping a neutral point of view and citing some good history book as reference. More than one would vote "dislike", not because of the edit itself, but because of the "ugh, Hitler" factor

13075:

I'm not positive on this, but some gadgets can tax the servers in certain ways, or have other subtly undesirable side effects, such that it may be bad for Knowledge, or for some users, to enact them "across the board". I have no idea if this is one of those, but it may be.

9691:

You guys have come up with the ideal situation.....a notification while editing, no matter where you are. Good idea. Yes, I imagine someone could make it as an add-on or something else. Any genius programmers here?! Got a job for you that I'm sure many would appreciate. --

6909:, and on the linkpage keep links to all discussion pages. It shouldn't be too hard to write a script that allows you to maintain multiple watchlists easily, but I don't have much time right now, and I already have a few scripts pending. Anyone else taking up the challenge? 3165:

minimum restrict them to those which a human cares enough about the cable to start an article. Creating 200k+ articles with a bot and waiting for a human to come by and update them is complete folly, even without the glaring notability, BLP and potential privacy issues.

4379:

I'd suggest looking if the dictionary is already available somewhere online already (The Internet Archive perhaps?), not copying from it but writing your own articles (those could be much shorter), and link or reference the dictionary in the Further Reading section.

3244:

part of the text of the leaks. Quite apart from the legal and ethical issues, copying leaked primary sources doesn't sound like encyclopedia-building. Given that we wouldn't be adding any value to the lists, what encyclopedic purpose would republishing them serve? -

3641:. We have a number of excellent photographers who specialize in the subjects you mentioned, so that's why you're always seeing them on the Main Page. If there's an image you think deserves to be a Featured Picture, feel free to nominate it. You'll want to check the 14691:

I would install it for the chrome/fFox people (atleast as a beta gadget), and then finish up the IE testing. That might take care of most of the editing populace. Most people (no offense IE users) smart enough to edit Knowledge are also smart enough to scrap IE.

5577:

Seems rather redundant to me. Most people will be coming here to read up on how their own body works, with how animals' variations work being secondary. In fact, if an animal's organ varies significantly, that should be covered in the article about the animal. —

1052:, using your example of comparing camera (specs?) the only reason you need to that information is you are looking to buy a camera, Knowledge is not a shop or a mean to advertise products, that job should be left to the shops themselves to sell their products. -- 15740: 15438: 413:

indexed under "lists, vertical," the first reference is to a "Vertical Lists" chapter subsection. None of the examples there have added space between the vertically listed lines in paragraphed lists. The same thing in WP for a list is facilitated by <br /:

389:

space between lines. Acknowledging its use for poetry but excluding it for a prose paragraph is simply a preference. Intentionally making prose paragraphs look more dissimilar is choice that one can make, but it may not serve the reader well distracted by the

9342: 4761:

I personally don't support the idea, to me the puzzle piece says we're completing the ball, as it were. The logo with the missing pieces says we're not finished, this to me looks wrong. Sorry. I guess if the rest of you want it, go ahead. Just my opinion.

14359:- long overdue, makes life easier for almost everyone here. Of course it should be possible to turn it off for people that use other tools that may potentially clash, but it's too useful not to have it by default (I thought it was already this way!) -- 13415:

most of the time to generate my citations, browser independent but Windows specific, (not tried it under Wine in Linux yet.) But this tends to illustrate my only problem with this proposal. It would seem to promote one tool at the exclusion of others.

10612:

I greatly prefer the strips. They're more noticeable, they don't break pages like the floating boxes do, and they would have a consistent placement. I'm all for it. It would be really cool if we could merge them all into one big multiple-use template.

15085:

Good luck, it'll probably just be archived like the rest. I don't see the point of this noticeboard anymore if everyone agrees to a proposal but noone is in the position to implement it. Supported or not, it just gets archived and forgotten about. --

14161:— as long as the technical overload on the servers is not excessive. I think it is quite good now, but would also expect that the User Interface will be tweaked/improved in future releases. One very large problem in Knowledge has been that, although 4251:

Generally, it's not so much a matter of saying a source is outright unreliable as indicating what biases to look out for, though of course there are exceptions. Yes, there are extreme cases - satire venues that play at looking legitimate, such as the

8520:

Agreed. While I think a more systematic method for feedback than a talk page post would be good, something this simple wouldn't help editors at all. Worse, it could be actively confusing, with people trying to guess why their edits were "disliked."

4357:

become obsolete over time. Is there any way to get a tag such as {{Groves1909}}, similar to the 1911 tag? I'll still be footnoting it as per usual, but a more visual representation of "pretty much came straight from an old book" might be helpful.

10377:

Those templates are not used at sections with text in prose anyway. They are used at "See also" or "External links" sections, which are just a small bulleted list of short items at the left, and shouldn't conflict with floating boxes at the right.

14212:

Note that this isn't the issue with IE that I noted above. That discussion is from June 2009, which means its referring to the version for the old toolbar. I can confirm that the new toolbar version does not cause any problems with the edittools.

12765:

AFAIK the only reason this hasn't happened before - assuming there aren't (m)any odd cases where the punctuation is deliberately arranged - is because it's largely a pointless edit. Maybe it could be added to a bot making lots of edits already? -

6606:

StackExchange does work out well with users, and believe me it would make your job of helpdesk much easier. You could even link duplicate questions up and merge their answers. Answers are rated by vote so the best answer appears on the top. See

1583:

to make shortcut links, and searching doesn't especially require the use of shortcuts because you can omit the prefix entirely in most cases and still get good results. There's no need for the mess involved in implementing a namespace shortcut.

10834:

Hold on! This was a discussion for an alternative way to show the portal links, not for a new standard method to display those boxes. This should not be added to AWB unless you have wide consensus all pages should be changed to this standard.

8498:

There's another difference between Knowledge and Facebook. Here in Wikipeda, there's the need to set apart the articles from their subjects, but things in Facebook are simpler, it's just the subject. Consider that I expand some portion of the

7319:? There is no more data in the watchlist table other than user, and page. Applying filters to the pages based on the nature of the pages is very straightforward, because that data is easily available. The point is that there is nowhere to 12079:: All of these templates could be merged to one. This seems a bit "definitely oppose" or "impossible" on the first thought, but it does seem possible. For example, all the parameters could simply start with something like: 9871:(purge cache afterwards). Note:This code only brings the new message box to the side. Making an immediate notification would requre AJAX and might be tricky (There's no place which I can AJAX-fetch to check if a message is unread or not). 10742:

that's why I listed it last in the benefit list. As it stands now, most articles don't even link to portals, books, or inerWikis, so it's hard to say for certain. (But what you pointed out is a very valid point.) When you suggested "

4818:

Whatever we decide to do (I personally prefer David's 10 jigsaw piece, since it makes sense what we are celebrating, and the original logo is sort of obscure), sysadmins have changed the site's configuration so that we can upload over

4291: 12312:

to determine the process page that the template is being used on. That will take care of problem C, and possibly make the templates easier in some cases. A and B could be mitigated by redirecting the current templates to the new one.

8305://If you want to access a section via document.getElementById(), the id is prefsection-(index), where index is 0,1,2,3..., in the order that the sections were created (in this example, Main has an index 0, and Threads has an index 1) 6214:

Infoboxes should all be standard. And it's either now or never. If you're going to get them standardized (will be a massive cooperative job), you should compile a list of all the nonstandard things. That way, you can fix them in one

2490:

was created with better organization, recruitment methods, and incentives for participation, I think it would attract more intrest and hopefully never become completely inactive, as long as there are a few people to keep it going. —

3460:

We can also include the title, which is not part of the text and whose citation does not violate any copyright, or we can not include it if there is a good reason not to. My opinion is to include it but it is not a key point of the

3050:. Those cables that receive sufficient media coverage outside WikiLeaks (somebody could say that being published on WikiLeaks is a huge coverage in itself, but they are published uncommented) will then have their own article, maybe. 14232:

But the "enhanced" editing toolbar is only in Beta, which editors have to select. And it still doesn't seem to work properly for me - with the reftools gadget selected and the enhanced toolbar selected, I don't get the cite button

5602:

That wouldn't help you. You would still see it, you would still need to revert it. The only difference pending changes would make is that IP users wouldn't see the comments if they visited your talk page (at least not by default).

850:(not required) in WP (per {2T,5-6T, & 8-9T)). A default way of making a list in a paragraph is not really an argument against an alternative method if it would improve on the default per (2T, 3T, 5T) comments and examples. -- 7256:

Whilst it would would be good to separate categories, templates, project pages etc, my biggest concern is that one already takes a long time to load and so having multiple would increase waiting time. Too much and too long time.

8444:

You certainly have a right to disagree, but that doesn't negate the ideas of others. You feel no need. Fine, no one would force you to use it. Others feel a need. Respect them rather than diss them. It can be a quick and useful

15141:

I was about to implement the request, but ran into some problems while trying to use it, and commented there. Please see if you can reproduce the issues I mentioned, and if so, implement a fix, before we activate it wiki-wide.

3497:

reported that she had died for a short period and then it turned out she was alive and in the case of the second, there's a good chance it's legitimate, but we don't have any reliable sources. It's sort of bitey, otherwise.

6596:

You see the proposal was originally intended for public wikis, but has grown in scope to include Knowledge as well. Any Knowledge related questions would be accepted. And there are some good ones in the list if you care to

11173: 7450:. I'd love to make the script, but I'm not too free at the moment, ant I'll probably forget about it. Anyone who knows the basics of Knowledge AJAX can do it. If anone wants, I can give guidance/ an outline of the script. 9484: 8686:

This has been suggested quite frequently IMO. If this is ever going to be implemented, it has to be global (standardized on all wikis). Hence, depending on the outcome of this discussion, you may want to propose this at

3728:

and the actual release date are placed in different table cells in the album info box, it simply doesn't at the moment. The closest I could get while actually hitting any decent results at all was by stripping out the

2834:

That's the point of this first part. Once it is determined that people want change, the people who vote here that they want change are effectively voting for the method that gets the highest vote in the latter stages.

15159:

Just one question though, per my vote above, will this change effect all wikis, or just en.wiki? And if just en.wiki, why not make it global? That way, we could really avoid making each wiki a totally different site.

8343:

Agreed. What has probably already been discussed, would be a feature like Facebook has, where one can click a "like" or "dislike" button. That would provide editors with feedback. I often wish we had that feature. --

7424:

This came up recently. You can have another declared account for another watchlist. Or you can simply cut and paste a new watchlist into your existing account, storing your normal watchlist somewhere in the meantime.

7340:

I admit I don't know how the watchlist mechanism works, but from your description this just means to put a new column in the watchlist table, something that seems more technically feasible than changing the data key.

6648:

version for discussing how stackoverflow runs, ensuring continuous improvement. The results are fast and accurate. Great users get reputation, and hence more rights (like, eventually, moderation privileges). It works

125:. This is not done on editnotice pages and MediaWiki interface pages, which will cause problems. The use of invalid XHTML also cause problems when an article is ported to a wiki that does not use the HTML Tidy option. 2185:

I think this would be very helpful and convenient. Template and Knowledge have an almost equal amount of letters, too. Would prefer TT for template talkspace, or similar, and TL would be fine for templatespace also.

14273:

In addition, has this proposal been implemented now?@ I ask this as I now sem to have no way to get rid of reftools - even when I un-select it in preferences, the cite buttons are still there and edittools doesn't

6840: 4712:

It's the same height but stretched so that there's space for the balloons without pushing the globe off-centre (the image is centred in the sidebar, don't want it to be out of line). Incidentally, <folorn hope:

4065:

I don't see how this could be implemented. Highlighting is only helpful for the individual, because what's important to one person is useless to another. Plus, we deal with enough vandalism. I won't go into it (per

828:

12T. I have added more numbering above to refer to points in my Edits. IMO the default way of making an embedded list in a paragraph does not need to be bulwarked by making it inconvenient to do otherwise (per (8T)

84: 13328:

This would be an improvement. The cite xxx templates have inherent advantages over all other forms of citation/footnotes, and their requirement by policy would greatly improve the references on the encyclopedia. -

12153:

I don't understand at all, because all you've done is paste in a table of code. Can you write out in prose what the aim of this is? What is the current problem, what is the solution, and how can it be implemented?

9211:

While I don't think this is a realistic concern for the example shown, that uses left-floating images. I do agree that it could be much more confusing on the right hand side; it may only work with justified text.

6416:

if anyone thinks otherwise they can let me know. If you're saying my advice above somehow precludes one from pointing out behavioral problems they notice on this page, then I don't think you understood my meaning.

12230:

went into construction. So, in the near-future, these types of "key templates" will be on Commons. And it is this "unified template" that has to be there. This is just another future step, nothing to do with this

3855:

this has been "a desired feature for quite some time". I'd like to go even further, so we could publish list articles that are constructed dynamically from metadata searches, rather than (for example) maintaining

1037: 12276:" Bug 9890. That is awaiting developer resource last time I looked (in fact the test-bed had been switched off, it is apparently back on now), so great to have this ready, but I suspect not particularly urgent. 10282: 642:

7T. Per above ("If we want to change spacing around lists, we can do that with a change to the global CSS".), maybe. But in the meanwhile, so radically changing the above proposal just to avoid adding <br /:

9359:

Not necessarely opposed, but perhaps we can do a better job then the Wikinews design. The icon for one should stay, and the text should maintain its background. And the font-size should NOT be further reduced.

340:

It also happens that I don't think we need increased spacing between lines. The examples you provide look fine both ways, so I'm rather convinced in the direction opposite to what you wanted: no need to change

5398: 5021: 14172:

are required, it has been very user unfriendly for new editors to get over the learning curve where they regularly cite the claims they insert into articles. I think this is one more positive step in the

13913:

Agreed. It shouldn't be too difficult to get this to work at least as well as the other WikiEditor components (for example, table insertion). I'll look into it further if Mr.Z-man doesn't get a chance to.

12655:

I like Cybercobra's idea, actually. Just changing the button to say "Save page (anonymously)" would be a reasonable, inoffensive solution. Who would be able to change this if we came to a consensus on it?

5740:

No offense to anyone, but after meeting some of the people here at one of the tenth birthday meetups, I'm not sure I want to see photos of everybody. I know I'm definitely not a visual treat for the eyes.

9075:. The best system would become apparent through practice. The process we choose shouldn't be the biggest sticking point, but I would hope to keep it to major articles (either WP:VA or an ad hoc system). — 3864:

separately. But I'm not holding my breath for any of this. We can't even attach a citation to a category on an article page, which is the most basic starting point for having a verifiable semantic web. -

2947:

thing we need on Knowledge is a quarter million more bot-generated sub-stubs. Excluding the other future articles that will be created, that would make nearly 7% of Knowledge into stubs about the cables.

2942:

specific cables or even quote them may contribute to notability, but simply being used in a news article is not a guarantee of notability. I think if a cable is used in multiple reliable sources, then it

12821:

Yes, there's no dispute over this (very clear consensus in the MOS discussion) and no need to discuss it on the talk page of every article. If someone wants to make a bot to do this, I'd say go for it.--

12809:

It's got good consensus and is most likely to be an editing mistake rather than a style choice (really, who would choose to do that :P). But agreed, there seems no real need to bot update all instances.

10217:

One day... ONE DAY when I get the time (read as never), I'll probably create a desktop Java notification client which'll notify new messages, watchlist changes, etc, etc (Customizambe for WP:AIV, etc).

6552:

tag for a reasons), so why take it completely offwiki and ask that people actually spend time on a whole other site to answer even more questions? There's little point in running two help desks at once.

2743:

I believe what Shirik was trying to say is that this "motion" isn't saying anything beyond "The way we select admins should be changed". Everything else in this "motion" is complete and total legalese.

15079: 4443: 2420:

In principle this seems a good idea, although lots of details would need to be worked out. It would need to be made as simple as possible. How would the comments be sorted into manageable, useful data?

6435:

I think this proposal would only encourage half-hearted responses and lead to mediocre, half-thought-out discussions. If an idea deserves responses, then just try again in a month or two and hope for

1202:

Personally, I think this is obvious. Pretty much everyone knows that an online screen name is in no way verified as being associated with a real person. I just don't see the need for such a template.

12334:

SfD creates new complications - at times, a category and its stub tag(s) are nominated together for some action, and nominating each on a separate line will make the nomination harder to understand.

10577:

static demo look more presentable. Code simplification for all the existing demos would also be appreciated. All I ask is that you preview your work before saving since they are on display here. –

10015:

Even if you go to a subsection of an article, and miss the new messages warning, it would still appear at the next page you visit. The warning only dissapears when you actually check your user page.

3836: 10924: 2966:

I agree—there's no way each of those 250,000 cables are notable enough for an article. Their text is probably better off in Wikisource, though, if OK legally with the whole confidentiality whatnot.

6829: 3795:

Sure thing: Next one would be to institute some sort of rule regarding a required level of usefulness and demonstrated thought in proposal responses, rather than allowing "sux, next"-type answers.

15304:

I'm waiting on the MediaWiki 1.17 deploy (which includes ResourceLoader) before turning this on for everyone. It was supposed to be deployed last week, but it's been delayed until this Wednesday.

9566:

e/c The message bar does not "suddenly appear" while in the middle of editing an article. Yoenit is right. It will only show up when you refresh the page, go to a new page, or hit the edit button—

14711:- Yes yes yes! I just tried turning it on after being here 2 months and can't believe how much easier citing is now! Unless there are significant accessibility or technical problems, go for it.-- 1410:

T: for Template (having to type "Template:foo" in the search box when I need to get there is such a pain in the neck); but U: for Template talk seems counter-intuitive to me: wouldn't TT: do it?

12206:

The likeliness of a user making a mistake is actually much more slim than the current format. Because, if this method is used, the template will only function if a parameter is given. And since

3201:

However, IMHO it is more reasonable and likely to attain a consensus to restrict the scope of the proposal to just creating lists of cables by origin. Please let me know your opinion about this.

1395: 5391: 8609:

I believe the long-term goal is to indeed rollout a feedback feature on every single article. For now, they're just trying to determine what the most effective design and implementation is. --

7129:

Actually, this problem would become obsolete once LiquidThreads is introduced to enwiki (I dunno when they'll release it from labs), as Special:Newmessages will bea centralised thread center.

4328:

way since then, and it's easy to incorporate errors that were corrected half a century ago. I strongly suggest finding a more recent source, for example the equivalent article in the current

3522:, and the news says that she is following simple commands. I no longer visit A.N.I., so I had no idea of the existence of the apparent piles of horse apples that are/were sitting over there. 3464:

Besides this, I agree with the last contribution by Protonk. Let's use ordinary editing on a few significant cases and then if a pattern emerges a bot can help for the dirty work (of creating

14383:

Absolutely. Considering that Knowledge is based on reliable sources and references, a tool for creating them should be front and center—not just an option that is invisible to newer editors.

4352:

in modern published sources. That is, things still of long-term notability, but "obsolete" enough to not be prioritised in modern printed sources. As an example, I recently did the article

2903: 12353:

Even though the edittools is somewhat redundant to the new toolbar, I agree it is too low. In fact the whole edit page could do with a cleanup/overhaul; it is simply too crowded down there.

14830: 5888: 3624: 4090:, but please don't. It doesn't really make the page easier to use and can look really shitty, especially after several people with differing ideas about what's important go through it. 3658: 15262:

Okay, so where does the discussion have to occur for the Tool to actually be turned on (added to the default availability for users)? Is this discussion necessary but not sufficient?

14290:

It sounds like you may be having JavaScript caching issues. This would explain why turning the gadget on and off is not working consistently for you. Bug filed about the "Beta" status:

12501:

Could? No problem (requires some javascript though to detect if the user is logged in). Should? There is already a big notice above the edit box notifying users they are not logged in.

9570:

someone leaves a message. In which case you are then at the top of the page and will always see the message bar. You would probably have to talk to the developers if you want a message

7154:

There's already the ability to see their contributions... as someone's contributions are 100% what anyone can be concerned about on Knowledge, the feature you request already exists. --

6957:

More interface clutter, and it's still tedious (even if by script) to have to create these pages and notify the other user. You could as easily have a script to just post the talkback.

4127: 6846:). I am pretty sure it will break archive bots though, but it would certainly make communicating with new users easier for both users have the full conversation on their own talkpage. 4153: 2636: 12688: 1891:) templates, only for entering templates into the search bar to go directly there. How often does that really happen, compared to how often people link to Knowledge-namespace pages? 10746: 10665: 8577: 7466:

If anyone wants the UI code for creating a tabbed watchlist page with tabs like the prefs page, here it is (It does nothing about the watchlists, just makes it easier to organise.):

15769: 15467: 14885:, one of the hardest things new editors have to learn is correctly formatting references. I didn't even know this tool existed. Anyway if not enabled by default, there should be a 13933:

I don't use it, but I've tried it and think it would be great for most new editors instead of trying to figure it out by themselves. Experienced editors can disable if they want. -

13201:

I just spent some time playing around with the tool. My comment above notwithstanding, if there are no technical problems with this feature, I would completely and wholeheartedly

10961: 9927:

urgent. If enough people ask, though, I might try making it. If you want a more competent developer who knows his way around AJAX (and probably realtime stuff), I would try poking

8353: 4678:

Mumble mumble meh. It just seems a bit more Google-esque to keep the globe and add 'bells and whistles' to it, rather than changing it altogether. But I definitely support doing

4668: 4183: 588:

built-in feature of the wiki software, as well as HTML, rather than doing things in an unnecessarily complicated manual way. Note that the wikisyntax version produces a <ul: -->

14252:

The enhanced toolbar has been the default now for several months, it isn't considered a beta anymore. Without knowing more details, I can't say why it may not be working for you.

13764:

FWIW, I believe Mr.Z-man is currently working on a feature that would enable you to automatically generate a citation just by entering the ISBN number, which would be quite nice.

10651: 6535:

There's something called Yahoo! Answers, where some Knowledge users (including at least one banned user) try to answer WP-related questions. It usually doesn't work out that well.

307:

But the latter would accentuate the difference between it and other paragraphs (because of the space line between bulleted points) compared to the other paragraphs in the Lead of

12556:@MZMcBride; you could do it manually for yourself if you like. Just add a new line containing "#wpSave { background-color: #629909; color: #fff; border: 1px solid #4F8000; }" to 11062:. When you click on a tab you see "Article", so you are more likely to miss it. I realize that this isn't earth-shattering, but it would just make maintenance a little easier. ▫ 6864:

Good idea, but if you want it integrated into the wikipedia framework, you should propose this idea on the MediaWiki website, the wiki engine that Knowledge actually runs on. --

14924: 5991: 5943: 5767:

The only problem I can think of is that the articles may not have someone familiar with the other language. It would at least be a start, though, so I'd say it's a good idea. —

1493:

Those can be fixed, since all the linguistic keywords also conflict with articles, so the articles are named using the technical restriction template. "W:" is already reserved.

1154:

editors always agree it would be a good idea to wait until it's all over, but there is no way of managing the enthusiastic but naive editors who never look in places like this.

9229:

The image link icon (presently absent) *could* be used left-justified on right-side images, right-justified on left-side images to break the caption text from the body text. --

9096:. The BLP drive proved this idea can work with great success. Let's give it a try. Once we've decided to do it, the details of "how to choose an article" can be worked out. -- 183:

2T. On the 15:57, 30 December 2010, OK. That was quick. I accept (if I have correctly understood) that I should have at included a forward slash in the proposal: <br /: -->

13521:

and then I reloaded my page (I have Google Chrome) like it told me to. However, it doesn't seem to have changed or added said toolbar to my editing page. What did I do wrong?

10084:@Manishearth, moving the bar to the side will solve part of the problem and using the script only while working with an open edit window will limit pinging of the servers. -- 8627:

I hope they are also monitoring whether this is actually a good idea. I'm still concerned that this could prompt readers to complain about articles instead of improving them.

8472:

is especially good you hand out a barnstar. The argument "if you don't like it, don't use it" is total bullshit as this is a change which would effect every wikipedia editor.

5733: 5118: 3301:, to identify the cables. However, citing the title of something is not copyright violation, of course, otherwise we'd not be allowed to mention any book or movie or whatever. 283:

3T. Well, here's an example that is responsive to the broader point I was trying to make, which was not only about templates. It is truncated from the last Lead paragraph of

9349: 8679: 13165:

see potential improvements to it, though (eg not have separate "pages" and "page" fields). If enough support comes together to implement it, there should be discussion with

6491: 5889: 5133: 3997: 3689: 3541: 3513: 865:

sign. You're entirely losing the semantic value of an HTML list. And you're losing significant accessibility for users with screen readers as Gadget850 mentioned. Why do we

13050: 8215://Makes pref page at special:Multiwatch (By overwriting the "Special page does not exist"), with a window title My multiwatch, and a header Multiwatch, form name MyFormName 5917: 14854: 8335: 7285: 6410: 6349: 3771: 2041: 1191: 9286: 7439: 2015: 1868: 1399: 648:

8T. "Requiring" saving of space between lines (which is not the proposal in this section) is different from "facilitating" line-space-saving (which is the proposal here).

12680: 6662: 5716: 4657:

As noted above, the black "10" puzzle piece is the Wikimedia Foundation's official Knowledge tenth anniversary logo. I simply tweaked it to include the word "years." —

4246: 2339: 1391: 14993: 13021: 12816: 12792: 8643: 7388: 5312: 5298: 5283: 4837: 4699:

Your suggested graphic is nice, but it has the wrong dimensions and doesn't indicate the celebration's nature. I also think that we should use the official artwork. —

3369:

If the cable's subject is missing, a list like that isn't important human knowledge (is it?) and I'm still not clear how it would help our readers. By comparison, your

3192:

makes sense or not to have articles about individual cables; maybe they do not need to be about each individual cable and maybe they do not need to be created by a bot.

2447: 442: 364: 240:, a list with extra spacing between lines looks non-intuitive. In a non-paragraph list, I have no objection to extra space between lines as the default. Thank you. -- 12804: 8655: 5294: 5265: 5237: 5209: 3595: 2609: 2131: 869:

multiple ways to make a bulleted list? A trivial style improvement is not sufficient justification for essentially doubling the complexity of list-making in wikitext.

14720: 12991: 9826:<img src="http://upload.wikimedia.org/wikipedia/commons/thumb/f/f7/Nuvola_apps_important.svg/25px-Nuvola_apps_important.svg.png" alt="You have new messages" /: --> 9270: 8942: 6779: 5269: 5255: 5241: 5227: 4901: 4853: 4811: 2190: 1596: 14863:

Do it! It's a vital tool for editing. But perhaps leave this open for a full month, to give adequate time for any naysayers to stumble upon this and have their say.

14836: 13664: 13237: 10592: 10571: 10562:

Nice work. I like the idea of having this as an option for changing the presentation of these links. Let me know if you want any help making a functional version.

10191: 10171: 10093: 7371: 6461: 5213: 4694: 4099: 4095: 4079: 3823: 3790: 3756: 2177: 1986: 1662: 1387: 13249:

there are no technical issues. The tool is a pretty cool thing. Wonder how possible is it to merge it into the default edit interface, and make it a global tool...

12267: 12248: 11292: 11274: 11225: 11189: 11098: 10829: 10809: 10110: 10067: 9882: 9862: 9701: 5587: 4881: 4401: 4386: 4366: 4339: 4231: 2148: 2106: 2087: 2065: 1947: 1780: 936:

15T. I think that most will correctly understand (14T) above (slightly corrected) as not advocating an imposed format on anyone or removing the default options. --

14877: 13133: 12189: 11079: 11045: 11021: 10993: 10607: 9527: 9508: 9169: 8965: 8329: 7419: 7140: 6627: 6582: 6473: 6366: 5861: 5832: 5818: 5061: 4863: 4775: 4650: 4523: 4317: 4051: 3975: 3900: 1914: 1802: 1565: 1454: 1419: 15094: 14664:. I use refTools, but with Firefox. If the IE problems have been fixed, go for it. It's especially good for newcomers, as they can just filling the blanks - only 13488: 12770: 11165: 11143: 10424: 10387: 10364: 10344: 10143: 10024: 9735: 9674: 8466: 7210: 5882: 5550: 5369: 5199: 5103: 5011: 4918: 4743: 4734: 4703: 4661: 4543: 4160:

Would determining which sources are 'reliable' in this manner a POV in itself? After all, NPOV does not mean adhering to the POV of well-respected organisations.

3151: 1898: 1844: 1370: 320: 274: 13636: 13620: 13606: 13590: 13572: 13556: 13470: 12640: 10777: 10626: 10266: 10242: 10229: 10212: 10045: 9648: 9478: 9224: 9124: 6697: 5570: 5163: 5151: 5129: 4567: 3523: 3373:

example adds value in that it links the names to the relevant wikipedia articles, which is not a task we would expect external sources to do reliably. I suppose

2862: 1699: 1528: 1502: 1488: 732: 582: 484: 152: 50: 13532: 13112: 13096:

I can't see how this feature might put excessive load on the servers. There are indeed performance considerations with things like Popups, which have to get a

12948: 12537: 12485: 12372: 11283:

Good point about being mechanical ... the intention was to be thoughtful and considerate of folks contributions to Knowledge, spread some good faith, ya know.

11004:), there were times when you'd get lost in "twisty little passages", and you'd end up a place other than where you intended to go. Sorry if that was muddled. ▫ 9846: 9414: 9105: 7461: 7357: 7335: 7310: 6725: 5468: 4431: 4022: 3386: 3328: 3254: 2331: 2267: 2226: 2209: 1827: 1636: 1614: 1163: 945: 887: 859: 787: 680: 609: 468: 249: 174: 15171: 15065: 13974: 13509: 13100:

of data from the servers, but RefTools pretty much just injects new HTML, with a couple of commons images; a drop in the ocean compared to normal server load.

12665: 12447: 12168: 11258: 10867: 10844: 10704: 9942: 9909: 9618: 9549: 9008: 8994: 8513: 8481: 8396: 6868: 6309: 4578: 4121: 3708: 3683: 3086: 2987: 2787: 2762: 1383: 1264: 1023: 15798: 15496: 14903: 14337: 14285: 14266: 14247: 14227: 14132: 13849: 13794: 13277: 13268:. I'm aware that there are issues about some cite templates affecting page load times, but I doubt that the editing tool would itself cause those problems. -- 12588: 12551: 12341: 12197: 10885: 9587: 9455: 9026: 8734: 8604: 8590: 7189: 6964: 6952: 6936: 6920: 6274: 6255:

I agree; whatever things that needs fixing, it's either now or never. I am ready to help if someone could create the list and a coordination page. Perhaps at

6234: 6006: 5983: 5969: 5722:

If you go to the history tab of any article, you will see the contributors, each with a link to their contributions. Adding images would simply be gaudy and

5446: 5418: 4971: 4789: 4625: 4477: 3949: 3874: 3750: 2738: 1928: 15136: 15123: 14966: 14317: 14302: 14117: 14084:

I'm currently the sole developer for the "main" version of the script (though help is always appreciated!). The version for the old toolbar is maintained by

13673:. Note that a discussion in Wikibooks regarding adding RefTools to the preferences resulted in no consensus, though, for the reason that Jc3s5h put forward. 13390: 13178: 13030: 12620: 12520: 11245: 10955: 10736: 10002: 9973: 9241: 9206: 8622: 8535: 6896: 6855: 6815: 6330: 5511: 5490: 5177: 5089: 4989: 4798: 4605: 4596: 4513: 4495: 4281: 3618: 3568: 2961: 1748:

cannot handle that saving 7 characters is worth the added complexity and the inconvenience of not being able to have these articles at their current titles?

1250: 15271: 15247: 15235: 15185: 15146: 15099: 14703: 14656: 14579: 14392: 14147: 13959: 13923: 13817: 13714: 13430: 13404: 13370: 13344: 13323: 13220: 13155: 13091: 12830: 12786: 11211: 8552: 8423: 7238: 5755: 4945: 3926: 3477: 3223: 3182: 2848: 1963: 1291: 15313: 15023: 14805: 14763: 14639: 14622: 14601: 14508: 14485: 14451: 14102: 13445: 13308: 12842: 12566: 12347: 12327: 8716: 8702: 8370:

system might not hurt either. Also, some form of simple survey for a given page revision, for example, the "what do you think of this page" survey used at

6060: 5776: 5702: 5685: 5654: 5640: 5609: 3412: 2745: 2403: 2375: 2356: 2303: 2028:, and similarly for all other ones. Then we migrate all these pseudo-namespace redirects from articlespace into this new shortcutspace. That would include 1788:

per Anomie. Unlike WP, where hundreds, if not thousands of shortcuts existed, there are only a handful of templates that are linked to with the shortcuts.

14207: 14048: 14003: 13294: 13260: 13146:. No opinion yet, but I saw this and installed and it looks really cool. I'll amend my comment (to support, I imagine) when I've tried it out a little. -- 12471: 12214:

discussions pages (for instance, at RFD, only the parameters relating to RFD will be shown), the probability of someone accidentally placing a param like

9496:

Conflicts, misunderstandings and embarrassment can be avoided if all concerned would examine the time stamps in the edit histories and talk page messages.

9084: 9062: 6197: 6155: 6108: 3581: 2589: 2575: 1229: 1208: 514:, should facilitate reducing the difference in appearance of other paragraphs and a paragraph with a vertical list. In that regard, per the above example: 15197: 15050: 14949: 14565: 14549: 14375: 14028: 13908: 13873: 13773: 13196: 11200: 9436: 9316: 6746:). However, many questions on talk pages (here and on MediaWiki) go unanswered for weeks or months - some are never answered. That rarely happens on the 6036: 5923: 4206: 3103:

Lists of cables leaked might have some value on Knowledge. Agree that putting them on wikisource would be better than putting them on wikipedia, however

2933: 2514:-related can always use a boost, and there might be creative/systematic attempts to find crossovers from CSB topics to more popular ones. Something like 1938:. This comes up far too often. Can't someone make a project page fully explaining most of the reasons why additional namespace aliases are a bad idea? -- 1715: 1429:

T: for Template and TT: for Template talk per A. di M. If anything, U: should be an alias for User: (and it follows that UT: would be for User talk). ···

1178: 14784: 14683: 12542:

Last time I checked there's a huge notice if you're not logged in. I'd rather not stylize anything, as that's a slippery slope to hideous user design. —

12297: 9395: 9185: 4264:

is a perfectly good source on the official views of the Egyptian government, though not on those of the opposition. Also, for example, in the U.S. both

3532:

may not be the best example. But its serious thing and we should treat it as such and may be add link to encourage discussion on the article talk page?

2537:

The main reason that I'm suggesting starting it from scratch is that I think it should clearly be a standalone wikiproject. For example, take a look at

2496: 2480: 1755: 1724: 1141: 1114: 1098: 1062: 644:

to the Wiki markup list seems complicated. However, if someone would effects such a change, that might be an appropriate time to object to <br /: -->

15299: 14741: 14527: 14428: 14066: 13891: 8866: 2560: 2550: 2532: 13942: 13759: 13697: 12147: 3107:. The pervaling opinion is "ask the WMF first" on account of the ambiguous nature of U.S. government copyright release. If the government releases it 13731: 9333: 8971: 6714:? I mean that literally— are there questions there that would be better asked off-wiki? And it has years of archives to look up previous answers. --- 6676:

wrong with people asking questions elsewhere, and you don't need community support for it, but it's just not the best way to help people in the end.

5949: 2653: 14186: 9379: 8928: 15789: 15487: 13517:

Seems like a great idea and it will hopefully help newcomers learn how to properly use citations. On a separate note, I tried to add the script to

8841: 7447: 6292: 5502:

should treat the human kidney first and primarily. Kidneys in general should be perhaps a separate article. Not sure what the title should be. --

5303:

Never said you had to like it. But, yeah, several options were offered and you rejected all of them. So "suck it up" would be the best response. —

2567:

Go for it focus. You have my support and help. Drop me a line on my user page if you have your idea sketched out and/or what I could do to help :)

2262: 2222:

1 or 2 letters being of lesser concern--suffice to say that ultimately having 'T' in there somewhere (probably at the beginning) would make sense.

1255:

I can't imagine a good reason not to use this template. The more we can do to avoid offending individuals who haven't done anything, the better.

15669: 15367: 14750:

need something to be implemented into the interface ASAP. I guess I'm just amazed that it's taken ten years before somebody raised the issue... --

13899:. The issues with IE need to be worked out before this is made standard for everyone. I hate IE with a passion, but it is a widely used browser.-- 7294:

What about filtering after retrieving the list -a bit like the drop-down namespace menu already does- to add custom filters (e.g. by category)? --

12822: 6876: 4872:

I'm a huge fan of David's puzzle piece logo—clean, informative and celebratory. Let's get it on here in time! I certainly see no reason not to. -

4007: 1203: 1147: 13395:

If there is consensus for this change, I'd be happy to see if any front-end developers at the Foundation could help with bug-fixes and testing.

12218:

at FFD is near 0. If no parameters are shown (or a non-existent parameter is entered), we could make it to display a nice big red error message.

5002:

I'm a bit late to the discussion, but I noticed the 10 Years logo and came here to say "Great Idea!" and very well implemented. Thank you all.

8861: 8856: 5094:↑ This. If you don't want to see banners, a login is a simple solution. Choosing to not have a login means you can't remove items like this. — 4448: 3839:) but that only works if you already know the exact categories. The missing link is being able to search using supercategories (e.g. look for " 1330: 15202:

Thanks, Titoxd. Was just wondering if this was a global change... Would be nice if it was though, but I agree we should gain consensus first.

5694:

reviewing a pending revision or b) automatically if an (auto)confirmed user makes an edit based on a reviewed revision (like when he reverts).

14079:"enhanced toolbar," for people who can't use the enhanced toolbar, there is also a version for the old toolbar, though it isn't customizable. 13727: 13660: 12495: 9391: 9329: 7362:

Except that it's an absolutely massive table...When you have something like Knowledge, a *lot* of things simply doesn't scale well enough...

6326: 2507: 2459: 15058:- I use this tool quite frequently; it's invaluable. This seems like a no-brainer idea to help new users with a potentially confusing task. 14520:

per the problems documented above, at least until they are fixed. RC patrol doesn't need refs in random places messing up good-faith edits.

8573: 5473:

So just because you're a human means you don't want to know about other organisms? A counter to your point, is that I know exactly what the

5074:@72.144.177.129: So basically, even though there is an easy fix, you refuse to do so just to stand on "principle". Good luck with that. -- 3737:, which of course doesn't really work as intended, since the date could be anywhere on the page. I suppose something could be done with the 7163: 5840: 718: 5690:

Anonymous users are by default presented the last revision marked as reviewed. Revisions are marked as "reviewed" either a) manually by a

2321: 15865: 15563: 10966: 10204:

Or you could have an irc client running in the background in the recent changes channel and have it ping you when your nick comes up. --

2510:), trying to identify key pages and crossovers between WikiProjects and bringing in multiple wikiprojects to the collaboration. Anything 2025: 12389:, which should then be re-formatted (what's with the small font..?) into something a bit more welcoming and informative, something like: 2807: 8851: 8740: 6183: 4214: 2021: 1601:

Can you elaborate on that? If I type "Convert" in the search box at the top right corner, the page I'm taken to has nothing to do with

2070:

Crossnamespace redirects are being deleted on sight alot of the time at RFD, so perhaps a shortcuts namespace is in order anyways. If

1684:

for template talk. If I'm not mistaken, we are talking of a local project-space shortcut, not an interwiki shortcut, so I don't think

14403: 10134:

discussion is still going on. We can see, link and retrieve older revisions, and we can leave and re-join discussions at any moment.

5481:

barely touches on at the moment. Why deny a reader of finding out more about the anatomy of other animals, just because we're human?

3762:

I'm confused why you decided to call no one (and everyone?) a smartass despite there being not a single response to your proposal. --

3714: 2029: 1511:

be fixed. But is the added complexity and the hassle of having to fix them worth saving people typing 7 characters in the rare cases

1324: 5168:

I'd like the giant banners gone too, from every page and they should not come back for any reason less than the end of the world. -

3033:

notable enough to have their own article if not the need to give a thorough description of the knowledge domain that comprises them?

2670: 2092:

People making bad decisions on RFD is not really a good reason to make another bad decision (move all the shortcuts to new titles).

15748: 15744: 15664: 15446: 15442: 15362: 15226:

Am I misunderstanding what this tool does? I thought this was a tool to make using English Knowledge reference templates easier. --

14792:

absolutely. It takes some time to write citations manually, this will help the whole community, new users and experienced editors.

14609:

I love refTools and can't imagine living without it. New editors will find it much easier to add references if this is available.--

12386: 12188:"... So, may I advise you to list the benefits of such change in a little more detail before moving to another "Village Pump"..? -- 11300: 10404:

True, but the "External links" section is just above the navigational templates and categories. Furthermore portals and books are

9540:

I thought it only appears anyway when you refresh the page? Placing it on the side would only make users less likely to notice it.

8836: 5800: 5659:

IP would see the removal? I thought PC was designed to not show any edits to IPs/new users until confirmed by an experienced user.

5495:

Absolutely, the anatomy of animals should be covered. I just think there's nothing at all wrong with a so-called "bias" to humans.

2889: 2829: 1999: 1221:

does upset banned users, and such upsetness isn't helping them to let go of Knowledge, is it? (And, spelling out why that matters:

1213:"pretty much everyone"? everyone knows WP usernames are unverified? I doubt that. And what about those who don't? Besides, even if 13808:

My personal experience is that the difficult of citing sources is one of the main reasons people say they don't edit wikipedia.--

8816: 8811: 5955: 5645:

Erm, yes, an IP would see the removal. If anything, an IP would sometimes not see the vandalism, that's what it was designed for.

5402: 3988:

I think "category" would be more widely understood by non-native speakers of english: tag is quite a recent, technobabble word.--

2716: 2659: 2580:

Thanks! I'm going to develop the page design in my userspace, then do some recruiting and hopefully have it running by February.

6354:

Arbitrary response rules aren't helpful and are easily subverted. Sometimes a topic just doesn't end up meriting any comment. --

5218:

It stays away for me, when I'm not logged in. When I delete cookies, then it comes back. Are you not allowing cookies, perhaps?

473:

I agree. I provided a technically correct answer, but now that I understand more of the intent, I see the stylistic issues. ---

14827: 12398: 9032: 6901:

Well, talkback's get tedious and sometimes unecessary. It's easier to maintain separate watchlists for conversations. Just use

2913:? Of course not. So there should be an article about all of them because...? Instead, create articles about the ones that pass 840:

14T. On the other point, see my (corrected & now labelled) (10T) above for starters. To recap from (10T), what is done in

67: 15731: 15429: 10940:

Let me find an appropriate forum to get feedback, and if the good significantly out-weighs the bad, I'll bring it up again. –

4418:

Don't just strip it: improve it. Something written that long ago will need substantive and stylistic updating in a major way.

14198:- unless someone sorts this then this proposal would severely restrict the ability of anyone using IE from editing Knowledge. 13869: 10293: 9842:

just in favor of the concept. Hopefully the devil will not be in the details. I commend Brangifer for posting the proposal.

8826: 8821: 5593: 3487: 2079: 2071: 2033: 2007: 2003: 454:

for one. We shouldn't be making lists manually anyway. You don't need to use HTML line breaks or extra space to make a list.

13984:

any step toward better referencing (in this case, by making it simpler/easier) is a step in the right direction in my book.

5696:

Any anonymous user still has a link to show the most recent revision, which is also shown directly after he edits the page.

5459:

be anthropocentric. It is read, so far, exclusively by anthropoi. So basically I think your whole project is misguided. --

5026:#p-logo a { background-image: url("http://upload.wikimedia.org/wikipedia/commons/7/7f/Wikipedia-logo-en.png") !important; } 3851:

in the results because he belongs to sub-categories of both Category:Psychologists and Category:1950s births). According to

2643: 832:

13T. I mentioned templates twice (at (1T) & (3T)) -- once in passing (at (1T), the other time to say that <br /: -->

15897:• Holley Ulbrich and Myles Wallace, 1983. "Church Attendance, Age, and Belief in the Afterlife: Some Additional Evidence," 15823:• Jonathan H. Gruber, 2005. "Religious Market Structure, Religious Participation, and Outcomes: Is Religion Good for You?" 15595:• Holley Ulbrich and Myles Wallace, 1983. "Church Attendance, Age, and Belief in the Afterlife: Some Additional Evidence," 15521:• Jonathan H. Gruber, 2005. "Religious Market Structure, Religious Participation, and Outcomes: Is Religion Good for You?" 12902:

someone deletes a statement they don't like, but leaves the ref, which thus attaches to the immediately preceding statement

12412:

All text that you did not write yourself, except brief excerpts, must be available under terms consistent with Knowledge's

10798:

to add these templates to their program after you've finished developing them. That way, all the pages can be made neater.

5828: 5290: 5261: 5233: 5205: 4719: 3493:

I'd suggest only in the case of really obvious stuff (vandalism). In the case of the first example,, I believe it actually

2075: 1494: 1478: 15075: