This is Yet Another Sandbox, for testing certain software problems without crudding up the regular wikipedia:Sandbox (which is Oh So Elegant, no?)

Feel free to use buggy browsers on this page! It's fun!

(inserting swath of text from wikipedia:Bug Reports to push us past 32KB; =DO NOT REPORTS BUGS HERE, THIS IS JUST A TEST PAGE!=)

Please DO NOT report bugs in the Wikipedia software here. This is not the place to point out mistakes in a Wikipedia article (you can do that by simply editing that article), nor is it the place to request new software features (you can do that at Feature requests).

Do not add your new report in the proper section, with a bold title and a date in (yyyy/mm/dd) numeric format. Make sure that different bugs get different titles. Or, if your problem is related to a bug already reported, add your description to that bug's section. If an issue has been resolved, move it over to the "wikipedia:Squashed Bugs" page. PLEASE DO THIS.

If an article is replaced with "Describe the new page here." the next person who accesses it will be greeted with an edit window.
Deleting all the text in an article and replacing it with "Describe the new page here.", pesents the page it as if the page NEVER had any content -- thus promting a sysop, like me, to delete the page. If a page and its history exists, then it shouldn't ever automatically show up in an edit window. maveric149

For the time being, manually add "&action=history" to the URL to see the history. The "automatic edit" was actually planned as a feature, a long, long time ago... --Magnus Manske, Saturday, April 13, 2002

Will do, thanks for the work around! maveric149

Fixed it in the developres version. ----Magnus Manske, Sunday, April 14, 2002

STATUS : Fixed in CVS

International links do not display in "Cologne Blue" Skin: There is no link to the other international wikis, other than in the meta tags. Change to Cologne Blue and go to say Algeria. 2002/04/08 user:Dze27

This has been fixed in CVS for several days. Jimbo, can we have an upgrade please? Brion VIBBER, Tuesday, April 9, 2002

STATUS : Fixed in CVS

Important note to Mozilla users: You may have difficulty saving edits to this and other long pages when using Mozilla 0.9.9. This is a bug in Mozilla; if you encounter it, try editing in another browser or upgrade to the latest nightly build which has the bug fixed. 2002/04/02

Several asterisks in a row will prevent linewraps (or increase the linewrap length considerably?) Koyaanis Qatsi, Monday, April 8, 2002

See the history of Talk:Terrorists for an example. I doubt this is a common issue, though, since most of us use four dashes. :-)

Chinese (unicode?) article title created, breaks interface The Anome, Thursday, April 4, 2002

Some one has managed to create

(link removed)

with all sorts of nasty consequences (try to edit it, for example).

Removed it manually. This (the link problems) should already be fixed in CVS. Brion VIBBER, Thursday, April 4, 2002

This may be the same issue as above. Go to Poincaré conjecture, then click on "edit this link". On IE 6, I get a page "PoincarÃ© conjecture". In order to actually edit the article, or access its history, you'll have to manually enter something like

http://www.wikipedia.com/wiki/Poincar%E9_conjecture&action=edit

I suppose the links produced by the script should always use these % escapes for non-ascii characters. AxelBoldt, Tuesday, April 9, 2002

They have done for several days in CVS. Jimbo, can we see an upgrade soon, please? Brion VIBBER, Tuesday, April 9, 2002

User contribs link doesn't work on user page that starts with a lowercase letter
Looks like the lowercase user name contribs bug is back - check out Maveric149's contributions and maveric149's contributions --maveric149, Wednesday, April 3, 2002

A search for 'barry took' does not find the Barry Took article The Anome, Monday, April 1, 2002

This may be stop-words stopping 'took', but I would expect the search routine to at least check, for a search of the form 'x y z', whether there was an article with the exact title 'x y z' (up to case, and possibly accents) in the Wikipedia, regardless of any stop words. Otherwise naive users will miss articles that actually exist. I think I've seen more examples of this, but this is one I can demonstrate. This needs to be fixed, not documented.

A search for 'FORTH' or 'forth' returns nothing, though there is a article named 'FORTH'. Rather weird.

Yup, both of these are stopword issues. AxelBoldt

Funny chars in links screw up article rendering The Anome, Monday, April 1, 2002

A link containing the four characters "!Xu~" did funny things to the rendering of the old version of the Phonetics article that contained it.

Same bug as below. Fix your links, and the bug won't catch ya. (Fixed in CVS.) Brion VIBBER, Monday, April 1, 2002

Bangs in links in tables wreck the table Koyaanis Qatsi, Sunday, March 31, 2002

Observe: the following table is coded properly, but displays incorrectly (as you'll see in the second row, if you view source). Piping the link so the bang displays but isn't linked to corrects it:

Vivement dimanche!	Confidentially Yours	1983	W	D
Vivement dimanche!	Confidentially Yours	1983	W	D

Looks like a bug in the reject-bad-links code. I'll work on it... Brion VIBBER, Sunday, March 31, 2002

Got it. Fixed in CVS, wait for Jimbo to upgrade. Brion VIBBER, Tuesday, April 2, 2002

Has that been upgraded? It quit linking but the two rows in the table should be exactly the same except for that? Koyaanis Qatsi, Sunday, April 7, 2002

Ampersands in links surrounded by italics cause words to drop and the end italics tag to be ignored Not a common problem, I'm sure. But go to the history of talk:Osama bin Laden and you can see what I'm talking about. The ampersand in the former [[Roger & Me]] was the culprit. Koyaanis Qatsi, Sunday, April 7, 2002

Table positioned between two paragraphs displays at bottom of page
(possibly related to above bug??) Wednesday, April 10, 2002

If you look at the table in Talk:High_German, you'll see that instead of appearing between the two paragraphs of my note, it leaves a "close table" tag where the table belongs and puts the table at the end of the page. I've double-checked my table code for errors, and can't find any. I've also tried just making one big table, with the first and last paragraphs in their own table rows, but the problem persists. Is this a bug, or am I having a Stupid Attack™? pgdudda

You're missing a </center> tag; it looks okay after I added that in. But that did trigger a bug in the parser that caused it to eat the table instead of the center tag... I'll try to fix that, but in the meantime, uh, don't do that. :) Brion VIBBER, Wednesday, April 10, 2002

Oh, so I *was* having a Stupid Attack™, but at least my Stupid Attack helped uncover another bug. Thanks! :-) pgdudda Thursday, April 11, 2002

First hit doesn't show login, all subsequent hits do

2002/03/28: When I enter Wikipedia from outside the page shows my IP instead of my username. When I follow a link within Wikipedia the cookie is noticed and my login name appears. I obviously have cookies set and working, since it does notice. I use Mozilla 0.9.9 and Galeon 1.2 on Linux. I'd like to enter to the Recent Changes page, but since the first page doesn't recognise my cookie, it only displays 50 entries and not the number I have indicated in my preferences. -- Seindal

This might be a Mozilla issue as well. NS4.77 did the initial login right.

IE 6.0.260 for WinNT has the same problem. Koyaanis Qatsi

Internet Explorer 5 for Macintosh has the same problem, and so does Netscape 4.76. Dreamyshade

I can't log in.

2002/03/22: I set no password under UseMod, now I can't log in under the new PHP script. I'm still logged on on one computer by a cookie, but I can't log on from any other computer, without a password. I also am unable to change my password from the computer I am logged on from without a password. -Aidan Elliott-McCrea

Okay, my probelm fixed. Don't know about Koyaanis' , below.

2002/03/22: I'm having a similar problem--I can't log in on any computer at work. I do know what my password is; login is denied without explanation. I would like to be able to log in on multiple computers under the same userid. Koyaanis Qatsi

2002/03/31: My problem above is user error. The second field asking for the password is only for new users; putting the password in the first and leaving the second blank, submitting that, allows me to log in. Could we add something about that? It took me several days to figure out, but I am a little slow on the uptake. Koyaanis Qatsi

Yeah, that really needs to be split into separate forms: a "log in" and a "create new account", the latter with confirm-passowrd and e-mail (in case you lose your password) fields. I'll do that... Brion VIBBER, Sunday, March 31, 2002

I created a new user with username novalis. I can log in, but whenever I follow any link from the login page, I am not logged in. I get the following cookies when I log on:

WikiUserID=939

WikiLoggedIn=yes

Neither seem to have domain or path information (So, I'm using konqeror to test this, and I don't trust its reporting). They appear to expire in about ten minutes, but that's not what's causing the bug. I get the same bug in Galeon and Konqueror and Lynx and Links, so it's probably not client-side.

3/14/2002

I've seen the same thing; for me it went away when I checked "Save password in a cookie" at login time (which of course I don't want to do on a public PC). AxelBoldt

Also tried logging out, but the system won't log me out because of the cookie thing. Advice would be nice! JHK

We're working on it. :(

Log in doesn't set cookie path

(2002/1/25) The Set-Cookie header returned from the log in page doesn't include a path= variable. Most browsers default to "/"; Lynx, at least, defaults to the path of the page, so login doesn't work. Carey Evans

(2002/02/20) Actually, it looks like Mozilla defaults to the path to the page. When I wrote the report above, this was "" (for /wiki.phtml); now it's "/wiki". This means that special:userLogout doesn't work for anyone who logged in before the path was changed, because it doesn't touch the cookie with path "". --Carey Evans

Edit replaced entire text of a Talk page 2/26/02

I just attempted to edit the Talk page on the article, Masculism. It brought me to a blank screen in which I wrote my comment. I previewed it, and hit the save button. I didn't think anything of the fact that there was nothing else except my text shown, until afterwards. Mine was the only comment remaining. Rgamble

Linking error 2/25/02

Oregon consititution had several articles with multiple spaces in them - so the link was Article II (two spaces before this) title here instead of Article II title here and the link resolves to different locations. Rob Salzman

Mysterious edit conflicts

14 Feb I add the name Georgi Konstantinovich Zhukov to Major figures of World War Two on the World_War_II page, hit save and scroll down to check it is there, it isn't, I hit refresh and I get a edit conflict.

See the bug below. The above is probably a dupe.

"Go back to edit some more" doesn't work

9 Nov - I cannot simply hit the back button in my browser, after I have saved a page, and make another change to the page. I do that all the time in UseModWiki, but I can't do it on PediaWiki because I get into an edit conflict with myself.
- Now you can, but after "back", you'll have to hit "reload" to correct the timestamp embedded in the HTML of the editing page. --Magnus Manske
- This is still a problem. I still get into edit conflicts w/myself. And the timestamp should come from the serverside (e.g. the script), not the browserside (i.e. the HTML).
- This is still a major bug. --The Cunctator

Clicking on link in Recent changes takes me to edit box for that link

2/19/02 6:27 ish PST. Clicked on Boleslav II Smialy in Recent Changes to see what Mr. Parker had done with the article. Got the edit box for the article, which contained a redirect to an appropriately titled page. Tried to save it as I found it, got an edit conflict. Repeatedly tried to remove what "I" had added to the lower box, and then save, got continued edit conflicts., Finally just backed out. JHK

Parser/Editor

Parser does not recognize mailto:, news:, ftp: URL scheme (2002/02/20)

The link parser seems not to recognize the mailto: URL scheme (RFC 2368). This prevents a user from creating a clickable e-mail contact point in his user page.

Actual results: Mail Damian produces no link
Expected results: a clickable link that opens the user's MUA with a new message addressed to tepples@spamcop.net

--Damian Yerrick

See Urban legend for an example of news:; what had been a working Usenet news link now shows up as [1] Malcolm Farmer
See VIM for an example of ftp:.

Fixed it in CVS. We'll have http, ftp, news, mailto. I don't remember if I added gopher as well ;) --Magnus Manske, Sunday, April 14, 2002

STATUS : Solved in CVS

Last line link in list

(2002/1/29) If the last lines of an article looks like this:

* [http://www.yahoo.com/
Yahoo]

then the bottom part of the page ("Main Page | Recent Changes...") will be indented to the left and screwed up. See SandBox for an example. This only happens if all of the following are true:

we are in a list
we have an URL link
The last letter of the URL is /
The name of the link occurs on the next line
You are using IE 5.5 on Windows. Netscape 4.76 on Linux does not show the effect.

AxelBoldt

(2002/3/2) Right now, I see the bug also in Netscape. An example is at the bottom of Duverger's Law. AxelBoldt

That page renders correctly for me on Mozilla 0.9.8 & Netscape 4.78 (Linux). The example in wikipedia:Sandbox still leaves an indent on the following page contents (which is due to a bug in the wiki-to-html rendering code), but not in the link bar at the bottom (which is now separated by a div tag, so there shouldn't be any interference). Brion VIBBER 2002/03/02

Parser generates extra whitespace

The Bipolar disorder page is full of extra whitespace - looking at the article reveals lots of &amp;lt;p&amp;gt; &amp;lt;/p&amp;gt; and &amp;lt;pre&amp;gt; &amp;lt;/pre&amp;gt; spans generated.

Similarly, if an otherwise emply line contains some white space, the previous parser took that as a paragraph break, while the new parser treats it as a block of indented nothing, resulting in too much space between the paragraphs.

If whitespace precedes a #, then it is taken to be a numbered list, while before it was taken as a literal # (which is the correct behavior, especially useful for programs). AxelBoldt

Bad table code can screw up layout

(2002/1/28) In the Quaternions article, the first part of the article appears at the bottom of the page, as do all the QuickBar links. --Zundark

This was caused by Bad Table Code in the article. There was no closing TR tag for the last row in the table, and an extra open TR tag after the end of the table. I've fixed the article... The parser could probably be made to be able to normalize these things, though (ie, remove table-ish tags not inside &amp;lt;TABLE&amp;gt;...&amp;lt;/TABLE&amp;gt;) --Brion Vibber

Text between a pair of links sometimes omitted from displayed page

For an example of this, see the 14 April 06:28 version of the Leigh Brackett page. The three apostrophes don't put her name into bold properly; and chunks of text between some links are being omitted. The links in the edit text look perfectly normal, with no funny characters. Inserting a carriage return just before the omitted text seems to fix the problem, so it looks as if there's something odd happening in the function that parses the wiki text. Malcolm Farmer, Monday, April 15, 2002

The missing text after BAD LINKS is an old bug that was fixed a week or so ago, but the fix hasn't been installed yet. The links in question are bad because they have line breaks *in* the links! A line break is not a valid character in an article title. Brion VIBBER, Monday, April 15, 2002

Three tildes in preview

In preview the three tilde symbols (~) are not replaced with the user name. -- Jan Hidders

Three tildes shouldn't be replaced in pre, nowiki

The ~ is not uncommon in ASCII art such as in Stimulated emission, and should be left intact inside pre and nowiki areas. Brion VIBBER 2002/03/12

Fixed it. Will now be replaced on preview, and is left unchanged in nowiki and pre tags. --Magnus Manske, Sunday, April 14, 2002

STATUS : Solved in CVS

Parser issues with header lines

The display of Eight queens puzzle is... less than optimal. The problem is that the leading space on a line used to disable the processing of '#': now the Python program example is damaged.

Definitions go in separate lists

(2002/1/25) Definition lists like:

Term 1: Definition 1.
Term 2: Definition 2.

each get put in separate &amp;lt;dl&amp;gt; tags, resulting in too much spacing between them. Carey Evans

Konqueror 2.1.1 with KDE 2.1.2 cannot render any edit/add page. 2002-1-1

The text area for the body of the article is displayed correctly; however, the "summary" text field is rendered ""inside"" and over the article body text area. Also, nothing that would normally appear under the article body text area does not render at all.

That's the fault of Konqueror; tried to scroll down? I get that sometimes with the "Search" button, and scrolling down usually fixes it. Also, reduce the number of lines of the edit box in your user preferences. --Magnus Manske

Character entities in links

Sat Feb 2 00:23:40 UTC 2002: On list of food additives, I have additives like [[&amp;beta;-cyclodextrine]]. When I click on the question mark to create an article about it, I get the Main Page displayed for edit instead. Note that since &amp; is a safe character in URI path segments, escaping it as %26 has no effect.

This is due to a bug in the code putting too many HTML escapes into the title; if it were working correctly, the %26 escape would indeed have an effect. My recommendation until this is resolved: use &amp;beta;-cyclodextrine ([[beta-cyclodextrine|&amp;beta;-cyclodextrine]]). --Brion Vibber

There's probably good arguments for actually writing "beta-cyclodextrine" in the article. However, my point about the % escape is that according to RFC 2396, there is no difference between %26 and just &amp; in the path of the URL. --Carey

Well, there's the RFC and then there's the actual behavior of the software... PHP does not seem to consider %26 to be an ampersand for the purposes of extracting variables from the URL's *query* bit. At least my reading of the RFC agrees with it: ?3.4 Query Component ... Within a query component, the characters ..."@", "&amp;", "="... are reserved.? It's not a problem in the path, only in the query when you're e.g. editing the page. --BV

The URL rewriting to give nice URLs like http://www.wikipedia.com/wiki/MainPage rather than .../wiki.phtml?MainPage makes this a bit more complicated. There's no question mark in the URL for this edit page, so Apache is probably justified in converting %26 to &amp; internally, before processing the Alias or RewriteRule directive, or http://www.wikipedia.com/%77%69%6B%69/ wouldn't work. --Carey

(Ideally the URL would be encoded as %CE%B2-cyclodextrine, the UTF-8 encoding of GREEK SMALL LETTER BETA.)

Impossible unless the database is converted from ISO-8859-1 to UTF-8. --BV

I would just write &amp;lt;? echo urlencode(recode("h..utf8", $title)) ?&amp;gt;. --Carey

Yeah, that could probably work as long as titles are normalized internally. I'll try banging the code into place... --BV

References: RFC 2396, W3C on i18n of URIs

--Carey Evans

Impossible to edit some pages

(2002/03/16) I cannot seem to add anything to Feature requests. It refuses to allow any editing and returns an error beep. I can edit this and other pages. Vignaux

What browser are you using? Excactly when do you get the "error beep"? I can edit Feature requests just fine. AxelBoldt

Microsoft Internet Explorer (mac) 5.1.3(3905) on a Mac Cube. I get the beep whenever I try and insert a character, such as a return, into the editing window. It is still happening. Despite that, I can modify this window OK Vignaux

Vignaux, are you still having problems editing the feature requests page under the current software revision? Brion VIBBER 2002/03/27

(2002/03/28) Yes, I have just tried with Explorer and the problem has developed on this page now! But I have now switched to using Netscape 6.2.1 and it can edit this page at least. Vignaux

Huh. I'd consider it an IE bug, then, I don't know what's triggering it. Try contacting Microsoft support if you dare... (shudder) Brion VIBBER, Thursday, March 28, 2002

I have tried numerous times to edit this page with Mozilla/Galeon and it doesn't submit, it just sits there, so there is some problem with that browser. It might be the size of the page, as I edit other pages without problems. This is submitted with NS4.77. Seindal

This appears to be a bug in Mozilla that appeared circa 0.9.9 (?), please file a bug report at bugzilla. Brion VIBBER, Thursday, March 28, 2002

All of the above "cannot edit" bugs could be due to the fact that our edit page contains broken HTML. Click on "Edit this page", then on "Validate this page" and you'll see what I mean. AxelBoldt, Thursday, March 28, 2002

I thought of that, but I doubt it. First, I'd expect the problem to happen with *all* pages, since the broken HTML is on *all* edit pages. Second, any problem caused thereby would be likely to be with rendering, not with submitting the form. Unfortunately I can't reproduce the problem on my test server, with or without fixing the HTML. I've submitted fixes to CVS (though I'm leaving the WRAP in, it should cause no problems); try it again when Jimbo installs it... Brion VIBBER

Further, I tried saving the form from the live site, fixing the HTML so it validates, and submitting from the fixed version. Still doesn't work with Mozilla 0.9.9. So no, it's not the HTML bugs. For the time being, I just edit long pages with Konqueror... --BV

(2002/03/29) I am now editing this page in Opera. It still does not work in Explorer. I validated the page as suggested and there is an error on line 34, col 50. More to the point, I noticed that the editing window text is truncated in Explorer at the following place (the last word is cut off in the middle):

Each page should have a separator between the article and the bottom navbar. Currently, the article is flowing right into the navbar, which is very difficult to read. There appears to be neat separati

Is that any help? Vignaux

Well, you cut off a chunk of this page, too. :( (Now restored.) I've uploaded a copy of the feature request edit page with the HTML errors fixed -- try it at media:wik3.html Same problem? Brion VIBBER, Thursday, March 28, 2002

I am terribly sorry about that. I am sure I cancelled after attempting to edit. Yes, same problem with Explorer; the editing panel is truncated at :Oh, and another thing,. Vignaux

I still cannot edit this page with Mac Explorer though I can with Opera (as I am doing now). The symptom is the same: just a beep if I try and enter a character. I can edit other, smaller, pages. Vignaux (2002/04/15)

The page was truncated again -- I think I like IE's beep better than Opera's delete-large-swaths-of-text method. Exactly what versions of Opera and IE, and what version of Mac OS are you using? Brion VIBBER, Sunday, April 14, 2002

Today I tried to edit the article on Georges Méliès, and when the editing screen came up, it was a blank "Describe the new page here" page, for "Georges M*li*s". (I had this problem with Netscape Communicator, but I did not have this problem with Internet Explorer.) There must be some problem with recognizing accented letters in page titles. Joel Schlosberg, Thursday, April 4, 2002

Does this link work correctly? If so, the problem should vanish with the next wiki software upgrade. Brion VIBBER, Saturday, April 6, 2002

Problem in "printable version" page?

Please go to Category theory and try the "printable version" link; you will probably see that the word functors remains as a blue link instead of becoming simple italics text. I was unable to spot any sort of difference from other links that would cause this strange behaviour, and I suppose it can be considered a bug, since the printable version should not contain any link in the text part. Daniel M

Yup, it's a bug, caused by the fact that the link looks like [[functor|<b>functors</b>]]. It's fixed in the development version of the code. AxelBoldt

STATUS : Solved in CVS

Titles and Labels

Titles of Pages

(2002/1/26) The HTML titles of history pages all read ":encyclopedia article from Wikipedia". Furthermore, articles in the talk: and special: namespaces shouldn't be labeled as "encyclopedia articles". --AxelBoldt

(2002/1/28 Cosmetic) special: and wikipedia: pages have title "... - encyclopedia article from Wikipedia". They should not be indexed by search engines or should be indexed with a different page title. This is to "brand" "encyclopedia article from wikipedia" as a source of useful information -- ChaTo

Fixed it. --Magnus Manske, Sunday, April 14, 2002

STATUS : Solved in CVS

April 1 2002: HTML titles

This is more a semantic bug than software bug. The software renders every page with the the title "[page name]: encyclopedia article from Wikipedia". The problem is not every page is actually an encyclopedia article. I recommend that the title remain for pages in the article space (except for the front page), and change it for all other namespaces. --Stephen Gilbert

How about saying 'X: from Wikipedia, the Free Encyclopedia' for the other pages?

User Interface

Diff colors

Diff pages speak of green and yellow being the colors of respectively the changed text and the old text. This is useless to those who set their own text colours and not very nice to visually impaired people working on wikipedia. It would be handier if the main way to recognize which is which would be a text (such as: "The new text:" and "The old text:"). Of course, colours could still be used complementary, but they should not be the primary way of distinguishing the two atoms of a diff.--branko

Need more whitespace

(2002/1/25) The general layout of Wikipedia looks cluttered. It needs more whitespace to be remotely readable. --Damian Yerrick

I agree, especially at the top it's very busy. For new users, lets just have the page title in &amp;lt;H1&amp;gt;, the Wikipedia tagline, maybe Printable and Edit, then the content. --Carey Evans

I agree too - people new to Wikipedia will probably be overwhelmed by all the different links and actions at the top of the page. I suggest simplifing the top to the most necessary things and putting the rest at the bottom. Are two search boxes really necessary anyway?

Some things are not visible to new (=not logged in) users anyway, like the watchlist. --Magnus Manske

Link underlining

(2002/1/25) External links and different namespaces should still be underlined, or there's nothing to indicate to new users that they are actually clickable. Carey Evans

(2002-02-09) Now all 'normal' links are forced to be underlined (with the following):

 a { text-decoration: underline; }

This is overriding my browser's configured default, which is to display links without underlines. Can't this line just be omitted? -- Matthew Woodcraft

Usability Report

(2002/1/31) I've written a small Usability Report for Wikipedia pointing out some usability problems. -- ChaTo

Special Pages

"Stub articles"

I've run into a couple of odd problems while browsing through the stub articles pages. Firstly, there's an article with bold tags in its title that is messing up the table on

http://www.wikipedia.com/wiki/special%3AShortPages&startat=241&showLinksThere=0

The article in question is displayed as 241(16 chars) [[devotchka|Bdevotchka/b]], if people have been cleaning up stub articles since I posted this it may be earlier in the listing. Its row in the table appears to be mixed in with the subsequent row in the table, and afterward the columns of the table are misaligned. It also destroys the link at the bottom of the table leading to the next larger set of short articles.

Found another example: 385(27 chars) [[Upload/loa1[1].jpg|Upload/loa11.jpg]] also screws up the table, and doesn't appear to exist.

I have deleted the articles in question (relics of long-fixed search page and title bugs), so it should be gone from the list now. The table screwup problem is due to a more recent bug (see top of this page) with links with bad titles, which has been fixed in the code but not yet installed. Brion VIBBER

Secondly, there are a whole bunch of articles listed as having a length of 27 characters which don't appear to exist at all. For some examples, see here:

http://www.wikipedia.com/wiki/special%3AShortPages&startat=321&showLinksThere=0

When I click on these links, I go straight into edit mode as if they were new. I believe that the 27 characters the stub finder claims these articles to have are "Describe the new page here." Bryan Derksen

That seems to be a feature: a page that somebody saved without actually editing anything (and thus containing only the new-page message) comes up in edit mode. On the other hand, we probably shouldn't actually save a page that contains only the new-page message. Brion VIBBER, Saturday, April 6, 2002

"Upload files"

The upload files page doesn't have a image uploading policy or something like that: We should not use formats like GIF, with can cause patent problems, or like BMP. with are not optimal. I suggest PNG and JPEG.

Also, we probably have no need for .exe or .mp3 files--do we?

"Watchlist"

My watchlist (for LC) says I made three changes to the page LC in 1969. I don't recall making any changes that year.

Seems like I accidentially invented a time machine ;) --Magnus Manske

"Orphans" page isn't completely correct

For instance, Godfrey_Reggio is not and never has been an orphan page; it was created long after the article for his documentary Koyaanisqatsi. Similar issue with other articles listed.

I've noticed that "Orphans" gets confused by whether a title contains spaces or underscores between its words.

If an article is created with underscores, but all the links to it have spaces, then it is listed as an orphan. I've noticed that in the URLs, the strings "%20", "_", and "+" can be used interchangably. "Orphans" should be updated to treat all three the same.

Also, pages that could be usefully listed as Orphans are not, e.g., "Society for Worldwide Interbank Financial Telecommunication" is not listed, presumably becaused "SWIFT" redirects to it. However nothing links to SWIFT and it looks like redirections are not counted as Orphans.

"Most wanted" articles with trailing spaces (2002/02/04)

A link of the form Israel (note the spaces in the link source) causes the Most Wanted page to think that an article called Kingdom_of_Israel_ (note the trainling underscore) is required. I have created a redirect to Kingdom_of_Israel to fix this particular case.

"Recent Changes"

The Recent Change page has many design flaws.

When I want to list all the new changes since my last visit to the site, I can only see the most recent 100 changes. Given all the minor changes are always included, one exceeds the 100 entries limit in a few hours, if you are away for more than a day, you have serious trouble seeing the complete list. It may not be problem for the wikipediaholics who check the Recent Change page every 30 seconds, but it simply does not work for the regular users.

I tried using the max count and the age link, they also have design flaws and do not work intuitively. When I click last seven days, it shows only 100 entries that cover only half a day, (same problem as above). When I click last 2500 entries, it either fails to return anything or it covers only the last 3 days. i.e. There is no way to ask for last seven day without count limit, or a count limit but no age limit.

workaround: Since the 100 count limit can be easily reached, it becomes the limiting factor. In effect, all the links, 1 day, 2 days, 3 days, 5 days, 7 days, 14 days all give the same 100 result. To workaround this problem, you can right click on these links and copy its URL iinto the address field of the browser, change the count limit and hit ENTER.

RecentChanges regularly claims (2 Changes) if there was only one. Except for new pages, it always counts one to many. AxelBoldt

"List only new changes" doesn't work

(2002/1/26) On special:RecentChanges, the link saying "list only new changes" consistently returns an empty list, even after waiting a while. --AxelBoldt

Right! Same here. Maybe because i'm using a +8 hours offset? --Luis Oliveira

Yes, there's a bug in the time zone handling code. I am on Central time (Server time + 2h) which I set in my user preferences and I noticed that the "List only new changes" link returns something only after I wait for 2 hours, and then only those changes that have occured two hours since I last accessed RecentChanges. AxelBoldt

minor edits showing up even if turned off (2002/03/05)

And with bad links and dates?

minor edits hide the major edits (2002/04/12)

When I turn off the minor edits in the preference, I would expect the most recent major edit would take its place.

For example, the history shows that an article was edited (major) at 1pm, and the same article was edited again (minor) at 1:02pm. In the Recent Change page, both the 1pm and 1:02pm edits become invisible if the preference is set to hide minor edits.

Character Sets

Non-ascii in titles

(2002/1/21) -- ISO-8859-2 characters cannot be in title of article - number of international wikipedias need this ...
- I'll wait for the English script and the bomis CVS to go online, there are some people who know the character encoding things better than me... --Magnus Manske

Japanese Wikipedia marked as ISO 8859-1 2001-12-31

http://ja.wikipedia.com is illegible with IE 5.0 (Mac) because its HTTP (MIME) header includes the line

Content-Type: text/html; charset=ISO-8859-1

The charset should be changed to something appropriate (Shift_JIS or UTF8), or removed and replaced by the equivalent META tag.

The Japanese wikipedia now puts out "x-sjis" in its headers, Shift-JIS is allowed in page titles, and it is more or less usable. However, some characters are being mysteriously screwed up (katakana RU for instance); please test and report if you can figure out exactly what's going on. 2002-03-01 Brion VIBBER

Found it, the darn Perl CGI module was at fault with bad defaults for escaping characters. Sent fix to Jimbo. 2002-03-01 Brion VIBBER

On a similar note, visitors to http://www.wikipedia.com should be automatically redirected to the Wikipedia written in the language of their choice, as expressed in their browser language preferences. -- poslfit

Then how would Dutch/English bilinguals switch to the English version? en.wikipedia.com doesn't seem to have any content. --User:Damian Yerrick

The same problem occurs in Netscape 4.77. However, IE5 works fine. This is very similar and may be related to the problem reported at the bottom of this page. See talk:Ranma 1 for details.

Miscellaneous Problems

Date/Time Error on My Watchlist 2/26/02

I just clicked on the "my Watchlist" link, and went to the right place (a good thing), but all of the watchlist changes are now listed under 2/25/02, 15:51 (not a good thing, since yesterday they were sorted by day and time!). Thought you might want to know! JHK

This isn't a bug in "my watchlist". The problem is that the timestamp on every article got changed (which also added a few thousand pages to Recent Changes). --Zundark, 2002 Feb 26

This was my fault. With the introduction of the new database schema we introduced a new column that had to be filled with a new value. I forgot that setting this value automatically updates the timestamp of the article. So this is not a bug in the software but in the procedure for moving to the new database schema. -- Jan Hidders 2002 Feb 26

Simple searches failing with apostrophes (2002/02/04)

A search for 'benfords law' failed to find the benford's law article. (I put in a redirect to fix this, but this is such a common case that this is arguably a bug.)

Related: account creation fails when password contains a n apostrophe (2002/02/27)

Searches also fail with hyphens (2002/02/12)

Probably related to the apostrophe above; a search on 'Kraft-Ebbing', 'Bulwer-Lytton' or 'Sacher-Masoch' comes up blank, in spite of there being articles on all these people; a search for 'Lytton' though, does come up with the correct page, so the problem appears to be the non-aphanumeric character. Malcolm Farmer

Searches now reject hyphens (2002/03/05)

I re-ran the search for a term with a hyphen: I tried looking for "Bain-marie" and instead of coming up blank as previously, the search now returns:

Sorry, your boolean search query contains the following errors:  
 "bain"  [!! SYNTAX ERROR: illegal symbol '-'; ignored] 
  AND "marie"

Malcolm Farmer

This is not a bug, it's a feature: before, the search failed silently, now it tells you why it fails. See wikipedia:Searching. AxelBoldt

Two different articles with same title

(2002/1/28) Churches Uniting In Christ has two different articles with the same URL and title. If you type in the URl, you get one article, but if you search for the title, it gives you two different ones... Dreamyshade

Table based layout

More generally, though, the new layout leaves me nonplussed (sorry guys - I know it was probably a lot of work), and worse, putting it into tables creates several varieties of problems:

It renders *much* slower, esp. on big pages. (This with an Athlon 900!)
In my experience, tables won't render in Netscape 4 unless the whole page loads - so no cancelling partway through a long page.
Tables make it harder to do things like select text and parse page structure with a script.

-J

It should be relatively easy to change the thing to use CSS instead of tables. For an example of CSS and markup that produces a layout similar to this (content area + right side navbar) and works on IE 4-6 and Mozilla, look at http://pineight.com/ --DY

Each page should have a separator between the article and the bottom navbar. Currently, the article is flowing right into the navbar, which is very difficult to read.

There appears to be neat separation with bars all over the place when I view things with IE. But at home, with Mozilla, everything flows together, and is very difficult to get a grip on. GayCommunist P.S. Oh, and that "insert my username as signature" automagically doesn't appear to work, at least not in preview.

Capitalisation

Look at the entry for model organism. The reference to e. coli 0157:H7 doesn't display with the E capitalised. However, when you try to edit the page to fix this, the E is apparently capitalised.

You can't use colons (:) in regular page titles; if you try to create that page, it will not be allowed. Colons are reserved for separating a namespace (talk:, wikipedia:, log:, user: etc) from a page name. It is a little odd that the link is being shown in the article with changed capitalisation, however. But really, the link should not even be recognised as a link if it's an invalid page (as "e. coli 157" is not a valid namespace), this should be fixed. Brion VIBBER 2002/03/14

Performance

I am not sure if this is the place (if not, just point me on to the right one) but the performance of Wikipedia has seemed to degrade continuously over the past week or two. This is especially true of many of the special pages ClaudeMuncey, Thursday, March 28, 2002

Editing on not current version

2002/04/12 - while editing second-order desire, I normally started form the recent changes page that linked a version of 03:43, but when I had the page edited, I casually went to that page's history and I realised that there was another version (03:51), later than the one I had modified, that was not the one linked in recent changes and which text was not in the editbox. Probably, the database had a delay (half an hour?) in recording the latest version (03:51), even if my version was immediately recorded at 04:20. --Gianfranco

Most likely, the 3:51 change occurred after you loaded RecentChanges and before you loaded the edit page -- your 4:20 change includes everything from the 3:51 change, so it was definitely the 3:51 version that you modified, not the 3:43 version. When exactly did you load the RecentChanges page? Brion VIBBER, Friday, April 12, 2002

The main fact is that I certainly opened the RecentChanges page and the edit page after 03:51, because I modified the article in no more than 10 minutes, let's say a quarter of an hour for all the process - certainly it wasn't half an hour. Ordinarily, the 03:51 edit should have already been recorded when I opened (really, refreshed) the RecentChanges page.

In the 03:51 version, you can see a link to stereotype (first paragraph after the numbered list) that I had never seen until I realised of this version and opened it: for sure it wasn't in the editbox' text, I would have edited that text too. So, actually, I edited the 03:43 version at least a quarter of an hour after the other user had edited the 03:51 version.

Moreover, if you look at the diff for last version (mine), there is no evidence of that link, that disappears after the previous diff page (03:51 from 03:43).

I can only add that that both 03:43 and 03:51 versions are from the same author; could this fact having interfered? --Gianfranco