Wikipedia: Wikipedia bugs

Please submit bugs with a bold title and date, and a specific reference.

UNCONFIRMED

Newly submitted bugs which noone has been able to duplicate yet.

CRLF line endings 2001-12-19

In David Lynch, as an example, if you inspect the resulting page, apparently, each stored line is ended with a CR-LF sequence. However, if I edit it within Lynx, the endings disappear, as they don't exist on Unix. That's all good, but all edits will then differ in all the lines (since no lines match their previous version, everything has a different ending..) See, for example: [[1]] I just fixed a typo in the first lines, and it looks as if everything has changed. Arguably, Lynx, and/or my text editor can be at fault too, but I don't think CR-LF should be stored as part of the text either.. --Chexum

On going to a random page I got http://www.wikipedia.com/wiki.cgi?NNTP, what came up was nntp, I redirected it to NNTP but this did'nt work. "Describe the new page here." would'nt go away. Also if I go to http://www.wikipedia.com/NNTP by searching and edit it when I hit save I am directed to nntp rather than my changed version. If I click on the NNTP link in this paragraph I get a 404 error.

I'm not sure if this is a bug: when you search for something, the old logo shows up on the search page, as in http://wikipedia.com/search.fcgi?request=happy

All's Well That Ends Well When I try to get to the page http://www.wikipedia.com/wiki/Alls_Well_That_Ends_Well--Text (Alls Well That Ends Well--Text), I get a 500: Server Error. This is the only page that's been doing this to me in recent months, and it's done it every time I've gone there. -- BD

: Update: I just got into the page by typing ?action=edit etc. into the URL. Looks like a complete dump of the raw text of the play, as I had expected; the only odd thing which might have been causing wikipedia to choke was an unescaped (ie, not HTML-coded) æ character right at the beginning.

Diff function http://wikipedia.com/wiki.cgi?action=browse&diff=1&id=Tissue gevies me the diff of 1394. Finally, a bug I won't have to fix myself ;) -- Magnus Manske, November 26, 2001

http://www.wikipedia.com/wiki.cgi?action=browse&diff=2&id=Vegetarianism gives the diff of JT. -- KQ, December 2 2001.

Superscripts in ASCII Tables distort vertical lines

This isn't really a bug, but I thought I should pass it along. There are some footnotes in the geologic Timescale 11/26/01 that are superscripted using HTML. They don't look all that bad in IE, but they do somewhat alter the spacing of the vertical bars following them on the same line in this ASCII table. They look worse in a text mode browser like LYNX than in IE or Netscape. Same will be true of other HTML that alters text sizes. That is the way things are I guess. Also, I suspect that ASCII tables and ASCII art (if any) need to be checked with LYNX. I trimmed the geologic Timescale to get a one to one of intended lines to displayed lines when using Lynx. Others might want to do the same if they have similar situations.

: --Carey Evans, 17 November 2001

Cannot diff redirected pages (9 Dec 2001) Attempting to retrieve diffs of redirected pages (e.g. BBS) results in the redirect being processed and no diff shown. Very irritating. -- Taral

NEW

Newly submitted bugs which have been duplicated or otherwise confirmed as being a real bug.

AOL Bug Users of America Online versions 4.0 and 5.0 FOR APPLE MACINTOSH running on various PowerMacs? with down-lever OS 8.5 and 8.6 (sorry I should have said) can no longer access Wikipedia -- they see a blank web screen and unaccountably a download dialog box opens and invites them to save "untitled" to their hard drives. AOL tech support confirms this and simply does not care. Since the world is teeming with prospective readers and contributors who may be using AOL, is there anything to be done, besides the obvious work around of running external browser? -- WOL

: I couldn't duplicate this bug using AOL 5.0, either using AOL's browser or using MS Explorer. (I am saving this change using Explorer. I saved a change to the sandbox using AOL's built-in browser.) --LMS

Case sensitivity Links that do not work:

OK - this is weird. I fixed the American football link in Johnny Unitas, it forwards to the new page, but it will not show up as a link.

: Right now (April 4, 2001), you have to use the same upper/lowercase letters in free links as the target page. (The first letter can be lowercase, but all the others must match.) This means that [American Football]? (capital-F Football) will not currently match American football (lowercase f). This is considered a bug, and it will be fixed in 0.92 (sometime in April 2001). --CliffordAdams (ID 1675. I am not a free man--I am a number!)

Example: Nitroglycerine. Compare the source with the appearance. Is something wrong. (At the time i make this complaint, there is no such article. This may matter.)

: This is intentional. The first letter of all pages (and the first letter of subpages) should be capitalized, and the wiki should force capitalization if it is entered in lowercase. Unfortunately, the 0.90 version has a few ways that lowercase pages can slip in--they are fixed in 0.92. (All pages will be capitalized when the conversion occurs.) --CliffordAdams

: Is REDIRECT lowerCase? one of these, since I've had the odd bother with this (as opposed to REDIRECT LowerCase?)

When using a REDIRECT command, the first letter of the article title must be capitalized to lead to an existing article.

www.wikipedia.net
If wikipedia is accessed as www.wikipedia.net, not www.wikipedia.com, then the main page is shown but hyperlinks are broken. The .net URL was given on slashdot.org. I also wouldn't expect a community project to be a .com. It was being accessed with mozilla/linux with javascript enabled and java disabled.

I assumed the site was junk and didn't bother looking at it again for months. You really should fix this ASAP. Who knows how many potential participants have been lost. I'd recommend more care with initial user entry into the site; that's make or break time.

JB 20010811

: Still a problem, October 31, 2001
: Still broken, December 2, 2001
: Still broken, December 6, 2001

Why not just have a simple redirect to http://www.wikipedia.com/ at http://www.wikipedia.net/ until this is fixed properly? -- The Anome

Caching problems
There is also a caching problem where links sometimes do not show as active although there have been articles written for them. To make the links show up, make a change to the page that the link is on and then save the edit. Changes that merely add or remove spaces do not work, but any other edits do. But please do not convert the spaces in the link to underscores, as doing so prevents that linked term from showing in a search. (That is, if you're searching for references to "Puerto Rico," the search results will not include any occurrences of "Puerto_Rico.") Cache bug

Possible bug to be fixed. Look at data compression. The link at the bottom to Arithmetic coding, looks like there is no article there yet, but you click on the question mark and you get the actual article to edit. (This now appears to be fixed?)
- This is a caching problem; to make the link appear simply edit the page and save. Any edit which does not merely add or remove a space will work; some people convert the spaces in a link to underscores, but I think that trick is to be avoided because then the term does not show up in a search. I like to add the html code for a space ( ) somewhere, as it doesn't change anything in the text.

On Wikipedians, the link to Wikipedians/New Zealand shows up as [/New Zealand%2

Note: caching problems are more common in the Czech version.

Pages claim to be XHTML 17 November 2001

Wikipedia pages include a DOCTYPE that claims the content is XHTML Basic. Given just how far from the truth this is, and how difficult it will be to ensure correctness when anyone can enter a range of HTML tags, no DOCTYPE should be included at all.

Examples of HTML used that isn't XHTML Basic below. See [2] for an even more picky analysis.

img tag isn't closed - should be <img ... />.
html lang, body bgcolor, img align and img border attributes aren't in XHMTL Basic.
hr and font tags aren't in XHTML Basic.
list items and paragraphs aren't closed: < li> ... < /li>.
Some attribute values aren't quoted, e.g. type=text must be type="text".
Some inline elements aren't contained in block-level elements, like the toolbar at the bottom of the page.

This does have actual effects on the pages: in Mozilla, the top hr element overlaps the logo, and nested indents (like on Carey Evans/Talk) don't work.

The pages also claim to be UTF-8 encoded XML (<?xml ...?> PI at the top of the page) while the HTTP headers say ISO-8859-1.

I can confirm this. The problem with nested indents is particularly bad, as it makes some pages more difficult to read. -- Taral