Wikipedia:Village pump (proposals)/Persistent proposals

From Wikipedia, the free encyclopedia

Village pumps: Policy • Technical • Proposals (persistent) • Assistance • Miscellaneous

Skip to: Table of contents | First discussion | Bottom of page

Village pump proposals — persistent proposals   post
In a nutshell: If you are concerned that a proposal at Village pump (proposals) is in danger of being (or has already been) automatically archived, despite having demonstrated consensus, simply move it here. This page is not automatically archived. Discussions can continue on this page. This is not an archive. Rationale: The purpose of this page is to provide safe haven to proposals that show consensus, but that would otherwise become (or stay) automatically archived due to inactivity before they can be implemented. It is an effort to ensure that potentially valuable proposals are not forgotten simply because there is currently no time to implement them. Developer intervention is required in order to implement most proposals, so this page is especially necessary while the developers are particularly busy with long-term projects (ie. the Wikimedia Foundation's unified login system). This page is not an archive, so feel free to contribute to any of the discussions you see below. Move a proposal to this page only if it meets all of the following criteria: The proposal discussion has not had any replies in at least 5 days. The proposal has already been described and discussed at Wikipedia:Village pump (proposals). The proposal seems to have gained community consensus. Note: This is not the place to post new proposals that have not been discussed at all yet. Post new proposals at Wikipedia:Village pump (proposals). Also, do not confuse this with perennial proposals, which are "persistent" in that they are frequently made, but have all been rejected. Proposals here, conversely, show some degree of consensus. How to move a proposal here: Proposals can be moved from either the main proposal page or from one of its archives. If a proposal meets the stated criteria, copy its entire discussion and paste it at the end of this page. Remove the discussion from its original location, but leave its section header (== ==). In place of the discussion, post a notice of the move. Be sure to include a link to this page, as well as your signature. For example:   ''Moved to [[WP:VPR/Persistent proposals]].'' ~~~~   This is to ensure that redundant discussions don't exist or continue in multiple locations.	Shortcuts: WP:VPRPP WP:VRPP WP:VPR/PP
Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar). Please add new topics to the bottom of this page.
« Older discussions | Archives: 1

Contents 1 Converting User: prefix to Editor: prefix 2 Special:Unwatchedpages 2.1 Highlight or put a mark to unwatched articles on RC 3 Edit conflicts 4 Create a new ref tag called <note> 5 Multiple watchlists 6 History Options

[edit] Converting User: prefix to Editor: prefix

This a proposal I have been thinking out for a while. Kind of a major one, but I would like to get the ball rolling and see where it goes. There is often much consternation (for good or ill) with individuals who edit their userspace and nothing else, often leading to needlessly wasted time in deletion discussions over content that is clearly not serving the encyclopedia.

Walton One has written a cogent essay, however, arguing that editors matter, and that making editors feel as though they are part of a caring community that does not rush to bash them over the head and delete any unencyclopedic (but harmless) nonsense in their userspace ultimately serves the encylopedia by allowing us to retain good editors--we are all volunteers after all (cf. WP:CARE).

Now countless millions of people use the encyclopedia by reading it, but many fewer individuals could actually be considered to be editors. Perhaps if this distinction were made in the title of the namespace it might discourage some of those who edit only to make a myspace-like environment and are not interested in contributing to the encyclopedia while they are at it. A new namespace of "Editor:" would better befit the true purpose of the space. It seems to me that this could be accomplished in much the same way as was the recent changes involving the WP: to Wikipedia: shortcut. Let me know what you think. I'm not terribly attached to the idea, so don't feel bad about tearing it to shreds, but I wanted to put it out there at least. IronGargoyle (talk) 23:51, 2 January 2008 (UTC)

I would also like to add that there is considerable evidence from social psychology that very subtle contextual cues (such as simple changes in words) can have profound influence on human behavior. IronGargoyle (talk) 01:15, 3 January 2008 (UTC)

Sounds like a good idea to me. Those subtle cues are a large part of why I campaigned to get "fair use images" changed to "non-free content". --Carnildo (talk) 03:04, 3 January 2008 (UTC)

Editors don't matter; contributors do. –Pomte 03:07, 3 January 2008 (UTC)

Sinze whne was editting not a a valuble nd usefull contrbushun? A good editor ads valu by improoving teh clearity ad acesibility of our content. By the same measure, Michelangelo was a terrible contributor; he took tons of perfectly good marble and threw most of it away. Tsk. How wasteful. TenOfAllTrades(talk) 15:42, 3 January 2008 (UTC)

You can change the official name of something long-standing, but people are going to keep acting as though you didn't. We saw this with WP:ATT: everyone was told to refer to the attribution policy instead of WP:V and WP:NOR, and they promptly commenced to ignore this and continued to use the old names. Is there really any benefit in having the official name be different from what everyone uses? -Amarkov moo! 03:27, 3 January 2008 (UTC)

I think part of the reason that might not have worked is that "WP:ATT" as a mere text string has no semantic meaning. An individual can be exposed to that text string on a subliminal or supraliminal level all day and it won't do a darn thing to affect that person's behavior. On the other hand, the words "Editor" and "User" do have different connotations beyond the context of wikipedia (then see the external link above for my evidence about why this would work for changing behavior). IronGargoyle (talk) 15:15, 4 January 2008 (UTC)

From a technical standpoint, it's a really easy change to make. However, you'd need widespread consensus before it could be done. --MZMcBride (talk) 03:39, 3 January 2008 (UTC)

It might be that the change wouldn't affect longtime users as much psychologically, but I agree that it's still worth it, for whatever affect it may have -- and it may have a significant effect on new users (ahem, editors). I like this idea a lot, especially if it's not a difficult thing to technically change. Equazcion •✗/C • 11:51, 3 Jan 2008 (UTC)

I like this idea a lot. It could have merits as Carnildo has pointed out, and I don't see too much wrong with it. It would certainly be good to be continualy reminded that we are all editors, and that subtle cue might increase good relations between editors. Leaving a comment on the page of another editor feels a little different then leaving a note on the page of another user. The only reason I see why not to do it, is that it is a change, and communities seem to have difficulty with changes. This community however is built on changes, and I certainly hope, that this is one of the changes that makes it: that is, not get stopped by the attitude of "userpages have worked fine forever, so why change it" while a good rationale to change it is provided. Martijn Hoekstra (talk) 15:50, 3 January 2008 (UTC)

I too like the idea of substituting 'editor' for 'user'. The problem with 'user' is that it is computer jargon and we want to be friendly to people who are not computer geeks but are contributing editors. Go editor! Cheers! Wassupwestcoast (talk) 20:05, 3 January 2008 (UTC)

The only problem I can think of is the many existing links to the User: prefix. Unless of course this can modified into some sort of redirect or something? I don't know how this sort of stuff works though. Good idea though, I think a lot of people need the reminder. .:Alex:. 20:52, 3 January 2008 (UTC)

Please bear in mind that this would have consequences not only for english wikipedia, but for every single project, as the english version is a redirect to the local version (if localized at all), and thus there are also a lot of these links internally and externally elsewhere. That even besides the fact that people in all these communities might be used to type user:... (At least, I do if I'm on another project then dutch) :) effeietsanders 20:59, 3 January 2008 (UTC)

Currently, there is a WP: namespace that redirects to Wikipedia:. The same could be done for a user: namespace that redirects to editor:. Martijn Hoekstra (talk) 21:10, 3 January 2008 (UTC)

I'm not a big fan of changing this, but I'll admit it's because I'm a fan of the status quo; pretty much every other wiki uses "User" (or a local translation). We are not first and foremost editors; we are first and foremost users (personally, I read more on Wikipedia than I edit). I do believe that it'd be an easy enough transition to make, though; the non-English projects already have similar redirects (ie: on the German WP, "Image:" redirects to "Bild:", "User:" to "Benutzer:", "Template:" to "Vorlage:", etc). EVula // talk // ☯ // 21:38, 3 January 2008 (UTC)

WP: only redirects locally on enwikipedia to Wikipedia:. It is, afaik, not a "global" thing. The English names traditionally "redirect" to the localized versions, but this is an automated process. That is something else then requesting a new namespace to have that redirected. Undoubtedly it will technically be possible though. As long as you put enough time in it almost everything is :).

Btw, I agree editor: is not ideal either. You can also create an account just to watch Wikipedia in the preferred layout. You don't have to be an editor for that. Actually, most user accounts have never edited a single entry :) effeietsanders 22:07, 3 January 2008 (UTC)

Any change has to be made somewhere first. As the largest Wikimedia project, English Wikipedia seems as though it should be the leader and not the follower. This change also wouldn't have to change the behavior of anybody. If the change worked like the WP: to Wikipedia: merge, editors could continue using the User: prefix if they wished. I agree with what you say about using Wikipedia. I certainly use it more than I edit. This isn't saying you can't use the encylopedia... it just very subtly encourages people to edit more (maybe including those who are just registering an account to get a preferred layout). IronGargoyle (talk) 15:15, 4 January 2008 (UTC)

If it is of any interest, the Czech Wikipedia uses the namespace "Wikipedista" (I'm Wikipedista:Puchiko). We could use "Wikipedian", which appears to be the usual term. However, it is certainly a lot longer to type than "User", so going with "Editor" appears to be the best choice. Puchiko (Talk-email) 21:15, 4 January 2008 (UTC)

I don't like the idea of typing two extra keystrokes every time I want to go to someone's userpage. Sarsaparilla (talk) 04:40, 6 January 2008 (UTC)

You wouldn't have to. User: should still redirect there, just as you can type WP: instead of Wikipedia: IronGargoyle (talk) 21:10, 6 January 2008 (UTC)

I see no advantage of using the term "editor" over "user". They are both accurate, and "editor" may mislead someone who isn't familiar with the non-hierarchy Wiki-model. -Halo (talk) 00:27, 11 January 2008 (UTC)

How would it be misleading? I can see one making the argument that they are both fundamentally correct (although I think the semantic focus should be on editing), but I don't understand how it could be misleading. Best, IronGargoyle (talk) 17:35, 12 January 2008 (UTC)

When "Editor" is mentioned, I tend the associate it with "Editor-in-chief" (i.e. the head of the newspaper), so it could be inferred to imply seniority -Halo (talk) 19:11, 12 January 2008 (UTC)

That is a point, but if every user (sorry, Editor ;-) has the same prefix, it shouldn't be an issue. I don't know if it's a good idea, but it would give a sense of Editors > Users (people who only "use" Wikipedia, i.e. never edit). That said, the current namespace name is just fine. No sense changing everything, really. Since anyone who uses Wikipedia can also be an editor... why not just add Editor as an alias for NS_USER? Tuvok[^T@lk/_Improve] 22:05, 12 January 2008 (UTC)

I think that's what I'm suggesting. Just that "Editor:" be the primary alias (i.e. the one that displays at the top of the screen. "User:" would still work). Carnildo's example of the change from "fair use" to "non-free content" is a fairly good analogy. This is more about subtle but cumulative behavioral change via a subtle change in the environment. IronGargoyle (talk) 02:59, 13 January 2008 (UTC)

Editor sounds a lot better than user and I prefer editor, but it appears that "editor" is going to become a user group, see ([1])-- penubag  (talk) 22:23, 26 March 2008 (UTC)

I agree per the joke about only comptuer professionals and drug dealers having "users". Listing Port (talk) 21:24, 4 April 2008 (UTC)

Oppose I don't think this is necessary, and I agree with Pomte that contributors matter more than editors. Now, if you made it so that people who heavily contributed could become "Editors", that might make sense; but lots of WP users don't really do much. OptimistBen | talk - contribs 04:28, 21 April 2008 (UTC)

There's no clear consensus for this, and it should be archived. ImperfectlyInformed | {talk - contribs} 06:53, 13 May 2008 (UTC)

Support - "users" are really "editors", so that should be more noticable. It also sounds like it would be relatively easy to do (just like WP: redirecting to Wikipedia:) -- Imperator3733 (talk) 21:48, 13 May 2008 (UTC)

Support - I honestly think that it makes more sense, we are the editors of Wikipedia. Not the users, besides, its not that big a deal, you just change the namespace and redirect User: to Editor: (or you can even go as far as making a bot that changes User: to Editor:). And all those who oppose this idea can continue to use User: if they wish. Maybe only autocomfirmed Users use the Editor namespace (fixed the giant dormant account problem).  Atyndall93 | talk  09:51, 1 June 2008 (UTC)

[edit] Special:Unwatchedpages

Could few users take a look at User:Maximillion Pegasus/Unwatched? Thanks. Maximillion Pegasus (talk) 05:01, 19 February 2008 (UTC)

That's kind of what I was saying here: (See below)-- penubag  (talk) 05:04, 19 February 2008 (UTC)

considering that the category only lists the first 1000 pages in alphabetical order, which currently takes it only from (1952-19??) ‎(Watch) to 2007 Countrywide Classic, without getting into the pages beginning with alphabetic letters at all, i dont se e what use it is to anyone at present.DGG (talk) 05:10, 19 February 2008 (UTC)

Which was why I though my proposal was good. -- penubag  (talk) 05:15, 19 February 2008 (UTC)

True, but it is still useful. I believe your proposal would go great with one of mine. Maximillion Pegasus (talk) 05:19, 19 February 2008 (UTC)

No one else seems to like mine. -- penubag  (talk) 05:32, 19 February 2008 (UTC)

They're both good ideas, I think. As long as access is limited to trusted users, ie. rollbackers etc, I don't see why not, to both suggestions. I mean I don't think either of them will be implemented, as the proposals page is basically one big waste of time since the developers are so busy with unified login that no new good ideas have been implemented in a while, except for those that are the simplest to implement, and everything just ends up getting archived in the end. Not a criticism just a statement of truth. Perhaps we should start building a page of ideas that have merit and that come up often, so that they can be revisited once the developers have more time. Equazcion •✗/C • 08:57, 21 Feb 2008 (UTC)

I think that idea is pretty good, Equazcion, don't let it get archived ;) -- penubag  (talk) 04:20, 22 February 2008 (UTC)

Sorry it took so long for me to notice this response. Here's to keeping the section alive. Maybe I'll start a subpage or something soon for ongoing proposals, or maybe a separate Wikipedia: page. Equazcion •✗/C • 07:15, 26 Feb 2008 (UTC)

[edit] Highlight or put a mark to unwatched articles on RC

Many vandals edit Wikipedia but are quickly reverted by RC patrol and by watchlisters get the occasional edits that slip in, but what about edits that slip RC patrol and aren't watchlisted? Maybe these edits could be highlighted in yellow or red in the RC list like we have at special:newpages. I recently had to contact an expert pertaining to many anon edits to Template:Infobox copper. There was false information unnoticed for weeks, and who knows where this will happen again. I believe my simple proposal can help levy the problem -- penubag  (Talk) 17:36, 4 February 2008 (UTC)

I like the spirit of this idea, but it would have to be made so that it doesn't seem TOO obtrusive looking to the eye. Arnabdas (talk) 17:57, 4 February 2008 (UTC)

CSS maybe? -- SEWilco (talk) 02:28, 5 February 2008 (UTC)

I'm of mixed mind. 80% of the random low level trouble here comes from anon editors, but on the other hand isn't it against the spirit of anonymous editing to be looking over their shoulders all the time?Wikidemo (talk) 05:20, 5 February 2008 (UTC)

Anonymous editing means that the editor does not wish to disclose their identity, but watching over them closer seems like a fine compromise. -- penubag  (talk) 08:48, 5 February 2008 (UTC)

There is no way that articles that aren't watchlisted are going to identified to other than admins. And there is no way to tell which edits "slip RC patrol" and which in fact are reviewed by an RC patroller and evaluated as acceptable.

What would be possible is to do what another Wikipedia (Dutch language?) is doing - having patrolled edits for anonymous IP edits only. That reduces the percentage of edits that need to be marked as patrolled, and it focuses attention on edits most likely to be vandalism (something on the order of 1 in every 5). -- John Broughton (♫♫) 23:48, 5 February 2008 (UTC)

That's never good enough. Unwatched pages need more attention, even if we only allow admins to view highlighted watchlists. -- penubag  (talk) 02:30, 9 February 2008 (UTC)

I'm sure this edit would have been noticed if my proposal was in effect, rather than go unnoticed for 30minutes. -- penubag  (talk) 08:10, 13 February 2008 (UTC)

even if we only allow admins to view highlighted watchlists - but that misses the point; the problem is (a) "edits that slip RC patrol and ALSO (b) "aren't watchlisted". But, as noted above, there is no way to tell which edits "slip RC patrol" and which in fact are reviewed by an RC patroller and evaluated as acceptable. At least there is no way now - we'd have to go to marking edits as patrolled. And if you're proposing that we do so, you're probably not going to get a lot of support - as it is, new pages are being patrolled, and (as noted elsewhere) despite the much lesser volume, nowhere near 100% of new pages are marked as patrolled. If editors don't find marking of new pages to be worth their time, why would they be willing to do so with just plain edits.

And if we're going to try patrolled edits, it makes sense to start doing this (time-consuming) task by focusing on what has the highest payoff - IP edits are many times more likely to be vandalism than edits by registered editors. -- John Broughton (♫♫) 23:58, 22 March 2008 (UTC)

No, that's not what I'm trying to propose. I'm not proposing that unwatched pages be marked as patrolled, but just put a little mark next to the pages appearing in recent changes so they'll get a little extra attention. There's aboslutly no down fall to this addition and can greatly keep Wikipedia reliable. -- penubag  (talk) 00:08, 23 March 2008 (UTC)

This section starts with a statement about highlighted in yellow or red in the RC list like we have at special:newpages - but that highlighting is based on 'which new pages have been marked as patrolled. How can ALL edits be similarly handled (with highlighting) if patrolling is NOT used for all edits? (And how could you possibly read anything I wrote as saying that unwatched pages be marked as patrolled - who in the world would suggest that?

If you think there is some way that the software can know which "edits have slipped RC patrol", other than my marking edits as patrolled, please share that information. Otherwise, please explain why you think changing to a system where edits are formally marked as patrolled (as is the case now with new pages) is a good idea, and whether you think there will be enough editors participating to actually make this work. -- John Broughton (♫♫) 16:10, 23 March 2008 (UTC)

I'm sorry, there was a misunderstanding. When I said RC patrol, I didn't mean actual patrolling edits as in New pages, I ment it as vandalism slipping the RC patrollers monitors. So basically my proposal is to just mark the unwatched pages that appear in RC with a little mark or a yellow highlight (similar to the highlight in NP). Wow, what I wrote is a mess. -- penubag  (talk) 22:29, 23 March 2008 (UTC)

[edit] Edit conflicts

Currently, if an edit conflict occurs, users are taken to an edit conflict page where once they make their edit again, they must then save the entire page, even if they were originally only editing one section. This often results in further edit conflicts, especially on pages with many active sections, such as this one. I don't think it's technically necessary for it to work this way, and propose that the edit conflict page be changed so that the user only has to save the section they were editing again, rather than the entire page. I think this would make things easier for everyone by cutting down on multiple edit conflicts. It would also save some server load/bandwidth to not have to deal with whole-page uploads whenever an edit conflict occurs. Equazcion •✗/C • 00:21, 28 December 2007 (UTC)

Hear hear! The question is, would such a change be technically feasible? Waltham, The Duke of 00:58, 28 December 2007 (UTC)

I hope so. Good idea. - Rjd0060 (talk) 01:09, 28 December 2007 (UTC)

Yes, it most certainly is, at least as far as I can tell. The edit conflict page is just another edit page on Wikipedia, only it happens to open the entire page for editing, for some reason. When an edit conflict occurs, you could just ignore it and load the section-editing screen again manually -- but why not have the edit conflict window do this automatically? Equazcion •✗/C • 01:11, 28 December 2007 (UTC)

There's only one feasibility issue I can think of: If the edit conflict was caused by the removal of the section you were editing, and possibly even if another section were deleted further up the page. A classic entire-page edit conflict could be displayed for just those cases, though. Equazcion •✗/C • 01:30, 28 December 2007 (UTC)

I don't think it's technologically possible. The "edit conflict" page already only comes up when the server has tried and failed to merge your changes with the other editor's. --Carnildo (talk) 03:17, 28 December 2007 (UTC)

I don't see why that's a problem. The software knows which section you were trying to edit. There's no reason it needs to display the entire page when an edit conflict occurs. It could just show you that one section you were editing. Equazcion •✗/C • 03:22, 28 December 2007 (UTC)

It should only be a problem if the section was removed, renamed, or reordered (WM works on section numbers). If one of those things should occur the EC page should give a message 'EC + can not find section' and display the entire page. --Lemmey talk 13:48, 8 June 2008 (UTC)

What I've always done is as follows:

1. edit section X of a page
2. attempt to save my completed edit
3. the save fails due to edit conflict. I (hopefully) take note of this.
4. from the "Edit conflict" notification page, I back up one page in my browser's history, arriving back at the section-edit just before I attempted to save it.
5. I select the contents of the edit window and save it on the clipboard (click, ^A, ^C). I may or may not also paste it into a local text editor and save a copy in a local scratch file).
6. I check to see whether the edit conflict affected the section I was working on (let's say that it did not)
7. I redisplay the article and click to edit section X (again)
8. I replace the entire section with my clipboard-saved edit (click, ^A, Del, ^V). (the Delete action is superfluous, but makes it clearer what is happening)
9. re-enter the Edit Summary and redo the save attempt.

This sequence is more complicated to explain than it is to do. Incidentally, I did it on this edit, with the added complication that the conflict did involve this section. -- Boracay Bill (talk) 01:41, 28 December 2007 (UTC)

I often do something similar, but it's a lot of extra steps that I'm suggesting shouldn't be necessary. Also, most people probably don't know they can do that and use the edit conflict window instead, which causes the extra server load and bandwidth use of a lot of unnecessary whole-page uploads/saves. Individually these instances wouldn't cause much burden, but in total they could amount to a significant difference. Equazcion •✗/C • 01:50, 28 December 2007 (UTC)

All of this functionality is in a file called EditPage.php. If one were to achieve what is proposed here, some fixes, or potentially a rewrite of that page would be needed. 哦，是吗？(O-person) 03:26, 28 December 2007 (GMT)

I don't think "server load" is particularly important; my sense is that edit conflicts are relatively rare. But from a user viewpoint, there seems no reason to present an editor with an entire page to edit if the editor was trying to edit only a section, assuming that the section still exists. -- John Broughton (♫♫) 13:45, 28 December 2007 (UTC)

I'm not allowing this to get archived. This is happening. Equazcion •✗/C • 04:17, 29 December 2007 (UTC) 04:17, 29 December 2007 (UTC)

Is there a bugzilla posting on this? -- John Broughton (♫♫) 16:01, 30 December 2007 (UTC)

I agree with John Broughton. In fact, the claim that the server tries to merge the changes is is completely false (not that whoever said it was lying, it's just not true). Looking back at most of my edit conflicts, the server doesn't even attempt to include edits to two completely different sections for some reason, which infuriates me every time. I understand a conflict on the same section, but is it necessary to display the whole page just to edit one tiny section? This whole system really does need looking into. .:Alex:. 17:26, 30 December 2007 (UTC)

That's true that it doesn't try to merge edits to the same section, but I always thought that when they say "merge" that this meant it tried to merge only as long as the edits were to different sections. If "merge" actually means that edits to the same section are supposed to get merged, this does not seem to be happening, and I mean ever. Equazcion •✗/C • 06:54, 31 Dec 2007 (UTC)

No, there is no bugzilla posting for this. I would do it myself but I'm not so familiar with bugzilla, and I also would like to get a more solid consensus going here... while no one seems to be against the idea, not too many people are commenting. Equazcion •✗/C • 07:00, 31 Dec 2007 (UTC)

Bumpity... Equazcion •✗/C • 17:06, 3 Jan 2008 (UTC) 17:06, 3 January 2008 (UTC)

If you write user specifications of what the software does now, what you want it to do, and why, I'll submit the Bugzilla. I suggest a subpage in your (or my) userspace as it makes a no-archived place to hold a discussion. MBisanz ^talk 17:46, 3 January 2008 (UTC)

←Okay, I'll get started on that. Lets call it User:Equazcion/Edit conflict bug. All feedback appreciated, as I don't have any experience writing bugzilla reports. Equazcion •✗/C • 22:37, 5 Jan 2008 (UTC)

As it turns out, a Bugzilla entry already exists for this, created by AzaToth in January of 2006. There's been no activity other than the original posting. I'd like to ask anyone who has a Bugzilla account to please vote for this one: http://bugzilla.wikimedia.org/show_bug.cgi?id=4745. Thanks. Equazcion •✗/C • 11:20, 7 Jan 2008 (UTC)

I asked users to vote for this over at WT:Help desk#Help desk regulars: please vote for bug fix. got a few to join but we need more. PLease go vote.--Fuhghettaboutit (talk) 05:40, 26 April 2008 (UTC)

I feel that this is a very serious issue and needs to be addressed asap. I'm not sure if it was some of the scripts I installed into my monobook, but whenever there is an edit conflict, I lose everything I was just writing. Even pressing on 'back' on my web browser does not bring back what I typed. This is extremely annoying and really gets on my nerves. The edit conflict message should at least show you what you wrote. -- penubag  (talk) 04:54, 15 May 2008 (UTC)

[edit] Create a new ref tag called <note>

Sometimes you use the <ref> tag for notes (ie a bit more information) instead of for a reference, and i have seen articles which use the old {{note}} template to create a separate list of notes as well as of references. It should be very easy for the mw:Extension:Cite/Cite.php extensions to add <note> and <notes /> as two new hooks which work in exactly the same way as <ref> and <references /> do.

This would enable an article to maintain two lists (one of notes and one of references) as now it is either lumped together in one list, or needs to use old templating systems. For example: International Whaling Commission uses just the ref tags but some of the tags are for notes (eg number 6), so could have two lists instead.

Also, would it not be possible (maybe with a bit more work) to be able to have multiple lists of each. Ie you could have <ref1>, <ref2>, <ref3> which corresponds to <references1 />, <references2 />, <references3> which would be handy for articles such as List of Governors of Alabama which has a list below a table, and then one at the end of the article; or United Kingdom (and like many of country articles) has some notes in the infobox as well as a References section at the end of the article.

(I also raised this question at the technical village pump.) Chris_huh^talk 15:01, 28 December 2007 (UTC)

This is often discussed at WT:FOOT. Incidentally, if there is a Bugzilla request for this feature perhaps it should be listed in the Related section of WP:FOOT. -- SEWilco (talk) 15:25, 28 December 2007 (UTC)

I think those are both excellent ideas, the notes and the separated lists of refs (and maybe even separated lists of notes, like <notes1><notes2>). I hope it gets implemented. Equazcion •✗/C • 23:58, 28 December 2007 (UTC)

Having a section attribute would be a good way to implement this. Example usage:

<ref section="notes">hello i am a note</ref> and <ref>i'm
just a regular (default) ref</ref>

== Notes ==
<references section="notes" />

== References ==
<references />

And then maybe make it configurable to allow wikis to use their own shortcuts. We could use <note> could be a shortcut for <ref section="notes">, etc. --- RockMFR 07:12, 29 December 2007 (UTC)

See Bug 11899.--Pharos (talk) 03:33, 30 December 2007 (UTC)

While it's a little clunkier (as it is not autonumbered), the {{ref label}} and {{note label}} are available for footnotes using any style: a-b-c, i-ii-iii, A-B-C, or even full words. Despite the fact that it doesn't autonumber, since the article/table shouldn't be peppered with all sorts of note jumps, it doesn't make it too hard to manage. It works quite well for me in 2007 New York Giants season, where two tables have their own set of footnotes.—Twigboy (talk) 05:19, 30 December 2007 (UTC)

• The problem might be solved more elegantly/generically (and without more html tags) by categorizing refs with a pseudo-"class type". For example, one would have...

<ref class="n">... something in class "n" (e.g. a note)... </ref>

<ref class="x">... something in class "x" (e.g. some other category of ref)... </ref>

<ref>... something without a class (e.g. a regular citation)... </ref>

The balancing <references /> would look like this:

<references class="n" /> to dump all <ref>s with class="n".

<references class="x" /> to dump all <ref>s with class="x".

<references /> to dump all <ref>s with no class.

This way, a page could have as many "notes" (or whatever) sections as necessary. For example, examples on a wiki help page.

Another option is to give <references/> a regex filter function:

<references name="n*" /> dumps all refs whose name= starts with 'n'

<references name="x*" /> dumps all refs whose name= starts with 'x'

<references name="[^nx]*" /> dumps the rest

This is however not suitable For refs that need different numbering schemes (e.g. notes vs citations).

• One way to resolve the autonumbering problem would be to use an alpha prefix for the numbering, perhaps even using the first letter of the class name (or restricting the length of the class name to 1). Another way would be to give each group N numbers (e.g. 1000), so the default would be 1-999, the next 1001-1999 and so on.
• The problem with using any autonumbering format except numbers and a-b-c is that Citephp depends on ordered lists (<ol> tag). Thus, while prefix + number (e.g. 'n1') would be the most flexible way to solve the autonumbering problem, it would require Citephp to emit CSS magic to simulate a numbered <ol>. It would still be ol (with list-style-type:none & hanging indent formatting), but the li's would need to provide numbering. Tables are another option.

-- Fullstop (talk) 22:27, 30 December 2007 (UTC)

I really like your idea. Definitely something that should be considered if you ask me. --TheDJ (talk • contribs) 14:49, 1 January 2008 (UTC)

Well it seems to be getting some support, it does seem to be discussed a bit at WP:FOOT, but nothing was done about it.

I have also thought of something else for the referencing system which may be useful. Sometimes an article may have multiple references to one book, each one being a different page. At the moment most of the time the book is referenced in one ref tag and then each time a different page from that book is used just the page is referenced (eg The Book. Pages 112-113.) How about having another parameter (like the name one) which allows you to group references together. Eg: <ref group="TheBook">Body, Some. ''The Book'' (1958). HarperCollins: London. 2nd Edition.</ref> as the main reference, then sub-references like this: <ref sub="TheBook">Pages 112-113</ref>.

Then this would format in the reference list at the end with the sub-references indented below the main references. Also the sub-references may have to have numbers such as 1ii as otherwise it might start to look odd with some numbers appearing in a wrong order in the reference list. Eg:

Chris_huh^talk 00:11, 2 January 2008 (UTC)

I once had a similar idea (using a loc= option in the <ref> itself), and even tried to simulate it with ref_label/note_label. But I was rather disappointed with the results. Its ok when you have only a handful of sources, but looks terrible when there are ~90 sources (~120 refs) as my one testbed had. The majority of the sources are only referred to once.

I finally settled with {{harvnb}}, which is much clearer when done consistently. Examples: 1 2 3. Note that all three also have separate 'Notes' and 'References' sections. Click on the ref #, it'll jump to the reference, click on the reference, and it'll jump to the citation.

-- Fullstop (talk) 04:13, 3 January 2008 (UTC)

There's an older Bugzilla request, submitted by me; someone should combine the two, I do not know how: Bug 5265 --Golbez (talk) 04:21, 3 January 2008 (UTC)

For multiple references to one book, you can use {{rp}}, which places the book's page next to the footnote number in the text.--Fuhghettaboutit (talk) 04:33, 3 January 2008 (UTC)

I think this was discussed on email lists, and I believe even a consensus that there should be reference groups, and <notes/> should behave like <references group=notes/>. It's definitely a known issue, I guess nobody's gotten around to doing anything about it. -Steve Sanbeg (talk) 00:08, 4 January 2008 (UTC)

So would can be done about this? Should i ask the developer of the Cite extension to have a look at it? Chris_huh^talk 00:59, 11 January 2008 (UTC)

See Bug #6271 Allow multiple classes of footnotes on the same page.

But it certainly would not hurt if the developer (User:Ævar Arnfjörð Bjarmason) could take a look at it. He might have an idea (or see a problem) that no one has thought of yet. -- Fullstop (talk) 03:43, 11 January 2008 (UTC)

Support I like the original idea; it's rather simple and intuitive, we don't have to mess around with attributes or anything. As far as citing other pages, that's one reason why I like author-date referencing. However, it's a bit clunky when you're just citing something once. That's why I don't think a combination is a bad thing. If we could get the extra functionality of citing different pages added to footnotes, however, that'd be nice. OptimistBen | talk - contribs 04:32, 21 April 2008 (UTC)

[edit] Multiple watchlists

For organizational purposes, it would be nice to be able to maintain more than one watchlist. I've been cleaning up my watchlist every couple months but I usually end up deleting things I actually want to keep, just to get the list cut down to a more manageable size. I'm tempted to maintain an external text file or something so I can move chunks of listings in and out of the raw watchlist editor depending on what I want to look at, but would it really be so difficult for the wiki have that kind of functionality already built-in? I can't see it being an additional resource hog. Equazcion •✗/C • 15:23, 12 Mar 2008 (UTC)

See m:Help:Watching pages#Related changes feature for "additional watchlists". Although they do have some drawbacks: such a list is not private, you have to explicitly put links to talk pages, there are less options to filter the changes. —AlexSm 15:30, 12 March 2008 (UTC)

Thanks, that is helpful. However, still, I think multiple watchlists for each user is a good idea. It would offer a lot of convenience and benefit for very little performance cost, if any at all. Equazcion •✗/C • 15:38, 12 Mar 2008 (UTC)

I was going to propose something like this! I suggest that each item on a watchlist have a "flag" or parameter which could be a bit, an integer or a short piece of text which the user associates with the item.

Suppose you're going to be really busy for a few weeks. Then you want only the few articles most important to you to show on your watchlist during that time. But then afterwards, when you have some time and want to see what's happening in the general areas you're interested in, currently you have to start from scratch rebuilding your watchlist. Under my proposal, you'd only have to click one setting, "show all items" or "show all items with priority level of 5 or fewer" etc. If it's a text parameter, you could click "show all items that I've tagged with "medicine" etc. depending on what your interests are at the moment. You could also label things as "watchlisted during RC patrol" or "watchlisted when I posted a message there" so you'd know why the heck things are on your watchlist. It might also be useful if the date the item was placed on your watchlist could be (optionally) displayed. --Coppertwig (talk) 01:23, 14 March 2008 (UTC)

Yeah, similar solution, probably even better since you'd be able to see all "watchlists" at once if you chose to, but also be able to filter based on user-defined tags. I actually like that better. Equazcion •✗/C • 01:28, 14 Mar 2008 (UTC)

I like that, too. However, I think I ought to mention an already existing tool: the ability to monitor changes in all the pages that link to a specific page. John Carter gave me the idea, and applied it on SBS's Templates page; all changes made on pages linked to from that page can be seen in a list accessible from a box in SBS's main page. I can tell you, it helped me clear my watchlist a long way. One can create a subpage in one's userspace with all the pages one is interested in watching; one may categorise its contents as one wishes (with headings and sections) and has the ability to hide links (or, indeed, entire groups of links) whenever one wishes by turning them into HTML comments. This tool, which I have only recently learnt about, has many potentials in my opinion. Waltham, The Duke of 20:33, 14 March 2008 (UTC)

Yeah that's the related changes feature, see the first response to the original post above. It's a good temporary solution but the watchlist is so much more functional, easier to use and read. I think it should be expanded to include this functionality. Equazcion •✗/C • 12:30, 16 Mar 2008 (UTC)

I guess I missed that. Yes, I quite agree, it is a good provisional solution, but it definitely won't cover all of our needs. Waltham, The Duke of 17:50, 20 March 2008 (UTC)

I really like this idea. I have articles on my watchlist that I'm actively editing, but others that I just want to monitor because they've been subject to vandalism before. To have different watchlists for the different reasons you watch an article just makes sense. But in lieu of multiple watchlists, I like Coppertwig's tags idea. Elle (talk) 00:00, 25 March 2008 (UTC)

Add me to the list of people who would find this really useful.Doug Weller (talk) 13:46, 31 March 2008 (UTC)

I've been wanting something like this for a while and am glad that others do too. I like the tagged watchlist idea best. Maybe there could be an expandable list of all the different tags that you have with checkboxes between the namespace selector (has that always been there? I just noticed it now) and the most recent changes. We would have to figure out an interface for adding tags, but that should be relatively simple. -- Imperator3733 (talk) 21:52, 19 May 2008 (UTC)

I too would very much like to have them. I would like to be able to separate a/the articles I take a personal interest in as an editor or potential editor, such as my high school, because they deal with things of central interest to me, from b/the articles with problems where I have left talk page messages or otherwise want to make sure the problems are addressed, c/the articles I have tagged for deletion or deleted & want to check that they are not reconstructed, or the articles I have rescued to check if someone nonetheless marks them for deletion, and d/the general pages where I follow discussions on policy or XfDs or clean up & administrative tasks. Of course there are multiple ways around this. Besides related changes, if there are pages I know I want to go to regularly I can simply have a list of links--or keep a list of links on an external document or use bookmarks. If there are pages I want to check whether or not they get deleted I can keep a list of them, and see whether they are red or blue. None of these are as satisfactory as multiple watchlists. I have seen a few editors using a declared additional account for this purpose, but if I did this, I would have to go back to my own account to edit them. I see no reason why it would be impossible to implement multiple watchlists. DGG (talk) 14:15, 22 April 2008 (UTC)

This may or may not relate to this but how about something like this?. I still wanted to add another feature, which probably would be of greater interest to you but if there's too many changes, the whole thing will never pass. The feature would be to have a clean up button next to each change in your watchlist which when clicked, deletes the entry in your watchlist until another change is made to it. That way your watchlists is always clean. -- penubag  (talk) 02:51, 24 April 2008 (UTC)

[edit] History Options

The Recent Changes list allows you to hide minor edits and bot edits. This should be available on all history pages. If you're really trying to track how the content of the page has changed, minor/bot edits can just clutter up the whole process. Those edits would still be shown in diffs, obviously. --Cryptic C62 · Talk 21:57, 30 April 2008 (UTC)

It would also be great if we could see all of a particular user's contributions to an article in one place.--Pharos (talk) 23:26, 30 April 2008 (UTC)

And then it would be nice to list the edits by size, both for the entire article and each particular user. Since WP does track the changes in kilobytes, this seems quite feasible. ImperfectlyInformed | {talk - contribs} 23:36, 30 April 2008 (UTC)

It would also be great if we could see all of a particular user's contributions to an article in one place.--Pharos (talk) 23:26, 30 April 2008 (UTC)

Another useful option would be the ability to search past versions of an article for a string literal. I quite often come across articles with orphan named refs (e.g., <Ref name="some name" />) where the parent containing the Ref body has been deleted, usually in the middle of a deleted block or text. Searching for the past edit where the deletion was made is tedious. (Perhaps there's an easy way to do this and I'm not aware of it?) -- Boracay Bill (talk) 23:42, 30 April 2008 (UTC)

What about some form of grouping a vandal edit with the edit that reverts it? Like if you hit the (undo) button, it will draw a faint red box around your edit and the one you're undoing. --Cryptic C62 · Talk 00:12, 1 May 2008 (UTC)

Not disagreeing with the above, but my personal list includes the option to hide all edits that have been reverted, along with the reverting edits, leaving only edits (and editors) who truly changed a page. Software-wise, that would be fairly easy to do, if each version had a hash value (and images already do have has values, for the purpose of identifying duplicates). [Boracay Bill - check the "History (of pages)" topic in the editor's index - you'll find (in the "Tools" subtopic) two things that will do what you want.] -- John Broughton (♫♫) 03:05, 1 May 2008 (UTC)

But that won't work when there was intervening edits between the vandalism though, which isn't uncommon. Or when the editor/reverter made other edits at the same time. Nil Einne (talk) 04:22, 1 May 2008 (UTC)

True, but perhaps another message could be displayed upon undoing an edit: "For the purposes of tracking article activity, please do not edit this article while also undoing an edit." Or something like that. --Cryptic C62 · Talk 10:32, 1 May 2008 (UTC)

The wishlist so far:

• Hide minor edits
• Hide bot edits
• Hide reverted / reverting edits
• Group reverted / reverting edits
• Sort edits by contributor
• Sort edits by size
• Search all previous versions

I can see a use for sorting Special:Contributions by page title, but hiding and rearranging edits in the page history may have a lot of complications. When you do a diff using the "(last)" link, would it diff to the previous revision or the last revision that you can see? If you sort the edits in any way except chronological order the diff links really wouldn't work at all. Mr.Z-man 19:57, 3 May 2008 (UTC)

Then perhaps chronological would always be the secondary sorting option. If you sort by author, within each author's section, it will be sorted by time. I don't really see the harm or complication in hiding minor / bot / reverted edits. --Cryptic C62 · Talk 15:52, 4 May 2008 (UTC)

It doesn't seem like the diff links should be trouble. Maybe they will be, but it shouldn't be that difficult to have the diff link automatically reference to the edited version of the page rather than simply the previous version in the list. If the diff does the former, it's a problem of design which could (and I believe should) be rectified. Sorting a particular user's edits by size would be extremely useful, although the transparency might be frightening for some. ImperfectlyInformed | {talk - contribs} 00:03, 5 May 2008 (UTC)

The problem with hiding edits, is that when you do a diff, its going to be including edits that you can't see in the history view. When you rearrange them, the (cur) and (last) links could still work as intentioned, but the radio button based diffs wouldn't work at all. Mr.Z-man 01:37, 7 May 2008 (UTC)

What if when the history is sorted in any way other than chronologically, the radio button diffs are disabled? There would have to be some explanation as to why they are disabled, but it would solve the problem. -- Imperator3733 (talk) 21:57, 19 May 2008 (UTC)

Even if hiding edits does end up being too complicated to implement, here's an idea that's not: In addition to displaying edits in groups of 50 - 500, we should be able to display all revisions in the previous day / 3 day / 7 days, etc. just like on the Watchlist. This would be really helpful for pages with a lot of traffic, such as WP:AIV. --Cryptic C62 · Talk 01:32, 7 May 2008 (UTC)

Moved this discussion from the archive into persistent as it demonstrated clear consensus. These changes would be enormously helpful. Impin | {talk - contribs} 09:46, 16 May 2008 (UTC)

Probably the best way forward is for the default to be the present one--that way any of the defects of the other displays, as mentioned above, and the dozens which will undoubtedly appear also, would not be fatal--we would be losing nothing but gaining options useful in some circumstances. DGG (talk) 16:13, 17 May 2008 (UTC)

Is there really a problem with sorting history pages differently than by date? When people look at the difference, they should be looking at the difference between that version and its prior version. I guess I'm not understanding what the big deal is. There's only one version. Impin | {talk - contribs} 02:07, 20 May 2008 (UTC)

in trying to sort out contentions over articles, it is very useful to sort out the contributions of the different editors. This is one of the first things to look at. Although it can be done in principle from the individual contribution lists, it can be difficult here too unless unless there are single purpose accounts involved,DGG (talk) 00:17, 11 June 2008 (UTC)

So you're advocating that we be able to list, say, contributions from DGG and ImpIn on this page? ImpIn | (t - c) 02:19, 12 June 2008 (UTC)

DGG: The reason I would like to be able to sort diffs other than by date is so that they can be sorted by size. The most major changes listed first. This would be a great improvement in helping to identify possibly harmful, or greatly beneficial changes made. I don't see why this is not possible, as every diff should be linked to its prior version, not simply the preceding version by date. ImpIn | (t - c) 00:59, 11 June 2008 (UTC)

yes, that's a good reason too--sorry if I implied my reason was the only one, or that the sort i suggested was the only one that should be implemented. DGG (talk) 03:15, 11 June 2008 (UTC)