|
Since / pages now have some of the functionality as the old subpages once did, it would be nice if selecting "Watch this article for me" on a / page would automatically watch other articles at the non-/ page. For example, User talk:Maveric149/archive 1 is a talk archive I set up that links to my regular non-/ed user page at user:maveric149 through the sidebar "Article" link. However, this page is not automatically "Watched" just because my user page and talk is. Another example; the sidebar "talk" link in Liechtenstein/Temp[?] goes directly to Talk:Liechtenstein (which is way cool, BTW), but watching Liechtenstein/Temp[?] does not also watch Talk:Liechtenstein (which is the only talk page for this / page -- should we call the / pages subpages again?). --maveric149, Sunday, June 23, 2002
(2002 June 12 ) For pages requiring numerical listings, as in special:Recent Changes, lines like this : "View the last 50 | 100 | 250 | 500 | 1000 | 2500 | 5000 changes; View the last 1 | 3 | 7 | 14 | 30 | 90 days; List only new changes" could be added. So if one wants to scroll down the list, just click on the numbers.
For example: for special:WantedPages, use View by numeber of articles wanted. special:WantedPages, use View the top 50 | 100 | 250 | 500 | 1000 | 2500 | 5000 -th popular of the list. special:LongPages, use View the top 50 | 100 | 250 | 500 | 1000 | 2500 | 5000 -th longest... wikipedia:Votes for deletion, start by the page with most votes etc. etc.
It doesn't have to be 50 | 100 | 250 | 500 | 1000 | 2500 | 5000, The numbers can be changed to fit the pages' needs. Like top 5, top 30, top 100 etc.
(2002/5/30) I note that the [[ sytax for internal links requires proper capitalization. I like my capitalization to be "proper" and thus use the | syntax all the time to allow the link to work. This is all the more frustrating because many of the entries have incorrect capitalization.
This could all be fixed if the wiki's were case-insenstive in the same way the search is. Or am I missing something obvious?
MSM
I'd also prefer case-insensitive linking. If the software were changed, it would be easy, I think, to run a script that automatically generated disambiguating pages for existing pages that differ only in capitalization. LC, Monday, June 10, 2002
(2002/5/30) This is a small suggestion, easy to implement. Could the welcome when we have logged on be just "Welcome xxxx". This would be more in keeping with the farewell when we log off. The current message always makes me think I was previously logged on and forgot to log off, particularly when it is terminated by the exclamation mark. (I am not sure if this is a cosmetic user interface feature or not) Vignaux
(2002/1/25) The general layout of Wikipedia looks cluttered. It needs more whitespace to be remotely readable. --Damian Yerrick
I also agree that the standard skin is too busy for newcomers. Why not make the Cologne Blue skin the default for anyone who isn't logged in? It looks much less cluttered, but still has all the functionality. This ought to be an easy code change, right? LC, Monday, June 10, 2002
I just edited Poincaré conjecture, and it was a bit difficult. All of the links off of that page -- Edit this page - Diff - History -- didn't work properly, because the name of the URL wasn't encoded properly. That is, when I went to the article itself, the "é" was properly encoded as "%E9", but it was left alone in the subsidiary URLs, which my browser proceeded to misinterpret.
[I realise that this is my browser's fault. I realise that it is my fault for using a Microsoft product (Internet Explorer for Unix, 5.00.2013.2002). But I can't find anything else with as wide a range of displayable HTML 4.0 character entities. If anybody knows of a (preferably free) alternative for use on Unix (not Linux), that has all of IExplorer's math symbols (not just Greek), then I would be grateful.]
So I went ahead and moved everything to Poincare conjecture, putting the "%e9" in by hand when forming the redirect. Of course, this leads to the problem that the article's title doesn't have the correct accent on the "e". This is a fairly familiar problem; many titles lack apostrophes for the same reason.
So one solution is to make sure that special characters in URLs are passed appropriately in a way that all browsers can understand. But so much better would be to allow Wikipedians to edit the titles of articles independently of their URLs. Then we can simply resolve not to have any special characters in the URLs. This process might even be done automatically; then we can type [[Lou Gehrig's disease]] and have the Wiki software automatically interpret it as it would [[Lou Gehrigs disease|Lou Gehrig's disease]].
I've seen enough editing of titles for other reasons anyway, and copying articles wholesale to completely different URLs is a lousy way to do it. Editing article titles is an idea whose time has come!
-- Toby Bartels
The date link in the right columm (e.g. April 13, 2002) is also nearly useless. It would be much more effective to link to April 13, 2002, which would have the benefit of giving people "this day in history".
Alternately, it would be nice if a stub page was automatically created for the given day (e.g. April 13, 2002), which links to the previous day, the next day, the date without year (April 13), the year (2002), the day (Saturday), and whatever else is appropriate to automatically fill in. RobLa -- April 13, 2002.
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 I no longer feel this is needed. The general format user talk:maveric149/Archive 1[?] works fine without going namespace crazy (namespaces are for different classes of pages that need to be treated differently by the software). If you follow a link to my talk archive, you will see that "Article" is highlighted on the side by and clicking on that brings you to my user page -- the same thing works for regular talk pages. This was the functionality I wanted with the talk archive. --maveric149
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).
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
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
2002/03/10
The search limit wouldn't let me search for world war 2 or ang lee.
There could be some way to get to exact topic instead of Search, or at least add some kind of I'm feeling lucky. (Boleslav Bobcik, Wednesday, May 29, 2002)
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
The presentation suggested (except for the green bit) is the same as presently used for links inside articles. Because it's done with CSS, some browsers use red for nonexistent links while others use question marks instead. So we just need to use the same code in both places, and it'll turn out the same in both places -- except for the green, which presumably wasn't what you were objecting to. -- Toby Bartels
To get favicons working in a standards-compliant way in Wikipedia:
add <link rel="SHORTCUT ICON" class=encyclopedia 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
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,
Here's the right thing to do:
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
Konqueror uses favicon.ico and KView can save .ico files. Using .ico does not exclude Linux users. -phma
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
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
It appears that the Watchlist does not work for all namespaces. I just edited Talk:Wikipedia Announcements and it didn't pop up on My Watchlist. What gives? --Chuck Smith
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
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 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 (http://eo.wikipedia.com/wiki.cgi?Bezonataj_Funkcioj).)
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
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:
I would very much appreciate using GET instead of POST, or at least accepting GET-style parameters. That way my Galeon (http://galeon.sourceforge.net) 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
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 though of a better idea below --maveric
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
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
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
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
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
2002 2 25 It is the opposite of the ordering of the "Recent Changes" listing (latest at the top) which I prefer. Vignaux
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 [http://www.wikipedia.com/wiki/special:whatlinkshere&target=Sutter's_Mill 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
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
The Inter-Wikipedia Links are a great feature, but hard to maintain. And there will hardly be more than a two-sided relation English -> foreign and foreign -> English. You'll hardly find links from let's say German to Portugese or from Dutch to Polish because this requires people that speak both languages. Now, since the English wikipedia already acts like an "anchor" to those links, why not use it as a search key in an additional database table and create the appropriate links to other languages automatically?
Possible realisation could be like this: Only references from the foreign language page to the English page would be needed. In the database table there is one column for each language. When an article is saved and a link to an English wiki page is encountered, the name of the calling page is stored or replaced in the record of the English page. When pages are displayed, search for the appropriate record and display links to all pages that have an entry there. This system will not work for articles in foreign languages that don't have a counterpart in the English Wikipedia, but since the English Wiki has more articles than all the others together, this will happen only seldom. -- Ben-Zin, Saturday, June 8, 2002
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.
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.
<a name="">
) make it easy to move around an entry that has not yet been broken up into subsections. --Damian Yerrick
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
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
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:
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
On the old software, Random Page omitted /Talk (Talk:) pages, but the new software doesn't anymore. When I click on the Random Page button, I'd like to see articles, not Talk: or User: pages. Dreamyshade
Search Encyclopedia
|
Featured Article
|