Wikipedia:Parser bug reports: Difference between revisions
Content deleted Content added
No edit summary |
MalnadachBot (talk | contribs) m Fixed Lint errors. (Task 12) |
||
| (35 intermediate revisions by 17 users not shown) | |||
Line 1:
{{historical}}
'''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.'''
=== el error, imagino de poca importancia, es que he notado una pequeña singularidad ; si usted va a una página especial tal como [ [ special:NewPages ] ] directamente, los menús del borde de la página son celestes, como deben ser, pero si usted va allí directamente,redirigiendo por ejemplo [ [ los nuevos asuntos ] ] los menús del bode siguen siendo blancos como si fuera una página normal [ [ user:Bryan Derksen|Bryan Derksen ] ]
=== Case-insensitive wiki's ===
(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-insensitive in the same way the search is. Or am I missing something obvious?
MSM
:I copied this to bug reports, because I'm ''pretty'' sure it's new behaviour. -- [[user:Marj Tiefert|Marj Tiefert]], Thursday, May 30, 2002
:No, it's always worked like that so far as I know. Some of the non-English wikis have been on a really ugly system whereby Every Word In A Title Had Its First Letter Capitalized Like This Which Is Really Fricking Annoying And I Am Really Glad That We're Getting Rid Of It There Because Oh-Man-Oh-Man It's Ugly Isn't It? But we haven't had that here on the English wiki, thank goodness; it's case-sensitive except for the very first letter of a title, which is always capitalized in the title and can be either way in a link (ie, [[Asteroid]] and [[asteroid]] are the same article). Certainly it's been that way at least since mid-January when I got here. If you want your capitalization proper, please fix the articles that have inproper capitalization. [[user:Brion VIBBER|Brion VIBBER]]
-----
'''Backslashes don't display''', Wednesday, May 29, 2002
See [[Blackboard_bold]] for two examples. This is a new bug, since they used to work. --[[user:Zundark|Zundark]], Wednesday, May 29, 2002
:This is an instance of the cache bug: the displayed page was not the current page, but an old cached version. Re-saving the page fixed the problem. [[user:AxelBoldt|AxelBoldt]], Wednesday, May 29, 2002
::[[ASCII]], on the other hand, is an actual instance of backslashes not displaying. I've fixed it twice now. Each time, the backslash displays immediately after saving the page, but if I then reload the page the backslash goes away again. [[user:Bryan Derksen|Bryan Derksen]], Wednesday, May 29, 2002
::I can't find a description of the cache bug at the moment, but your (Axel's) description appears to be wrong. Re-saving the page had no effect, it only made it look as if the problem was fixed because you were no longer seeing a cached version. Reload/refresh the page and the backslashes will disappear again. See [[Eigenvector]] and [[Matrix]] for some particularly obvious examples. --[[user:Zundark|Zundark]], Sunday, June 9, 2002
:::Correct, saving a page in cache stripped backslashes. It's now fixed in CVS. [[user:AxelBoldt|AxelBoldt]], Sunday, June 9, 2002
----
Line 41 ⟶ 43:
''(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
: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. :) [[user:Brion VIBBER|Brion VIBBER]], Wednesday, April 10, 2002
Line 53 ⟶ 55:
[[justrob|Rob Salzman]]
:Hmm, I think this is semi-fixed. Anyone still seeing these kinds of errors? [[user:Brion VIBBER|Brion VIBBER]], Friday, April 19, 2002
<
== Parser ==
'''Last line link in list'''
Line 92 ⟶ 79:
: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). [[user:Brion VIBBER|Brion VIBBER]] 2002/03/02
'''Another linking error''' - My user page had some external links that were just the usual raw html://yaddayadda.com/etcetera and they used to work, but today they didn't. I wasn't because there was an asterisk or a parenthesis immediately before or after the URL. It doesn't seem to be because the URL ends in a / - I looked at other user pages to compare, and I '''cannot''' figure out why it wasn't working - gremlins? (Look back one or two levels in the history of my user page to see the formats - I've since forced it to work, by hiding the URL from the displayed page.) -- [[user:Marj Tiefert|Marj Tiefert]], Wednesday, May 15, 2002
:I believe that the current software is actively unlinking URLs like that. I edited a page that had an external link in it of the form you describe above, just a bare URL, and even though I didn't touch the external URL in question it came up unlinked after the edit. Try it out; find a page with an existing external link, edit it, and the link will be gone in the new version. This doesn't apply to links using the syntax <nowiki>[http://yaddayadda.com/etcetera name of link here]</nowiki>, however. Those remain intact through an edit. [[user:Bryan Derksen|Bryan Derksen]], Monday, May 20, 2002
::This only seems to happen under some circumstances; I've seen it in some articles, but I can't for the life of me reproduce it in [[Wikipedia:Sandbox]]. I think it may be already fixed under the current development version (where I can't reproduce it even by exactly copying Marj's user page). [[user:Brion VIBBER|Brion VIBBER]], Monday, May 20, 2002
:::If you only have a naked URL on a page, it won't turn into a link. If there are other URL's on the page, it sometimes turns into a link. This is fixed in CVS. [[user:AxelBoldt|AxelBoldt]]
::::2002-6-10 Seems to still be a problem; see the links at the end of [[daylight saving time]] for an example. [[User:Rootbeer|Rootbeer]]
::::2002-6-16 I fixed [[daylight saving time]] by opening it for editing and saving it again with no changes. I don't know enough about the internals (caching?) to say why it worked. But if this problem has been fixed in the software now, I suppose that any other pages with non-working links will eventually be edited, and thereby start working again. [[User:Rootbeer|Rootbeer]]
<span style="color:red;">STATUS: FIXED IN CVS?</span>
----
Line 99 ⟶ 98:
The [[Bipolar disorder]] page is full of extra whitespace - looking at the article reveals lots of <p> </p;gt; and <pre> </pre> spans generated.
Similarly, if an otherwise
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). [[user:AxelBoldt|AxelBoldt]]
<
----
'''Bad table code can screw up layout'''
Line 109 ⟶ 108:
: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;amp;lt;TABLE&amp;amp;gt;...&amp;amp;lt;/TABLE&amp;amp;gt;) --[[user:Brion VIBBER|Brion Vibber]]
----
Line 165 ⟶ 157:
the open DD and the DL. I'll take a look at the parser code to see if that's possible.
<
----
Line 204 ⟶ 196:
:Yup, it's a bug, caused by the fact that the link looks like <nowiki>[[functor|<b>functors</b>]]</nowiki>. It's fixed in the development version of the code. [[user:AxelBoldt|AxelBoldt]]
<
----
It's always a positive sign that somebody is working hard to improve a system when brand goofy new bugs start to appear. I just put together a new preliminary subject outline for [[philately]] with a certain amount of bulleted text. Now, when I enter a new first level bullet after a line with a second level bullet, that first level bullet doesn't appear in the article. [[user:Eclecticology|Eclecticology]], Thursday, May 9, 2002
Line 242 ⟶ 212:
(see [[Montgomery County, Maryland]] for an example!) All of a sudden, this has stopped giving reasonable results. -- BRG (Friday, May 10, 2002, but first noticed earlier)
------
Again with [[philately]]: When I linked to this from the "recent changes" page, I was aghast that the work that I had done was gone without explanation. I checked the history and the (diff)'s, but that showed that my input was all still there, and that apparently no human had touched it. From this I made a couple of minor edits (just to have something different) and saved it again. That was last night. Now again if I try to link from "recent changes" I still get an older version of the page. At this point I am beginning to wonder to what extent a link reliably gives the most recent version of a page. [[user:Eclecticology|Eclecticology]], Friday, May 10, 2002
:This morning I'd noticed a similar problem with the article on [[Maryland]], which I've worked on a lot; only it had apparently gone back many versions. While trying to restore my edits, however, I found the correct version suddenly appeared! -- BRG
----
#REDIRECT appears to be broken;
When I try to access a redirected article, it appears with the "Redirect from '''foo_bar'''" header, but the article itself appears as:
# REDIRECT foo_bar
Any idea what's happening? Refreshing the page has no effect. I'm using IE6.0 on WinXP. (2002.05.15 [[user:pgdudda|pgdudda]])
:Got an article you can give as an example? This is expected behavior in the case of redirect chains: if article A redirects to B, and B redirects to C, going to A gets you to B but no further (thus preventing endless loops of redirects where A redirects to B to C to A to B to C to A to B to C to...) I've you've got one of these, please edit the articles in question and fix it so that all the redirect pages redirect to the actual page, rather than to other redirects. [[user:Brion VIBBER|Brion VIBBER]], Wednesday, May 15, 2002
::I was running into this problem with the article "prefix__morpheme", attempting to redirect it to the article [[prefix]] by typing in "#REDIRECT prefix". That generated an error, but changing it so that there were double square brackets around the word "prefix" makes it work fine. I had thought the square brackets were unnecessary, but apparently not. (FYI, [[Prefix__morpheme|Prefix morpheme]] now points to [[Prefix morpheme]], though I may consolidate that with the [[Prefix]] article, since the former is a one-line stub. Thanks for helping me get that sorted out! (2002.05.15 [[user:pgdudda|pgdudda]])
:::Ahh, I see what you mean. Yes, the brackets are required, at least at present; if they're not ''supposed'' to be required, somebody better let me know so I can fix it. (Though that would break some other things, pending some discussed changes to the database structure.) [[user:Brion VIBBER|Brion VIBBER]], Wednesday, May 15, 2002
-----
'''Another redirect oddity'''
I came across a page ([[Giant Impact theory]]) which had a messed-up redirect. The redirect was coded thusly:
<nowiki>
#redirect[[giant impact theory]]
</nowiki>
And redirected to an empty page whose name was, character-for-character, <nowiki>#redirect[[giant impact theory]]</nowiki>. I put in a space and upper-cased the word redirect, and that fixed it. [[user:Bryan Derksen|Bryan Derksen]], Thursday, May 16, 2002
:The missing space was triggering the problem; I've fixed it to handle that case a bit more gracefully... [[user:Brion VIBBER|Brion VIBBER]], Thursday, May 16, 2002<br><span style="color:red;">STATUS: FIXED IN CVS.</span>
=== Foreign ISBN ==
The ISBN link on [[Tintin]] is bad, but the {{ISBN|2203017104}} is correct, tested on www.fnac.com. Could this be because the book isn't in English? -- [[user:Tarquin|Tarquin]]
:That book doesn't appear to be in Pricescan's database (yeah, probably because it's not in English and thus not in the mainly English-language online shops they search). Try linking to a specific site, such as [http://www.amazon.fr/exec/obidos/ASIN/2203017104/ ISBN 2203017104] (amazon.fr) or [http://www.fnac.com/Shelf/article.asp?PRID=105330 ISBN 220301704] (fnac.com). Or, if there's a generic price-comparison site en français that can search by ISBN, use that. (If you find one, let me know about it!)
:By the way; there's a bug in the parser that will mess with links that are given the name of ISBN X, that's why I added in the "no."s. --[[user:Brion VIBBER|Brion VIBBER]]
I don't know if this is a bug, but this is annoying. When we have an external link to something, anything placed right next to it will have a space in between. It seems to only affect Wikibooks.
| |||