This page is kept for historical interest. Its content is outdated or may be wrong. You may find more up-to-date information at on the www.mediawiki.org website.

Bugs, issues, and feature requests for MediaWiki should always be reported at Bugzilla to make sure they aren't lost or forgotten.

Please do not add any further Nothing on this page is likely to be seen, read, or acted upon by the developers. Please report bugs and feature requests, and post patches, at http://bugzilla.wikimedia.org/

Anything below this line should ultimately be refactored into a bug report, enhancement request, or better yet a patch and put on http://bugzilla.wikimedia.org/

If you use Bugzilla to report one of the issues mentioned below, please remove it from this page.

The MediaWiki developers and users use a customised version of Bugzilla called MediaZilla to track bugs and feature requests. However, MediaZilla is a tool for software developers, not a discussion forum.

Bug reports should be made immediately on the bug tracker at MediaZilla, particularly any involving database errors. The developers will be notified of the report by e-mail and can directly track and prioritize bugs there.

For bug reports, please make sure you describe your operating system, which browser you use, and your user settings such as skin and quickbar options. If your problem is visual, attaching a screen shot is a good idea.

Use this page to discuss possible new features. Feature requests which are uncontroversial can be listed at MediaZilla immediately, however controversial feature requests should only be submitted after a consensus has been reached.

See also MediaWiki development and MediaWiki roadmap for a list of detailed feature proposals.

If you are about to make a comment on the new release, please use MediaWiki 1.3 comments and bug reports instead. If you are reporting bugs with, or have comments about, the Article validation feature, please go to Article validation feature.

Post a comment

Archived discussions

MediaWiki feature requests and bug reports/Archive

Other pages in meta containing feature requests

Toc hide option hack

The following were moved from List of feature requests which now redirects here.

Feature requests

Unsorted

Protection against slowloris

I would like a possibility for protection against slowloris on apache2. What I want is a separate mediawiki direcotry tailored for file uploads, then I can protect file uploads by only allowing it for registered users. Unregistered users will not reach the upload subdirectory. In apache conf I would have the following code

<DocumentRoot /home/web/htdocs>
   LimitRequestBody = 8192 #(or some other small value)
</DocumentRoot>
<DirectoryMatch /home/web/htdocs/my-wikimedia-site/the-upload-path>
   LimitRequestBody = 4194304 # for 4MByte
</DirectoryMatch>

Thus I would be protected against slow lowris for all my site except the wikimedia upload subdirector, which only would be reachable for registered users.

WikiLearn or WikiQuiz

I already posted this request in the German feature request page and was told to place it here as well. My idea is to create something like your personal learning file which could be named WikiLearn or WikiQuiz. I would want to work it like this: for every article in Wiki* the authors also create questions (like "When was William Shakespeare born?") and connect them with the right answers. If a user comes across a question he would like to add to his active knowldge he could just click a link "Add question to my personal question folder" and it would be added to his question list. After some time complete question lists for various topics could be created (like "Basics of English literature") and could be shared among the users. And, of course, the users should be able to learn these questions in a small applet which asks questions, corrects your answers and keeps track of your learning progress (questions you couldn't answer should be asked more often than those you already knew). I would like to hear some comments about this idea. Maybe I'm posting this idea on the wrong site again? I hope something like that could be implemented. --Carcassi 09:05, 23 Feb 2005 (UTC)

Page export for offline reading

A feature that is realy useful is the abilty to export a page directly from the wiki to a file for offline reading in PDF format for example. I think it's not so hard to do using PHP's PDF module. Another thing a little bit more difficult is to allow to export all articles of the same categorie to the same file for offline reading.

Site export for Offline reading

As an extension to the above the ability to export the entire site as HTML or PDF would be very useful to allow for information to be available where network connection is not possible. This would be particularly useful in the event of a disaster where the main wiki is down - particularly if this wiki holds your DR information!

Searching for wanted pages by category

I believe that most Wikipedians who write new articles focus on writing articles in a certain speciality area of their own (e.g. Biology, Mathematics). When looking for new articles to write, I believe that Wikipedians often find themselves looking through random pages. However, this is inefficient as most pages found would not be within their topic area. Looking through the list of wanted pages is not much better, as there are lots of wanted pages too. What I suggest is that there be a search for wanted pages by category.

Because non-existent pages have no category, I suggest categorising them based on the category of pages which link to them. If multiple categories link to them, then place them under mulitple categories. 202.156.2.91 08:57, 24 Nov 2004 (UTC)

Automatic datepage generation ála category pages

i've been categorising alot of people on the no.wiki, and i saw that just a small number of the persons where added to the corresponding datepage (even less where added to the yearpage). I belive that the date/year pages can be a really nice way to browse the wikipedia and see new articles that you wouldn't have even though of reading before. I suggest that there should be a [[category]] alike markup that could do the same job, the difference being that it updates the date and year pages. my suggestions for markup is this [[Born:Year:Date|a short description of the person, forexample "american actor"]] And the same goes for a [[Dead:Year:Date]] Another potensial tag could be the [[event:Year:Date]] that would automaticaly update the historical events on the page. This would greatly decrease the need for manual labour on the datepage, and ensure that the links in the datepage accualy all link to people, instead of just red links. It's shortcomming is that alot of people would forget to put up the tag, thus reducing the date/yearpage, but i belive that in true wikispirt the most important names would get thru.

Profoss 03:41, 12 Jun 2004 (UTC)

Redlinks however show us what still needs to be done, which is just as important as what is already there. I wouldn't be so quick to get rid of them all. T.P.K. 16:40, 4 Oct 2004 (UTC)

Inline Music Notation Markup

I find one of the nicest features of MediaWiki is the inline TeX processing. It would be extremely useful to have a similar service for generating musical notation. Music notation markups are pretty scattered right now, but w:GUIDO or w:LilyPond would maybe be workable? I know it's a big project, but something to think about for the future definitely. I wonder if we could contact the GUIDO developers and ask to use the source code they use for converting GUIDO code directly into GIFs and MIDIs ala the GUIDO noteserver (http://www.noteserver.org/). Imagine how great it would be to have easy, text-editable markup for generating music score and accompanying MIDI built into MediaWiki... --w:User:Chinasaur 128.218.169.187 08:01, 3 Jun 2004 (UTC)

Take a look at Music_markup for some discussion on this. - Tobin Richard 03:46, 12 Jun 2004 (UTC)

Collapsable TOC

For articles with a lot of subsections, the TOC can get unweildy. It would be nice if it was possible to collapse sections in the TOC, perhaps with a little linkified " " sign for "expanded" and a "-" for "collased" (like how many GUIs do it), and maybe "collapse all/expand all" linksat the top or bottom. Whether TOCs default to collapsed or expanded could be a user preference--maybe a threshold based on number of subsections, or a customizable default level of collapsing (e.g. subsections more than 2 levels deep are automatically collapsed). - Gwalla 21:39, 31 May 2004 (UTC)[reply]

Page protection improvements

Protected pages could have a list of exceptions that are allowed to edit the article. This would allow users whose user pages are constantly vandalized to make edits, while still protecting from vandals.

The exact opposite could also be done. Pages would be protected from a list of users involved in an edit war, while allowing the community at large to continue making useful edits. It is somewhat anti-wiki to allow two people to prevent an entire article, often a large and popular one such as w:George W. Bush, from being changed by everyone. Guanaco 22:26, 28 May 2004 (UTC)[reply]

As another alternative, how about a middle layer of protection that protects from edits by anonymous users and users with fewer than X posts / fewer than Y days... --Ssd 15:09, 20 Jun 2004 (UTC)

I second this last suggestion. It would be useful to be able to block anons and/or newbies, in general or from a given address range, from editing a specific page or from doing specific actions. See e.g. User:B-Movie Bandit. Gadykozma 1 Oct 2004 (UTC)

I would like to suggest a new feature for Wikipedia: display the start of the linked article as a tooltip when the mouse lingers over a link. Currently, only the title is displayed, using the TITLE property of the LINK tag.

Quite often I read an article about an unfamiliar subject that contains many unfamiliar terms. My main purpose is to understand the main article, but I need an idea of what those terms mean. For example, when reading the article Mycenae, it is helpful to know that Argos is a "city in Greece in Peloponnese", and that the Persian Wars "started about 500 BC and lasted until 448 BC".

It is inconvenient to have to follow each link to an article about each unfamiliar term, because the extra operations of clicking on the link and going back to the original page are required, and because of the delay of loading the pages. It interrupts the reading of the main article. It would be alleviated if the first 100 or so characters were shown as a tooltip.

For an implementation of this idea, see for example http://encyclopedia.thefreedictionary.com/Mycenae. The page itself is a bit cluttered, but I'm just talking about the tooltips on the links. TheFreeDictionary has implemented them using Javascript, but a similar thing can be done using the LINK tag's TITLE property.

Pgan002 08:05, 19 May 2004 (UTC)[reply]

Workaround: get a browser that deals with tabbed browsing, such as Mozilla Firebird, or if you're on a Mac, Safari. Dysprosia 08:12, 19 May 2004 (UTC)[reply]

I second this suggestion, at least as a "wishlist" feature. Even with a tabbed browser (which I do use heavily for this purpose), this would be a great aid to reading; switching between tabs is still more awkward than a transient mouseover popup, and on a slow internet connection (or a slow wiki-day) auxillary pages can take a while to download. There'd presumably be a painful performance hit, though, for the server? — Matt 08:34, 19 May 2004 (UTC)[reply]

Workaround, even in a non-tabbed browser: right click & open in new window. Spares you the reload time for "back" button. -- Jmabel 18:31, 19 May 2004 (UTC)[reply]

Just to give a technical slant on this issue: Firstly, the tag in question isn't <link>, it's <a>; a slightly pedantic point, but <link> is for something else - it's how you link in stylesheets and favicons, for instance. Secondly, there is a major limitation with implementing this feature using title attributes: not all browsers have multiline tooltips; for instance Mozilla, and I guess any other XUL-based systems, will only show a limited amount of the caption, as much as it can fit in a medium-sized one-line box. So to make the feature useful, we would probably have to do something crazy with JavaScript, like TheFreeDictionary do.

Now, the reason I say "something crazy", is that I'm not quite sure how this would have to interact with the database. Our mirrors have an advantage over us here, in that they don't have to deal with the information constantly changing - they can be really aggressive with their caching, whereas we have to make sure changes get reflected ASAP. Looking at the source, it seems that TheFreeDictionary actually merges in the text for the tooltips as part of the page that gets sent - so before being sent, each article has to be generated from not only itself, but all those it links to (and you will generally end up downloading a load of text that you never see). An alternative would be to have the JavaScript fetch the data somehow when you point at the word - saving on server costs and initial download, but meaning you get almost as much delay as opening the link anyway (esp. if you use a new window/tab/whatever, as people have suggested).

I'm not saying this is a bad idea per se, just that implementation-wise, there are a few things that would have to be worked out. It would certainly be useful, but it wouldn't be easy. - IMSoP 14:54, 20 May 2004 (UTC)[reply]

Tooltips would be even better if there is the possibility to include a small one-line description of an article. This description could even be used in many special pages. I'm thinking of something like [[Description:This is a one-line description of the Article]]. --de:Benutzer:Tali

See here Navigation popups

Graphs and diagrams

Would it be very difficult to have Wikipedia take raw numbers and make a nice graph or diagram out of them in the form of a PNG image? This so people won't have to upload images when they want to make a tweak.

I'm not sure whether generating graphs on the fly is a good idea, given the fact the server is even now incomprehensibly slow. In the future, when all browsers will support SVG or an equivalent format, this will be easier. (SVG to PNG conversion has been discussed before, by the way.) At the moment, the (sensible) guidelines for SVG are that both the source SVG and the editor-generated PNG image should be stored on Wikipedia, with the PNG image page containing a link to the SVG source. Thus, if the image need be updated, one can simply download the source, update at will, regenerate PNG and upload it. The only thing I deem problematic with this is that if SVG files are uploaded as .svg, changes in them are not tracked, which they should be. Possibly a better solution is to copy the SVG into the image page, thus allowing proper tracking. An alternative is the format created by en:User:Erik Zachte, EasyTimeline, which is specifically designed for graph generation. Once again, I gather the idea is to store both source and PNG online, for reasons detailed above. -- Itai 14:03, 18 May 2004 (UTC)[reply]

Alternative construction of Red links

The value and utility of red links as they are currently constructed and defined in Wikiworld is severely limited, and as a result the use of red links is discouraged and the meaning of red links has recently been relegated to a redirect to Wikipedia:How to start a page

There would appear to be value in exploring a new construction of red links so that a wiki link to an as-yet undefined page would translate to a link to a Wiki search page for the word of phrase so linked. At present, it is possible to create an improvised version of such a page link, however the result is a green link / external link, and its meaning does not become self-correcting once an entry has been created for the new page in question. See - see Information Habitat/Red links for more details on this approach. Information Ecologist 18:23, 3 May 2004 (UTC)[reply]

Links to jump to specific lines in diffs

I'd like to have the "Line X:" part of diffs be a link to the corresponding place in the page. Would this be hard technically? --Spikey 05:49, 16 Mar 2004 (UTC)

I support this :) When trying to see new replies e.g. here, I usually use the diff. But if I later want to reply, I have to scroll through all that enormous TOC to find a way of clicking me to a place in the vicinity of the interesting reply... \Mike 21:24, 2005 Feb 1 (UTC)

Chinese Wikipedia— pages as traditional and simplified characters

Our Chinese Wikipedia site now want to adjust the program to save two version's of article, which includes Traditional Chinese and Simplified Chinese, at the same time after submitting. We got stuck when we edit the EditPage.php because of it's complication, the large amount of using PHP class. We can ofter the class using for translate Chinese.And can you help us? Thank you. from User:Dowba--Shizhao 01:08, 8 Mar 2004 (UTC)

Does the text need to differ between trad and simple, or is there a 1:1 mapping between the two character sets? MrJones 19:24, 2 May 2004 (UTC)[reply]

Nope. The mapping is many to many, and depends on usage and context. - Anon

Semantic Web features or a Web Service

Though the linking and categorization of wikipedia is quite mature there are still informations that are hard to retrieve. I think it would be useful to have an interface for web agents/tools/websites to access wikipedia's database. To allow for a machine to find relevant articles they should be associated with semantic informations. This would require a web service, a query language, an enhanced data format for the pages and tools to add semantic information manually or automatically.

Structured/Templated Types of WikiPages

Although the markup in Mediawiki is extremely flexable, mature, and robust, there is a flaw in everything's inherit text-based existence. A more well structured system of templates, used for templating entire articles, would be a fantastic addition. This could be used to track common fields of information across similar articles (such as the ISBNs of all the books with articles here). These templated article types could inherit the fields defined by other types, aide greatly in the structurizing of the wikipedia, and do wonders for its integration with third-party software using the SQL access. Additionally, these improvements should reflect in the editing of pages. Bringing back the example of books and ISBNs, editing an article of the Book template type, would present not only a large text field for the article text, but also a seperate, one-line text field for editing the ISBN. For many types of articles, this could do a lot to make it easier to work with and create articles.

Feature request: ability to hide spoilers

I have posted a feature request on sf.net regarding the ability to hide spoilers. The current spoilers warning seems ineffective, since it doesn't have any way to actually hide the info, so by the time you've seen the spoiler warning, you may have inadvertently seen some of the spoiler text as well. Unfortunately, I can't think of a good way to do this, except to have a section of text be delineated as spoiler text in some way. Perhaps have a special section header, or include the paragraph after the {{msg:spoiler}} text.

See Offensive content for an example on how this can be done in 1.3 -- Gwicke 15:18, 14 May 2004 (UTC)[reply]

Lists and floating images

In the Preview for a certain page, I use a single list item (*) and the bullet point appears on top of a floating image on the left. I use the Opera browser.

It might be helpful if you told us which certain page. Otherwise, there's not a lot we can do. - IMSoP 23:38, 7 Apr 2004 (UTC)

I find this happens too (in IE). That's why featured pictures candidates uses tables. Have a look at this old version. [1] The comments to the right of the pictures all have two bullet points to force them to the right so that they aren't obscured by the pictures. I don't see any bullets next to those lists in IE6. fabiform | talk 23:55, 7 Apr 2004 (UTC)

Keep user contributions longer (20 April 2004)

When a vandalized article is deleted, this article is no longer visible on the vandalizer's 'contributions' list. I belive they should remain there, since in some cases you don't want to block a user immediately after one somewhat bad contribution (say a newbie test) but if the article is deleted, and the user continues writing such tests, maybe one or two times every other hour, s/he should be blocked or at least given a thorough warning. Nowadays, you are dependent on whether the sysop deleting his/her previous junk really found it worthwile to add a note on the discussion page. And even if they do, you have to check the version history to make sure it hasn't been deleted. That's pretty much work, which no-one(?) really has the patience to take care of (at least I haven't). Hence my suggestion is that the 'user contributions' saves also those articles deleted, preferably with a note 'deleted' or something like that.

Personally, I would imagine using such a possibility in the case of newbies. Most of them does one test editing, receives a note about the sandbox, and is either never heard of again, or begins contributing good articles. The other group continues to write newbie-type of articles again and again and again. One such article would perhaps not be reason for blocking, but when the eleventieth shows up whithin a day, something has to be done against that user.

cheers, \Mikez 13:00, 20 Apr 2004 (UTC)

Initial wiki content, e.g. Help pages

There seems to be no initial content in the wiki...I've just installed mediawiki-1.2.4??

At the very least I think it would be good to have a basic 'Help' content about how to use mediawiki ie the mediawiki user guide

I believe MediaWiki 1.3 is aiming to have a new "Help" namespace. Presumably this would be included with new installs of the software. Until then, you will need to download the database if you want the exisiting Wikipedia help files. Angela 20:04, 22 Apr 2004 (UTC)

Alternatives to simply deleting articles: flagging, no-archive, &c

Less permanent deletion option

Re: requests for undeletion -- it seems to me that many of the problems with deletion (unavailability of someone's work without asking a sysop; difficulty in viewing old content for considering undeletion, apparent finality and unpleasantness) could be remedied in a tangential way:

Have separate ways to mark an article "removed/non-archived" and "deleted"; the former would be used for all but the most legally and associatively bad cases -- copyvio, slander, grossly offensive content running afoul of policy. Any logged-in user [but not a spider or google-bot] could see all non-archived history for a given page. For instance, say

Jan: Alex creates a "Cher" page that says "kjdkfjasdkf" which is removed

Feb: Bo creates a new "Cher" page that defames Cher the star, which is deleted

March: Ciprian crates a "Cher" page which is all about his kitten by that name, which is first somehow redirected to "User:Ciprian/Cher" and then removed

April: Dario creats a page about the 19c French drinking song "Cher", redirected to "Cher (song)"

June: Fleur pastes a long segment from the American popstars latest autobio into a new article about Cher, which is deleted.

July: Jomo puts up a suitable page on Cher, which stays.

Then it should be possible for any logged-in user to see everything but Bo's and Fleur's entries, by date, as long as they were associated with the page title "Cher"... as a stopgap, before this is implemented, the last revision of a deleted article can at least be made available to logged-in users this way.

sj 00:44, 2004 Feb 22 (UTC)

Other flag options: extra content flags

I have the sense that many disagreements could be resolved more speedily and politely if there were options more nuanced than "ignore/delete", but no more time-consuming:

an "unabridged" flag which could be appended to an article [like the blinking pink diamond in the corner of your VR set reminding you that this isn't real ], for material considered too trivial or "unencyclopedic" for inclusion in the main wiki / full-text-search [the search page could have an "unabridged" option].
an "unverified" flag, similarly, removing it from the canonical wiki linkspace and canonical search. Then funny articles, elaborate jokes, material of dubious validity, or for the moment unverifiable -- put up for vanity? political aim? &c. -- could be separated from the main 'pedia without deletion, allowing it to be revised and improved, even later re-incorporated once fleshed out. (This would also hopefully reduce the incentive to [fork])
a better-automated way for an avid user/admin to engage page authors when trying to make such changes/moves/etc : a cooling-off period during which other avid users could observe the proposed move/deletion/trans'ing before an official notice goes out; then an extra line at the bottom of the Talk pages of all users which had edited the affected page?
All of the above could be used in combination with a thoughtful naming policy update [when do you keep a good name but move the content to an "unverified"/"unabridged" page and leave only links to it from the primary page?]

Sj 05:21, 7 Feb 2004 (UTC) (copied from metawiki deletion policy page Sj 08:12, 22 Feb 2004 (UTC))

User Talk

What does everyone think about a feature so that anything that you post on somones user talk page also gets posted on yours? Its somewhat clumsy to have a back and forth conversation with somone, and if they reply on their user page you dont get a message alert so unles youre watching their user page, you might never know that somone has replied to you.128.101.143.61 18:14, 4 Mar 2004 (UTC) (Theon in wikipedia)

It would have to be optional. I expect a lot of people wouldn't want all their messages on their own talk page. Angela 03:59, 3 May 2004 (UTC)[reply]

I like that idea. I always do it myself. But yeah, it should be optional. - Omegatron 21:56, 22 Jan 2005 (UTC)

Redirecting Namespaces

I think it would be nice to have redirecting namespaces. For example, in the sq: pedia, User: is translated to Përdoruesi:, and it would be nice to have Perdoruesi: redirect to it for all user names. I imagine it would be handy for many other international wikis. thanks, Dori | Talk 06:09, 25 Dec 2003 (UTC)

Feature request: PubMED unique identifiers

I would like to request a feature similar to the ISBN feature for PubMED unique identifiers (PMIDs). These are used to refer to articles in medical journals and they are supported by a wide range of online services, including journal publishers, MedLINE, etc. See this page for more information. 66.27.202.81 03:47, 7 Jan 2004 (UTC)

I'm pretty sure I requested such a feature a long time ago on SourceForge. --mav 09:13, 19 Jan 2004 (UTC)

~~See PMID. Should the link word be PMID or something else like PubMed?~~ Angela 00:04, 18 Apr 2004 (UTC)

I lost my server so that link won't work anymore and the tokeniser is now disabled so it wouldn't have worked now anyway. Angela 01:03, 9 Aug 2004 (UTC)

Traditional and Simpified Chinese UI

The new feature of MediaWiki is a great idea to localize wikipedia, however, we are still struggling balancing between traditional Chinese and simplified Chinese user interface.

See: Meta-Wikimedia:Babel#Traditional_and_Simpified_Chinese_UI and Chinese zh:Wikipedia talk:?????.--Shizhao 06:06, 9 Dec 2003 (UTC)

Who is this addressed to? MrJones 18:13, 2 May 2004 (UTC)[reply]

More prominent Locked Database warning

Last week, during the Wikipedia upgrade to V1.3, I was almost caught out by the database becoming locked whilst I was working on an article. On saving the edits, the final page did display a warning header to say that the database was locked and the edits weren't saved. Although the wording of this warning is good, it is actually less prominent that the warning at the top of edit previews.

Because this warning only occurs rarely I think it would be a good idea to make it more obvious.

The simplest step would be to change some of the text to red and possibly increase the font size of the word Warning. However this would actually be a situation where the old <BLINK> tag could be used legitimately on the opening Warning. Since <BLINK> is deprecated and non cross platform, it would be better to put something like a blinking animated gif of a hazard icon at the start of the warning block. -- Solipsist 09:33, 5 Jun 2004 (UTC)

Talk Page Helper formats

Talk pages, and similar ones (like vfd) often get very confusing and disorganized.

I propose a couple new formatting options for talk pages.

Consider a format like

%thread title% Blah blah talk talk talk

Everything in the same paragraph would become a so-called "thread", treated much like a section, except instead of just "edit" links, they spawn BOTH "reply" and "edit", links, so that users wishing to reply to the thread could hit that, and get an edit box to do so.

Now here's why it would be special:

Threads on a page would be sortable by most recently posted and most recently replied to (and whatever else seems reasonable).
They would also be collapsable, to make a very crowded page shorter, and feel more readable. (users coupld opt to have them all start collapsed and merely read titles and perhaps the first few words of the thread)
Threads and replys would be auto-punctuated with 4~'s to sign it.

To sum up, talk pages could retain thier wiki markup formatting styles, but have a more forum-like feel to them, and gain all the ease of use that modern php forums have.

Siroxo 16:21, 8 Jun 2004 (UTC)

Would it be possible to keep the ==Title== formatting, but have these titles treated as threads like you describe on talk pages, while staying as they are on article pages? Also, what about automatic pruning of old threads to an archive page once the original page is too long, while keeping active threads on the top talk page? I don't think collapsable sections would increase readabilty though, particularly if they start as all collapsed. I prefer to have everything before me (barring old archives), as long as they're sectioned off. TPK 15:57, 12 Jul 2004 (UTC)

Pronunciation Details?

Would it be worth putting pronunciation details in for topics (where the pronunciation is not immediately obvious)? I guess it is going to take a bit of a wiki genius to put in all the crazy characters that are using in standard pronunciation keys, but it could be a really helpful feature...

--Dave Taylor (Dave_au)

Variable request

It would be nice if there was a variable specifically that loaded the section number you were on, so that one could have a template message allowing the edit of a specific section of an article rather than the whole thing.

Proper use of id Attribute in Special Pages

Throughout most of the special pages, several generated tags do not have the id attribute set, while the name attribute is. For the use of Stylesheets, appropriate id attributes should be added. --Dwight 10:42, 18 Oct 2004 (UTC)

Restricting random page lookups to an individual category

I'd like to be able to get a random page from a given category only. I think random pages could be a great way to find out more about a given topic, but the current random search is just that, too random. So ideally, whenever I go to a category page, I see an additional link saying "Random page in this category". --CPK 18:52, 14 Nov 2004 (UTC)

Highlight/Right Click Wiki(pedia) Search

This is likely out of scope (may need to be a little third-party plugin), but I would love to be able to highlight a word on any random URL page in my browser, right click, select "Wikipedia Search" (or other configured Wiki), and go directly to Wikipedia search results, based on the highlighted string. This is available, for example, if you install the Google Toolbar (it goes to Google search results). I've gotten to the point now that I just go to Wikipedia instead of Google for most of my information anyway, so this would be a nice feature. --NathanBeach 20:30, 15 Jun 2005 (UTC)

Saving Place on User Tab

Often when I read wikipedia I have to stop to sleep or eat. It would be nice to have a feature that lets me save a link to my user page showing where I left off, which would make it easy to start there the next time I log in from any computer. It is analogous to a book mark. Jason Burt --24.20.104.89 01:02, 18 Oct 2004 (UTC)

Article editing interface

Edit summary: Forcing the issue through blocking blank entries.

Don't know if this has been discussed before. A number of people seem to find it frustrating when people don't provide an edit summary. I do. --bodnotbod 09:39, May 4, 2004 (UTC)

[...]

What about just giving the user a warning at the top of the resulting page ("You didn't fill in the edit summary field when you made your last edit. In the future, please fill the edit summary field with a description of the edit that you made.")? Paullusmagnus 13:50, 7 May 2004 (UTC)[reply]

A gentle reminder could at least some of those who are simply ignorant, but not THAT lazy. --Menchi 21:02, 7 May 2004 (UTC)[reply]

I support forcing an edit summary. How does one lobby or escalate such a request? --24.14.184.229 22:15, 17 September 2005 (UTC)[reply]

Automatic wiki link renaming if article is moved

right now, if an article is moved to another page, a redirect is created from the old page to the new one and the links in Wikipedia stay pointing to the the old page. Why not automatically change all of the links to the new article name? The old article with a redirect can stay, of course, but why point at it? That way, for example, articles would be more Google friendly because presumably the new article name is more reflective of the true nature of the article in question. Also, it would be easier to eventually delete spurious redirect pages. 128.12.51.110 22:41, 10 May 2004 (UTC)[reply]

The short answer is that this would be a nightmare. To put it more verbosely, to have the software track down all the links and change them would not only be very expensive in terms of server time, there is every possibility of conflicting with an edit being performed elsewhere at that moment. Not to mention the delay effect: it won't happen all at once, so at any time between start and finish you'll have some bits done and some not. You can't wrap this sort of thing up in a transaction to make it all-or-nothing because the software simply doesn't support it: this does not make DBMS geeks (like me) happy but we have to live with it.

Bear in mind that some pages have many links to them. you can't just say "this wouldn't happen to a heavily-linked page" because sure as a cat some doofus will do it: someone moved the Village Pump not so long ago after all. You've got to program for the biggest idiot (and as soon as you make it idiot-proof someone invents a better idiot).

Rant over, we now return you to your normal editing. HTH HAND --Phil 08:27, 11 May 2004 (UTC)[reply]

What a pity. Couldn't we lock the database for a couple of hours every week for maintenance?

Could you please specify the hours you do most of your editing, so we can lock the database during those hours?

Is it possible to redo the links when a page is presented for editing? Suppoese a page has a reference to [[alpha]] and that 'alpha' is redirected to 'beta'. Then, the next time anyone wanted to edit the page, what they are given in the edit box is [[beta|alpha]]. Likewise [[alpha|gamma]] would become [[beta|gamma]]. This would be resource-efficient, as the server will be updating the page anyway, if/when the user saved the page. And it would not create any extra collisions (such collisions that happen, would have happened anyway, because the user is editing the page). M.e. 08:42, 3 Jul 2004 (UTC)

Split and Merge features

Splitting and merging article can be a bit of a pain. You have to have two windows (or tabs) open at the same time to the appropriate edit pages. It would be handy if there was a "Move Page"-like feature for splitting and merging: you'd click on Split or Merge This Page, which would bring you to a page asking you for the title of an article to split/merge to. Once you submit an article title, it would open a page with two edit boxes, one for the article you're splitting from and one for the article you're merging into. Submitting would update both articles. This could also allow the history to keep better track of splits and merges. — Gwalla 02:57, 29 Jun 2004 (UTC)

External Editing

Would it take any significant load off of the server if an external editing application were written (or maybe an extension for mozilla, or something along those lines), so that people could edit, press preview, edit, etc. until they get what they want, and then upload the edits, so that the previewing would not load down the server? (The only thing i can think of that it would need to check, to see if an article exists, to decide if the link should be red or not, wouldnt take up as much bandwidth as reloading the entire preview) I don't know how much of a load this would save, but it is a thought. - 12.19.200.130

Suggestions for improvements to editing

Should I add these to the main Feature Requests page? There are several ways I think editing could be made easier, but I am not sure whether they would require code changes to MediaWiki, and thus belong on the main 'suggested features and bugs' page, or whether they can be done less invasively, so I figured I'd start here.

Sectional "Edit" links on the Diff page
A 'view current article' (verbiage TBD) link on the Diff page
Following the lead of w: redir-ing from meta to wp, and m: in reverse, add t: as a shortened form of wiktionary: (maybe also b: for Wikibooks, s: for Wikisource, etc.)--the easier we make it for people to link to Wikt, the fewer dic defs will be added, and it may help inspire people to contribute to Wikt
On the Editing pages, have the <Enter> key do a Preview, instead of Save--this would save me (and everyone else that Previews frequently before saving) a TON of time, in addition to the safety factor
Add a "(diff prev)" (verbiage TBD) link column to all User Contribution pages
Add sig/timestamp to all VfD entries (and maybe similar public forums), even if the person doesn't type the ~~~~

PS I haven't been here long, so I realize some of these may have already come up (#5 I think was also suggested by RickK, above--the others I didn't see here in a quick scan). Niteowlneils 19:57, 9 Apr 2004 (UTC)

1 would be great. 2 exists on the new skin (see test). 3 would be helpful. 4 would be awful as I rarely want to preview and don't want to have to tab twice as much. 5 has been requested before and isn't likely to happen before the new database schema is created. 6 would be really annoying. I often edit VfD without wanting to sign. Generally fixing things for other people or removing listings once they've been deleted. It would be bizarre to leave auto-sigs behind. Angela 09:08, 17 Apr 2004 (UTC)

The way diff deals with moved blocks of text

At the moment, when an edit consists only of blocks of text moved around, diff returns pretty confusing results. I have no idea if this is feasible and I guess this request is more for diff3 developers but in an ideal world, moved blocks would be detected and displayed accordingly.

how should they be displayed? it can get very confusing in the general case. M.e. 10:04, 5 Jul 2004 (UTC)

Sections

allow choice of level for new Section

When adding a Section via a link like the Add Comment link above, which uses a URL with ...&action=edit&section=new appended, there is no way of choosing the hierarchical level for the new section. If you want to append a second-level (===) section, you have to either re-edit to adjust the level or edit the currently-last section and append the new section by hand. It would be nice to have an additional control by which the level of the new section could be set. Phil 14:31, 12 Dec 2003 (UTC)

Editing whole sections

I think it would be handy if clicking on the edit link for a section let you edit that entire section, instead of the current counterintuitive behavior of just letting you edit the section header and the text before the first subsection. Right now, if you want to make a few changes in various subsections of a section, you either have to edit the entire page (overkill) or make several small edits (spamming the history). - Gwalla 20:37, 5 May 2004 (UTC)[reply]

This is done in 1.3, see http://test.wikipedia.org/. -- Gwicke 15:21, 14 May 2004 (UTC)[reply]

This might negate the purpose of section-editing, viz. to be able to easily edit pages too long for many browsers to handle. With 1.3, editing of a small introduction to a huge section containing many subsections has become difficult, which also means to edit the intro. of a huge multi-sectioned article, the entire article has to be edited. Having a (sub)section called Introduction (or similar) for such cases may not always look nice. Would it be feasible to have the older behaviour available, at least through some complicated manual crafting of URLs (e.g. something like wiki.phtml?title=foo&action=edit&section=0&introtextonly=1)? Or has this been discussed before? -- Paddu 08:50, 3 Jun 2004 (UTC)

It wouldn't because if you only wanted one of the smaller subsections, you would just edit that. If on the other hand, you wanted to edit the larger section, you wouldn't need to load the entire page, or make several edits. Thanks to whomever implemented it. Dori | Talk 14:24, 5 Jun 2004 (UTC)

You probably didn't understand my question. How does one edit a small introductory paragraph (or even the section title itself) of a large section, without having to edit the whole large section? If the large section wasn't divided into subsections, tough luck, someone should've redesigned using subsections. Someone with a fast connection and a good browser can split into subsections. But what if the large section is divided into subsections, but one wants to edit a paragraph at the beginning of the large section before the start of its first subsection. Earlier, he/she/they could click the section-edit link of the large section & edit just the small introductory paragraph. Now he/she/they has to click the section-edit link of the large section & wait for the browser to download the entire section & show that in a large editbox, and (if the browser is good enough) edit the text and wait for the entire large section to be uploaded to wikipedia, while others keep getting "cannot connect to database" errors:). -- Paddu 11:31, 10 Jun 2004 (UTC)

Feature idea: Return to TOC link next to section edit link

When reading a longish article with many sections I often find myself hitting my browser's back button to return to the top of the article so that I can use the TOC (in fact some people annoyingly slash the first paragraph of articles to just a sentence or two simply to put the TOC that much higher!). IMO it would be real neat and make navigating articles that much easier if there were a [TOC] link just left of the [edit] link on each section. Anons should also see the [TOC] link since this is primarily a feature to aid readers (and since there are at least 30 hits for every edit, I think it makes sense to have a [TOC] link while not having a section [edit] link). What does everybody else think? --Maveric149 05:21, 12 Dec 2003 (UTC)

I would say that it adds unnecessary clutter. If it's an option, it would be tolerable (I already have edit links turned off). Do you know that you can hit Home or End and go to the top or the bottom (I didn't know until a few months ago when another wikipedian clued me in)? Dori | Talk 00:03, 13 Dec 2003 (UTC)

You can go to the top or bottom of the page, but you can't jump to the start of the TOC. I think this would be a good optional feature, and quite easy to implement.

If only I had a machine that could or knew how to configure Linux to support files > 2Gb :-) Not a good excuse, but It's not currently worth (to me) coding for a wiki as fiddly to setup as MW if I can't have my own full copy of WP to play with. MrJones 18:13, 2 May 2004 (UTC) amended by MrJones 11:33, 8 May 2004 (UTC)[reply]

Option to Turn off Automatic Numbering on certain Tables of Content

I would love to have the ability to turn off automatic numbering on certain Tables of Content. For example, Statutes, Regulations and Acts typically have their own numbering scheme for each section of the Statute, Regulation, Act, etc. When I mark each section of the law in order to generate a Table of Contents, I end up with the wiki numbering scheme for the TOC and also the law's numbering scheme, which does not look right. Banjolawyer 18:02, 4 Feb 2005 (UTC)

Page preview inline (in an iframe) on the edit page

Use an iframe for preview, so when you press the preview button, the new article is shown in the iframe. This would save on load time, plus make the thing much less jumpy - it could fit on one screen.
Provide an option to preview the article in normal view, with the 'not saved' warning and a link back to edit view.
Add a button to show the article's talk page (or vice versa) in the preview iframe.
In fact, make the iframe a mini-wikipedia browser. If any link is clicked, show the article in the iframe. If out-of-site link is clicked, open in a new window. Provide buttons to quickly switch the iframe display from preview to source and back. This way editors could easily look up text in other articles and copy wikitax.
Provide last n page history links for the minibrowser.
Provide "what links here" button for the minibroser.

Zocky 16:25, 12 Dec 2003 (UTC)

All sounds good, except I think iframes are obsolete Tim Starling 07:03, 13 Jan 2004 (UTC)

They are slow and memory hungry, certainly. That will matter less with time. Best avoided, or at worst made optional, though. MrJones 18:13, 2 May 2004 (UTC)[reply]

Edit hints

Abstract: Provide an algorithm based article commit check system in MediaWiki similar to the current edit conflict to reduce unwanted edits (vandalism, flames on discussion pages, edit wars, stubs). The proposed ideas are strictly based on certain formal aspects of editing. This is no suggestion about censoring of articles by content. Those algorithms are based on formal aspects of common sense e.g. about length and form of articles.

Full proposal can be found at Edit hints.

Please make changes to the proposal, comments and votes directly in the article (or in its talk page) and not here. I discussed this proposal (beside other things) quite a lot with other wikipedia/wikimedia people at 21C3 meeting in Berlin and tried to make a summary of all ideas (and detailed pros and contras). Arnomane 22:58, 3 Jan 2005 (UTC)

Recent Changes

Can Recent Changes display the top edit when hiding logged-in users?

Is it possible for Special:Recentchanges to display whether an edit is the the top edit in some situations? Specifically, when the "hide logged-in users" option is on (like this: [2]) it's a pain not to be able to tell if an edit is the most recent. This isn't a problem when you can see the whole list, of course, but when you're searching RC for possible vandalism, it's great to only look at the anons, but annoying and a waste of time to check the diff and discover that it's no longer the top edit. BCorr|Брайен 05:30, 1 Apr 2004 (UTC)

Would it not make sense for RC to always show whether a change was the top edit whenever anything is hidden? There are currently 3 possible categories of "things to hide":

minor edits
bots
logged in users

It would make sense that the RC mechanism would detect when anything is hidden and take steps to show when the change displayed is the top edit. --Phil 10:37, 2 Apr 2004 (UTC)

Previews

Preventing bad edits

What about requiring anonymous users to do preview before saving new articles? Previewing new articles is a good idea in any case so it won't harm good users. And on the preview we can notify about copyright etc. --ilya 05:45, 20 Dec 2003 (UTC)

I like this idea! --Maveric149 20:47, 21 Dec 2003 (UTC)

Red links problem

There was a large discussing about vandalism and 'red links problem' and I've got that many people simply don't undestand what will change after they type something.

There seems to be a confusion of vandalism and bad edits here. They are not the same thing. MrJones 18:13, 2 May 2004 (UTC)[reply]

I suggest that we require anonymous users to do preview when they edit a new article.

We can make in preview two buttons, something like Reject and Accept (or even Save draft which saves XXX to User 0.1.2.3/Draft of XXX), so people will understand that after they press yes-button this will look like this for everybody. When I write a new article I usually do preview by myself - to ensure that there are no grammatical errors, that it looks good, that I have forgotten nothing et cetera, so it won't disturb me. And I suggest that we specify it in preferences, so logged in users that find it unnecessary can turn it off.

As for me, even when I added this entry I did preview and changed title from Dealing with vandalism to Red links problem: idea. And then I signed and pressed Save and it was wrong, because I was anonymous and had to edit it one more time to insert my name. So as far as I'm concerned the more previews the better! ilya 00:24, 9 Jan 2004 (UTC)

That's fine up to a point, but previews can be slow. MrJones 18:13, 2 May 2004 (UTC)[reply]

Squash consecutive edits

Suggestion: Collapse consecutive edits by the same user in a period of 30 minutes. Many new users don't use the preview functionality correctly. This results in several versions showing in recent changes and in the history that make it difficult to determine what a user was changing - for instance, asking for a diff in recent changes brings up just spelling corrections or other minor changes to the more major changes done earlier. I think it would be useful to collapse these edits into a single entry so it is not as necessary to rely on users double-checking with the preview button. Kevin Saff 17:50, 19 Apr 2004 (UTC)

Also, I often find when I am editing a section that a need to make an small edit in another section. I either have to copy my changes and paste them into a fresh full page edit, or make two edits. This would let users make the two edits without filling up the edit history.

Here's the trick, though: what are the values of the timestamp, the summary, and the "minor edit" flag in collapsed edits? --Spikey 20:24, 19 Apr 2004 (UTC)

I have also edited multiple times due to multiple sections. I think the timestamp should take the value of the last edit, which is what it would be if the user had made all changes before saving. Maybe the summary could collapse all the edit summaries (such as "rewrote article / moved sections / added link / spelling"), if this wouldn't be too long. I think the "minor edit" flag should be true only if all the changes were marked minor. Kevin Saff 20:43, 19 Apr 2004 (UTC)

Would it make sense to add a checkbox (next to 'minor edit') to merge consecutive edits? Sometimes I intentionally make spelling fixes separate from major article changes. Sometimes it takes me more than a half hour to think up the changes, and I might still want to merge them. A checkbox would allow either choice. --Ssd 01:42, 20 Apr 2004 (UTC)

Sometimes it is helpful to make consecutive edits, as it allows you to explain each change with a separate edit summary rather than making one major change all at once. This makes it easier to see what changes someone has made rather than having to compare one huge diff. Angela 02:07, 20 Apr 2004 (UTC)

You're probably right. Would it make the interface to complicated to have a checkbox for "Merge this edit" (if separate edits are the default) or "Do not merge this edit" (if merging is default)? Kevin Saff 15:14, 20 Apr 2004 (UTC)

The timestamp is the timestamp of the last edit; and the merged edit is minor only if all the edits are minor edits. Perhaps you could concatenate the summaries. M.e. 10:10, 5 Jul 2004 (UTC)

I think TWiki does this. M.e. 10:10, 5 Jul 2004 (UTC)

At the least, consecutive edits should show by default when you click diff in a recent changes or watchlist. - Omegatron 22:06, 3 Feb 2005 (UTC)

Previous changes

Currently it doesn't seem to be possible to ask for the data earlier than those you're looking at, accept by adding them to what you've already read. A way to load the next 50, rather than reloading with 100, etc., could be an improvement. Aliter 23:36, 11 Jun 2004 (UTC)

Proposal: showing size (# characters) of each edit

What: I'd like Recent Changes (as well as the watchlist and individual articles' history pages) to display a machine-calculated "size" for each edit. "Size" would be calculated using the diff utility; as a preliminary proposal, an edit's "size" would be defined as the number of characters in the patch file required to move from the previous edition to the current edition. I think this measure of size would be reasonably isomorphic with people's intuitive judgements about which edits are large and which are small. That is, an edit with a larger "size" (formally defined) would also have a larger size (intuitively defined).

Why: By allowing people to see the machine-determined sizes of different edits, this change would A) help people decide whether or not to believe that particular major edit/minor edit designations have been made appropriately, and B) help people compare the size of different major edits. The latter would be nice, for example, in cases where you wouldn't care if ten or so words of an article had changed, but you'd want to be sure to know if the whole thing had been rewritten.

I doubt this is a very hard feature to add, and I'm considering exploring it as my first foray into hacking Wikipedia code. But I wanted to see if anyone had any comments on this idea first. First, does my idea make sense as expressed above? Are there any objections or proposed revisions?

--Ryguasu 05:17, 11 Aug 2004 (UTC)

Searching Mediawiki

Wiktionary search in Wikipedia

I don't know if this belongs here, but, given the less-than-ideal border drawn between Wikipedia and Wiktionary - Wikipedia often containing dictionary entries, and the opposite for Wiktionary - it would be useful if, when an article is not found but before a "Search results" page is brought up, a Wiktionary search for the query will be performed, and the user redirected in case of a match. -- Itai 15:46, 10 May 2004 (UTC)[reply]

Why limit this to failed searches? I'd prefer a much tighter coupling between de Wikipedia's and the Wiktionaries, and one of the things would be to have every search on one of them offer matching titles on the other. That way people would know there was more information there. (Of course, to I'd prefer to have matching titles to also show up as links on the pages themselves, so the reader can see on the page that there's more information.) Aliter 12:02, 13 Jul 2004 (UTC)

The best would be to have a search portal, such as google has, on say search.wikimedia.org, that would search through all the wikimedia projects simultaneously and would also be fast to load. Samohyl Jan 11:59, 16 Nov 2004 (UTC)

Word stemming

From http://www.sca.org.au/cunnan/wiki/Cunnan:Village_pump#RFEs

A search for links type page where I can find what links to a certain article without creating the article. e.g. I've written a bunch of pages with links to, say, lollard, lollardry, lollardy, lollards, etc, and I want to find them all in turn if I have to but fix the links so I only create one "lollard" page.

This could be done with a the ispell support for word stemming. MrJones 15:27, 8 May 2004 (UTC)[reply]

Alternatively there is GNU Aspell which the page for ispell admits is better in some cases; however the latter claims that the former only works with English which now appears to have been overcome. Maybe the Aspell programmer could do with a bit of help, and having it connected to Wikipedia couldn't hurt him :-) --Phil 08:43, 4 Jun 2004 (UTC)

The way I understand how to do this, is just do the double square brackets arround the stem, and then complete the word without any spaces following.

blah blahblah blahblahblah should all point to the same page --Aaron Peterson, alpeterson@wsu.edu 509 332 7697

PanWiki Search

For the purposes of integration of Wikipedia, Wiktionary etc. Can search results include articles on other Wikiplaces. For example in Wikipedia I search for something and on the right a box displays top results for that word or item in other parts of wiki -OldakQuill, 17:32, 2 May 2004 (UTC)

More options for Search

We need more options for the Search facility, particularly in the area of sorting. Example include but are not limited to:

sort by size
sort by most recent edit date
reverse order of sort

Phil 15:21, 23 Dec 2003 (UTC)

Crossword puzzle search

It would be great to have a special crossword puzzle search functionality. It should contain a choosable number of input fields for single characters. The search returns all words/articles which have the given characters at the appropriate places and the correct length. -Piet

Article manipulation (automatic)

Spell checker

Each time you click "Show Preview" wikipedia should run the document through a spellcheker (smart enough to not check code), and report the errors. There could even be a feature to autocorrect if the user wishes. I've corrected many spelling mistakes, and made many too, this would go a long way to streamlining the wikiprocess. —siro χ o 09:23, 24 Jun 2004 (UTC)

Automatic addition of U.S. location data by Rambot

Maps added automatically to such articles

I think there could be a map-inserting bot for those articles created by Rambot... As rambot gets the coordinates, a map should not be difficult to make up... One showing the USA and the position of the city/village... and another in the corresponding county/state/whatever... Should not be difficult for bot-developers? 80.58.23.44 13:36, 6 Mar 2004 (UTC)

Speak to the pywikipediabot people. They might be able to help. Angela

Disambiguation

Automatically show other meanings of article title

There are more and more specialised articles with the same title (homonyms). A common example is Madonna and Madonna but there are words with much more meanings, too. I'd like a list of "other meaning" in the same way like interwiki links are displayed. So if you are looking at article Madonna you automatically see that there are other articles on "Madonna" (in this way we could also get rid of most of the disambiguation pages).

Easy implementation:

Whenever showing links for articles "Foo" or "Foo (bar)" search for "Foo [(. )]?"

Better implementation (not that diffucult neither):

Add a table "Simpletitle" that only contains the title part without the context in brackets, pointing to each article id:

"Madonna" => id of article "Madonna"
"Madonna" => id of article "Madonna (singer)"
"Madonna" => id of article "Madonna (religion)"

Thanks a lot -- Nichtich 16:34, 13 Feb 2004 (UTC)

FTP upload for Wikibooks

The organization and compilation of pages for wikibooks differs in from entries in other parts of the wikimedia foundation. In particular, there is much more likely to be a single dominant contributor to a particular wikibook.

In the case of wikibooks on Information Ecology [3] and Information Habitat: Where Information Lives [4], where wikibook pages are generated from a relational database / digital engine - see [5]

Your database contains text strings which are copied to the wikipedia? Use pywikibot. MrJones 11:33, 8 May 2004 (UTC)[reply]

- with the capability of developing entire sets of pages in either HTML or wiki format, the ability to proceed with publishing the book in a wiki / speedy manner would be greatly enhanced if there could be a way to upload sets of pages using FTP.

Given that there is already a file upload mechanism using HTTP, it would be better to use that. I would think most scripting languages would allow that. IIRC, the cURL library allows uploads, so you'd just need to find a wrapper for that. MrJones 11:33, 8 May 2004 (UTC)[reply]

One of the direct benefits of the use of FTP uploading in wikibook pages would be the ability of contributing authors and editors to upload distinctive cascading style sheets for the books we are co-writing and to include reference to these style sheets in the substantive pages that are uploaded.

CSS is far from transparent, not a great technology, and totally un-wiki. This is a bad idea. Allowing users to upload CSS to use themselves (to 'skin' the media wiki) is a different matter. MrJones 11:33, 8 May 2004 (UTC)[reply]

In order to allow for FTP upload to wikibooks, it might be necessary to establish a special category of User / Contributor and a set of procedures regarding the nature of privileges of an FTP Contributor - e.g. restricting to subdirectories of wikibooks initiated by the contributor.

Clearly it would also be necessary for there to be a wiki script so that any pages uploaded via FTP would be seamelessly integrated with both the Page history for the uploaded pages and with the applicable User contribution page. Information Ecologist 17:46, 3 May 2004 (UTC)[reply]

I think there is merit in being able to submit pages as files via http. I don't know if there are security implications, but I suspect not (beyond being able to create huge files, but potentially one can do that anyway with pywikibot). I guess edit conflicts would have to cause the upload to be rejected.

I don't think the uploads need to ever actually exist as files. MrJones 11:33, 8 May 2004 (UTC)[reply]

Video

Automatic thumbnails for video

An automatically generated (static) thumbnail for video files would be very useful for the French Sign Language wikibook (http://fr.wikibooks.org/wiki/LSF)

Actually, no... thumbnail selection is best done manually, from recent experience-- Kowey 15:43, 23 Jan 2005 (UTC)

Thumbnails for video

Barring automated thumbnails, it should at least be possible to manually specify an image file to use as a thumbnail for a video.

Article manipulation (manual)

The Watchlist, and other page monitoring and user tracking

Proposed Measure of Article Reliability

If we could get two bits of information about the activity of a particular article, Number of Views per unit time and Number of Edits per unit time, we could get a "Edits per view" measure which could indicate the accuracy or reliability of an article content. My idea is that if an article is inaccurate or incomplete a large number of viewers will edit the article (high edits per view). If the article reaches a high level of accuracy, few people who view the article will edit it (low edits per view). Such a measure could be seen also as Article Stability. Seabhcan 09:09, 23 Feb 2005 (UTC)

Both major and minor edits on my watchlist?

I like to see minor edits on my watchlist, but this causes a problem: if somebody makes a big change and then they (or somebody else) corrects a typo, only the description of the latter shows in my watchlist. Would it be possible to see both the last minor change AND the last major change to each article? (Apologies if this is already implemented and I'm just being stupid, but I can't find a way.) 209.195.116.173 16:59, 30 Mar 2004 (UTC)

I'll second that one. Summary of a spelling fix is annoying when it obscures much larger changes. --Ssd 05:55, 17 Apr 2004 (UTC)

This would indeed be a fine thing. --Bodnotbod 19:17, 5 May 2004 (UTC)[reply]

I see the exact same problem. Major changes can easily be hidden by quick minor fixes after them. I think part of what could help would simply be a number next to each entry showing how many minor and non-minor changes have been made in the timefram selected on my watchlist. For ex:

(diff) (hist) (3) (2) Talk:Chilli pepper; 10:35:29 . . Taxman (Talk) (Merge into Capsicum was innapropriate)

With the 3 being the minor edits in the last three days in my case, and the 2 being the non-minor. This could allow for more easily watching more edits. - Taxman 15:20, 27 Jul 2004 (UTC)

I'll add a note of support to any implementation that solves this problem. Catherine 23:18, 14 Oct 2004 (UTC)

Show the latest major edit's summary on the watchlist

When someone makes a huge edit to a page on my watchlist and then the user makes a minor edit on the same article, I might not pay as much attention to it if it says "spelling" instead of "rewrote entire article". Perl 19:31, 19 Apr 2004 (UTC)

Or better, show the number of edits today. MrJones 18:13, 2 May 2004 (UTC)[reply]

Identify sudden page reduction or blanking

I just came across a page that had been virtually blanked (possibly by accident) several days ago and that no one had caught. I've seen this before. How easy would it be to display on Recent Changes some indication of a large reduction in the size of the text? This would also flag text removed to merge with another page & chg to redirect, but I'm thinking that a large reduction is more often a problem. Thoughts? Elf 02:36, 31 Mar 2004 (UTC)

Diffs from User contributions page

Would it be possible to add a diff link onto the User contributions page next to each entry on the page? When tracking a vandal, it's difficult to tell what their changes were unless you go to the page, then to the page's History, then click on the diff link there. RickK

Watchlist watching

I personally feel that the watchlist would be much more useful to me if I had the capability to view on the list only the articles whose most recent revision was made by somebody *other* than me. Maybe this is an artifact of being a relatively new contributor and having a short watchlist (c. 200 pages), but it's a slight nuisance having to scroll through articles that haven't been touched since I left them, and so therefore won't warrant another look. - Seth Ilys 05:25, 12 Jan 2004 (UTC)

I'll second this request. My watchlist on Wikipedia is dominated by my own entries, especially since I often respond as soon as other people write something new. --Rs2 21:54, 31 Mar 2004 (UTC)

Yes, this would be a great improvement. --Bodnotbod 19:22, 5 May 2004 (UTC)[reply]

Tracking Vandalism

To better deal with vandals and suspected ones it would be a nice feature to have a User-Watchlist that allows to highlight the edits of specified users, ip-adresses and ip-namespaces (eg. 82.82.x.x). Maybe this feature should only be available to Admins. -- Sansculotte 08:07, 13 Jan 2004 (UTC)

One problem I see with this idea is that it could be used as an enemy's watchlist, which could lead to more revert wars. Noldoaran 18:42, 21 Feb 2004 (UTC)

If it's restricted to admins, which go through a nomination and selection procedure, this shouldn't be a problem. --Bodnotbod 19:44, 5 May 2004 (UTC)[reply]

See which articles have not been checked by a moderator

When an article has been read by a moderator, it will be typically not be necessary for an other moderator to check it for vandalism. It would therefore be usefull when there is a list of edits by anonymous and known "problem editors" that have NOT been read by a moderator.

This list would be "moderators-only". GerardM 09:51, 10 May 2004 (UTC)[reply]

Watchlist timeframe

Some people want a shorter default for the watchlist so that it loads more quickly. Others like it at 3 days. (summarised request of Wik et al)

Enhanced Watchlist: like Recent Changes

I would like the option to have my Watchlist "enhanced" like RecentChanges in that I would like to see all the edits to my Watched articles within the timescale specified. They could be revealed/hidden with the same blue arrow mechanism as for RC. --Phil 16:41, 28 Apr 2004 (UTC)

I second this. Kevin Saff 15:10, 29 Apr 2004 (UTC)

Yes, that is a wish I have had a long time.--Patrick 21:38, 13 Jun 2004 (UTC)

Number of (active) users watching that page

For a specific page I would like to know HOW MANY users do have that page in their watchlist. Or, even better: how many active (as defined elsewhere, like "more than X edits in the last Y days") users … Please note that I'm NOT asking for displaying WHO is watching that page. I just want to know the number. Not the names.

Reason: I have that "Watch this page" checkbox enabled by default and so, from time to time I have to tidy up and remove some pages from my watchlist. But I'd rather remove pages that are watched by hundreds of active users than those that are monitored only by a lousy bunch of three or four people. This is to control vandalism on the less popular pages. --Sikilai 01:05, 31 Mar 2004 (UTC)

Yes, I'd love to see something like this too. A report that highlights unwatched pages could lead to an "adopt a page" scheme, where users are encouraged to add neglected (less than 5 -active user - watchers?) pages to their watchlist to keep an eye out for vandalism. Having said that I had my first attack of vandalism yesterday, on what must be an obscure page, and people leapt in incredibly quickly. I was more impressed than you can imagine at how well the policing worked.

Note for the original requester - I understand that each page used to have a counter (of page views), but this was dropped as it caused lag. I guess (though I'm non-technical) a 'running count' of watchers would slow things even more than that did. --Bodnotbod 19:14, 5 May 2004 (UTC)[reply]

I think this would be a very useful administrative type feature. Perhaps it could be implemented in a way that does not slow things down. Would it help if the counter was not on the article page, but perhaps on the watchlist page? I.e., you'd have to add the page to your watchlist before you could see how many were watching it, or otherwise put it in some special list or view a special page properties page, or maybe put the counter on the edit page, or some subset of these?? --Ssd 03:09, 10 Jun 2004 (UTC)

I would love to see this as well. I would recommend that it just display the total number of users watching a page, and if someone clicked on that number, then it could break down the list into number of users who have edited in the last week, month, year (which would actually take time). The total number of users watching could just be incremented and decremented when someone added or removed themselves from the watchlist. Jrincayc 14:51, 13 Jun 2004 (UTC)

I implemented a simple information page that tells how many users are watching a page. Still needs more work to be able to seperate out the active users. See en:User:Jrincayc/Infopage. 02:35, 7 Jul 2004 (UTC)

This is a great idea. Neutrality 01:40, 30 Aug 2004 (UTC)

I too think this is an excellent idea. I've wondered about this for a while (but only just found this page). Thryduulf 10:18, 28 Feb 2005 (UTC)

Unsorted

Metadata for articles

It would be useful in certain cases to note certain attributes of a page in a comment at the top of an article.

This could be, for instance:

Dialect (British vs. American spelling, bokmal vs. nynorsk in Nowegian)
That the page is a real article, for counting purposes, i.e. not a stub.

The syntax could be:

<!--WikiMetadata:
    Dialect: uk
    Article: yes
-->

Please consider my idea,

Vacuum 22:48, 4 Jan 2004 (UTC)

See Field-value pairs. --Evan 06:18, 5 Jan 2004 (UTC)

Limit to "What Links Here" ?

As "What Links Here" is limited to 500, could there be a "Next 50" link? (summarised request of w:User:Anthopos and Maveric149)

Chronological ordering of What links here

Make the order of "what links here" chronological by time the page linking to it was last changed. (summarised request of Dori et al)

Redirects from here

Is it currently possible to find all of the links on the current page which lead to a redirect? If not, how difficult would that be to implement?

I'm imagining something that looks like the "what links here" list, only it lists links going in the other direction (from here, intead of to here). Redirects could be shown just as they are on the "what links here" page.

Having this would be convenient for identifying redirects that should be avoided (i.e., directly linking to the target page instead). Having a list of all the links from the page would also be useful, especially since the text itself can hide the actual links.

-Anthropos 21:35, 12 Dec 2003 (UTC)

List of redirects to watched articles

I would like the mediawiki software to notify me via watchlist when someone creates a redirect to any article on my watchlist. The problem is that this would take a lot more bandwidth possibly. Why is there no Wikipedia:requests page? Green Mountain 19:20, 3 Jan 2004 (UTC)

Double redirects

I just spent a long time cleaning up a lot of double redirects, most of which seemed to have been caused when people moved pages, but didn't tweak the redirect pages that linked to the page they moved. How about making the check for redirect loops a little smarter, so that it can follow two levels of redirect before blowing out, meaning we only have to hand-patch chains that wind up three deep (or longer)?

Failing that, how about a check in the "rename" function for redirect pages in the "what links here" list of the page being renamed, followed by a LARGE WARNING screen or something that makes people aware there are redirect pages they have to fix?

redirects to a section in a page

There is a page Varangian Guard which contains #REDIRECT Varangian#The_Varangian_Guard. If the link is followed manually it goes to the correct position in the Varangian page. But the redirect seems to send the user to the top of the Varangian page not to the section The Varangian Guard.

As click and go follows links to page sections it would be nice if #REDIRECTs did the same thing. Philip Baird Shearer 03:12, 23 May 2004 (UTC)[reply]

Page move rollback

An idea for a tool that allows administrators to rollback page move vandalism has emerged out of the discussion at en:Wikipedia talk:Requested moves/Min edit count. This would include the automatic deletion of the redirect pages created as a result of that move e.g. a user recently moved en:Wikipedia:Pages needing attention to en:Wikipedia:Pages needing pelican shit links (and also other pages were moved to locations with 'pelican shit' in the title). The page move rollback would have restored the page to its correct location and deleted the pelican shit redirect.The actual content of the article would be unnafected, in case someone had made a useful edit while the article was in the wrong place. Ideally any redirects that had been edited manually to reflect the new location would be rolledback as well, but I don't know if this would be technically possible. Thryduulf 10:29, 28 Feb 2005 (UTC)

Linking to family trees

As an example, the article Julio-Claudian family tree has a single image with the entire family tree. I'm wondering if it's possible to create a family tree that appears similar but has a feature linking the individual names in the tree to the articles about those people. Does the software exist to do this? MK 06:22, 16 May 2004 (UTC)[reply]

I suggest some sort of mark-up to generate the trees in HTML format may be best - I know the GEDCOM file format exists for genealogy data, but I don't know of standards for genealogical markup in an easily readable format (for example, in XML) or conversion utilities. Image maps are possible but may not be compatible with all browsers (but then, images are not compatible with all browsers either.. --Chuq 03:38, 24 May 2004 (UTC)[reply]

Actually the GEDCOM 6 specification is in XML format but it's only a draft dating from 2001, no idea if it's still evolving or just abandonned. -- Lenaic 12:08, 19 October 2006 (UTC)[reply]

Markup

Ending Blending

I notice ending blending only works with letters after the ]]s. It might be nice to also be able to use it with apostrophies. Other punctuation should remain unblended, though. Are there any other marks on which blending would be appropriate? [[person]]'s [[cat]], would show up as: person's cat,

216.139.26.93 05:40, 23 May 2004 (UTC)[reply]

Sections

Improved numbered lists

What about changing the way numbered lists are generated into something like this:

# text
## text
##text
# text
## text
### text
### text
### text
## text
### text
### text

would then translate into:

1. text
    1.1 text
    1.2 text
2. text
    2.1 text
        2.1.1. text
        2.1.2. text
        2.1.3. text
    2.2. text
        2.2.1. text
        2.2.2. text

The TOC already does that, so why not numbered lists? Indent is nice for short lists, but large numbered lists are just an incredible mess to look at.

An alternative would be

1) text
    I) text
    II) text
2) text
    I) text
        a) text
        b) text
        c) text
    II) text
        a) text
        b) text

Either way, the way it works now is not easy to follow. The indentation is not deep enough and it is easy to lose what level you are at. Does MLA have any guidelines for this?216.139.26.93 06:24, 13 Jul 2004 (UTC)

Collapsable tree in "See also" section

Wikipedia is becoming more structured, with TOCs implemented and categories coming up. I think it may also be appropriate to structure the "See also" section that most articles have and probably all should have.

In many articles, many links to other articles and external sources should be included, but the lists soon become too large and ugly.

So I was thinking, maybe add some markup for the "see also" list, and make the whole thing collapsable, like TOC, so in [Dog], we could have something like:

<seealso>
* Scientific classification
** Species: [Canis Lupus Familiaris]
** Genus: [Canis]
** Family: [Carnivora]
* Breeds of dog
** Working dogs
*** [Dog Breed 1]
** [Dog Breed 2]
*** Working dogs
*** [Dog Breed 3]
***[Dog Breed 4]
*Other common household pets
**[Cat]
**[Gerbil]
**[Tarantula]
</seealso>

But it would be much better if the list branches would be collapsable as well. Maybe use pluses for collapsible branches which are open by default, minuses for closed collapsable branches and asterisks for non-collapsable branches (or any other suitable markup), like:

<seealso>
  Scientific classification
** Species: [Canis Lupus Familiaris]
** Genus: [Canis]
** Family: [Carnivora]
* Breeds of dog
-- Working dogs
*** [Dog Breed 1]

*** [Dog Breed 2]
-- Toy dogs
*** [Dog Breed 3]
***[Dog Breed 4]
-Other common household pets
** [Cat]
** [Gerbil]
** [Tarantula]
</sealso>

which would display

[-] Scientific classification
- Species: [Canis Lupus Familiaris]
- Genus: [Canis]
- Family: [Carnivora]
Breeds of dog
- [ ] Working dogs
- [ ] Toy dogs
[ ] Other common household pets

How does that sound? Zocky 20:06, 9 Dec 2003 (UTC)

I like that idea, but it is really 2 ideas, collapsable lists (which has been proposed before, and I think is a great idea.), and a see also section. How hard would this be to implement? JavaScript (ECMA script) would be needed to support the collapsable lists. Noldoaran 18:05, 21 Feb 2004 (UTC)

There is at least one open-source JavaScript tree menu available. Perhaps this could be customised? Also, spaces are allowed in xml-style tags, so it could be <see also></see also>, which is nicer, no? :-) MrJones 18:13, 2 May 2004 (UTC)[reply]

What's the longest See Also section you have seen? I think this would mostly just add clutter to your JavaScript-enabled page. Pgan002 09:31, 4 Jun 2004 (UTC)

One-line Table Rows

I love the shorthand table syntax, but is there any way to let rows be on a single line? Take, for example, the w:Armenian numerals page, recently converted to the new format. Contrast the old form:

<tr><td align="center">Ա<td>ayb<td>[[1 (number)|1]]

with new new form:

|-

|align="center"|Ա||ayb||[[1 (number)|1]]

For long tables, this makes them scroll off the page. (Check out this diff.) But I can't seem to get table rows to fit on one line, since the |- wants to be all by itself.

Solutions? Workarounds?

Grendelkhan 17:58, 15 Apr 2004 (UTC)

Interwiki links -- pedia, tionary, source

It's been discussed on IRC that it might be useful to be able to conveniently link to parallel articles at Wikisource and Wiktionary (and probably vice-versa) in the same manner as interwiki language links are now done... perhaps on a second line titled "Sister projects:" or something similar. -- Seth Ilys 00:17, 19 Mar 2004 (UTC)

Alternatively, one could write things like [[wp:X]] [[wry:Y]] [[ws:Z]] which upon saving would have their longer versions substituted (e.g. [[Wiktionary:Y]]) for ease of understanding by later editors. MrJones 16:26, 2 May 2004 (UTC)[reply]

The current system of Interwiki links lacks structure. The links can be placed anywhere within the content of a page, thankfully many people place them at the bottom of a text. My idea is that when editing a page there should be an extra field just for the interwiki links. This way you have a complete overview of the available interwiki links. Another advantage is that potential editors will not be scared off by a couple of strange looking Interwiki links. I imagine that with the current system some of our participants will be frightened by the Japanese, Chinese, Arabic interwiki links and might leave Wikipedia because of it. If one would want to preserve the current database scheme there is the possibility of merging the Interwiki-link field and the Text-field when the Save Page button is pressed and split them when the page is opened. This way the database doesn't need any changes but only the MediaWiki source. The other possibility is to add a new field to the database containing only Interwiki links next to the normal content field. An advantage of this method is that it will be easier to synchronise the different languages of Wikipedia. Meaning that the Dutch wikipedia might have an article on Immanuel Kant with Interwiki links to the French, German and English version. The English wikipedia might only have links to the Dutch and French version. It wouldn't be that hard to synchronise the different Interwiki fields between the different languages. The only problem I can see with the second approach is that another history page has to be created just for the Interwiki links although this problem can be overcome. I think this idea has been suggested before but I suggest it anyway. I hope I was clear. --Maarten van Vliet 20:58, 21 May 2004 (UTC)[reply]

I suggest having a separate namespace for article metadata. See my comment here. - Gwalla 21:24, 31 May 2004 (UTC)[reply]

Interwikis on commons?

I would like to put the interwikis for a page in the commons or some place.

Instead of 80 article with 79 lines of interwiki in each one, just one page with 80 lines.
More control over vandalism
Less database space
Less bot activity to update interwikis. (or none at all)
Each wiki goes there and create their own links, while not "polluting" recent changes.

What do you think?

(Can discuss on my Talk page) Osias 20:35, 1 Feb 2005 (UTC)

Interwiki Links and Google

If I look at the French article fr:pomme, the link to the corresponding English language page looks like this:

English

It would be much nicer if instead it looked like this:

English: apple

This way of displaying links has two advantages:

It is informative to see how the article title is written in different languages.
The Google search engine will give the en:apple page a higer score for searches on the word apple, rather than for the word English, which is completely unrelated to the subject.

PeR 22:11, 17 Jun 2004 (UTC)

I liked! :) --Osias 14:17, 25 Feb 2005 (UTC)

Unit conversion syntax

Would it be feasible to define a syntax for unit conversion? If someone knew a length in meters, for instance, they could type, say,

The longest specimen discovered was 3m (#3m#ft#).

To get:

The longest specimen discovered was 3m (9.84ft).

It would probably be most useful as a substitution, so that future editors could know the feet and calculate the meters. --Spikey 18:09, 11 Mar 2004 (UTC)

I think it would be nicer to allow something like [[Measurement:3 m]], and have it automatically displayed to each user in a manner dependent upon a user preference setting (e.g. "display units in metric", "display units in Imperial"). -68.196.5.19 06:36, 3 May 2004 (UTC)[reply]

A good start but, I daresay, too long. This can be made much more appeasing by changing it to 3m, for instance. Automatic identification of "3m" (as done with http://something and ISBN 1234 ) is not really an option, given that such phrases are too ambiguous. Automatic detection (and consequent conversion) can be, on the other hand, enabled for "3 metres" and the like. Coming as I do from a mostly SI-compliant country, however, I must say that it is my humble opinion that the only thing worth measuring in feet is, as it were, feet, and that each foot is exactly one foot long, shoes notwithstanding. -- Itai 17:21, 5 May 2004 (UTC)[reply]

I would like to throw my support behind this suggestion of saving a user's unit preference and then rendering each page to match this preference. This would be an elegant solution to the ongoing debate at Wikipedia:Measurements Debate where I have also made this suggestion. I have submitted it to the Sourceforge bugtracker as feature request #1007079. (This is now bugzilla bug 235.)
As a native Imperial unit user (USA) now resident in a metric country (Japan), I would also like to say I agree with Itai's sentiment, however I think it extremely unlikely that the USA will metricate in the foreseeable future. --61.215.132.202 07:50, 11 Aug 2004 (UTC)

I just had the very same idea and wanted to propose it here. The only thing I have to add to this discussion is that this is already done for correctly formatted dates, so such a thing wouldn't be entirely unprecedented. I'm all for it (also, I can't think in miles) --GrmWnr 20:24, 1 Feb 2005 (UTC)

I agree that the best way would be for the wiki to handle the conversions:

The specimen was [m:3 m].

To get:

The specimen was 3m (9.84ft).
The specimen was 9.84ft (3m).
The specimen was 3m.
The specimen was 9.84ft.
The specimen was 8.2 Klingon length measuring units.

what comes out depends on user preferences.

I too would love to see this! Despite the valiant efforts of User:Bobblewick, many automobile articles include all sorts of local units, from feet to horsepower. It would be wonderful to specift, say, [[142 hp]] and have it rendered as "106 kW" to metric folks. Or use curly brackets or some other symbol to set off auto unit conversion. Another useful conversion would be currency - put in [[US$10]] and have €8.22 show up. --64.80.135.178 18:14, 2 Sep 2004 (UTC)

I also agree for most of the units, but I see a problem for currency: exchange rates differ over time, and even within one currency we talk about 1970 dollars, 1900 dollars etc. For historical articles, manual conversion seems best.Lbs6380 18:46, 13 Feb 2005 (UTC)

The only way I can see this working is if the author also includes a hint of what unit to convert it to and how many significant digits the result should have. Distances at sea are measured in nautical miles; long distances on land are measured in statue miles; sports, shooting, and gunnery use yards; vertical distances are always feet, never yards; surveying uses chains; people are measured in feet and inches (at the same time!); rainfall is in "tenths"; almost everything else is feet, except when it's inches. Sub-inch measurements in some fields are binary fractions; in other fields they are decimal fractions. Converting the other way also has problems: rain is in millimetres; snow is in centimetres. As for significant digits, should 90 feet be converted to 30 m, 27 m, 27.4 m, or 27.43 m? These decisions are hard enough for a human editor to make. I can't picture a simplistic algorithm making satisfactory conversions more than about half the time. Indefatigable 23:46, 27 May 2005 (UTC)[reply]

I am a metric guy recently moved to USA and I am doing my best to learn the Imperial stuff. I know that, except for those contributing to politics, our fellow Americans are smart people who will actually agree to a stronger USA metrication and who already do their best to learn the SI. I bet most of the American Wikipedian would agree hat using Wikipedia as an engine for USA metrication is a good idea.

Still, suppose you're math challenged, the kind of person who is considered the target of our work, be it a poor African or a poor American, who missed the school for whatever reason, but discovered that knowledge is power and came to Wikipedia just to know. He, as everyone else, should see the measurements in metric (), but moving the cursor over the measurement, he should be able to see the value in his custom measurement unit, sent into an ALT commentary. If he is doing the effort to see the custom value, than Wikipedia is a dead end. Otherwise he will learn metric or at least will get used with the idea that real stuff also come in metric.--Luci Sandor

I would like to see a feature that would convert everything non-SI (feet, miles, Fahrenheit, etc.) on a page to equivalent SI units (m, km, C). You could argue back & forth whether the reciprocal feature would be required (convert all SI to non-SI units). At the very least, I hate seeing BOTH units up there, e.g. "blah blah blah 100 feet (30.48 m) blah blah". It makes the text so difficult to read. I will leave it up to others to decide what units should be supported and which should not be supported.

What about American phrases like "temperatures were in the triple digits". Presumably this refers to temperatures above 99F. What is the equivalent SI phrase? Should it be translated to "temperatures were above 38C". Perhaps, but that's impossible to do automatically But it illustrates the difficulty of presenting a page in the user's choice of SI or non-SI systems. It's just one of a million reasons for the entire world to abandon all systems except SI, but of course that's not going to happen anytime soon.

There are a lot of Wikipedia pages that have tables of min/max/average temperatures and precipitation. For example, here's one for Iqaluit: https://en.wikipedia.org/wiki/Iqaluit#Climate. It is VERY difficult to read such a table, because everything is in both measurement systems. It would be so much easier to read if it was SI units only (an American might say "it would be so much easier to read if it was in US customary units only"). Both people would be correct - having both sets of numbers doesn't help anybody read and process the information. I have noticed that there seems to be a standard style for presentation of climate data in the Wiki pages. Is there a style class called "climate"? If so, would it be possible to have a button on each climate table that would flip the values between SI and non-SI? I guess that would have to be done with a bit of Javascript. But here's a better way to manage this without javascript. Put a button on every page for "SI" or "non-SI". If you click the "SI" button it would re-load the page with a URL query parameter, e.g. ?si or ?nonsi parameter. When the page loads, it checks for the ?si or ?nonsi parameter and converts all of the numbers on the page from one system to the other.

Take it one step further to propagate the setting through all Wiki pages. When the page loads, if the ?si parameter is present, then modify every Wiki link on the page to include the ?si parameter as well, so as you crawl through the Wiki pages, that setting would follow you every step of the way, through every link. Of course, every page would have a "SI/non-SI" link on it to toggle/disable the setting. It would trigger a re-load of the page and modification (or not) of all of the links in the page.

That method means you wouldn't have to log in to access your SI or non-SI preferences.

Back to the original problem of what units to display... Automatic conversion is going to end up cluttering the text with unnecessary decimal places. If someone writes "it's about #1000 feet# long" and Wikipedia converts that #1000 feet# to 304.8 m, it's going to read "It's about 304.8 m long", which then makes the use of "about" silly. If "about" is used, then it should read something like "it's about 300 m long". But then again, that's not what the original author said, is it? Same for miles and many other units. If you write "it's #23 km# long", is it really exactly 23 km? If so, then the conversion text should read "it's 14.29 miles long". But that seems silly, it reads better as "it's 14 miles long". But what is the overall context? The precision AND context of the original number must be considered when converting to the 'other' system. Whenever you play fast & loose with the rules of conversion, you have to ask if it reflects the sense of what the original author said.

I think the rules for precision could be hard-coded for specific things like temperature (in the context of weather) for conversion between Celsius and Fahrenheit. For weather, you could say that "100 F" should be converted to 38 Celsius, i.e. to the nearest degree. For scientific documents, you would have to use more precision, e.g. conversion of "#-273.15 C" to "-459.67 F". But if C has 2 decimal places, does that mean that F also needs 2 decimal places? Perhaps not. -- jag

Pronunciation option

I have noticed on several articles that have pronunciations use different pronunciation keys. For example:

IPA is the standard pronunciaton key, but it is difficult to understand by novices (English-speaking ones chiefly), and it uses characters which may not be supported by all users.
X-SAMPA is an ASCII version of IPA, but it also is difficult to understand.
Most dictionaries use a system that is similar in most dictionaries.

Would it be possible to create a feature similar to the “dynamic dates” for pronunciations? For example, all pronunciations are written in X-SAMPA but displayed according to a preference set by the user.

"Incorrect" quotes

[This may be a bug rather than a feature request .. please advise.]

I am a bit surprised that although the text of Wikipedia articles is proportionally-spaced, the quotes generated are those of a monospaced font.

Any reason why "foobar" doesn't generate “foobar”, and 'foobar' doesn't generate ‘foobar’? The matching quotes are surely what the writers intended?

Mfc

I’m a bit shocked at the lack of response to this question. Even Microsoft Word gets matching quotes right, and the Wiki shorthand specifically calls out quote and double-quote notation. Why crowbar straight quotes into text which is displayed in a proportional-spaced font? I suppose we can fire up a ’bot to fix the ugliness, but surely it would better to keep the more editable notation in the ‘raw text’ version of the articles? -- mfc

Don't be too discouraged—most posts here don't get much response. As to your question, curly quotes are rarely used on the web. One reason is that they aren't in the Western European encoding, and UTF-8 hasn't hit it big on the web yet. Thus we have to use entities like you have, which are a pain to deal with. Still, we usually don't have to work with HTML source here, so I think your suggestion is a good one. But that's why most people aren't used to them on the web. --Spikey 19:43, 18 Mar 2004 (UTC)

OK, thanks for the response. I've been using the curlies on my webpages for several years now, and haven't had a single complaint from viewers, so I think all the common browsers handle them. And they seem just the thing that Wikipedia should be handling in its formatting becuase they are such a pain to enter manually (‘--’ to a proper dash would be good, too :-). mfc

Most users never complain about anything on web sites, even when they know the webmaster personally. Drives me nuts that I don't hear about broken links or mangled formatting or missing images etc. for months. I doubt that anyone would even think to complain about weird (or non-)display of quotes. :-) Just FYI. Elf 02:40, 31 Mar 2004 (UTC)

At school, a couple years back, we browsed with Navigator 4.x on Solaris, and all those “clever” curly quotes looked like question marks. I always found this humorous, imagining a very confused writer. I haven't noticed it on other browsers/platforms since then, AFAIK. Anyway, I tend to prefer the straight quotes. Kevin Saff 17:34, 19 Apr 2004 (UTC)

Now that Wikipedia endorses typographically (almost) correct dashes w:Wikipedia:Manual_of_Style_(dashes), it's definitely time to look at quotation marks and apostrophes.

There's talk about having wikipedia automagically convert double-hyphens to n- or m-dashes. Quotes and apostrophes should be even simpler from the user side, because you don't have to type in any special way. From the programming side, it's a bit more complicated, because it has to account for things like this: he said ‘that was in the ’80s, don’t you know?’ And of course, the rules are different in each language.

Smartypants is Perl software that does this right at http://daringfireball.net/projects/smartypants/. It's free, but not GNU licensed, I think. Might be good inspiration, even if it's not directly usable.

Textile also includes smart quotes in PHP http://www.textism.com/tools/textile/. —Mzajac 20:21, 6 Sep 2004 (UTC)'

As pointed out above, Wikipedia already uses many characters outside the range of basic ASCII: dashes (—, –, −), arrows (↑, →, ⇒), Greek letters (α, β, γ), various symbols (×, ∈) etc. The argument that some browsers will not render proper quotations marks correctly thus seems quite weak, since those browsers will already have lots of other problems with rendering Wikipedia content.

All modern browsers that I have come across are able to render curly quotation marks properly, including text-oriented browsers such as Links and Emacs-w3m, which will render them as `foo' or "foo" when used on low-end terminals.

http://www.deepwood.net/~drlion/links-quotes.png

The screenshot demonstrates that curly quotes cause no problem with modern versions of Links. On the contrary, using straight quotation marks can cause problems with correct setups. This is a real problem for people who use fonts like Donald Knuth’s Computer Modern (made popular through TeX), which causes straight quotations marks to be rendered as primes or double primes intended to be used in math expresions set in italics. This is demonstrated by the following screenshot.

http://www.deepwood.net/~drlion/computer-modern-quotes.png

These characters have been in Unicode for well over a decade [6] and in HTML for almost a decade [7]. It’s time to move on.

— Daniel Brockman, 16:10, 1 Jan 2005 (UTC)

#quickbar {position: fixed;}

What do you think about this? en:User:Ilya

Sounds good to me. Noldoaran 02:55, 9 Mar 2004 (UTC)

New features for extended image markup

First of all, thanks to JeLuF for this great new feature!

It'd be nice if images could also be centered as well as left/right aligned.
I would also like to be able to include links in the caption (internal and external)

thanks, Dori | Talk 17:20, 1 Feb 2004 (UTC)

I love the idea! Ruiz 09:30, 3 Feb 2004 (UTC)

Alt, title, and caption text in extended markup

I think more than one piped text should be assigned to the title, alt, or caption text. What I mean is:

[[Image:foo.png|frame|Caption text]]

will currently make an image with "Caption text" as the alt tag, title tag, and the visible caption at the bottom of the frame. It is impossible to make one different from the other with the current markup (without adding HTML), but people want it and it is the way the tags are meant to be used, and it should definitely be possible with the extended markup. I propose that one piped text behaves exactly the same as it currently does, but any additional piped text become one or more of the other types of "captions":

[[Image:foo.png|frame|Alt and Title text|Displayed caption text]]

[[Image:foo.png|frame|Alt text|Title text|Displayed caption text]]

This seems like it would be easy to add to the code and would be backwards compatible. - Omegatron 13:54, 21 Jun 2004 (UTC)

Maybe Title text should be the last item, as it seems completely optional in the Wikipedia context. The title="" attribute is meant for additional information, and there seems no point in repeating text that's already in the caption on the page. —Mzajac 21:14, 6 Sep 2004 (UTC)

Yeah I guess title text wouldn't really have any use beyond what the alt and caption cover. perhaps filename? Hmm... Look at this discussion: [8]. - Omegatron 03:00, 7 Sep 2004 (UTC)

TeX Markup Bug

In en:Wikipedia:WikiProject_Mathematics, <math>\int_0^\infty e^{-x^2}\,dx</math> renders thus (in Mozilla 1.4, Mandrake Linux 9.2) with the preference "HTML if possible, else PNG":

-- Paddu 08:25, 1 Mar 2004 (UTC)

No distinction between second level and third level headings

Headings are more distinct in MediaWiki 1.3- h1 and h2 are underlined and h3-5 differ more in size, you can try it at http://test.wikipedia.org/. -- Gwicke 17:19, 14 May 2004 (UTC)[reply]

HTML Tags

Please add some more HTML tags & attributes. eg SPAN, and attributes: eg 'title'. Also, the main page doesn't validate in w3c.org's page validator. Nichalp Partial precis by MrJones 18:13, 2 May 2004 (UTC)[reply]

More important missing tags (to me) are <del> & <ins> for talk pages, and <acronym> & <abbr> for articles. — Jor (Talk) 20:51, 29 Mar 2004 (UTC)

del and ins are in 1.3, span seems to have many enemies for some reason (while font is still allowed, yuck). -- Gwicke 17:16, 14 May 2004 (UTC)[reply]

Wikitext needs a way to enter blockquotes. And typing "<blockquote>" shouldn't disable auto-paragraphs.

Everybody is using colons for indentation, which make ridiculous broken definition lists -- yuck.

I'd like to see <cite>, too.

—Mzajac 20:37, 6 Sep 2004 (UTC)

HTML is un-wiki and should be avoided, I think. Markup should be easy and non-complex, creating more uniform look. We could add wikimarkup corresponding to the more wanted HTML tags, if they are very useful. — Sverdrup 18:14, 30 Mar 2004 (UTC)

To get special effects on text, I'm sure HTML markup can be included. Even a 6yr old can understand HTML! It should be optional like wikipedia tables currently.

There are some very good reasons not to use "special effects on text", mostly relating to accessibility, but also to do with the difference between semantic and presentational markup. If there are specific items of markup that seem they would be very useful, we could certainly add wiki markup for them - which may or not be similar to HTML. They should not be thought of as HTML, however; IMHO, we should have a disclaimer on such markup saying "any resemblance to HTML is purely coincidental" (disclaimer: I may be joking; partly) See also MeatBall:FormOverContent. - IMSoP 19:18, 5 Apr 2004 (UTC)

I love the fact that I don't need to get involved with HTML. And I have taught myself HTML in the past, set up websites and used Dreamweaver. My Wikiholism is almost entirely because of the lack of HTML involved. I think issues surrounding an increased HTML integration cut to the very core of this project and I hope Jim Wales would be informed of any moves in such a direction for a serious consideration of what it means for the openness of this project.

As for even a 6 year old can understand HTML, I would ask you to consider the problems/questions many people seem to have dealing with the very simple interface you have now. --Bodnotbod 20:30, 5 May 2004 (UTC)[reply]

Cascading style sheets

Macros

Let's add something to display number of articles in all languages --Ilya 06:35, 21 Dec 2003 (UTC)

That's a real good idea and would be a very nice thing to have at our future portal at http://wikipedia.org/. But we should get rid of the term "article" in the software and replace it with the generic "contentpage" since few other Wikimedia projects call their content pages "articles". --Maveric149 20:47, 21 Dec 2003 (UTC)

Contentpage is not a word, it is a typo. I think you mean "content page". -- Tim Starling 06:53, 13 Jan 2004 (UTC)

Neither is Recentchanges or NUMBEROFARTICLES and yet they are used in the software. Users, of course, would see "Content page". --mav

So they should be {{Number of page languages}} and {{Total number of page languages}}? MrJones 15:43, 2 May 2004 (UTC)[reply]

Why not {{eo:NUMBEROFARTICLES}}, {{w:NUMBEROFARTICLES}} or anything of the sort? / Mats 21:28, 28 May 2004 (UTC)[reply]

need for a CURRENTDATE macro

There are macros for CURRENTDAY, CURRENTMONTHNAME etc; but not for the current localized date. In English and most languages you can simply build it from the other CURRENT* macros; eg in Spanish: CURRENTWEEKDAY CURRENDAYNUMBER de CURRENMONTH.

However, that is not the case for all languages; in French for example the first of each month is spelled "1er" and not just "1"; in Walloon it is even a bit more complex, there is like French a special case for first daye "1î", and also, like in Spanish, and article ("di") between day number and month name; however, that article changes to "d' " depending on the vocalic context: it is "d' " for all month names starting with a vowel (avri (april), awousse (august), octôbe (october)) and also for all day numbers ending in vowel (1î, 2, 3, 20, 22, 23).

In the LanguageXx.php there is a section that allows defining how the date is built; I modified it to fit the above rules and it works very well; now the only thing missing is a macro so that the output of function date() for the current date could be displayed directly in a wiki page.

Style sheet support for tables

Ugly indented table borders have to go! There's a demand for this: many people are adding id="toc" to their nav boxes (which incidentally breaks validation on pages that also have an actual TOC).

Having something like styles for "table.data", "table.infobox", and "table.navbox" built into the site style sheets would give us a consistent look for this stuff which is currently very visually diverse throughout the wikipedia. And some graphical effects have to be achieved by putting inline styles on individual rows or cells, so table code gets very cluttered with CSS. This could be much shorter in a site style sheet.

Finally, "tr.odd" would let us add nice, consistent stripes for readability of data tables, like here: w:Romanization_of_Ukrainian.

Depending on page's section, Special Variables: Section

I would like to request a special variable {{SECTION}} where it would automatically include the section number of where the variable was put. This allows linking of editing sections directly. This would be particularly useful, such in the case of en:Wikipedia:Votes for deletion and en:Template:sect-stub. -- AllyUnion 10:10, 10 Dec 2004 (UTC)

Either that, or edit by anchor. -- AllyUnion 10:14, 10 Dec 2004 (UTC)

Pipe trick for commas - place names

Piped links can be created that suppress the part of an article title within parentheses, simply by placing a single pipe. For example, Paul Williams (Architect) becomes Paul Williams. It would be tremdously useful if a similar trick could be created to suppress the part of an article title after the first comma. Most cities include the state or country name after a comma (and neighborhoods of a city may have two commas). But in most instances, the full article name is not desirable, because the state or nation is obvious from the context and would be repetitious. Rigth now it requires retyping the city name after a pipe. A shortcut that allowed just the city name to be displayed by adding one or two characters would be a big help. -69.105.58.197 22:14, 25 Dec 2004 (UTC) (Willmcw in Wikipedia)

Unsorted

Feature request: Adding syntax to avoid double typing for non-literal wikilinks

en:User:Morwen raised this on the IRC channel, and it seems like a good idea to me: There should be some Mediawiki syntax to let you do [[United States House of Representatives|House of Representatives]] without having to type in House of Representatives twice; e.g., [[United States {House of Representatives]], [[{{Reading}}, England]], or [[{{John Smith}} (UK politician)]].

It was noted that if {{}} should be kept separate, say for use with variables, and another suggestions was "Reading", England -- BCorr ¤ Брайен 20:52, 23 Dec 2003 (UTC)

I discovered recently that some of these eventualites are already covered by using [[Article name|]]. For instance: [[Foo (bar)|]] displays as Foo. It also works for namespaces, as in [[Image:Foo|]] -> Foo. A more general syntax would be nice, but it would have to avoid becoming too non-obvious for editors who hadn't come across it before. Of course, it could always be an editing macro that was expanded on save, so that, say, [[United States ||House|| of Representatives]] automagically became [[[[United States House of Representatives|House]]. - User:IMSoP ~17:30, 31 Jan 2004 (UTC)

[[Category:somecategory|]] does not work, I wish it did. --Ssd 11:58, 5 Jun 2004 (UTC)

Utilisation of the "link" HTML tags "link" for linking to subsections of documents

The majority of the browsers now support the "link" tags natively or with plugins. It will be a great idea to add generation of this links for the articles (section, subsection, authors, bookmarks,...). See The 'link'-Element in (X)HTML and Documentation about link tags for more information and examples of utilisations.

To contact me : shift@NOSPAM.free.fr

What does this do that [[abc#xyz]] doesn't? MrJones 11:33, 8 May 2004 (UTC)[reply]

Article display interface features

Link checking

Broken external links, automatic "updated" appendage

Would there be a major perfomance hit to check for broken external links? They couldn't be checked at request-time, but perhaps a periodic cache would work. Then broken links (no server response or 404) could be displayed differently, possibly by changing the color, similarly to internal links.

Also, would it be possible to add an option to external links to have them display the date last updated? Again, it would need to work through a cache, I'm sure. What I envision is a syntax like:

 [http://www.domain.tld/ u Some website]

to generate:

 <A HREF='http://www.domain.tld/' class='external'> Some website </A> (updated 19:02, 4 Apr 2004 (UTC))

based on the HTTP response header. When certain pages stop being updated, it's useful to know that it's old. --Spikey 19:03, 4 Apr 2004 (UTC)

Another useful feature would be hostname display (similar to how slashdot handles it) showing the hostname in brackets after a link. --WhjiteDragon

Indicating links to pages marked with stub and disambig messages

Could we add a preference for marking links to {{msg:stub}}— and {{msg:disambig}}— tagged pages? This way, if an article is below the stub threshold and not tagged, the editor ought to check if it's a stub, and if so tag it. If it's marked as a disambig page, the editor knows to check the page and disambig the link. This saves checking every brown link on the page (which I always do). Spikey 19:56, 4 Apr 2004 (UTC)

"Tagging" a page is nothing more than adding one of those messages to them. Those pages don't have any special status, and indeed I don't think they should because messages get created, deleted, and changed all the time. Dori | Talk 20:42, 25 Apr 2004 (UTC)

Actually, marking disambigs when previewing articles prior to their submission would be awfully convenient, especially concerning articles that one doesn't expect to be disambiguations. -- Itai 23:27, 5 May 2004 (UTC)[reply]

Full ack. Disambiguation pages are marked by a Template, but its a very special one. We could replace it with a MediaWiki-Message - anyway marking links to disambiguation will improve the quality a lot because you see many more wholes where normal articles seem to be. -- Nichtich 20:34, 1 Jul 2004 (UTC)

I think it would be very convenient if links to stubs/disambigs were a slightly different color. Readers would be able to avoid clicking on links to stubbed articles which don't contain much information. Meanwhile, contributors would know which linked articles are most in need of expansion. And, as Spikey said, it would lower the number of inappropriate links to disambigs and make it easier for editors to find untagged stubs. Intangir 10:04, 6 Dec 2004 (UTC)

Unsorted

Changes to most of the user interface ;)

Here's some stuff I think would make great improvements without necessarily requiring much work.

Browsing

If page is longer than say, 16 or 32 K (has to be a power of two :) or if specifically requested (preferences or article text) show just the part before the TOC. Add after it a collapsed list of section titles, with a button to expand. Load the section "dynamically" in the browser. It shouldn't be too hard to do (there is obviously already a way to grab a single section) and it would reduce pain of bothe server and client side. Imagine what it would do for the village pump.

Implementation difficult, usability arguable

Page history

Use an iframe for displaying older versions and diff files. Zocky 16:25, 12 Dec 2003 (UTC)

FineTim Starling 07:03, 13 Jan 2004 (UTC)

How about a vanilla frame? It'd be good to be able to resize the two sections. MrJones 18:13, 2 May 2004 (UTC)[reply]

Recent changes

If there's less than three changes per article, don't collapse, just indent

Arguable, user option?

Use an iframe for displaying older versions and diff files.

Arguable, clutter?

Provide an edit button for the page displayed in the iframe. When clicked, go to editing. After saving or cancel, return to recent changes.

Sounds good

Add a 'user contribs' links for every change

Zocky 16:25, 12 Dec 2003 (UTC)

Arguable, clutter. User option? Tim Starling 07:03, 13 Jan 2004 (UTC)

Watch list

Make the watch list exactly like recent changes, just limited to the chosen articles.

Implementation difficultTim Starling 07:03, 13 Jan 2004 (UTC)

User contribs

Make user contribs exactly like recent changes, just limited to the changes by the user.

Implementation difficult Tim Starling 07:03, 13 Jan 2004 (UTC)

Preferences

Make most of above changes optional.

Please comment and if any of this has been suggested and/or rejected, please provide links. Zocky 16:25, 12 Dec 2003 (UTC)

My comments are above in italic. -- Tim Starling 07:03, 13 Jan 2004 (UTC)

Standard markup for map coordinates of places?

Perhaps we could have a standard format for map coordinates (i.e. latitude and longitude). Each article on a geographical feature could have such a field, something like [latlon:12.345N,67.890E] (in decimal degrees) or [latlon:12'34'56S,98'56'10W] (in sexagesimal degrees). With an upgrade to the search engine, this would enable searching by geographical location, or a "find other stuff near here" link. Another possibility would be to render the field as a clickable link to http://www.multimap.com or world map or whoever the favoured map provider happens to be. We have a similar system in place for ISBNs, so could we do it for map coordinates? -- Heron 12:56, 26 Jul 2004 (UTC)

Geographical information is more complex but implementable. See GALILEO Masters 2004 -- Nichtich 19:20, 26 Jul 2004 (UTC)

That's very interesting. I hope our application is successful. Let me know if I can help: for example, if you need a native English-speaker to proof-read any of your documents :-) -- Heron 20:08, 26 Jul 2004 (UTC)

Category feature requests

category columns and TOC

When a category has a huge number of subcategories or articles, it would be helpful if these were broken up a bit.

A CompactTOC would be helpful if there are several screenfulls.
DONE tabular columns instead of a text blob might be helpful
with a very huge number of items, perhaps limit number of items per page or group by first letter(s?) of sort key and split the category listing into multiple pages (or should we do this manually?)

Special:Categories format

Currently en:Special:Categories is just a numbered list in a single column. Perhaps a multicolumn view would be more useful? Any heirarchy here should really be enforced by the users assembling the categories, however.

Display the sort key instead of article name

Currently, the category sort keys are not displayed. Would it be possible to add an alternate category view that displayed the sort keys instead of the link targets? Perhaps the category article could specify a default in a tag if the user didn't pick a view?

The two lists in categories should display sort key, rather than the names of articles and categories. Alternatively, provide additional parameter for displayed text. W:Francis II, Holy Roman Emperor could thus include:

[[category:Emperors of Austria|1804|Francis I (1804-1835)]]
 [[category:Holy Roman Emperors|1792|Francis II (1792-1806)]]

Zocky

I think that's a great idea. Josh 01:37, 29 Sep 2004 (UTC)

Watchlist should show addition/removal of articles in watched category pages

Currently, watching a category page means you only see changes to the category description. It would be very useful to also be able to see when articles are added or removed from the category, even though the edit is made on the individual article and not the category page. This would be a big help to editors trying to keep track of a general subject. — Gwalla | On Wikipedia 18:34, Aug 17, 2004 (UTC)

Flattened view

Categories should have a "flattened view" option that lists all articles in subcategories, subcategories of subcategories, etc., alongside articles that are in the main category proper. Perhaps as a related Category_flat: or Category_all: namespace. — Gwalla | On Wikipedia 18:34, Aug 17, 2004 (UTC)

Search within categories

Being able to restrict search results to those within a specific category would make them far, far more powerful. Even better would be the ability to sort results by category.

Extracting Specific Topics from Wikipedia

It would be nice to mirror only 1 category from Wikipedia on a personal Homepage. That can be achieved by offering Database dumps of every category in a separate file. Or it can be used a program that extracts one or many categories from the general sqldump. Suggestions, already possible maybe ? Thanks. --217.95.7.4 18:30, 28 Sep 2004 (UTC) Additionally it would be great to have a list of selectable categories at the end of each Edit Box. That way a lot of Wikipedians would use this feature of Information Retrieval.

Lists related to categories

Currently the kludge

[[Category:category name| ]]

that is placed in a list page to force creation of a link within the category page treats the list as a member of the category and places link in the list in the category page.

This is cognitively jarring, as the list and the category should cross-reference each other rather than containing each other as listed elements. E.g., w:Category:Medal of Honor recipients currently has w:List of Medal of Honor recipients within the list, implying that the list recieved the medal. Which makes my brain hurt.

In addition, use of this kludge has induced mistaken usage, causing the back-link to be misformatted (as, e.g., a bullet with no text) or to appear sorted within the list itself (i.e, someone didn't use it right and just added the list to the category and figured that was the intent even if it didn't quite work the same), rather than placed before the A's.

The Category page generator should instead place the cross-reference link above or below the list, in a References, or Cross-References, or See-also, or Related Pages link section. Blair P. Houghton 20:45, 15 Jan 2005 (UTC)

Automatically Generated Navigation Bars

I think it would be great if it was possible to automatically generate a navigation bar from a category and its subcategories.

For example, take the navigator bar below (copied from w:Template:InuyashaCharacter):

InuYasha Logo

InuYasha characters

Edit

Listed in approximate order of appearance.

InuYasha's Group

Sesshōmaru's Group

Sesshōmaru | Jaken | Rin

Naraku's Group

Naraku | Kohaku | Kagura | Kanna

Other Detachments of Naraku (in order of creation)

Miscellaneous Recurring Characters

Kikyō | Kaede | Sōta Higurashi | Kōga | Tōtōsai

Miscellaneous Non-Recurring Characters (not sure about order)

Assuming that each section (InuYasha's Group, Sesshōmaru's Group, etc.) were a subcategory of a main category (in this case InuYasha characters), I would like to be able to insert a command into an article in one of the categories to give it a box like this. Perhaps another possibility would be to have the box only show items in the article's own subcategory. However, it is important that a person be able to rearrange items in the box. In fact, that would be a good feature for categories, in general. This would allow categories to completely replace templates, as some people (see en:Templates for deletion) seem to want.

Josh 02:06, Sep 29, 2004 (UTC)

Category Family Tree

I would like if at the top of each Category: page was a brief 3 or 4 level Family Tree style table, showing an outline of the structure of the higher super-categories and lower sub-catgeories. Several Category pages have manually added trees, but it shouldn't be difficult to autogenerate them. Particularly useful would be being able to see cousin categories without having to search up and down the generations. Seabhcan 16 Oct 2004.

Promoting / Syndicating content

"Email this article"

I'm surprised this hasn't yet come up - I did not find any prior mention of this - but it would be nice if MediaWiki offered an "Email this article" feature. -- Itai 12:33, 5 May 2004 (UTC)[reply]

What would this be useful for, more than using a standard email client to email the article's URL? -- 130.49.222.251 08:49, 4 Jun 2004 (UTC)

I like this idea, alot of news sites and stuff have it. People have sent me articles using them. It would be a good way to "spread the news" of Wikipedia and its sisters. -- Siroxo 12:09, 11 Jun 2004 (UTC)

If and when a "PDF output" option becomes available, this might be a viable option. in the meantime, emailing HTML is just too horrid, not to mention a security risk. --Phil | Talk 17:04, 11 Jun 2004 (UTC)

PDF Output (and also bundling articles to a reader, and also LaTeX-Output) is possible with wiki2PDF: http://wiki.auf-trag.de/ --Lambo 10:07, 26 Nov 2004 (UTC)

I don't see what's so "horrid" about e-mailing HTML. It's a standard practice those days. HTML is a security risk only if HTML is designed to be malicious. Since HTML will be auto-generated by WikiPedia code, there is no security risk. kjk 12:31, 19 Jul 2004 (UTC)

Video on Wikipedia? BitTorrent distribution method somehow incorporated into MediaWiki?

Couple random thoughts: http://en.wikipedia.org/wiki/Talk:Powered_paragliding

Bugs

Unsorted

Chinese Wikipedia

As the plus '+' sign is now allowed in titles, I tried to make a search with "C++" in the search box in the navigation bar. It does not work and displays article not found and it says the search string is “<a href="/wiki/C++">C++</a>” <a href="/wiki/Special:Allpages/C++">[索引]</a> (quotation mark including) This problem seems to be unique in Chinese Wikipedia as I tried with a couple of other Asian languages and they all work. SYSS Mouse 03:54, 10 January 2006 (UTC)[reply]

Capitalization in simple: interface

When logged into simple:, the "i" in "Guanaco my talk personal settings my watched pages pages i worked on log out" needs to be capitalized. Guanaco 17:17, 29 May 2004 (UTC)[reply]

Reverts I am shown to have done but did not actually do

On en:User:Vicki Rosenzweig user page I am shown to have reverted to a previous entry and then rereverted to the original. I did not touch the para which was thus reverted, I merely looked at it. Is there something wrong with this page or with my sign in? It is worrying me, and I have been asked why I have reverted. Would appreciate your looking into this. -- Dieter Simon 03:01, 17 Mar 2004 (UTC)

image del

On zh:Wikipedia:????/?? image no del. Help!!!--Shizhao 02:30, 22 Mar 2004 (UTC)

Try this:

Click the del link next to the image, give a reason, and click the button. As expected, it gives you an error message.
Edit the URL of the error message, adding "&wpConfirm=1&wpForce=1", and press enter.
It should then report that it completed successfully.

Czech Wikipedia

~~Please, look at cs:Wikipedie:Chyby. Reports are in English.~~

Most of those could probably be fixed through changes to LanguageCs.php and have a developer reload it. Make sure you talk it out with the other contributors, and maybe contact the person that made the changes in the first place, to make sure you all agree on them. Dori | Talk 20:37, 25 Apr 2004 (UTC)

Italian Wikipedia

I copied a Timeline from the english wikipedia (w:Template:Timeline_Tour_de_France_Winners), into the italian wikipedia w:it:Template:Cronologia vincitori del Tour de France). Seems on the italian version there are problems with characters like éàì etc.

Snowdog 23:29, 17 Jul 2004 (UTC)

Dutch Wiktionary

Bug nl:1

I am busy creating articles for each language; one in Dutch, English and one in the original language. I cannot create an article for "?????". I get a message that it is an illegal name. I tried to change the en: URL by replacing en: with nl: this did not work either.

Bug nl:2

There is a problem with DNS. [[9]] will give you that there are problems with the database while everything is fine on [[10]]. This is in contrast with nl:wikipedia where the "www" will give you the "Hoofdpagina".

Sidebar disappearance

When I compare two versions of an article, the sidebar links is gone, but not the logo. Is this intentional? I use floating sidebars in standard skin with a firefox browser. \Mikez 18:27, 9 Jun 2004 (UTC)

Listing the first of 0 items

Any special page forced to display an empty list, will tell you: "Showing below 50 results starting with #1." Obviously, these ought to say something like: "No page matches.". Aliter 23:36, 11 Jun 2004 (UTC)

Article manipulation

"Move page" bug?

When I try to move a page on the Italian wiki, it seems that the corresponding talk: page is never moved along, even if the checkbox is checked, no name conflict exists, and so on. Could it be because on international wikis the namespaces are different, and this piece of the software uses fixed ones? For ref. the talk namespace is "Discussione:" instead of "Talk:". At18 15:45, 14 Dec 2003 (UTC)

Failed to move a non-existent talk page

When changing titles, I tend to get a lot of "The corresponding talk page was not moved."-messages. Usually because in reality no talk page is present at all. This message doesn't help, here. Given information would require that this message only comes up when failing to move an existing talk page. A non-existent talk-page ought to result in "There was no talk page.", or similar. Aliter 23:36, 11 Jun 2004 (UTC)

Suggest adding to wishlist when viewing non-existing article

It would be very convenient to be able to just click on a link to add a non-existing page to the wishlist.

Do you mean the watchlist? - Gwalla 21:13, Jul 5, 2004 (UTC)

Markup

Inconsistent treatment of bogus Section Header

Just noticed a curious situation. The current bottom of the article reads as follows:

22 [[msg:]], {{msg:}}, {{{msg:}}} as well as the WikiTemplate: namespace

Moved to Message substitution

====Article title bug?====

Have a look at en:MellieÄ§a, click page history, what links here or some other link, notice the name of the article. Dori | Talk 22:40, 15 Dec 2003 (UTC)

This is typical of somebody putting non-latin1 characters into a link on a latin-1 wiki and clicking it. The outgoing link is converted to utf-8, but it doesn't understand them coming in. --Brion VIBBER 23:14, 15 Dec 2003 (UTC)

The first line (in bold) is the title of what Wikipedia thinks is the final section, because the extra "==" have confused it. So you would think that this was all one section? If you try to edit that "final" section, you only get the first two lines because the editing code obviously takes the "==" as delimiting the next section. So the software has its cake and eats it: there's one section or two depending on how you look at it :-) BTW, I'm going to fix the bogus Header once I've saved this edit but it'll still be there in the History. Phil 12:50, 16 Dec 2003 (UTC)

What links here: bogus links shown

Not always correct - this is a known bug

Two odd behaviors

I have experienced two odd behaviors using Wikipedia. I'm not sure if these are bugs in the software, or something strange about my system. I'm using IE 6.0.2800.1106 SP1, running on a Windows 2000 OS.

It seems that whenever I make any change to my preferences, I will have to log in again at the next session. I have "Remember password across sessions" checked, and it works fine so long as I don't make changes to my preferences. If I do, I will need to log in again for the next session.
When I'm editing, using the text box, there is an issue with the text box scroll bar. If the slider is at the top of the bar, and I click anywhere beneath the slider, it jumps to the bottom of the bar, and the document follows. Then, if I attempt to click above the slider, it sticks on the bottom. Very strange (and quite annoying).

Could someone let me know if they've seen these sort of things too? Or, can someone with a setup like mine let me know if they don't have this behavior?

Anthropos 05:45, 22 Jan 2004 (UTC)

I fear you need to re-install windows. You're not the only one to have problems with log in, but my problems are not the same as yours.

Non-English characters in English Wikipedia

I was trying to make an interlanguage link to the Polish Wikipedia. The title of the Polish article contained an "n" with an acute accent. The English Wikipedia changed the "n" to a question mark. Why not set the character set for the English Wikipedia to the set of all characters? --Juuitchan P.S. Aren't we are all sick and tired of looking up Unicode codes for Japanese characters, and then converting them to decimal?

Image deletion possible problems

I could not even delete the following image en:image:durrës small.jpg, but Delirium apparently was able to. Perhaps this is a browser-related bug (I was using Mozilla 1.5 under Win XP), or perhaps it has to do with the special character in the title. The other weird thing is that even after Delirium deleted the file, the thumbnail still shows up. Is this a bug or a feature? Dori | Talk 14:53, 13 Feb 2004 (UTC)

Caching problem? Try forcing a refresh (ctrl and r or similar). Angela

Freelinking to Wikisource

To freelink to documents on wikisource, you need to prefix the link by "m:Wikisource:" (ex. Wikisource:Constitution of the United States of America. Is this supposed to be like this? It seems that "source:" or "wikisource:" alone should be enough, and seems to fit better. —siro χ o 02:17, 12 Jul 2004 (UTC)

External links

Not really a bug, but addreses which uses { doesn't seem to work (an example: [11]) 129.11.77.159 12:20, 27 Nov 2004 (UTC)

Moved elsewhere or to be moved

[[msg:]], {{msg:}}, {{{msg:}}} as well as the WikiTemplate: namespace

Moved to Message substitution

Feature request: footnotes

Moved to Talk:Footnotes

Footnotes/Endnotes - a proposal for a new MediaWiki feature

There has been a lot of talk on WikiEN-l about the need for citations in articles. I tend to agree with that. But our current system of wiki refs only encourage the creation of footnote-like references to external websites (which is less than ideal).

I have put together a proposal that, if enacted, would create a more wordprocessor-like footnote system that could be used for all types of footnotes (web, ISBN, journal articles, and written out dead tree citations).

See and respond on:

Footnotes

Automatic edit war squashing

See Automatic edit war squashing

Pagination for longer articles

It would be nice, very nice, to be able to semi- automagically break up a longer article into separate pages when viewing. This could be handled somewhat like section editing is handled now. Here's the proposal: author inserts __PAGE__ in the wikitext where they would like to see a page break, then adds a __PAGINATE__ command at the top (much like __TOC__) to trigger pagination. If the parser sees __PAGINATE__ it splits the content at the page marker __PAGE__, slaps a simple navigator of the kind < Page: 1 2 3 4 > to the page, then -- and here's the best part -- it sends only the requested page content, while keeping the rest of the article in the cache...just in case. The nav links are the usual page url with a "&page=3" (eg) added to them. And Voila! juice 68.122.227.102 09:16, 3 Sep 2004 (UTC)

What would the advantage be of adding tags to split the page into multiple pages vs. just manually splitting the page into multiple pages (with different names) in the first place? --Ssd 11:47, 3 Sep 2004 (UTC)

doing it manually is the old way... more taxing, less opportunity for the working folks. automagic is the way of the freedom loving hackers! - that's why you should vote for it! (sorry, too much convention viewing!) Seriously, though, the advantage is that it's semi-automatic (author only inserts the tags) -- and it keeps the article as one cohesive unit with one title. For book-length articles, manual breaking into chapters makes sense... like in the 9/11_Commission_Report. That option is always available. juice 68.122.227.102 18:21, 3 Sep 2004 (UTC)

thumb|center

[[Image:|thumb|center]] to center thumbnails. I remember that this existed before but it doesn't now. Anyways, marking this as a request instead of a bug as I reported it as a bug before [12] but was told that this feature didn't exist at all. —Joseph | Talk 23:33, 20 Sep 2004 (UTC)

Enabling the instant revert button globally

I have been discussing with Angela the reasons behind disallowing normal users to use the instant revert button. Basically, there is no reason why an administrator can revert a page easily and a normal user is obligued to revert it by force (open > select history > click edit > save as). Angela's concern was that enabling it globally would allow vandals to revert fixes immediatly. However, this is an evitable situation:

We could simply have a timer that disallows simple users to use the revert button. Say that the timer is set for 5 minutes: if I revert a page, I can't use the revert button until 5 minutes have passed (as I'm not an admin, just a simple user). However, an admin is not constrained by this timer: he can use the revert button again and again and again without a time limit — just at it is now.

This can be achieved by comparing the timestamp of the user's last use of the revert() function on a certain page with the timestamp of the server; ie: user used revert() on X article at 14:00 09/20/2004 and the timestamp of the server is 16:00 09/21/2004: the user is allowed to use the revert() function.

—Joseph | Talk 23:32, 21 Sep 2004 (UTC)

Better idea: enable regular users to use the rollback button on anonymous users only. en:User:Neutrality

I just applied for adminship just so I could get this button. It should be available to everyone. It could cause problems because it makes revert wars easier, but wouldn't it also use up less bandwidth for revert wars? :-) There could certainly be little tech fixes in place to prevent its abuse. - Omegatron 21:55, 22 Jan 2005 (UTC)

A new way to edit tables / Separate table namespace

(I've crossposted this a few times and received no response. Maybe this is the right place for a discussion?)

I think tables should have their own namespace, as they are fundamentally different from articles and clutter up the markup.
I have an idea for a new kind of editor specifically for the table namespace, to make tables more easily editable in the spirit of a wiki.

Please see the discussion on en:Wikipedia:Proposal for intuitive table editor and namespace - Omegatron 15:29, 26 Jan 2005 (UTC)

Better diff handling of paragraph splits/merges with minor mods

When a paragraph is split or merged, and each part is slightly modified, it throws off the alignment of all other paragraphs in the differenced section, making far more text appear "edited" than was actually touched. The diff utility should recognize when consecutive new-version paragraphs map to the same original-version paragraph, or vice versa. --65.122.15.98 00:22, 24 Jan 2005 (UTC)

Indication of an image's copyright status

On lots of images that I see in Wikipedia articles, I often wonder whether they are GFDL images taken by a member, or nonfree images that might possibly be in need of replacement.

It would be great if there were an easy way to tell whether an image is "free" or not just from the article page, without actually having to load a page with the full-size image on it, wasting bandwidth. Perhaps you could have a version of the image-magnify link that would be green if an image has a "free" tag on it, or red if it isn't. This shouldn't be too hard. Perhaps some alt-text too on non-free images indicating their status.

Non-free images should simply be deleted; there is no excuse to have them around. --brion 05:55, 18 Feb 2005 (UTC)

I think the previous poster was suggesting that a coloured link would help spot the non-free images (those not explicitly marked as 'free'), which would be useful as an aid to checking and, if necessary, deleting them. --HappyDog 16:00, 26 Feb 2005 (UTC)

MediaWiki feature request and bug report discussion/Archive

Archived discussions

Other pages in meta containing feature requests

Feature requests

Unsorted

Protection against slowloris

WikiLearn or WikiQuiz

Page export for offline reading

Site export for Offline reading

Searching for wanted pages by category

Automatic datepage generation ála category pages

Inline Music Notation Markup

Collapsable TOC

Page protection improvements

Tooltip first few words of article when mouse is over link

Graphs and diagrams

Alternative construction of Red links

Links to jump to specific lines in diffs

Chinese Wikipedia— pages as traditional and simplified characters

Semantic Web features or a Web Service

Structured/Templated Types of WikiPages

Feature request: ability to hide spoilers

Lists and floating images

Keep user contributions longer (20 April 2004)

Initial wiki content, e.g. Help pages

Alternatives to simply deleting articles: flagging, no-archive, &c

Less permanent deletion option

Other flag options: extra content flags

User Talk

Redirecting Namespaces

Feature request: PubMED unique identifiers

Traditional and Simpified Chinese UI

More prominent Locked Database warning

Talk Page Helper formats

Pronunciation Details?

Variable request

Proper use of id Attribute in Special Pages

Restricting random page lookups to an individual category

Highlight/Right Click Wiki(pedia) Search

Saving Place on User Tab

Article editing interface

Edit summary: Forcing the issue through blocking blank entries.

Automatic wiki link renaming if article is moved

Split and Merge features

External Editing

Suggestions for improvements to editing

The way diff deals with moved blocks of text

Sections

allow choice of level for new Section

Editing whole sections

Feature idea: Return to TOC link next to section edit link

Option to Turn off Automatic Numbering on certain Tables of Content

Page preview inline (in an iframe) on the edit page

Edit hints

Recent Changes

Can Recent Changes display the top edit when hiding logged-in users?

Previews

Preventing bad edits

Red links problem

Squash consecutive edits

Previous changes

Proposal: showing size (# characters) of each edit

Searching Mediawiki

Wiktionary search in Wikipedia

Word stemming

PanWiki Search

More options for Search

Crossword puzzle search

Article manipulation (automatic)

Spell checker

Automatic addition of U.S. location data by Rambot

Maps added automatically to such articles

Disambiguation

Automatically show other meanings of article title

FTP upload for Wikibooks

Video

Automatic thumbnails for video

Thumbnails for video

Article manipulation (manual)

The Watchlist, and other page monitoring and user tracking