Wikipedia:Phase II feature requests
This is a list of feature requests for the Wikipedia system. For purely cosmetic user interface features, please see wikipedia:User interface ideas
More namespaces
It would be nice to have a wikipedia utilities:namespace for all the wikipedia utilities, talk archive:namespace/user talk archive:namespace for no longer relevent talk comments, and wikipedia talk archive:namespace for all wikipedia/wikipedia utilites outdated talk. --maveric149, Saturday, April 6, 2002
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).
Printer-friendly display
Would be nice to have:
- Serif font (?)
- Footnoted URLs should be listed as footnotes! Currently you just see the [1], [2], and that's all... (In fact, all external links should have their URL's listed at the bottom as footnotes. AxelBoldt)
- Some ability to link higher-resolution images for diagrams, maps, etc.
Brion VIBBER, Tuesday, April 2, 2002
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
- Any reason we can't each set our own color scheme in the Preferences? Anonymous users, of course, would be stuck with the default, so this wouldn't help everybody. But if you don't like green/red, you could use orange/blue or lavender/crimson without bothering anyone else. -- Rootbeer 2002/04/03
- 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
That reminds me -- I think a diff of a redirect page should actually work on *that* page, not show a diff of the page that's been redirected to. Several times I've gotten quite confused when checking a page that had just been changed into a redirect, expecting to see the change from the previous page contents and finding myself looking at a whole nother page instead. Brion VIBBER, Saturday, April 6, 2002
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.
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.
In fact, I would go further: search engines should
- match exact (case sensitive!) matches first, and then
- match (case insensitive) 'exact' matches second, and then
- I disagree strongly; we should never be case-sensitive. --BV
- fall back to ignoring diacritics (as if ASCII-only), and then
- fall back to Metaphone or other similar scheme (just replacing all vowel sequences by '*' normalises to a sufficient extent for many purposes)
- Agreed. --Brion VIBBER
Just looking at the failed searches shows that about half of them would succeed given some very simple normalisation. Many of the others would work if a combination of guess-the-spaces and stemming was used. Wikipedia is small compared to the Web, and so techniques like this will improve recall without deluging the reader in dross, providing that exact matches and article-title matches take priority. 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 <link rel="SHORTCUT ICON" href="http://www.wikipedia.com/favicon.ico"> 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
- 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:
- <link rel="icon" href="/upload/favicon-w.png" type="image/png" />
- <link rel="SHORTCUT ICON" href="/favicon.ico" />
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)
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
I'd say just add all the namespaces when someone puts something on their watchlist. That would make the process simpler I think. How easy would this be to add? --Chuck Smith
- Easy as pie. I just checked it into CVS. Brion VIBBER, Wednesday, April 3, 2002
- Sweet! How easy would it be to put the pagecounts next to the articles listed on your watchlist? Also, could the pages on my watchlist be boldfaced on Recent Changes for me? --Chuck Smith
- (re: page counts) You mean the 'this page has been viewed X times'? Could be interesting info... (bolding watched titles in RecentChanges) Hey, now that's a great idea! Should be pretty easy, too. --Brion VIBBER, trying to edit in lynx while installing new KDE packages
- Sweet! How easy would it be to put the pagecounts next to the articles listed on your watchlist? Also, could the pages on my watchlist be boldfaced on Recent Changes for me? --Chuck Smith
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.
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
- 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
Pages that link here & REDIRECTS
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
Inter-Wikipedia Links
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.
- Done. It only shows up in the upload log and recent changes so far, but I'm thinking we could have an informational page per-image which would include these comments as well as lists of pages that link to it, etc. Brion VIBBER, Thursday, March 28, 2002
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
- 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
- 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 (<em> for emphasis, <cite> for citing names of works, etc.) and to bold something (<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
- 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 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
- 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.
- My search function covers search in titles, but case-sensitive, due to some setting in MySQL. I'll look into a "reverse link" feature.
- 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.)
- Is there any mechanism to allow downloading of individual articles, or groups of articles from wikipedia? I don't see any. I suggest that we put a "Download this Page" link on each page on the top and bottom bars. Also, there could be a "search for downloads" feature where you search for words, and there is a check-box next to each article found so that you can check off which you want to download. This would make it easy to download groups of articles on a related subject. (Also, I think we should allow downloading of articles in either plaintext, HTML, or wiki formats, since any could be considered the "source" of the article.) -Joel Schlosberg
Old feature requests:
- Top priorities: really important features we still don't have
- Report features and automation
- Interface and user preferences
- Wiki shortcuts: new shortcuts, code tricks
- Naming conventions (this is all done, but not yet implemented on Wikipedia)
- Cookies, logins, and privacy
- Other feature requests
- Completed feature requests
- Really ambitious and fanciful feature requests
- Wikipedia approval mechanism