Jump to content

Wikipedia:Ignored feature requests

Add links
From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Brooke Vibber (talk | contribs) at 15:34, 28 March 2002. The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

This is a list of feature requests for the Wikipedia system.

FDL versioning

The text at the bottom of the input field does not mention which version of the FDL my comments will be released under: 1 only, or 1+. (This is important because the FSF is just closing comments on the FDL 1.2 draft). user:Novalis 2002/03/13. (BTW, sorry if I'm supposed to add stuff at the bottom instead of the top -- Galeon doesn't like long textfields much).

Improved diff

Wikipedia's diff is currently almost useless. A better diff would look like:

<p> We the people rich white males of the United States of America, in Order to form a more perfect Union, establish Justice, insure domestic Tranquility, provide for the common defense, promote the general Welfare, create a free encyclopedia, and secure the Blessings of Liberty to ourselves and our Posterity, do ordain and establish this Constitution for the United States of America. </p>

Red text: New stuff added or deleted. Non-red bold or strikeout text: Changed stuff. Python's Difflib will, given two sequences, tell you which elements are new, deleted, changed, or original. It's Free Software, and as of the lastest version, GPL compatible. It could be ported to PHP. user:Novalis

I really like this idea. However, wouldn't green be a better color for added text? That way one could quickly scan a page to see what was added or taken away. --maveric149
Agree -- user:Novalis 2002/03/13
Actually, we need something slightyl different so that color-blind people can use Wiki too. Maybe green italics for new, red strikeout for cut, black bold strikeout and black bold for changed. -- user:novalis 2002/03/14
I'm colorblind and I love the new diff idea, keep the colors! --Chuck Smith
An improved diff function based on that of PhpWiki was checked into CVS a couple of days ago which does at least some of this. Brion VIBBER 2002/03/13
I haven't had a chance to get it running yet, but when I skimmed the code last night, I saw that it was still splitting on

, which is wrong, since single line breaks don't mean anything (actually, I don't know PHP, so I'm assuming that explode is the same as Perl's split). -- user:Novalis 2002/03/13

OK, now I've taken a closer look. The internal diff algorithm is right, since it's the same as Python's difflib. It's just being called on a line-by-line basis, *then* on a word-by-word basis. Output is still insane. -- user:Novalis 2002/03/14

Statistics

At some point the number of users statistic is becoming meaningless due to accidental log ins which create multiple users or users who are just no longer active. Would it be possible to take users who have not been active for a long period of time (3 months?, 6 months?) out of the system or out of the statistical listing - then the statistic could be number of users active in the last x months? Trelvis Mar 12

The most popular page should have an explanation of what the number is. How long a time period are those numbers collected under? Could it be reset every week so it shows this weeks most popular, rather than the most popular all time? Trelvis

Improved Search

Could the search list be ranked either based on traffic or like Google by the number of pages linked to it, so that the most popular pages come up first. This would prevent some of the wading through a large list of obscure pages and redirects which are less popular?

When you get a search result could we add an option to do a Google search on the subject? (I found this useful in the old software)

Also when the search results come up any wiki links in the example text which have a searched phrase do not work because the html bold tags are added into the link - so far I haven't seen many accidentally formed pages with the bold tags built in, but this should be fixed. It might be on the bugs page already.

I know I have seen a request for advanced search capabilities somewhwere, but I will restate that request here for compactness. Trelvis

I would like to have redirected articles and "Complete list of Encyclopedia topics" pages omitted from search results. AxelBoldt

I agree that it shouldn't search the body of a #REDIRECT, but it should still search the title; otherwise, the failed searches page become unnecessarily longer when users type in a misspelled word for which there is a redirect but which is not used in any regular article.

--Damian Yerrick

Looking at mis-spelled search requests for 'Circumsision', 'Circumsicion', 'Circumsission' and 'Lamberghini', we should probably use something like Soundex or Metaphone to search for a sound-alike article if a literal search fails. Note that recent versions of PHP have a metaphone() function built in.

See http://www.zend.com/manual/function.metaphone.php for more details.

-- The Anome

Search limit of four characters too short 2002/03/10

The search limit wouldn't let me search for world war 2 or ang lee.


I'd like a way to list all pages in a namespace. For example, http://www.wikipedia/wiki/wikipedia%3A should list all pages in the Wikipedia namespace that the current user can access, and http://www.wikipedia/wiki/special%3A should do the same as special:Special pages. --Damian Yerrick

From the New Features page:

  • Talk namespaces All namespaces have their own Talk namespace ("Talk", "Wikipedia Talk", "User Talk"), to use instead of a /Talk page. Listed at the bottom of every page, empty Talk pages are red, existing ones are green.

I'd like to suggest that these links should have the same presentation as in-article links: that is to say [talk:My Article]? if not present, and talk:My Article if present. This enforces the same semantics and appearance for these articles as for the rest of the system, making the user interface simpler and more intuitive: there's one less thing to learn. -- The Anome


To get favicons working in a standards-compliant way in Wikipedia:

add &lt;link rel="SHORTCUT ICON" href="http://www.wikipedia.com/favicon.ico"&gt; to the head element in all generated pages. This will tell the browser to fetch the icon at the named URL. At the moment, some browsers default to fetching favicon.ico from the site, but this will

  • tell all compliant browsers to do this
  • gives you the option of having different icons on different pages, should you want to

The Anome

There is no http://www.wikipedia.com/favicon.ico. Should there be? --Brion VIBBER 2002/02/05 11:48 PST
Shouldn't the icon be a PNG instead of an ICO? Unlike ICO, which is a Microsoft proprietary format, PNG is a W3C standard. --Damian Yerrick

In an ideal world, yes. If we want to look nice and be more user-friendly, we have to live with the fact that most users will be using IE. We should not bash Microsoft if it affects our users adversely. Fortunately, leading open-source browsers (Mozilla) support the .ico format for this purpose. A bit of open-source browser evangelism targeted at IE users would be good, though - I am an enthusiastic Mozilla beta-tester, and 1.0 should be fantastic for the typical PC user.

Suggestion: send .ico to IE users (for user niceness), .png to all others. Give MS until (say) late 2003 to catch up with W3C standards (plenty of time), and then pull the .ico support. -- The Anome

Has anyone actually checked whether MSIE allows PNGs as shortcut icons or not? In any case, I've uploaded a couple of examples of a shortcut icon for Wikipedia, based on the quote, File:Favicon-q.png, and the W, File:Favicon-w.png. --Carey Evans

I checked, and IE doesn't appear to support PNGs. IMHO the W looks quite good, so I turned it into a standard 16-colour Windows icon: [1]. IE, Mozilla, Galeon, Konqueror, and probably Opera support this. --Carey

Here's the right thing to do:

  1. &lt;link rel="icon" href="/upload/favicon-w.png" type="image/png" /&gt;
  2. &lt;link rel="SHORTCUT ICON" href="/favicon.ico" /&gt;

Mozilla will look for the icon; IE will look for the SHORTCUT ICON or the favicon.ico depending on version. And you don't need to store the image at too high quality; a 16-gray PNG should be small in byte size without losing any visible quality. --Damian Yerrick

If several changes have been made to an article and I go to the History list, I would like to have a way to see all the diffs at once, the net change to the article since I last saw it. With the old software, I'd have clicked on the "diff" link corresponding to the first change, which would have displayed the difference between the original and the current version. The new software (I think?) forces me to click on all "diffs" separately to get a sense of the net changes. AxelBoldt

I second this. The old software was annoying because it only let you see cumulative diffs. The new software is annoying because it only lets you see diffs of individual changes. There should be a way of seeing both types of diff. --Zundark, 2002 Jan 27

My watchlist

Yes, I adore the watchlist feature. So anyway, I was wondering if it would be too much of an additional grind on the server to list the number of pageviews for each of the pages on our watchlist? I think many people would be interested in this.

I would also like to be able to make my watchlist public. I hope this could be a feature that can be added in the future. Public watchlist (default: no)

--Chuck Smith

It occurs to me that whenever I hit "watch article", I would also like to see changes to the associated talk page... which may not exist at the time I start watching the article. Might it be useful to automatically include talk pages of watched articles in the watchlist? Brion VIBBER 2002/03/14

It would be nice to have a history table (and an auto-generated graph as well if possible), showing the trends, day by day, week by week, etc. for each of the monitored variables. This would give an instant overview of what's going on.

See MRTG for an example of this sort of thing (for network traffic in this case), or the trends graphs at seti@home for another. -- The Anome

See also the plots at http://www.distributed.net/statistics/ --Damian Yerrick


A very minor issue: I don't want my minor edits showing up on my contributions page. I don't consider myself to have contributed the article on Agatha Christie, for instance, and my contribution to it (a typo correction, IIRC) was so minor as not to deserve notice. I would not, however, mind have the page list articles I instigated, e.g. Dziga Vertov and Dave Brubeck--those, in my mind, are more properly contributions. Best, Koyaanis Qatsi

It seems this has been changed, but I don't like it at all. Previously I've been able to set my preferences so that the meaningless distinction between major and minor edits effectively disappeared. No longer is this the case. --Zundark, 2002 Feb 2

Orphans

I would like the Orphans page to not list User: and User:Talk pages. The User pages don't need to be linked to anything, since they are not articles. The User:Talk pages are Talk pages, not articles. They aren't actually orphans anyway: Users are already linked from the List of Users page, and the User:Talk pages are linked to from the User pages. -- Dreamyshade, Feb 5

Seconded. I've been trying to clear out orphans for a while. A more general strategy may be to exclude from the list talk pages where the 'parent' page isn't an orphan, and then to make the namespace links more conspicuous. --Damian Yerrick
Not necessarily. The list of users links to all users, but special:AllPages links to everything.

Also, would it be possible to omit the various Complete list of encyclopedia topics pages when generating orphans? A link from these pages is not really helpful in terms of the general navigation of Wikipedia, there are probably plenty of articles which are only linked to from here and which nobody will ever notice. Bryan Derksen

As a more "out there" idea, how about doing the orphan search as a graph traversal starting at the homepage? That way it would spot "islands" of articles which link to each other but not to anything else in Wikipedia. Bryan Derksen

I think this is a great idea, but it should probably be on a different Orphan page (maybe a "Stranded" page), to separate true orphan pages from island pages. Dreamyshade

Edit page

Edit conflicts would be a lot more fun and a lot less grueling hot metal pins stuck under the fingernails if a diff between your version and the other person's version were shown. --Brion VIBBER, 2002/02/06 (Suggestion originally from eo::Bezonataj Funkcioj.)

Seconded. --Damian Yerrick

Recent changes

Editing an article causes the previous edit summary for that article to be removed from Recent Changes. This is incredibly annoying. Not only does it mean that I can't see many of the summaries that other people write, but also I obliterate my own summaries if I edit an article a second time. With the old software there was at least a way to change this behaviour, and it was reasonable to assume that anyone who was inclined to read summaries had set their preferences so that they could see them all. So I would like an option for full Recent Changes (and preferably it should be the default). --Zundark, 2002 Feb 7

Search, Sherlock, and Mozilla

It would be nice if the search engine could produce results that worked better with Sherlock search plugins, like the one on my user page. Basically, this would mean:

  • Having some easily identified text near each result, the same as Google does with special comments.
  • Using a unique URL, that Mozilla can spot as a cue to pop up the search sidebar when I search from the search box at the top or bottom of the page.
  • Using GET, because Mozilla's search sidebar seems to have issues with POST.

--Carey Evans

I would very much appreciate using GET instead of POST, or at least accepting GET-style parameters. That way my Galeon Smart Bookmarks could start working again. The Perl module CGI.pm parses both GET and POST parameters invisibly to the script; is there a comparable module for PHP? --Michael Shulman

You can actually use GET at the moment - my Mozilla plugin uses a URL like http://www.wikipedia.com/wiki.phtml?search=%s. --Carey Evans

Listing New Articles on User page

It would be nice if the ten newest articles that someone started would appear at the bottom of their user page. --Chuck Smith

Change to username

Changing a username. Extract from FAQ

"Q. How do I change my username?

A. Simply go to special:editUserSettings and enter a new username and password, then save your settings. The old account will eventually be pushed off the Recent Changes page and can, if you like, be deleted by an administrator."

I tried this, either I am completely daft (very likely), or it cannot be done (perhaps). If it CAN be done, can someone please provide clear instructions, I cannot see a field in special:editUserSettings for changing the username, or if it cannot be done, can the facility be provided please. I ended up creating a new username, which seems a waste. user:Perry Bebbington

I tried it too, for a lark; it does not work.
The only way is to create a new username and start using that one. I'll change the FAQ answer. AxelBoldt
You must first Log Out before putting in a new username (yes, it was different on the old system).

Adding text documents to the upload page, and linking to the uploaded file in an article, displays the text in non-editable text box

I just added a new entry on What Wikipedia is not. The entry is concerned with the habit of some, to do wholesale copy-and-paste jobs of public domain source material (i.e. entire books, laws, etc.). One of the worst (or best?) examples is the The Origin of Species article that has each entire chapter in its own subpage! This would be a real nice, cool and useful thing, if the entire planet couldn't edit the text and therefore change what Darwin said. This type of use (misuse?) of public domain text is, for practical reasons, useless. I agree that short and highly relevent documents should be in an encyclopida -- It is just not possible to protect what the original authors said if the text is editable in the wiki way. It would be great, if we had a place to "upload" such text, link to it in an article, and have it displayed in a non-editable, text-box (all it would be in edit mode is the URL to the text file -- just as it now is with images). In this way, the text will be at a stable IP, be content secure (unless somebody overwrites the file), and also be formatted and presented in a consistant way. maveric149

The "Upload" page needs a lot more features if it's going to scale well. There needs to be some way to determine whether any of these files are linked to from Wikipedia articles, and if so, which ones. Also, this page is eventually going to become really big. Don't know how much of a problem that will be, though. Perhaps some way to sort these files by something other than upload date would be useful? Bryan Derksen

Overwrite warning and/or history for Upload files page

Another scalability issue has to do with the fact that there is no overwrite warning issued when you upload a file that has the same name as a file already on the server. Some type of warning, along with limiting uploads to logged in users (to help prevent somebody from maliciously uploading a porn image, with the file name Pope_John_Paul.jpg for example, to replace an valid image of the Pope with the same file name), would also help. maveric149

Just got into a bit of an upload war :) I was blotting out a whole bunch of stupid banner images from the "never take shit" guy as he was uploading them, and removing some of his earlier spam while I was at it, and it occurred to me how easily I could wipe out a whole bunch of legitimate uploads instead. There should be some sort of "history" for the uploaded files to allow reversion to previous versions. Bryan Derksen

"What articles are linked to this file"

Sheesh, there's a ton of stuff in there now which doesn't look like it belongs in an encyclopedia. What would really help is some way of finding out what uploads are linked to from which Wikipedia articles. That way it'd be easy to spot which aren't linked at all, and which are linked to from inappropriate articles. Bryan Derksen

More upload and image stuff

2002/03/21 I've just checked into the CVS repository code to allow contributors to add a brief description (just like the Summary field on page edits) along with a file upload. The description will show up in RecentChanges and in the upload log.

While I'm at it, what else needs fixing with the upload system? (aside from the above) Should we try to limit file types or sizes? etc.

A related thought I recently had was the question of image resolution; a map or diagram that looks great at screen resolution is annoyingly fuzzy on a printed page. Could we use some mechanism for screen/print resolution doublets, where the low res version is shown on a normal page view, and the high resolution version in the printer-friendly view? --Brion VIBBER

Should we add requests to the top or the bottom of this page?

2002 2 25 Wouldn't it also be a good idea to include the date of the request as well or is there a convention against that? Vignaux

Reverse the date ordering of the "New Pages" listing

2002 2 25 It is the opposite of the ordering of the "Recent Changes" listing (latest at the top) which I prefer. Vignaux

2002 2 25 I really like the idea of having different colors for all the user pages, talk pages and wikipedia pages. However, could a better color scheme be used? Really, lime green for the wiki pages, and salmon pink for the user pages (I do hate pink) are just horrid choices! And the blue of the talk pages makes it difficult to tell where hyperlinks are when your settings are set to not underline them. But the concept is real cool and will be most useful. I will play around with some colors and report back in a day a two. maveric149

I hate the idea of colors. The web is busy enough as it is, and wikipedia is a major busyness offender. Colors are just one more layer of not very interesting information between us and the TEXT. I'm here for the text, people. The interface can go play somewhere else. Metawikipedia? MichaelTinkler
I'm a relatively new contributor, but as a design student and extensive user of online encyclopedia's, I have to say that almost any implementation of color and/or graphical features is going to make this place more desirable for those looking for a professional resource. Right now, the design is geared almost 100% toward the editing end and very little toward the user end. Personally, if I were designing it, I would make the top frame thinner with a more horizontal orientation of the logo and give both it and the side menu some type of cohesive color scheme (blue with a compliment perhaps). I would also suggest making the default font the verdana, arial, helvetica family because it's much cleaner and easier to read than the seriffed times new roman. Jazzoctopus
I'd be quite annoyed to get Helvetica after choosing the very readable Lucida Bright in my browser. I agree with you about the size of the top section though; I had the UseMod Wiki set up to have only the title and logo at the top, with everything else down the bottom out of the way. --Carey Evans
  • I would suggest that the colors be made considerably paler - they do interfere with the hyperlinks - and that the main article pages should be backed by plain white. Being able to read the pages is, after all, the most important aspect, with all else secondary to that. -- April
How about leaving the main text area of all pages white, and only have different color schemes for the top, side and bottom menubars? The more I think about, the more I am being convinced that having any color other than white for the main text area is a bad thing. I do alot of work in :Talk pages with tables with their own color schemes before I place the tables in the article. Now with the different background colors, the eye is tricked, and anything you work on that has color on a :Talk page will look very different when you place it in the article. maveric149
How about a setting in preferences so I can turn off these colors altogether? The current scheme is truly awful, but no matter what it's replaced with it's going to look bad for someone. Really, do we need to be hit over the head like this about what sort of namespace any given article is in? Bryan Derksen
An alternative would be just a coloured bar down one side, which looks quite neat, IMHO of course. Something like "html { border-left: thick solid green; }" in the CSS stylesheet for this page, for example. --Carey Evans
What I'd love to see is for the people who'd like to see something specifically different in the interface to take a page from the wiki, save the HTML, modify it to their heart's content, and post it for everyone to see. Then if people publicly admit to liking it (as opposed to every change to the live code which is met only with scattered complaints), we foolish blind programmers will have something concrete and pre-approved to put into the code! --Brion VIBBER 2002/02/25
I agree that the main text area should have a white background, but the sides and top should have some interesting color to create a contrast. The problem with leaving it plain and making the user edit it to their choice is that a casual user won't do that and just think it's a plain, boring looking website. And I still think that most web designers agree that the arial family of fonts is clearer and more professional for websites. Jazzoctopus

Alternate designs

Fair enough, Brion. I've put together a few pages, which are living at http://home.clear.net.nz/pages/c.evans/wp/ for now. The most useful link there is the Talk link at the bottom of the page, that explains it a bit. I haven't tested it in IE, and I know it won't look as good in Netscape 4. --Carey Evans, 2002-02-27

I looks nice with IE as well. But, even though the top part in this wiki might be too large, the one in yours seems too small. No edit/Main Page/Recent Changes link (try that on a very long page!), no info about how you're logged in, no search box, and you'd definitely want to have some kind of horizontal line there to divide the header from the rest of the page. The "think colored line" thing is very nice, though. I agree to change the background color of the text back to white on all pages. Either we let the header/footer/QuickBar change the color, or we use the "thick colored line" thing. --Magnus Manske
On every Wiki I know, I can hit the "End" key to get all the page functions. Wikipedia, and Usemod wikis before I turn it off, are the only Wikis I can think of off-hand that put so much info between the title and the content. With just title, byline, content, I don't see why a horizontal line is necessary, although it's nice with a whole control panel at the top. --Carey
Thanks, Carey! It looks great (I, too, love the line along the edge), but I have to agree with Magnus that *some* info at the top is darn useful. When I use the non-English wikipedias which are still on the old code, I go mad looking for the edit link at the top... (Also, the edit links seem to be broken.) This situation might be improved upon with a decent sidebar; one that's a little cleaner looking and only takes up space at the top (ie, float:right). Perhaps the sidebar might be a chunk which includes the logo? Just a thought. --Brion VIBBER
The edit links aren't supposed to work, I might think about the edit page and other special pages later. The logo itself is currently in a separate floating <div>, so it shouldn't be much trouble to try adding text below the image. However, I wonder how a floating div and floating table like in Beryllium will interact? --Carey
Surprisingly enough, not half as ugly as I imagined. However it's less than ideal, perhaps; the table is much longer than the sidebar, so it doesn't wrap and we get a big blank space. Of course, not as big as we have now where the sidebar lasts the entire length of the page! --Brion
Netscape 6: the blue bar down the left is good, but I don't like the font: it comes across as too big, and unattractive. The latter is, of course, subjective. Vicki Rosenzweig
The font was the default sans-serif font specified in Edit → Preferences... → Appearance → Fonts → Sans-serif, which probably is big and ugly by default. I've changed it back the to default browser font for now, however. --Carey
Parts of it are certainly an improvement on the current design, but it still has a text-only, techie look. I'm working on a prospective design that I'll have up for you to all see in a day or so. I still have a fair amount of my own school designing to do. : ) Jazzoctopus
Techie web page design is what I do best. :)
In my continuing effort to get rid of the links at the top of the page, I've put a magic QuickBar on my sample pages. Try the button in the top right with a relatively modern browser. --Carey Evans
Alas, I don't have your pages on my local machine. :) I think you mean your sample pages... The pop-up menu is interesting and definitely a cool effect, but I suspect it would be non-obvious. As someone who isn't terribly familiar with other wikis, I find that having the various navigation & whatnot functions immediately visible is a good thing. At the bottom or hidden away in a submenu means that new users won't notice them. Brion VIBBER

Ok, all, here's the design I've come up with. [[2]] It retains most of the current design with a couple of graphic enhancements and a slightly different organization. It's just a sample page, so many of the links don't work. Jazzoctopus

Nice one! Might be a little confusing for newcomers, though. And, changing the logo (which looks good on the page) is not a good idea since we don't want to have totally different logos for the same site, now do we? IMHO, this should become a skin to choose on the user preferences. Accidentially, I just changed statistics so it shows how many people use a certain skin, so I'd say give the community some choices, and then we'll make the most popular one the standard (I know the current standard will have a slight advantage;). --Magnus Manske
Nice! A few comments: The title of the page is not at all obvious. I'd move it down into the white space with the rest of the content, and try to make the header take up a bit less space. Also, all the links in the right hand column are scrunched up and broken onto two lines each on the browsers I tried. The font's tiny too, on my current browser, but on others I tried the top bar was spread out and taller than the logo, which looked a bit strange. --Carey Evans
Pretty! I have to agree with Carey though, the article title needs to be more prominent, and all the text in the sidebar is wrapped. Font sizes vary from platform to platform, from browser to browser, and from user to user. Consider also the non-English wikipedias, which may have longer names for some of those functions. Brion VIBBER
Oh, and another thing, folks. Please remember we'll need room in the design for links to the other-language wikipedias. These haven't been put into many articles yet (in part because the links go to broken pages on most of the other wikis running the old software), but for an example see the article on Esperanto with links to the article in 5 other languages. In the current design they're pretty weighty; using both local and English names for the languages is probably going to be too much, I'd recommend pruning it down to just the local name -- Français, Deutsch, etc -- if people can read the language, they can recognise the local name, no? or even just language codes (fr, de, etc) perhaps with a tiny flag icon or something. (Of course, people will hate more little colored things at the top of the screen, so flags are probably a bad idea.) Brion VIBBER

(See also Marian's excellent UI redesign proposal.)

Nice and fast work on the Cologne Blue skin (the first cut at Marian's UI, I assume). Here are a few suggestions, based on my browser, IE 5.5:

  • drop the font size on the "WIKIPEDIA" banner text from +4 to +3
  • drop the font size on the topic headline (which looks nice in the Verdana gray) from 8 to 6
  • in the second table, the one enclosing both the options bar on the left, as well as the body text, kick the cell spacing up to 5 or so, which gets the whitespace closer to Marian's
  • in the options bar table, drop the cell spacing to 0, but kick the cell padding to 5, maybe, which will give you a continous bar with some spacing structure in it. ClaudeMuncey
  • Shortcuts to Wiki Shortcuts

www.seedwiki.com has a great idea in its page editing: popup menus with all Wiki Shortcuts they use. When one Shortcut is selected it should be inserted in the text. On the bottom where Wikipedia writes DO NOT USE .... it has a nice summary of Wiki text formatting. Would be helpful. -GillianAnderson

Statistics

List the number of pages which are redirects. Calling redirects junk pages is not very accurate. --Chuck Smith

It would be nice if the "Pages that link here" utility could follow redirects and list the pointed to article as if it were diectly linked. For example, I originally created the Sutter's Mill article by naming it "Sutters Mill". After creating it, I went ahead and created related articles that linked to Sutters Mill by [[Sutters Mill|Sutter's Mill]]. Which worked OK. But then the new wikiware was installed allowing for apostrophes and I moved all the content in Sutters Mill to Sutter's Mill (so as not to imply that there were multiple owners of the mill who were named "Sutter"). But now, the Sutter's Mill article is an Orpan and there are no articles that are listed in Pages that link to Sutter's Mill except for my userspace. This to spite the fact that the article is linked to several others through a redirect. --maveric149

One problem with the "Pages that link here" feature: if I'm editing an article (eg Franz Schubert) that has a redirect coming from another article title (eg Schubert), I'd like to be able to see all of the articles that link to both pages. I could do this by looking at both pages (with a little URL fiddling) right now, but it's not easy. Anyway, it's not a major concern. Thanks, -D

RDF editing

This is a rather esoteric feature, so bear with me. It would be very cool to be able to enter machine readable metadata about pages, and specifically, to allow RDF triples to be entered.

A crude prototype of how this might work is running on the RDF wiki. The basic concept is to have three URIs where the second URI describes the relationship between the first and the third (e.g. <http:...Mona+Lisa> <http:...Resides+In> <http:...Louvre>)

The way that I could see this working is that one namespace exists for relationships (the second URI), and that the first and the third URIs are normal Wikipedia articles. The relationship lists would reside on a special page associated with the first URI.

-- user:RobLa

I just dealt with an article about the French language that was written in French. My solution was to cut and paste it to the French language Wikepedia and to add a Wiki in the form "fr: langue française". That worked fine. From there I tried to put a Wiki in the form "en: French language" to link it back, but was not so lucky. Is there any way that this sort of link back could be made to work. An other language linkage would be helpful in alerting others that there is already something in English that you only need to translate without writing a whole new article. Eclecticology

When we get all the non-English wikipedias moved over to the new software (currently pending additional work on character sets and yet more changes to the search engine -- see discussions in Wikitech-L -- as well as message string translations), you'll be able to do exactly that. For now, just manually put in a link with the full URL. Brion VIBBER 2002/03/14

Image captioning

It'd be nice if the upload page allowed us to enter notes about the images we upload (or even if it required us to enter certain pieces of info.) For instance, we could say where we got the image, whether it's public domain, etc (sort of the equivalent of writing on the back of a photograph.) This would be useful for resolving copyright problems where nobody bothers to properly caption an image in the article.

More Most Wanted

The most wanted feature is great, but it doesn't give enough results. Right now, most of the most wanted are things like '11th century BC' Olof

  • It probably would look better without that kind of time line article cluttering the listing, (Currently 26 out of 50) Most of them would only be templates anyway. Perhaps if we each took one on they could be cleared up quickly. Even so increasing the number to the 100 most wanted would make sense. That would give each contributor a greater chance to find something in his own filelds of interest. Eclecticology
  • The more HTML is supported, the better. Some people write naturally in HTML, others prefer the simple wiki style -- why restrict anyone? The only issue with unrestricted HTML is that malicious people could screw up the overall layout of the page, but who cares? We can always just revert back to the previous version.
    • Just don't permit frames, please. Actually, I never missed any tags tht aren't implemented in the current version. What more tags are needed? Actually, I would oppose using <a> tags and I would prefer (contrary to an earlier opinion of mine) marking external links with [ and ] in order to see that they are in fact external links. This way we can tell easily when someone is linking within Wikipedia and when they're abusing the system by adding external links in inappropriate places. Generally speaking, let's keep the markup simple so that the people who can add content, but who don't necessarily know how to code, will feel 100% comfortable contributing. --LMS
      • I still need some more eyeballs to look at the parser. The question about the HTML tagsa was, should I have a list of allowed tags, or a list of "dangerous" ones and allow all others? Right now, all tags are allowed, except <SCRIPT></script> to prevent JavaScript or similar diseases;)
      • I second rejecting SCRIPT, FRAME, and IFRAME, but I don't oppose all A elements. For instance, named targets (<a name="">) make it easy to move around an entry that has not yet been broken up into subsections. --Damian Yerrick
      • You must only allow elements and attributes through which you know are safe. With many existing browsers, script can be attached to pretty much any element, and you can never say what wonderful 'features' are going to appear in the next release. You have to restrict what you let through to a safe minimum, and even then you have to worry that there'll be some tricky way of providing plain text which some stupid brower will interpret as an oddly-encopded scripting directive.Matthew Woodcraft
  • XML is the de facto standard. If we want to attract users from Slashdot, Kuro5hin, Everything, etc., we really need support for a language that feels like HTML. Perhaps we could act like h2g2.com and implement HTML support through XML, requiring all entities to be properly closed and automatically changing submitted pages to be well-formed when submitted in "XHTML mode". XML would also help solve the WYSIWYG vs. WYSIWYM problem by separating content from presentation, with multiple ways to italicize something (&lt;em> for emphasis, &lt;cite> for citing names of works, etc.) and to bold something (&lt;strong> for strong emphasis, <hw> for headwords at the beginning of paragraph, etc.). Could we use some sort of filter to let users edit a page as wikistyle, as XHTML, as UBBCode, etc? --Damian Yerrick
    • I disagree; implementing XML within a wiki context would be a disaster. We can add XML markup later, to more complete versions of the articles. One of the main reasons why there is this pared-down markup code is so that it is easy to use. Remember that. Your mother should feel like she can figure out how to contribute. --LMS
      • My idea was to store text as XML on the server, translate it to wikistyle or UBBCode in the edit page, and translate the submitted text back to XML. XML would also make using Wikipedia content with non-Wiki sites easier. --Damian Yerrick
        • I am going to implement different output modes (e.g., printable page [without the links], maybe RTF or PDF), so I could make an XML output function too. That could also be used for generating daily XML tarballs. But, all of this will take place after wikipedia is running on the new script. --Magnus Manske
        • I would like to support XML, directly or indirectly, so that text can be typed. This could be for typing text areas of documents or for associating text with fields of a record of some kind. In the latter case, you could support Lotus-Notes style database operations. The former could be used to indicate things like Summary, Body, Abstract, Question, Answer, Comment, etc. This is more of a general Wiki idea, but there are ways that this could be interesting for Wikipedia: Sections for Reference, Instances/Examples, Definition, Background, etc. --sdw
  • How about a reverse query on "pages that link to this page"? And how about making the search function also search titles of pages? --Damian Yerrick
    • My search function covers search in titles, but case-sensitive, due to some setting in MySQL. I'll look into a "reverse link" feature.
      • It doesn't pick up on the latest titles because somebody seems not to be running the update script too often. Reverse links would automate "see also" sections much as the other site's soft links do. Of course, the ideal would be to run it from a cron job.
  • I think that this would help Wikipedians keep with growth of Wikipedia: each page should have list of categories it belongs to, something like Biochemistry or Estonia. Categories could be introduced by something like #CATEGORY Foo, Bar or #KEYWORDS Foo, Bar. Then following features would be neccessary:
    • RecentChanges for limited set of categories
    • Listing of all articles that belong to some category.
    • Listing of all categories --Taw
  • Hi! First off, I'd like to say that I think the new Wikipedia scripts are wicked cool. So, here's my little itty bitty feature request: you know the special page that lists all articles? There should be a way to fetch a text/plain listing. Just straight up one-article-name-per-line text. (The reason I'd like this is so I could fetch such a listing via cron, say, nightly, for tab completion in my Wikipedia emacs thingy.)

Old feature requests:

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Ignored_feature_requests&oldid=39927"