Wikipedia:Parser bug reports: Difference between revisions

Revision as of 17:26, 14 May 2002

Latest revision as of 09:26, 10 February 2023

(32 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

----

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

Line 10 ⟶ 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 Attack™Attack™? [[user:pgdudda|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. :) [[user:Brion VIBBER|Brion VIBBER]], Wednesday, April 10, 2002

Line 22 ⟶ 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

<fontspan colorstyle="color:red;">STATUS: UNKNOWN</fontspan>

== Parser ==

Line 46 ⟶ 79:

:That page renders correctly for me on Mozilla 0.9.8 &amp; 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 53 ⟶ 98:

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

Similarly, if an otherwise emplyemploy 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). [[user:AxelBoldt|AxelBoldt]]

<fontspan colorstyle="color:red;">STATUS : Solved in CVS</fontspan>

----

'''Bad table code can screw up layout'''

Line 112 ⟶ 157:

the open DD and the DL. I'll take a look at the parser code to see if that's possible.

<fontspan colorstyle="color:red;">STATUS : Solved in CVS</fontspan>

----

Line 151 ⟶ 196:

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

<fontspan colorstyle="color:red;">STATUS : Solved in CVS</fontspan>

Line 173 ⟶ 218:

: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&nbsp;&nbsp;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.