Wikipedia:Phase II bug reports: Difference between revisions

Revision as of 21:11, 6 January 2002

Latest revision as of 06:05, 14 March 2025

(369 intermediate revisions by 97 users not shown)

Line 1:

{{archive}}

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

{{see also|Wikipedia:Squashed bugs}}

'''This is an archive only of bug reports from Phase II of the Wikipedia software (used before [[June 20]], [[2002]]). Please see [[Wikipedia:Bug reports]] for instructions on adding bug reports for the current system.'''

== Proper sections ==

*[[Wikipedia:Bug reports/Logging in|Logging in]]

== UNCONFIRMED ==

*[[Wikipedia:Bug reports/Editing|Editing]]

*[[Wikipedia:Bug reports/Parser|Parser and formatting]]

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

*[[Wikipedia:Bug reports/History|History and diffs]]

*[[Wikipedia:Bug reports/Searching|Searching]]

*[[Wikipedia:Bug reports/Special pages|Special pages]]

*[[Wikipedia:Bug reports/Internationalization|Internationalization]] (character set issues, etc.)

== Uncategorized bugs ==

----

'''[[Clitic]] comes up as an old version'''

2002-05-09 phma

'''The first letter of usernames are automatically capitalized upon submission of the "preferences" page.''' 2002-1-1

The Clitic page shows as an old version. If you hit "Edit", the current version shows in the edit box.

[[Extremophile]] is also showing up as an old version, and with a diff showing that it is new, when it has been edited several times.

:Page caching has recently been reactivated after a couple of months disabled, but the old page cache wasn't cleared. Some pages may thus show the old cached versions; this should be fixed pretty soon. In the meantime, editing and immediately saving a page should re-cache it with the current version. [[user:Brion VIBBER|Brion VIBBER]], Thursday, May 9, 2002

If a all lowercase string is input into the "UserName" field in the preferences page, the first letter of said string is capitalized.

:''Yes, this is still happening a lot. It's nasty -- can we turn off caching until we are sure it is 100% reliable?'' [[user:The Anome|The Anome]], Monday, May 20, 2002

:This is already fixed. Jimbo, please upgrade us to the latest CVS version and clear the page cache (which should always be done when the software is upgraded so that pages misrendered by old bugs can be corrected automatically.) And no, Anome, we can't just turn everything off until we're sure it's 100% reliable -- then there would be no Wikipedia at all! :) [[user:Brion VIBBER|Brion VIBBER]], Monday, May 20, 2002

----

May 12 2002

I am still getting this problem on many pages, if the pages show at all.

May 8, 2002:

----

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

'''User contribs link doesn't work on user page that starts with a lowercase letter'''<br>

Looks like the lowercase user name contribs bug is back - check out [http://www.wikipedia.com/wiki/special:contributions&theuser=Maveric149 Maveric149's contributions] and [http://www.wikipedia.com/wiki.phtml?title=special:contributions&theuser=maveric149 maveric149's contributions] --[[user:maveric149|maveric149]], Wednesday, April 3, 2002

== Titles and Labels ==

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.

'''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". --[[user:AxelBoldt|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 -- [[user:Chato|ChaTo]]

:Fixed it. --[[user:Magnus Manske|Magnus Manske]], Sunday, April 14, 2002

<span style="color:red;">STATUS : Solved in CVS</span>

----

'''April 1 2002: HTML titles'''

This is more a semantic bug than software bug. The software renders every page with 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. --[[user:Stephen Gilbert|Stephen Gilbert]]

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

== User Interface ==

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

'''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.

[[user:Carey Evans|Carey Evans]]

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

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

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? -- [[user:Matthew Woodcraft|Matthew Woodcraft]]

'''Usability Report'''

includes the line

(2002/1/31) I've written a small [[User:Chato/Wikipedia_Usability_Report|Usability Report for Wikipedia]] pointing out some usability problems. -- [[user:ChaTo|ChaTo]]

----

== Miscellaneous Problems ==

'''Two different articles with same title'''

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

(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... [[user:Dreamyshade|Dreamyshade]]

----

'''Table based layout'''

The charset should be changed to something appropriate (Shift_JIS or UTF8), or

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:

removed and replaced by the equivalent META tag.

* 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/

--[[user:Damian Yerrick|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. [[user:GayCommunist|GayCommunist]] P.S. Oh, and that "insert my username as signature" automagically doesn't appear to work, at least not in preview.

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

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 [[Ranma 1/Talk]] for details.

'''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. [[user:Brion VIBBER|Brion VIBBER]] 2002/03/14

----

=== Performance ===

2002-05-30<br>

Wikipedia is down from about 4:40 to 6:00 server time every day. Any sort of access gets a timeout, and there are no changes during that time. -phma

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 [[user:ClaudeMuncey|ClaudeMuncey]], Thursday, March 28, 2002

'''CRLF line endings''' 2001-12-19

2002/04/23 - Performance has been awful for at least a week. What can be done to speed up the system???? Even with a high-speed link, it takes over 1 minute for any page change. kjgraham

2002/04/24 - There have been some HUGE performance problems with me over the last couple weeks. Over the last week, it seems the server has been down(to my connection @least) from when I get home @ 3:00PM EST to about 5:45. I cannot access the frontpage or any other page. Also, many of the searches are screwing up. Maybe 3/4 of the "most wanted" pageloads fail on any given day. Is the server experiancing any obvious problems? One suspect thing: The Most Wanted, Orphans, etc pages seem to load extra-worse. Are these pages being compiled dynamically for each person viewing them? It would make much more sense, given the load, to compile things like the most popular page at an interval, like every 30 seconds or something, and then load that version of the page. -LeSqual

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: [[http://www.wikipedia.com/wiki.cgi?action=browse&diff=1&id=RoseParks/Disability_Etiquette&diffrevision=2]] 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

2002/04/24 - For the last few days, Wikipedia has been slower than [[Everything2]], a site notorious for lag. --[[user:Damian Yerrick|Damian Yerrick]] (a date-challenged user)

:Date-challenged? When I set the date two days in the future, I was only predicting the time it would take Wikipedia to finally commit the changes to this article ;-) Fixed. --[[user:Damian Yerrick|Damian Yerrick]]

----

2002/05/18 - Links don't always seen to be appearing. I created a number of articles on counties in New York State, and they do not show up as links in the [[New York]] article. They appear just like all the yet-to-be-done county links. But they are there. (See [[Allegany County, New York]], for example!) -- BRG

By editing and saving the New York article, the links appeared. This even though no change was made in the edit. -- BRG

:Somewhere between Lynx version 2.8.2 and 2.8.4, now Lynx also submits texts with the CR-LF line-endings, so it's a bit better. I still think that they souldn't be there on the displayed entries. --[[Chexum]]

----

'''troubles with slashes in article names'''

Not sure where to categorize this one, so I'll put it here for now. There appears to be a bug with how Wikipedia handles articles with slashes in their titles. I discovered this while on a rampage deleting 0-length and "describe new article here" articles; when you try to delete an article with a slash in the title, you get a 404 after clicking on the confirmation link. When I changed the URL-encoded slash from %2F into a / in the URL, however, the deletion proceeded normally.

:Possibly an Apache configuration problem; I'm not quite sure what's up with it, but changes already in CVS conveniently work around it by calling the script name directly instead of relying on the URL rewriting with the pseudo-directory /wiki/. [[user:Brion VIBBER|Brion VIBBER]], Saturday, May 18, 2002

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

Furthermore, the automatically-generated Talk link from a page with a slash in the title leads to its "parent" aritcle's talk page rather than one for that specific article. For example, check ou the talk link in [[George Orwell/Shooting an Elephant]]; it leads to [[Talk:George Orwell]] instead of [[Talk:George Orwell/Shooting an Elephant]]. --[[user:Bryan Derksen|Bryan Derksen]], Saturday, May 18, 2002

:Hey, that's not supposed to happen! Grrr. [[user:Brion VIBBER|Brion VIBBER]], Saturday, May 18, 2002

----

'''ISBN ghost link'''

2002/07/05

'''All's Well That Ends Well'''

I entered a reference to the below book in the [[knot]] article. When the 'Save' returned it had turned the ISBN into a link sending the user to:

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. -- [[Bryan Derksen|BD]]

http://www.pricescan.com/books/bookDetail.asp?isbn=0921335474

: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) &aelig; character right at the beginning.

The link is not generated by the text of the article. It appears the Wiki software is generating the link. If this is a default setting I would propose http://www.isbn.org/standards/home/index.asp as a better option.

If this is a bug can it be remedied?

'''All The Knots You Need'''<BR>

Lee,R.S.<BR>

Algrove Publishing<BR>

{{ISBN|0-921335-47-4}}

Booo....

'''Diff function'''

[[user:Satsun|Satsun]]

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.

<XHTML bug moved to NEW>

:--[[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]]

:Could this be related to the XHTML bug below? (If it's still a problem.) When did it start? --[[Carey Evans]]

'''Case sensitivity'''

<b>Links that do not work:</b>

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 <i>first</i> letter can be lowercase, but all the others must match.) This means that [[American Football]] (capital-F Football) will not <b>currently</b> 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|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.

Yes, this [[ISBN]] linking feature is expected behaviour.

Look at the other ISBN in the article, which I have fixed, to see how it's supposed to work.

I don't see how a link to <code>isbn.org</code> is useful, since as far as I can tell, there's no way to look up an individual book there.

<code>Pricescan.com</code>, while of a commercial flavour, gives you access to all the information that you need to find a book.

Unfortunately, that site doesn't have every book &mdash; that's why your link leads to an error.

&mdash; [[user:Toby Bartels|Toby Bartels]], Saturday, July 6, 2002

----

I have twice had problems editing wikipedia articles using the Opera browser (5.0.498) on Mac OSX (10.1.5). It seems not able to handle long articles, truncating them drastically and annoying the heck out of whoever typed all that stuff in in the first place. The problem is made worse because I, at least, am not in the habit of using Preview to compare what is produced to the previous version because I am really only checking the changes I put in intentionally. Nor do I customarily run a Diff after the article is saved. I am reluctantly dropping Opera despite its other virtues. One Opera virtue I will miss: it clicks when a page completes loading, very useful when wikipedia is in molasses mode, allowing me to multiprocess off somewhere while "Awaiting document from wikipedia" I've also reported this problem to Opera.[[user:Ortolan88|Ortolan88]], Thursday, July 11, 2002

:This is a problem with many browsers on the Macintosh platform, and appears to be due to a limitation in the MacOS text edit widget (only 32k of text allowed, any more is truncated). [http://mozilla.org/ Mozilla] implements its own widgets and should not be limited by this. ([http://netscape.com/ Netscape 6/7] should be the same, being a derivative of Mozilla). --[[user:Brion VIBBER|Brion VIBBER]], Sunday, July 14, 2002

'''www.wikipedia.net'''<br>

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]]

----

when I click on the date [[July 14, 2002]] on the tool bar, I get a "parameter is incorrect" message..., Sunday, July 14, 2002

:I thought we already took that feature out? (It was very unpopular; the last thing we need is an article for every day in history! :) The simple solution: go into the [[special:EditUserSettings|preferences]] and change the "skin" to the improved Cologne Blue interface. Nasty link-of-the-day is definitely gone there, and in general the site is more attractive. --[[user:Brion VIBBER|Brion VIBBER]], Sunday, July 14, 2002

'''Caching problems'''<br>

::ok. Thanks. But I prefer not to switch to cologne blue until I have no more choice. Though it's MUCH nicer, the color of the links is too pale, I don't see very well and it's rather tiring to my opinion. Worse, the navigator doesn't appreciate at all the dynamic links of the tool bar, the police is all wrong, small and distorted. On the fr.wiki I can't use Netscape at all, because it refuses links with accentuated letters...something to do with encoding, but I didnot find the solution. I guess Netscape is really on its way out...--ant. <br>btw, we are done with the homepage translation

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.")

I suspect that this is because the link is to <code>July&nbsp;14,&nbsp;2002</code>, rather than to <code>July%2014,%202002</code> or <code>July+14,+2002</code>, as it should be.

'''Cache bug'''

Netscape, at least in its earlier incarnations (I don't know about now), can't handle this, for example.

&mdash; [[user:Toby Bartels|Toby Bartels]], Sunday, July 14, 2002

* 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 <i>(&amp;nbsp;)</i> somewhere, as it doesn't change anything in the text.

On [[Wikipedians]], the link to [[Wikipedians/New Zealand]] shows up as &#91;&#47;New Zealand%2

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

:true. It does link to a blank page to be filled on Opera. So that's a netscape issue (4.7) -- ant

----

== RSS feed address ==

I'm not sure if the rss feed for wikpedia was to the "old" version or the site or the new, but just to let someone know:

http://www.wikipedia.org/tools/feed-en.rdf as listed with http://syndic8.com no longer appears to host a feed. If there is an updated url to this feed, please "re-"suggest" the feed (this restarts the indexing/approval process) at syndic8.com, and I'll keep an eye out for it after it polls, to try and get it quick re-approval for the index. I'm a big fan of wikpedia efforts and I think having feeds to the "what's new" aspect of the site would be a valuable resource!

Thanks, Lori Easterly

---

[[Category:Wikipedia archives|{{PAGENAME}}]]

'''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 [http://validator.w3.org/check?uri=www.wikipedia.com] for an even more picky analysis.

* img tag isn't closed - should be &lt;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.

:The headers are correct, the internal doctype and character set are both wrong. This should be fixed when we move to the new software. UseMod wiki in general gets it right: it shows <code>&lt;!doctype html public "-//W3C//DTD HTML 4.0 Transitional//EN"&gt;</code>, and no character set. --LDC

::The utf-8 encoding cause Netscape to show Unicode characters as question marks. See [[Ranma 1/Talk]] for details.

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