MediaWiki 1.3 comments and bug reports/Resolved

A proposal to move this page to MediaWiki.org was rejected.

This page contains some posts with issues that were resolved and moved here to keep the other page as short as possible. Feel free to move it back if you think the issue is still unresolved.

Post new section

Meta subpages

Please turn subpages back on for Meta's content pages please. See: Wikimedia PayPal donations for 2003. --mav 09:38, 22 May 2004 (UTC)[reply]

They seem to have been enabled. Dori | Talk 05:07, 23 May 2004 (UTC)[reply]

Where did the copyright notice go?

What happened to the copyright notice at the bottom of every page? --mav 10:03, 22 May 2004 (UTC)[reply]

It wasn't yet enabled. -- Gwicke 11:59, 22 May 2004 (UTC)[reply]

External links

While the new bracketed URL (in Cologne Blue, that is) after an external link will be useful for article pages, it should be suppressed for Wikimedia-internal projects. Take a look at Wikisource or Wikibooks' recent changes page to see how it looks.

Is there a currently implemented method to prevent this? Thanks Dysprosia 11:32, 22 May 2004 (UTC)[reply]

Yes, a reload (shift-reload in moz, ctrl-f5 IE/opera) will get you the new css that hides that part. -- Gwicke 12:09, 22 May 2004 (UTC)[reply]

Lovely! Thank you. Dysprosia 12:34, 22 May 2004 (UTC)[reply]

Community Portal

Under the "nagivation" heading, there is a link to "community portal" even on wikis that don't have a community portal, such as meta (a community portal on meta would be redundant). Perl 13:48, 22 May 2004 (UTC)[reply]

Setting MediaWiki:portal to '-' removes that link, same with MediaWiki:currentevents. -- Gwicke 14:21, 22 May 2004 (UTC)[reply]

timelines, but not chemistry or chess or music

I remember requesting inclusion of the en:Wikitex code to allow for creation of chemical diagrams with PPCHTeX, music with Lilypond and chessboards with... whatever. I was told that it needed security testing, that it wouldn't be included. Out of left field comes this <timeline> syntax, which is suddenly getting stuck in 1.3. What gives here? Chemistry diagrams are made with a huge variety of drawing packages, and uploaded as images, which means that they lose the wiki-nature. I was unaware of a burning need for image-maps to replace enumerated lists---why are we getting <timeline>, but not <chem>, <music> or <chess>? <chem>, at the very least, should be trivial to implement---it'll work fine with a whitelist of exactly one command! Grendelkhan 23:49, 22 May 2004 (UTC)[reply]

We have timelines because somebody volunteered to do the work to implement them. -- Cyrius 00:20, 23 May 2004 (UTC)[reply]

MediaWiki vs. Template: The Insubordination

MediaWiki 1.3 seems to be insubordinating: I made a page MediaWiki:GOOToc as a Table Of Contents header to be used in the Wikibook on Genealogy. However, when I put in {{msg:GOOToc}} into the page, it insisted on Template:GOOToc when it's a MediaWiki: page! 24.184.225.245 03:10, 23 May 2004 (UTC)[reply]

Custom messages now go in the Template: namespace. MediaWiki: is just for interface pages, and the custom messages will be moved to the Template: namespace. Dori | Talk 04:32, 23 May 2004 (UTC)[reply]

And use {{GOOToc}} not {{msg:GOOToc}}. -- Tim Starling 04:49, 23 May 2004 (UTC)[reply]

Thanks for the help. 24.184.225.245 14:09, 23 May 2004 (UTC)[reply]

MediaWiki:Portal

I changed the content in MediaWiki:Portal from - to Goings-on so that Goings-on could be linked in the sidebar, but the result is that it points to Meta:Community Portal (which does not exist). How can this be fixed? --mav 12:52, 23 May 2004 (UTC)[reply]

You need to edit MediaWiki:Portal-url. I did it so the Goings-on text now links to Goings-on. Perl 13:04, 23 May 2004 (UTC)[reply]

For future reference, in such cases, do a search in Special:Allmessages for what you're looking to change in the interface. Dori | Talk 13:05, 23 May 2004 (UTC)[reply]

Categories enabled but broken

Category links are enabled but the categorylinks table doesn't seem to exist on any of the updated wiki. For example take a look at Special:Categories and try to view the category "stub" - 211.28.160.221

The exact error returned (on meta, it is slightly different for the other updated wikis) is

A database query syntax error has occurred. This could be because of an illegal search query (see Searching Meta), or it may indicate a bug in the software. The last attempted database query was:
SELECT DISTINCT cur_title,cur_namespace FROM cur,categorylinks WHERE cl_to='Test' AND cl_from=cur_id ORDER BY cl_sortkey
from within function "". MySQL returned error "1146: Table 'metawiki.categorylinks' doesn't exist".

- 211.28.160.221

center and images

When a centered image is followed by centered text, there needs to be a </center> after the image and <center> before the text. In the old software, a centered image followed by centered text could be accomplished simply by putting a <center> in front of the image without needing </center> after the image and <center> before the text.

Unclosed tags are invalid, please close them. -- Gwicke 13:58, 22 May 2004 (UTC)[reply]

I tried closing the <center> tag and the problem still exists. After I have looked at the problem, I have found that it seems to be somwehat ignoring a skipped line in this case. I have made a subpage: User:Perl/centerproblem which illustrates the problem. Perl 14:13, 22 May 2004 (UTC)[reply]

The real reason for this problem was simply that the parser didn't create paragraphs inside the center div. This is changed now- the break is there, the text is centered as intended. -- 217.81.59.171 18:28, 22 May 2004 (UTC)[reply]

problem with interwiki links in the new theme

Interwiki links don't show up at all. Look at [1]. Perl 13:41, 22 May 2004 (UTC)[reply]

Actually, it turns out that the software must think the links are interlanguage links because it has "english" listed 8 times under the "other languages" heading on the left. Perl 13:45, 22 May 2004 (UTC)[reply]

For example, on the wikibooks portal, links to things from the English Wikipedia are interpreted as interlanguage links, making them disappear from the text and creating a bunch of English ILLs on the sidebar. P M 15:47, 22 May 2004 (UTC)[reply]

There is now a similar problem at Wikisource. In http://sources.wikipedia.org/wiki/Author:Thomas_Jefferson and in all similar "Author" pages the biographical section was set up to show links to biographical articles on the various Wikipedias. There was never any intention to bunch them up at the top or bottom of the page. Eclecticology 21:07, 22 May 2004 (UTC)[reply]

Fixed now, interwiki links are inline on wikibooks, source, meta, wikiquote, ~~sep11~~. No need to prepend : to make them inline there. -- Gwicke 02:16, 23 May 2004 (UTC)[reply]

UTF-8 chars

UTF-8 chears changes to "?" see [2] after 00:24, 20 May 2004 KIZU M (=日本語= KIZU IRS score) --Suisui 14:37, 22 May 2004 (UTC)[reply]

As I see it now, there seems to be no problem. Tomos 00:33, 23 May 2004 (UTC)[reply]

Database-related errors (linkscc table)

This may be a one time thing, but I had never seen it before. I was editing a section when this came up.

A database query syntax error has occurred. This could be because of an illegal search query (see Searching Meta), or it may indicate a bug in the software. The last attempted database query was:

    SELECT cur_text FROM cur WHERE cur_namespace=8 AND cur_title='Wikititlesuffix' LIMIT 1

from within function "". MySQL returned error "0: ".

Dori | Talk 15:16, 22 May 2004 (UTC)[reply]

I got the same thing trying to access the meta Main Page P M 15:47, 22 May 2004 (UTC)[reply]

Got the same error while trying to access Talk:Mainpage. User:Tillwe, not logged in

I got a similar error too. And from time to time this database error keeps coming up, while logging in, while accessing a module...

Vijay

I got this when I clicked on a thumbnail

From Meta, a wiki about Wikimedia
A database query syntax error has occurred. This could be because of an illegal search query (see Searching Meta), or it may indicate a bug in the software. The last attempted database query was:

    REPLACE INTO linkscc(lcc_pageid,lcc_cacheobj) VALUES(6708, 'x^��� �@�E�%�P:V�fV*(BAWn���18u���)�wS�\\�����d�s���Ka�3�LM�P�r&��ՠ�G:���n�/3 ���U�M&���X��[���6��d���(ə�����a�0M���oX��+�Fh*tQ��A����V%���j��[�27��~��S�5��9*�U\"t�ʿ�F���� �|l_')

from within function "". MySQL returned error "1213: Deadlock found when trying to get lock; Try restarting transaction".

When I clicked on another thumbnail, I recieved this error:


From Meta, a wiki about Wikimedia
A database query syntax error has occurred. This could be because of an illegal search query (see Searching Meta), or it may indicate a bug in the software. The last attempted database query was:

    REPLACE INTO linkscc(lcc_pageid,lcc_cacheobj) VALUES(6709, 'x^��� �0���%�0V\'��I�E��E��[����ڡ�ٻ�9P��1_~�?�q���v�Lu!��������x�\0�q�#�T�i�^���A5D�9�Λ��X���l�4��d�<��*� Nj>�8���y�\0ݏ�+���*6��Z�����Ы���>�cT�ͯMKu����p�!І�#�QeBsg����O��I�n�')

from within function "". MySQL returned error "1213: Deadlock found when trying to get lock; Try restarting transaction".

When I refresh the image: page, the image displayed as it should, so it might be a one-time-thing. Perl 13:10, 23 May 2004 (UTC) Perl 13:10, 23 May 2004 (UTC)[reply]

I don't know if this is related, but I changed Trophy box some minutes ago. The change was saved, but the changed page didn't load, waiting for several minutes only brought the "hide" field of the TOC into view, rest of the page blank (in Netscape 7.0). And something completly unrelated: the cursor in this edit box has a little dot on the top? -- Tillwe 18:48, 23 May 2004 (UTC)[reply]

Jeronim just found the reason for this: the linkscc table (used for permanent link caching) wasn't updated to the new DB link table schema that uses numerical ids for both keys:

mysql> describe linkscc;
+--------------+---------------------+------+-----+---------+-------+
| Field        | Type                | Null | Key | Default | Extra |
+--------------+---------------------+------+-----+---------+-------+
| lcc_pageid   | int(10) unsigned    |      | PRI | 0       |       |
| lcc_title    | varchar(255) binary |      | UNI |         |       |
| lcc_cacheobj | mediumblob          |      |     |         |       |
+--------------+---------------------+------+-----+---------+-------+
3 rows in set (0.00 sec)

Trivial to fix, we disabled linkscc for now, Jeronim is updating the conversion script to do the table conversion automatically on upgrade. -- Gwicke 22:04, 23 May 2004 (UTC)[reply]

Comparing versions is history

When trying to compare two versions of the page, those are placed inside the frame. Of course, this is not wide enough, so a slider appears at the bottom of the frame. But since the length of the frame is dynamic, this slider is far below the point where you're comparing the versions. This might also hold ordinary pages, if there is a way to make them too wide, eg. with a table. (What is wrong with this editor field. It wants to display a few pixels more than its wide.) Aliter 17:52, 22 May 2004 (UTC)[reply]

That's an extramely annoying IE bug, i've removed the full-width footer for 5.5 and 6 in favour of solid horizontal scrolling. All other browsers render this correctly and have the full-width footer. To get the new style, do a ctrl-f5. -- Gwicke 23:58, 22 May 2004 (UTC)[reply]

?? For example, to see this on an ordinary page, try af:Redigeer. (I hope at least someone on Af: knew what was happening. Still the main page does show a problem with the templates. Anyone willing to help?) Aliter 17:29, 23 May 2004 (UTC)[reply]

Hmm, can you give me a hint what i should look for on af? -- Gwicke 20:52, 23 May 2004 (UTC)[reply]

Sure: The right edge of the table on af:Redigeer. (If you can see that, due to your screen being wide enough, shrink your window a bit first, to simulate a smaller screen; if the window gets a horizontal scroll bar you've made it too narrow.) Try to look at the top left cell, and then find the page's scroll bar to bring into view the entire top right cell, and now to the next cell on the left .... Aliter 00:10, 24 May 2004 (UTC)[reply]

Did you try a shift-f5 to get the current css? Looks fine here at 1024x768 and smaller in Firefox and IE6. Please make a screenshot if the problem is still there and tell us your browser type and version. -- Gwicke 11:08, 24 May 2004 (UTC)[reply]

Yes, I did a refresh (several) when I tried whether the history, here on meta, now functioned correctly. When it did, I went looking for a wide page, which I found on af:. What is logical, but not intuitive, is that af: has its own copy of the style sheet, and needed to be refreshed separately. (Fortunately, not a problem that will occur in everyday use.) Yes, you did solve this on the first try! Problem solved. (The problem on the front page of af: I've now historied back to an apparently incorrect conversion of
"{{msg:{{CURRENTMONTHNAME}}_{{CURRENTDAY}}_selektiewe_herdenkings}}"
to the new system. Anyone?) Aliter 13:15, 24 May 2004 (UTC)[reply]

History, diffs, and the Compare button

Can we please get a second "Compare selected versions" button at the top of History pages? At least for me, the most common thing I want to do with arbitrary diffs is compare the most recent revision to one 4-5 revisions back. -- Cyrius 19:35, 23 May 2004 (UTC)[reply]

Added the second button, made it an input type="submit" for better styling. Reload to get the new styles if the first button has a list bullet in front of it. -- Gwicke 14:12, 24 May 2004 (UTC)[reply]

Works for me. Much better than having to scroll a couple of pages to find the button. -- Cyrius 21:38, 24 May 2004 (UTC)[reply]

<pre> behaviour broken

In order to keep this page tidy see bug example at MediaWiki_1.3_comments_and_bug_reports_pre

Fixed. -- Gwicke 11:15, 24 May 2004 (UTC)[reply]

Table problem

I noticed that the afrikaanse wiki has already been upgraded to the new mediawiki version. Volunteer Wearth]] reported a problem with table syntax in the upgrade, see w:af:Suid-Afrika.

Could some developer pls check before upgrading other wikis????

TeunSpaans 06:31, 24 May 2004 (UTC) (I must confess i dont see much of a difference myself, just made a test)[reply]

A second issue on this page is the "Nasionale leuse", as Andre Engels remarked, "!ke e: /xarra //ke" doesnt look like afrikaans, english, bantu, zulu or any african langue. This seems to be present in all older versions, so it might have been a human error. Is there any conversion software that may have caused this?

TeunSpaans 06:31, 25 May 2004 (UTC) (it's some unknown near-extinct language)[reply]

IE6 script errors

In IE v6-SP1, with "Display a notification about every script error" turned on, pages have this "error": line=19 char=16 error="'addcss' is undefined" code=0. --Zigger

Fixed by clearing the local cache. --Zigger 07:05, 30 May 2004 (UTC)[reply]

Already reported to sourceforge - status=pending. --Zigger 13:42, 30 May 2004 (UTC)[reply]

Showing URL for external links

In the Arabic Wikipedia, in May 28 (after the software upgrade probably), when using the Standard skin, the URL of links are displayed in perathesis after them. for example [http://linux.org Linux.org] is displayed as "Linux.org (http://linux.org)" showing the link right after the linked word. -- Isam 11:25, 28 May 2004 (UTC)[reply]

This issue is fixed now.. Thanks -- Isam 13:42, 28 May 2004 (UTC)[reply]

"It's" with bad apostrophe in alt text

In the alt text which displays when you hover over the View Source link on a protected page, it says something like "This page is protected. You can view it's source." This should be "its" not "it's" - the apostrophe needs to be removed, please. Thanks --82.35.17.203 23:22, 29 May 2004 (UTC)[reply]

I believe this is something all sysops can fix by editing MediaWiki: pages, so I'll look into it on en:. Guanaco 03:02, 30 May 2004 (UTC)[reply]

It's fine on en:. Guanaco 03:08, 30 May 2004 (UTC)[reply]

Not as I see it, it is not. The example page I am using is the Main page, so do tell me if that's wrong. I tried swapping browsers but it's the same in Opera which could not on my machine have had a cache of the previous state - it still says "it's" not "its" as it should. Sorry to be a drag. Should I move this out of "resolved" again? 82.35.17.203 11:38, 30 May 2004 (UTC)[reply]

I looked through the MediaWiki messages and found en:MediaWiki:Tooltip-viewsource. See [3]. The meta version is still broken, however. Guanaco 12:45, 30 May 2004 (UTC)[reply]

Thanks for sorting out en. I was getting palpitations! :) --82.35.17.203 00:47, 31 May 2004 (UTC)[reply]

Fixed in Language.php as well. -- Gwicke 19:38, 1 Jun 2004 (UTC)

New Style (moved from Talk:Main Page)

The search option puts "$1" in the googlebox;.
- OK now. Aliter 00:53, 30 May 2004 (UTC)[reply]
The logo has disappeared; without logo the left column is about half its height too far down.
- The logo is now present. Aliter 15:57, 22 May 2004 (UTC)[reply]
IE 6 claims the pages has an (ignorable) error. (Might be the logo.)
- Indeed, with the logo appearing, the error has disappeared. Aliter 15:57, 22 May 2004 (UTC)?[reply]
There appears to be an empty box at the bottom of the virtual page on the Main page.
- Disappeared. Aliter 18:22, 25 May 2004 (UTC)[reply]

Mozilla Firefox 0.8

Search box error in Firefox 0.8

In Firefox 0.8 on Windows XP the Search boxes are messed up in the new format.

Here is a screenshot.Jeff8765 23:48, 24 May 2004 (UTC)[reply]

This happens if you have a minimum font size set in your prefs, you can either reduce the minimum font size (most probably by one point), select a larger default font in your browser prefs or change the font size or input width in your user stylesheet. -- Gwicke 00:17, 25 May 2004 (UTC)[reply]

Thanks. 67.20.46.9 02:20, 25 May 2004 (UTC)[reply]

Search function

Hey! What happened to the Search function that Wikipedia used to have? Why was it removed? Are there any plans to restore it? --Fibonacci 20:47, 29 May 2004 (UTC)[reply]

The search box is still there for me, just moved. It's now below the navigation box on the left-hand side of the page. Jrdioko 21:00, 29 May 2004 (UTC)[reply]

Superscript entities not rendering properly

On certain articles (specific example, the en:Chevrolet Camaro page on the main Wiki), HTML entities used to render cm^3 are appearing as text rather than rendering appropriately. The HTML I'm receiving actually contains an escaped ampersand followed by the text 'sup3'. One way of "fixing" this problem is to use proper entities, i.e. those terminated with a semicolon, but the above page did show properly before the switch-over.

Compare: cm&sup3 vs. cm³

ChrisCostello 01:40, 30 May 2004 (UTC)[reply]

That's the point - proper entities. They need to have an ending semicolon in order to be valid HTML entities but the semicolon was most likely cut-off by the conversion script. --Borislav 10:57, 30 May 2004 (UTC)[reply]

Ah, understood. I'll fix them wherever I run across them, then, unless there's some more appropriate way of going about this. ChrisCostello

Italy is a user?

The Italy article has User contributions and E-mail this user nav links Niteowlneils 21:32, 30 May 2004 (UTC)[reply]

Confirmed fixed. Yeah, Vibber! Niteowlneils 23:37, 30 May 2004 (UTC)[reply]

HTML comments displayed

All of a sudden, HTML comments preceding custom messages are now appearing in the articles! RedWolf 05:56, 30 May 2004 (UTC)[reply]

Well my problem seems to have suddenly gone away by itself. Gremlins, I tell you... RedWolf 08:07, 30 May 2004 (UTC)[reply]

Opera 7

This browsers use presentation style when site is in full screen. But wiki doesn't have this style and i see site without all formating. -- Adam Dziura

I believe this has been fixed; works for me in Opera 7.50. --Brion VIBBER 06:56, 1 Jun 2004 (UTC)

Mozilla-based browsers

With Firefox 0.8 (Linux and Windows) I have this problem even if there are no categories. Judicious use of the Web Developer extension and the DOM inspector shows that the "catlinks" div is present and getting in the way of the image. --rbrwr 12:03, 31 May 2004 (UTC)[reply]

Screenshot showing this problem

Detail of screenshot with the "catlinks" div outlined

I have added div#catlinks {display:none;} to my monobook.css and the images float correctly to the right. It does, however, leave me unable to view category links when they do exist. --rbrwr 15:15, 31 May 2004 (UTC)[reply]

This has already been fixed. --Brion VIBBER 07:00, 1 Jun 2004 (UTC)

script error

Also, they often get a script error message on nearly every page, I got one too, after some browsing, invalid argument at line 153 of their homepage, char 5. Same on meta, by the way. WXP, IE6, display script errors turned on.

Can you provide an url for the page this happens on? -- Gwicke 17:17, 25 May 2004 (UTC)[reply]

<http://af.wikipedia.org/wiki/Tuisblad> (but at the moment it doesn't happen to me there). Aliter 18:51, 25 May 2004 (UTC)[reply]

Already reported to sourceforge. --Zigger 13:24, 30 May 2004 (UTC)[reply]

Already fixed. --Brion VIBBER 07:00, 1 Jun 2004 (UTC)

Vietnamese Wikipedia

The following two bugs are described in SourceForge bug #962789 (group #34373):

Errors for logged in users

Anytime I am logged on, and I view any page at the Vietnamese Wikipedia, I get the following error:

A database query syntax error has occurred. This could be because of an illegal search query (see Searching Wikipedia), or it may indicate a bug in the software. The last attempted database query was:

SELECT user_name,user_password,user_newpassword,user_email,user_real_name,user_options,user_rights,user_touched FROM user WHERE user_id=4

from within function "User::loadFromDatabase". MySQL returned error "1054: Unknown column 'user_real_name' in 'field list'".

– [[User:Mxn|Minh Nguye>?n (talk, blog)]] 23:04, 28 May 2004 (UTC)[reply]

Fixed a while ago. --Brion VIBBER 07:07, 1 Jun 2004 (UTC)

Errors creating an account

A database error is thrown when creating a new account:

A database query syntax error has occurred. This could be because of an illegal search query (see Searching Wikipedia), or it may indicate a bug in the software. The last attempted database query was:

INSERT INTO user (user_name,user_password,user_newpassword,user_email, user_real_name, user_rights, user_options) VALUES ('username', , , , , , 'quickbar=1 underline=1 hover=1 cols=80 rows=25 searchlimit=20 contextlines=5 contextchars=50 skin=monobook math=1 rcdays=7 rclimit=50 highlightbroken=1 stubthreshold=0 previewontop=1 editsection=1 editsectiononrightclick=0 showtoc=1 showtoolbar=1 date=0 searchNs-1=0 searchNs0=1 searchNs1=0 searchNs2=0 searchNs3=0 searchNs4=0 searchNs5=0 searchNs6=0 searchNs7=0 searchNs8=0 searchNs9=1 searchNs10=0 searchNs11=1')

from within function "User::addToDatabase". MySQL returned error "1054: Unknown column 'user_real_name' in 'field list'".

– [[User:Mxn|Minh Nguye>?n (talk, blog)]] 23:18, 28 May 2004 (UTC)[reply]

Fixed a while ago. --Brion VIBBER 07:07, 1 Jun 2004 (UTC)

Special:Statistics

The HTML in this page is messed up. It comes from MediaWiki:Sitestatstext. Dori | Talk 21:40, 22 May 2004 (UTC)[reply]

Special->Maintenance page also has some visible raw HTML. I imagine it's probably known/expected that about half of the special pages (EG Orphaned pages) have no content at the moment? Niteowlneils 23:41, 29 May 2004 (UTC)[reply]

It seems the problem stands for all Special: pages, as well as for all tab labels (you cant use HTML entities like   for exemple) Srtxg 07:27, 31 May 2004 (UTC)[reply]

Undeleting

The View or restore x deleted edits? message is no longer shown. If a page is recreated, it is impossible to know whether it was previously deleted, and impossible to undelete it without going to the very slow special:undelete page or typing the URL manually. Angela 02:02, 30 May 2004 (UTC)[reply]

I confirmed this on ja. using the monobook skin viewing ja:土井たか子 and its history page. I also think the link is very useful, for example, to check if the same article received copyright violation twice from the same IP, if deletion occurred, if deletion was really appropriate, etc. So I also hope this link would come back.Tomos 08:58, 30 May 2004 (UTC)[reply]

Fixed. --64.164.245.96 03:51, 1 Jun 2004 (UTC)

In theory, an 'undelete' tab should show up if applicable already, have to check if that broke somehow. -- Gwicke 19:44, 1 Jun 2004 (UTC)

PHP error when trying to view history of my own user page

went to my own user page on en
hit the history button (at the top, using unmodified monobook)
brings up url http://en.wikipedia.org/w/wiki.phtml?title=User:Finlay_McWalter&action=history
Fatal error: Call to a member function on a non-object in /usr/local/apache/common-local/php-new/includes/Skin.php on line 1911
I get the same error in classic skin (haven't tried the others yet)

-- Finlay McWalter 02:08, 30 May 2004 (UTC)[reply]

No such message, presumed fixed. --Brion VIBBER 02:25, 1 Jun 2004 (UTC)

No scrollbars in "Editing help" popup window

In Mozilla Firefox 0.8, clicking on the "Editing help" link from the edit page pops up a window with no scroll bars. That doesn't work as the text is way to big to fit. Thue

Seen on IE5 as well. Grendelkhan 01:11, 31 May 2004 (UTC)[reply]

Fixed this, scrollbars=yes was missing. -- Gwicke 09:37, 1 Jun 2004 (UTC)

Add to watchlist confirmation page

After I have added a page to a watchlist, confirmation page contains html tags and last few words are on other paragraph:

The page "Requests for permissions" has been added to your <a href="/wiki/Special:Watchlist">watchlist</a>. Future changes to this page and its associated Talk page will be listed there, and the page will appear bolded in the <a href="/wiki/Special:Recentchanges">list of recent changes</a> to

make it easier to pick out.

MediaWiki:addedwatchtext needs to be cleared/updated to use the wiki syntax (the default in Language.php is in wiki syntax, but the MediaWiki namespace isn't overwritten on update). -- Gwicke 21:52, 23 May 2004 (UTC)[reply]

Special:Allmessages has some more messages marked in red (= they differ from the default messages). A sysop should probably check those and update them to the default if necessary. -- Gwicke 22:40, 23 May 2004 (UTC)[reply]

Does this mean we now have "all messages" pages in both MediaWiki: and Special:? Aliter 12:22, 29 May 2004 (UTC)[reply]

The MediaWiki:All_messages should be deleted, it isn't automatically updated, and is nothing more than a (very huge and useless) mediawiki template... Special:Allmessages is automatically updated and very nice.

As for change of html syntax to wiki syntax for links... while some mediawiki messages are broken using html syntax, others are ok; I'm unable to tell the difference...

A last thing, anytime I build a link with templates (eg: [[{{ns:-1}}:Foo]] instead of [[Zpezjal:Foo]] the link appears as if the page didn't existed (with a &action=edit appended and color different etc), while the page does exist, and ideed the link is fine when hardcoding the namespace.

Srtxg 22:46, 29 May 2004 (UTC)[reply]

From further below: "Adding page to watchlist"

When I add pages to my watchlist (by going to that page and clicking "watch this page") I get html in the output that shouldn't be there. Raul654 22:32, 29 May 2004 (UTC)[reply]

From further below:

The Added to watchlist page returned when you hit the Watch option to add a page to your watchlist has body text which includes a couple of linked. The HMTL for the links is being rendered around the anchors - i.e. printed on the screen ... the links themselves, consequently, do not work.

I fixed it for en: on en:MediaWiki:Addedwatchtext.

See MediaWiki_1.3_comments_and_bug_reports#Add_to_watchlist_confirmation_page above. -- User:D2

This is just a matter of replacing the HTML with the corresponding wiki syntax in the appropriate MediaWiki page. Dori | Talk 16:05, 1 Jun 2004 (UTC)

Text before TOC does not display at all

The ad-hoc fixes seems to be making things worse.

See for instance: http://en.wikipedia.org/w/wiki.phtml?title=Joseph_Stalin&oldid=3835722

The text displayed begins with the "Other names" section. The entire paragraph of text before the TOC does not display at all, although Edit shows that it is present.

This bug was definitely not present when the new software was first introduced, it seems to have been introduced earlier today. 67.68.192.238 04:46, 2 Jun 2004 (UTC)

Confirmed with Firefox 0.8 on linux. The first paragraph disappears when the top image is right aligned. Dori | Talk 06:01, 2 Jun 2004 (UTC)

OK, this now seems to have been fixed. The link above displays correctly.

Image right alignment in Safari

For some reason, right-aligned images that are at the very top of articles do not align flush to the top of the article (although aligning left does not exhibit the same behavior). It's a problem that's hard to describe. To see what I mean, view en:Naruto (manga), for an example. The text should not be above the logo at all. This seems to be an issue only in Safari 1.0.2 (not Firefox). Can any other Safari users (specifically those who have newer versions) verify this? 69.148.93.2 01:47, 30 May 2004 (UTC) (User:RadicalBender)[reply]

This is the category links issue. Already fixed for pages w/o category links. --Brion VIBBER 06:57, 1 Jun 2004 (UTC)

Upload file: wrong style

The page http://meta.wikipedia.org/wiki/Special:Upload is using a wrong style (ugly bold font). Malteser 13:34, 23 May 2004 (UTC)[reply]

http://meta.wikipedia.org/w/wiki.phtml?title=MediaWiki:Uploadtext&action=edit - there are two open bold tags at the end of that message. -- Gwicke 22:33, 23 May 2004 (UTC)[reply]

Broken msg's

Case in point: en:Samsara. It'll show the problem better than anything else I could put here. --Furrykef 04:27, 30 May 2004 (UTC)[reply]

Already Reported to sourceforge by furrykef. --Zigger 17:09, 31 May 2004 (UTC)[reply]

Template parser broke?

~~The templates on Belgium and its equivalent en:Belgium no longer work (source displayed).. -- User:D2~~

It works again. Thank you for fixing it. -- User:D2

Categories list and right-aligned images at the top

On any articles utilizing the new category feature and a right-aligned image at the very top of the article, the alignment is all out of wack. For examples, see en:Chobits and en:Fruits Basket. This is a problem in all browsers. 69.148.93.2 06:43, 30 May 2004 (UTC) (User:RadicalBender)[reply]

yup, for another example, see en:George Clinton (funk musician). Gentgeen 11:36, 30 May 2004 (UTC)[reply]

It's bad for articles with tables, too. See en:Water. Gentgeen 12:26, 30 May 2004 (UTC)[reply]

Came here to report the same problem. No article with a taxobox or an infobox can currently use categories. Which is a shame, because articles with taxoboxes are just the sort of articles that have things in common with other articles, and thus can be put into categories. Pcb21 14:34, 30 May 2004 (UTC)[reply]

This results in very ugly articles. See

from en:USS Indianapolis (CA-35)

This will only get worse as new and more categories are added. A category tab should be used to store that type of information or it should be put at the bottom of pages where it will not get in the way of content. --mav 00:44, 31 May 2004 (UTC)[reply]

I just submitted a bug report to SourceForge. [4] Please comment there as well so we can get the attention of the developers. --mav 00:55, 31 May 2004 (UTC)[reply]

Adding this has made a mess to all profile pictures, Here's an example ... Wikipedia:Friedrich_Paulus it really looks terrible with all that empty space.

It made an even bigger mess to Nimitz... http://en.wikipedia.org/wiki/Chester_Nimitz

--213.167.155.246 07:02, 31 May 2004 (UTC)[reply]

This is how the
categories are now

I agree. I even posted something about this in the Talk about "Category" before I was informed of the existance of this page. There, I used the Professor Birch article as an example, and suggested that instead of having this floating to the right pushing everything to the side like this, it should be just aligned to the right with tags like this:

category alpha

This is the begining of the article; blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah, blah...

--Fern 10:33, 31 May 2004 (UTC)[reply]

before putting #siteSub { display: block; } in my monobook.css

after putting #siteSub { display: block; } in my monobook.css

Actually, it's quite easy to fix. Just put this in your user monobook.css:

#siteSub {
  display: block;
}

Currently, it is set to display: none in the css. I'm not sure why this is done, but setting it back to display: block fixes things. This can be also easily fixed for all users by changing the main.css of the Monobook skin. -- Lmov 10:02, 1 Jun 2004 (UTC)

Awesome fix, man! ~blankfaze

This will put the categories above the "From Wikipedia, the free encyclopedia." line:

#siteSub {
   display: block;
 }

#catlinks {
    margin: 0;
    padding: 0;
    width: 100%;
    text-align: left;
    float: none;
}

categories and right-floats

In the monobook skin, category links push away anything floated to the right, causing massively ugly page distortion. See en:William Riker, en:William Shakespeare, or en:Hogwarts. (But not en:Cho Chang or en:Ron Weasley, for some reason.) This is making people start to loathe categories. Please fix. 66.159.150.86 04:10, 31 May 2004 (UTC)[reply]

Never mind; this is a duplicate of #Categories_list_and_right-aligned_images_at_the_top. Grendelkhan 05:16, 31 May 2004 (UTC)[reply]

Should set off categories

Just came across my first Categories article diamondsuit. I think the categories need to be set off somehow (box, diff color background, etc.), especially using the MonoBook skin--looks like a jumbled mess. Niteowlneils 17:44, 30 May 2004 (UTC)[reply]

Edit boxes and push buttons

On Netscape 7.01 <Mozilla/5.0 (Windows; U; Win98; de-DE; rv:1.0.2) Gecko/20021120 Netscape/7.01>, the text in one-line edit boxes (like "Summary") and push buttons (like "Save page") in Verdana appears some pixels down; if you "press" "Save page", the text overlaps the dotted border at the bottom. -- Tillwe 22:53, 23 May 2004 (UTC)[reply]

That's a minor rendering bug in old mozilla versions. -- Gwicke 11:29, 24 May 2004 (UTC)[reply]

Some sidebar links broken on de

Some of the sidebar links in the standard and cologne blue styles are broken on the german wikipedia, those show a partially html link in source text. Ahoerstemeier 12:08, 28 May 2004 (UTC)[reply]

Apparently already resolved.

No_system_messages

Every time a Wikipedia is surprised with the beta, they also get a new All_system_messages page. Each entry on this new page just shows a current text value of "MSGNW:", which does not translate into the actual setting. (The page also loads quite slowly. If this means it's too long, can it be split?) Aliter 17:50, 28 May 2004 (UTC)[reply]

Apparently MediaWiki:All_system_messages and similar are now obsolete; Special:Allmessages is the page to look at Srtxg 23:29, 29 May 2004 (UTC)[reply]

Is see. There's a certain logic to that. However, in that case the redirect from MediaWiki:All_system_messages to Special:Allmessages doesn't function. Aliter 10:38, 30 May 2004 (UTC)[reply]

Simply because there was no redirect; the page had to be edited and a redirect put in; or simply and plainly deleted.

Skin selection

I went to change a few of my preferences; in the Skins section none of the four options were selected. When I saved my preferences I appeared to be using a null skin with no styles at all. I assume it should default to Monobook if none of the choices are selected Matthewmayer 10:57, 22 May 2004 (UTC)[reply]

This should be fixed. -- Gwicke 14:12, 22 May 2004 (UTC)[reply]

No skin in the list is selected - should be the actual (default) MonoBook. --Zigger
After pressing save without changing it, the actual skin became Standard, and the list still shows none selected. --Zigger
After selecting a skin and saving, the list showed a selection correctly. --Zigger

Already reported to sourceforge. --Zigger 13:28, 30 May 2004 (UTC)[reply]

sourceforge status now "Closed" resolution "Wont Fix". --Zigger 15:48, 31 May 2004 (UTC)[reply]

Replace with

Personally I prefer over . If it's easy to switch back, please do .. those are already somewhat un wiki .. -- User:D2

I noticed that articles with aren't rendering properly now - no break generated. That is with an older Netscape. Opera doesn't show tables at all. Should these all be changed to now? --Big_Iron 10:50, 30 May 2004 (UTC)[reply]

The extra slash in the rendered version is to make the entire page validate as XHTML - unlike older HTML, you can't have an "unclosed" element. The parser is now generating , however, which should be interpretted as by older browsers rather than breaking, per bug 962876. No change is, or needs to be, made to the wiki source (it's automagically rendered correctly AFAICT) so "unwikiness" is a non-issue. - IMSoP 11:22, 31 May 2004 (UTC)[reply]

Couldn't it just be done in the output? Writting XML by hand is very un-wiki. -- User:D2

It's changing it only on output now -- Gwicke 20:36, 1 Jun 2004 (UTC)

Thanks. -- User:D2

Problem with paragraph division

There is a problem with paragraphs in former CIA World Factbook pages (and possibly elsewhere). What used to be several paragraphs with breaks in between, has become one big messy paragraph. See en:Demographics of Latvia or en:Politics of Pakistan and there is probably a lot more of those. Andris 06:22, 30 May 2004 (UTC)[reply]

I believe 1.3 is very unforgiving of unclosed HTML tags. I already fixed one of these pages due to unclosed tags in the article. A workaround is to replace all of these tags with preceding blank lines. Perhaps they can fix the parser to accomodate unclosed paragraph tags? RedWolf 08:05, 30 May 2004 (UTC)[reply]

Navigation and toolbox rendered improperly

When browsing some longer articles in Chinese Wikipedia using Mozilla 1.6, all the items on the left (except the logo) are displayed below the whole article. See: [5]

Yeah, I beleieve this is the same bug I reported above at "Weird sidebar bug". 68.1.106.199 17:51, 30 May 2004 (UTC)[reply]

This is usually caused by some not properly nested tags. In this case the error source is the MediaWiki-message EU. There is a starting tag <center> right before the table but the browser can't find its closing tag because it's put within the table. Just put the </center> tag outside the table. --Borislav 12:25, 30 May 2004 (UTC)[reply]

Broken Arabic Shaping for Links

Last Feb the user JeLuf added a very needed feature to the MediaWiki, and it seems that it is reverted in the most recent version (that is used now for the Arabic Wikipedia). The feature is linking prefixes with the word, so that al[[razi]] will be linked in the same way as [[razi|alrazi]] will be linked. Prefix merge with the link is very important for Arabic in the same way that [[car]]s linking is important for English and other languages. Please have JeLuf patch applied again, or have one of semilar effect applied. a Bug for that was submitted with the Number 411192. --Isam 11:32, 28 May 2004 (UTC)[reply]

That is done trough mediawiki:linktrail I think. So, go to ar:MediaWiki:Linktrail and change it to something like (yes, all non-ascii letters must be given separately; ):

/^(ﺀ|ﺁ|ﺃ|ﺅ|ﺇ|ﺉ|ﺍ|ﺏ|ﺓ|ﺕ|ﺙ|ﺝ|ﺡ|ﺥ|ﺩ|ﺫ|ﺭ|ﺯ|ﺱ|ﺵ|ﺹ|ﺽ|ﻁ|ﻅ|ﻉ|ﻍ|ـ|ﻑ|ﻕ|ﻙ|ﻝ|ﻡ|ﻥ|ﻩ|ﻭ|ﻯ|ﻱ|[a-z]+)(.*)$/sD

maybe a more compact (but less readable) thing could be written, playing by the range values of bytes composing arabic uftf-8 sequences Srtxg 23:22, 29 May 2004 (UTC)[reply]

but the thing is, it is not a linktail, it is a linkhead.. the letters I am talking about are added to the begining of the link, not to the end of it. --Isam 06:36, 30 May 2004 (UTC)[reply]

yes, I realized it shorter after... linkhead, and use of both linkhead and linktrail, will be indeed usefull for a lot of non indo-european languages; definitively a thing to add (and it shouldn't be that hard to add I suppose) Srtxg 18:37, 30 May 2004 (UTC)[reply]

Should be fixed, see the sf.net tracker. -- Gwicke 23:29, 2 Jun 2004 (UTC)

Blank lines appearing in TOCs

Blank lines have started appearing in TOCs in the Standard skin. They occur between headings of different levels, but not between headings of the same level. -- Heron 13:02, 30 May 2004 (UTC)[reply]

Here's a screenshot: Image:Standard-skin-bug-firefox-20040530.jpg Mozilla/5.0 (X11; U; Linux i386; en-US; rv:1.8a2) Gecko/20040529 Firefox/0.8.0+ - David Gerard 10:17, 30 May 2004 (UTC)[reply]

Some toc styling was missing in the older skins, please report if this fixes it. -- Gwicke 23:39, 2 Jun 2004 (UTC)

This bug does appear to be fixed. Thanks! - David Gerard 08:01, 3 Jun 2004 (UTC)

Please change the template parameter syntax!

Arg! I pointed out some time ago that it is a Bad Idea™ to have the syntax for template parameters the same as the syntax for including a template (which you can do within a template...).

An example:

Look at Template:Template test - that sure looks ugly with a link to a non-existent template; oh, wait, that's just the parameter, but the renderer doesn't know that...
This template requires one paramater, which will be displayed here: parameter
but if I miss the parameter out, I get: This template requires one paramater, which will be displayed here: {{{1}}} - and of course, if I were to create Template:1, its content would appear everywhere someone forgot to give unnamed parameters to a template that used them!
this gets even worse with named parameters, as the chance of accidentally using a param name that has content as a template will increase, and you could completely overlook the fact that there was a parameter missing.

Please, please, please don't make this feature live until it has a decent syntax - if people start using the wrong version, everyone will get confused.

Create a new syntax for referring to parameters - {{{parameter}}} would seem the obvious choice.
When viewing a template, have the renderer display a preset message each time this appears, along the lines of "[Parameter param_name]"
When parameters are missing from a template, display a second preset message, such as "[Missing template parameter: param_name]"

Sorry - thanks for coding the feature, it's really neat. I'm just frustrated that my previous comments on this have been seemingly ignored for so long, to the point where the feature is going semi-live with what I consider a major flaw. And yes, I probably would do it myself, but I have the last 2 exams of my degree on Monday and Tuesday, after which I will probably be busy celebrating/commiserating for a bit! ;-) - IMSoP 16:33, 22 May 2004 (UTC)[reply]

Why are people reporting bugs on test? -- Tim Starling 00:34, 23 May 2004 (UTC)[reply]

Cos it told me to :-P Actually, I assumed it was so that transient problems with the test version didn't have to be recorded in with more permanent bugs. That approach seems to have been working rather well, in general... - IMSoP 16:40, 24 May 2004 (UTC)[reply]

OK, I've implemented the triple brace thing, see the italic sections above. Your reports weren't ignored, I just never saw them. These sort of parser modifications are fairly involved, I wouldn't expect you to do it yourself. -- Tim Starling 04:05, 23 May 2004 (UTC)[reply]

Well, that depends how "involved" I want to be, doesn't it? - IMSoP 16:40, 24 May 2004 (UTC)[reply]

Thanks for fixing it, by the way - I seem to have come across as ungrateful again. :-/ - IMSoP 01:41, 27 May 2004 (UTC)[reply]

Here's a quick test page MediaWiki 1.3 comments and bug reports/Belgium, I have created a Template:Infobox Countries with the old two brace parameter and Template:Infobox Countries-newsyntax with the new three brace parameter. Seems to work. --Blarney 03:16, 24 May 2004 (UTC)[reply]

(copied from another report)

(The problem on the front page of af: I've now historied back to an apparently incorrect conversion of
"{{msg:{{CURRENTMONTHNAME}}_{{CURRENTDAY}}_selektiewe_herdenkings}}"
to the new system. Anyone?) Aliter 13:15, 24 May 2004 (UTC)[reply]

Fixed. -- Gwicke 23:41, 2 Jun 2004 (UTC)

New block after template

There seems to be a new block inserted after every template. (see the Main Page at Wikiquote). It seems to be having some formatting issues: for example, if you use "{{foo}} bar", you get the contents of Template:foo, followed by a teletyped block containing bar (as if " bar" was on a new line).

-- kelvSYC

Fixed. -- Gwicke 23:42, 2 Jun 2004 (UTC)

Definition lists are broken ( those with ; and : in wikicode)

~~Some of the bugs with definition lists have been fixed (see Test:Parser_and_template_issues#Problem_with_User_Names_in_Definition_Lists).~~

~~It appears now that some previously working ones are broken, see en:BC, en:Data codes for Switzerland -- User:D2~~

en:User:Phil Boswell fixed the two by adding a space before the colon. It works now. Good to know that this feature now works much better than before. -- User:D2

Nowiki tags in signatures

Whatever change was just made to en: is changing the way signatures are interpreted. It seems that any # or : signs at the beginning of a post are not parsed if the user has nowiki tags in his signature as described here. Actually, a look at that section itself shows how the functioning of nowiki tags has changed. – Jrdioko (Talk) 00:16, 2 Jun 2004 (UTC)

Fixed due to SF bug report. Thanks. – Jrdioko (Talk) 21:21, 2 Jun 2004 (UTC)

More resolved cases (heading level not changed)

Safari: conflicts with CTRL-a, CTRL-e, etc.

In text fields in Safari (well, in Mac OS X in general), it used to be possible to use CTRL-[aekw] for the corresponding en:emacs actions. Now, though, typing CTRL-e in, say, the edit box reloads the page, and CTRL-a goes to the article. Is it/would it be possible to turn the hot keys off so I can use the emacs movement commands like before? --bdesham 01:20, 31 May 2004 (UTC)[reply]

Yes, you can change/unset them with js. I intend to move the access keys to js completely, then you'll be able to customize them much easier in an array. -- Gwicke 18:33, 2 Jun 2004 (UTC)

Tables not working

The tables are definitely not working properly. Not only that, they cause the rest of the page not to show up. For an example, see this Wikibooks page. - SamE 21:52, 27 May 2004 (UTC)[reply]

This is especially true on all the Album pages with the infoboxes. Under the old style, the infoboxes were properly displayed on the right with text flowing on the left. Now with Monobook, the infoboxes are at the left, have lost the border lines and text no longer flows. Ugly! How can this not have been tested? RedWolf 19:09, 29 May 2004 (UTC)[reply]

I have created a bug report for this issue: [6] RedWolf 16:26, 31 May 2004 (UTC)[reply]

Indented tables apparently cause the rest of the page to be indented as well. Aliter 16:32, 30 May 2004 (UTC)[reply]

Seems to be much more robust now. There was also a problem with tidy missing on some servers which caused the cleanup to fail. -- Gwicke 23:48, 2 Jun 2004 (UTC)

Table caption formatting?

Hi, I'm using Mozilla 1.6 on Debian Linux (testing), and the formatting of table captions doesn't seem right any more on with the new MediaWiki (which I otherwise think is beautiful).

See, for example, this table — even though the caption is specified as align=bottom, it appears at the top. Moreover, the caption is has the same margins as the rest of the text, so it is indistinguishable from an ordinary paragraph (whereas previously it was narrower, to match the table). Is this a problem with that particular table's code, or is it a bug in MediaWiki? —Steven G. Johnson 19:07, May 30, 2004 (UTC)

Looks fine to me. -- Gwicke 23:50, 2 Jun 2004 (UTC)

I can't reproduce it any more, so maybe it was a transient problem. —Steven G. Johnson 02:16, 3 Jun 2004 (UTC)

Vertical space in line drawings / ASCII art

The new style sheet has inserted vertical space between the lines of diagrams such as this one from Wikipedia:Manual_transmission_driving_technique#Shift_patterns:

Under the previous style sheet the lines were unbroken.

The examples from Wikipedia:ASCII_art are also affected. Saucepan 00:54, 1 Jun 2004 (UTC)

Decreased the line height in pre areas a bit, the lines join here now. Please test (reload) and let me know if they join now. -- Gwicke 09:08, 1 Jun 2004 (UTC)

Looks great now. Thanks! Saucepan 15:17, 1 Jun 2004 (UTC)

Verdana

Font Selection

I'm using IE6.0 under Win2000. I have in the past set my default font to Arial Unicode MS, which give a much broader implementation of Unicode characters. Under the standard skin, this eliminates all the boxes that show up when unusual (for me) characters are encountered. It works great, and I recommend it to everyone.

However, under MonoBook, I seem to have no control over the font, and I get those ugly box characters (e.g. in list of foreing language wikipedias). Are we intentionally forcing a particular font onto users that use MonoBook, or is this an unintended consequence? -Rholton 20:10, 31 May 2004 (UTC)[reply]

Ugly Default Font with Firefox on Win2k/XP

Using Firefox on Win2k, the default font for body text is very ugly and hard to read, like it isn't being properly anti-aliased. Another user seems to be having the same problem with Firefox on XP. I have also tested IE on 2k, and Firefox on 98, and both look fine. This seems to be isolated to Firefox on Win2k/XP. Firefox 0.8 on XP is fine and anti-alised in at least some cases.

Hey there, I had this problem, and I believe I was the first to post it on the Village Pump page. Any, I set Mozilla up to over ride fonts on webpages, and the problem is solved for me. It may be a last resort for prople with this problem if the problem can't be reproduced enough for someone else to work on fixing it.

The default uses your browser pref for sans-serif now. -- Gwicke 20:50, 1 Jun 2004 (UTC)

Printable Version

What about a printable version of pages with the monobook skin?

Printable version is built-in now as a print stylesheet. Just hit 'Print' (or Print Preview) in your browser. --Brion VIBBER 02:21, 1 Jun 2004 (UTC)

Rollback and page history

Rollback

Rollback seems to be buggy. The last version before the Rollback looses the username. Examples: [7] [8] -- Akl 15:29, 28 May 2004 (UTC)[reply]

I encountered a similar problem. In this case, I see a link to "Special:Contribution" in place of a user name (an IP address).[9]. In case it matters, there were two consequtive edits made by the same IP user, and I reverted back to the version before those two edits. One of the IP users' name changed to "Special:Contribution." Tomos 12:03, 30 May 2004 (UTC) Another example is here [10][reply]

Anon

after reverting and blocking a vandal, the IP disappears from the history list (screenshot). user:tsca

(moved up within this page to combine with the similar report. Tomos)

Already reported to sourceforge. --Zigger 13:18, 30 May 2004 (UTC)[reply]

Page history bug

I rolled back vandalism to en:Edmund Stoiber, but when I went to the page histoy instead of getting a link to the contributions of 80.188.208.248 it instead said "Special:Contributions" and the link took me to "http://en.wikipedia.org/w/wiki.phtml?title=Special:Contributions&target=" (image of the problem here). Maximus Rex 20:42, 30 May 2004 (UTC)[reply]

subscript rendered as superscript

O2 is rendered as O₂ (O-superscript-2)

And, fascinatingly, only in the monobook skin, rather than in the standard skin. -- The Anome 08:17, 30 May 2004 (UTC)[reply]

weird sidebar bug

This is a really weird sidebar bug. I've discovered that when I view Angela's WP User page] (that's the ONLY page I've encountered it on) ... the sidebar is forced below the content for some reason, so it's just

wikipedia logo | content

sidebar | empty space

if that makes any sense. this is a small bug, but a bug nonetheless. Blankfaze 02:50, 30 May 2004 (UTC)[reply]

There is one superfluous tag, right before the last </div>. It messes all up. --Borislav 11:12, 30 May 2004 (UTC)[reply]

I removed the font tag. Is it ok now? It didn't cause any problems with monobook on Mozilla 1.4. Angela 19:30, 2 Jun 2004 (UTC)

Yes, that fixed it. It wasn't just your page anyway; I encountered it several times after posting this bug, as did other people. I guess it's just an error of sloppy coding on writer's parts. Blankfaze 15:17, 3 Jun 2004 (UTC)

Edit summary

when the edit summary begins with a plus (+1), the plus is cut off (1) in recent changes and history.--tsca 11:26, 30 May 2004 (UTC)[reply]

Can't reproduce.--Eloquence

localurl broken

~~The follwing link (edit) doesn't render as edit any more. -- User:D2~~

It works again. Thanks. -- User:D2

Timeout

It used to be that I could count on about half an hour before Wiki timed me out. Now I do well to get five minutes, sometimes not enough to complete a simple edit. I'm operating on the assumption I'm being bumped off because of glitches as servers/software are being tweaked. If not, please please please fix this. Denn i 24.65.177.33 00:56, 1 Jun 2004 (UTC)

I think that's just the load, I doubt it has anything to do with 1.3 directly. Dori | Talk 14:50, 3 Jun 2004 (UTC)

Bugs related to Fonts

It's Greek to me!

In Greek Wikipedia all characters with accent appear wrongly. e.g. &1x. KIZU 17:47, 29 May 2004 (UTC)[reply]

That's an issue with the Verdana font. – [[User:Mxn|Minh Nguye>?n (talk, blog)]] 18:09, 29 May 2004 (UTC)[reply]

No, it's not Verdana, it is Wikipedia engine. The only thing the "Verdana bug" can do is to show combining accents in the wrong places (more precisely, one character late). — Monedula 19:18, 29 May 2004 (UTC)[reply]

No to font enforcement!

It is a bad thing to prescribe any particular fonts for viewing Wikipedia. The default skin should use the browser's default fonts, and nothing else. Wikipedia is not like a paper encyclopedia, there is no need for sticking to a particular font. Font prescriptions may be used for user-selected skins, but not for the default one.

Worse of all, someone has chosen Verdana as the preferable font. That font has a terrible bug, which will cause quite incorrect display of many Russian pages. — Monedula 00:36, 29 May 2004 (UTC)[reply]

I agree. --Eequor 14:08, 29 May 2004 (UTC)[reply]

I agree wholeheartedly Sj 20:02, 1 Jun 2004 (UTC)

Indeed. Verdana is also lacking a full range of transliteration diacritics for Indic languages, and I'm sure for others as well. Which is a huge problem for many pages.Kukkurovaca 19:43, 29 May 2004 (UTC)[reply]

It seems that prescribing a particular font will always cause problems for some languages. — Monedula 11:05, 30 May 2004 (UTC)[reply]

Well, that's a good argument for not prescribing a font. Some are better than others, however; Arial Unicode MS would get us quite a ways, but not everyone has it and you have to buy it.Kukkurovaca 20:13, 30 May 2004 (UTC)[reply]

The problem is not with "some languages", the problem is with the Verdana font: it is bugged! any language using combining diacritics is affected. Srtxg 07:24, 31 May 2004 (UTC)[reply]

Agreed! Right now I can't work at all with IPA symbols, even though Arial Unicode MS displays them perfectly. -- 220.249.38.3 14:47, 1 Jun 2004 (UTC)

Since at least 20:50, 1 Jun 2004 (UTC), the default is to use the default browser sans-serif font instead of Verdana. --Zigger 16:17, 2004 Jun 3 (UTC)

Font size way too large small

I like the new design a lot, but the font size is terrible. I'm using Opera 7.23, and I have my browser set with a default size of 18px. Ordinarily the problem is that websites have the font size for their layout set too small, so I have Opera set to always display fonts at a minimum of 18px. But here the font size is too big, which is equally a strain to read. Consider this a vote for simply not specifying a font size for body copy at all... just let the user's default size be what it is.

Gee, I found the font size way too small and had to edit monobook.css to save my eyes... //tsca

It doesn't make much sense to me, either... but for some reason all the pages on the site now look to me they have something like 26px font. I suspect it's some combination of Opera and the "minimum size" setting. Still, too big or too small, it just reinforces my agreement to "no font enforcement of any sort". ;)

And now, after the latest CSS change, the font is really too small. Please, does "x-small" sound like the one that should be used as default font for readable text? Even if Internet Explorer or something like that make the fonts big, that doesn't mean "extra small" is readable for all. Correct me if I'm wrong... but it's uncomfortably small text here now, on Mozilla, Opera and Konqueror. -- TJ 09:13, 2 Jun 2004 (UTC)

Serif

I very much would like a serif version of the monobook skin; I'm struggling today with changing it by customization, but after chaning to serif I have to go through the whole skin and change spacing, margins etc. Please add a serif variant of a next-generation skin. ✏ Sverdrup 12:31, 30 May 2004 (UTC)[reply]

I have the same desire -- the still quite quirky result is visible in [11]. Initially, the only thing I wanted to do was to change the #content class of the css into a serif font -- which resulted in everything being very strange, because of calculating everything in en:ems. Now, half of monobook.css is in my user space css (maybe let people choose to replace monobook with their user space css, instead of overwriting it?). So, I fully agree with the need for a serif (or maybe better: content area free font) version of the skin. And for some documentation! -- Tillwe 14:23, 30 May 2004 (UTC)[reply]

On seriffed fonts vs. sans

I think keeping the serif fonts as a preference option is a good idea, as serifs are muchmore comfortable to read thats say sans-serif verdana. However, this goes only for article body, not everything. -- Spiff 17:07, 31 May 2004 (UTC)[reply]

Phonetic Characters (IPA)

Some IPA characters no longer display correctly, for example the lower case superscript h which represents aspiration, other characters include certain vowel characters too.

Dylanwhs 22:25, 30 May 2004 (UTC)[reply]

Proposed "Wikipedia font law"

This law should say:

The Wikipedia default skin must use the browser's default fonts only

The reason for this is that no font is perfect, and no browser, too. It is impossible to tell in advance whether a given combination of font, browser and language will produce anything acceptable. With the browser's default fonts, on the other hand, one can reasonably expect that the user has already set them up so that his/her favorite languages and special characters are displayed correctly.

Vote for this law! — Monedula 22:33, 1 Jun 2004 (UTC)

Agree completely. --Eequor 05:03, 2 Jun 2004 (UTC)

Sounds very reasonable. -- 18:02, 2 Jun 2004 (UTC) (Why am I an anon, by the way? It seems that meta.wikipedia.org requires a separate login...)

Sounds good to me too. el:User:Ank

Agree. Several of the fonts that have been choosen in the last couple of days don't exist on my platform as scalable fonts, and so look really ugly when resized. Either resize the fonts and use a default font, or choose the font family and use a default size. Don't change both at once!! --Ssd 12:35, 4 Jun 2004 (UTC)

ZH fonts are too small

Do anyone here agree with the fact the the fonts are too small? It's hard for the elderly and I wonder if they can be changed to normal size. Thanks.--Shizhao 12:45, 2 Jun 2004 (UTC)== ZH fonts are too small ==

Do anyone here agree with the fact the the fonts are too small? It's hard for the elderly and I wonder if they can be changed to normal size. Thanks.--Shizhao 12:45, 2 Jun 2004 (UTC)

All of the text fonts are too small. I'm not even elderly and I normally just go right back out of any site that uses fonts of this size. If I weren't already here and working, I can assure you that I wouldn't even bother staying to try to read the articles. And the history and comparison text sizes are almost unreadable. I'm not going to futz with my defaults because I want to know what new users and what *readers* are seeing when they come to this site. 64.173.10.133 18:52, 2 Jun 2004 (UTC) (Sorry, that was me. Elf 01:25, 3 Jun 2004 (UTC))

I totally agree. Users of the internet set the default fonts they wish to use and the sizes they wish to use. Tastes vary. There should be a very good reason for software to override a user's own default settings, especially in an application like Wikipedia which is intended for reading and text browsing and should rather go out of its way to accomodate a user instead of forcing a style on a user who is not logged in.

Casual users probably comprise the greatest number of users of Wikipedia, users who are searching for particular information using a search engine and have no special interest in Wikipedia for itself. To force the particular, and to me very peculiar, tastes of any single Wikipedian screen designer on those users is the wrong thing. It doesn't make Wikipedia look good at all, especially when the fonts are smaller than the user is accustomed to and the user prefers a more screen-friendly font.

Leave user browser settings alone. They are none of Wikipedia's business. Let the user decide, including the user who is not logged in. Jallan 19:25, 2 Jun 2004 (UTC)

Font size way too large

When I use IE6 it's too small. I can enlarge it by using alt+(scroll wheel) but then it's intrusively big.

OTOH, it looks just fine in Netscape. This isn't a conspiracy by the anti-Microsoft crowd, I hope!

195.92.67.70 00:17, 2 Jun 2004 (UTC)

Helvetica?!

Who changed the default Monobook typeface to Helvetica? What is this, the '70s? Helvetica is even worse than Verdana. At least Verdana was designed for screen use. -- 160.39.232.187 17:03, 1 Jun 2004 (UTC)

I changed it to the meta-typeface 'sans-serif' after many complaints about Bitstream Vera and Verdana (mentioning bugs in the latter case). You can set which font to use for 'sans-serif' in your browser prefs. I personally think that Verdana is a better choice as well, if there's a majority in its favour i'd be more than happy to change it back. -- Gwicke 17:15, 1 Jun 2004 (UTC)

The Verdana bugs (combining diacritics) make it unsuitable. It's not a question of aesthetics, the functionality doesn't work. It simply doesn't display what it's supposed to display.

Anyway, why specify a font at all? Let it be the user's default font, as before. Many people find sans-serif to be less legible. Why impose it on them? 67.68.192.238 04:55, 2 Jun 2004 (UTC)

"You can set which font to use for 'sans-serif' in your browser prefs." I'm using IE6.0 under Win2000. Can someone let me know how to do this? I can change the default web page font (Tools/Internet Options/Fonts), but it doesn't seem to have any effect on monobook. I'd really like to use monobook, but I find Arial Unicode MS to be the best font for me. -Rholton 13:58, 2 Jun 2004 (UTC)

IE uses Arial as sans-serif; there is no way to change this. — Monedula 10:18, 3 Jun 2004 (UTC)

Hmmm...So there's no way to use Monobook and Arial Unicode MS at the same time? That seems to be a major drawback, since Arial Unicode MS is, as far as I know, the most complete Unicode implementation available -- even if not for free. Seems rather odd that an international/multi-lingual project would prevent the use of the best multi-lingual font available. -Rholton 13:02, 3 Jun 2004 (UTC)

Font size too small in Hindi Wikipedia ( http://hi.wikipedia.org )

Please increase font size--203.115.73.243 13:44, 1 Jun 2004 (UTC)

viewing page that does not exist displays "Babylon 5 characters" category

Looking at http://en.wikipedia.org/w/wiki.phtml?title=DNA_binding_protein , the page lists 'Articles in category "Babylon 5 characters"' even though the page is unrelated and doesn't even exist. Editing said page confirms that it is empty - PlatinumX 21:48, 30 May 2004 (UTC)[reply]

Looks like a normal empty page to me - perhaps a temporary glitch in the ~~matrix~~ database? - IMSoP 10:18, 31 May 2004 (UTC)[reply]

Sans Serif font for article text?

Surely this was an oversight? Sans serif is probably OK for the navigation items (nice work there, btw) and headings, but is much harder to read in the body of articles. (This isn’t just a personal opinion; it is a known result—see just about any of the classic readability tests done in the last century, or any style guide.)

Can we have a serif font back, please? Quota

Fonts can be set by each wiki by changing the file MediaWiki:Monobook.css. This changes it for all users in that wiki, and it's a matter of policy not of software anymore. Dori | Talk 14:03, 4 Jun 2004 (UTC)

Redirect Template

Suddenly the {{reference}}-s are translated to #redirect Template:reference-s. Aliter 16:48, 3 Jun 2004 (UTC)

That's not a bug, a bot is currently doing some conversions. See: [12] and [13] Dori | Talk 17:05, 3 Jun 2004 (UTC)

Misc font comments

Since fonts are now regulated via MediaWiki:Monobook.css, I am moving some font comments here to alleviate the size of the bug page. Dori | Talk 14:05, 4 Jun 2004 (UTC)

Sections with colons

A section with a colon in the title cannot be linked to. Example Wikibooks:Civ:SMAC Tech Tree#Doctrine: Air Power. Clicking this link will direct the reader to the top of the page, not at Doctrine: Air Power, even though a section with that title exists. --Furrykef 08:39, 5 Jun 2004 (UTC)

Fixed. -- Gwicke 11:23, 8 Jun 2004 (UTC)

Project: namespace?

I originally posted this at MediaWiki feature requests and bug reports, but this is probably more appropriate here.

The article en:Project: A-Kon no longer works (there was an article there before). It keeps trying to redirect to Wikipedia: A-Kon, which doesn't exist. Is there some new Project: namespace that I don't know about that breaks that article now? RadicalBender 16:03, 5 Jun 2004 (UTC)

Yes, Project is the new default namespace for a wiki (i.e. Wikipedia: for en). See [14]. Dori | Talk 16:16, 5 Jun 2004 (UTC)

I realize that it could very well be the only article in Wikipedia that breaks like this, but is there a workaround for this to allow the article at that location? Regardless, someone needs to go into the database and retrieve that article and move it to another page (like en:Project A-Kon without the colon) and then I'll add it to the list of pages not allowed by MediaWiki. RadicalBender 01:40, 6 Jun 2004 (UTC)

It was indeed the only affected title, and I moved it as requested. -- Tim Starling 03:02, 6 Jun 2004 (UTC)

Interwiki links in Wiktionary

All the Wiktionaries have been upgraded to 1.3 today. Since this upgrade, no interwiki (interlingual) links show up in the Other Languages list, as they are supposed to. Instead, they are displayed as normal links wherever they show up in the page. See the bottom of Wiktionary:Wiktionary:Welcome, newcomers for an example. – [[User:Mxn|Minh Nguyễn (talk, blog)]] 22:03, 5 Jun 2004 (UTC)

Appears to have been fixed. Dori | Talk 16:00, 8 Jun 2004 (UTC)

Link goes straight to edit box

On MediaWiki roadmap the link real names and only that link goes straight to an edit window for the page instead of to the page itself. Rmhermen

wfm, probably just a cache thing. Dori | Talk 16:02, 8 Jun 2004 (UTC)

Colours

The new look is infinitely better than the old one -- kudos to all involved. A few rough edges remain though, in particular with regards to the main page. The pink background of the featured article box just doesn't work visually. A shade of orange similar to that of a highlighted tab might be better -- orange is close to a complementary colour of blue. There are a few other places with similar problems, but they're not so important. It would be a shame to let the redesign fail to impress on the Main Page, though 217.159.81.197 13:35, 30 May 2004 (UTC)[reply]

This doesn't have anything to do with the new version, it's mostly an article layout thing, so I would suggest en:Talk:Main Page. Dori | Talk 16:09, 8 Jun 2004 (UTC)

Turning back pages two or more at one time

When 1 turn back a couple of pagesmore at once, it receives a PHENOMENAL ERROR, so this has to stop, right away!, parakalo (thank you)., and next time, when switching to a higher format like this one, 1.4 or 2.0, first do it on a test page until it functions properly - Pumpie 18:30 (EADT), 22:30 (UTC)

On some computers, turning back more than one at a time in fastest mode, it receives problems, so stop this INSANITY, NOW!!!!, this has to stop and any user has to fix this problem so this error when it comes up never shows up again on some computers!, Pumpie, 13:26 (EADT)/17:26 (UTC)

I don't know what this means, but I'm guessing it had to do with some of the initial db problems early on. I haven't seen anything like them since. Dori | Talk 16:10, 8 Jun 2004 (UTC)

There were serious xhtml markup errors detected by tidy.

Looking at a page on test I got this error msg. Page had not changed in days and was always OK. After minor edit (adding a space) page was shown properly rendered both on preview and after save. Returning some time later the same error had reappeared. See [15] Erik Zachte 20:41, 28 May 2004 (UTC)[reply]

I have discovered the same thing happening on [16] today. It hasn't changed since yesterday, and worked fine then. I also discovered that when changing from MonoBook to Standard, the error message disappeared. Arj 11:32, 29 May 2004 (UTC)[reply]

I just saw this error when I went to view List of mountain ranges, which was last updated on May 14. I backed up and went to it again and the page displayed just fine. RedWolf 04:49, 30 May 2004 (UTC)[reply]

I'm seeing this also on Combined Arms. The page hasn't been changed since April 19. Edit->Preview of the article works fine. Is this a result of recent skin changes? cleduc 05:20, 30 May 2004 (UTC)[reply]

A bug report has been created on SourceForge for this issue: [17] RedWolf 17:15, 31 May 2004 (UTC)[reply]

MediaWiki strings that need to be updated by sysops

updated

Hopefully the strings updated on the Wikipedia will be used while upgrading the corresponding Wiktionary, so that the translation job doesn't have to be done twice...

Mysterious spaces

Mysterious spaces are appearing in pages, breaking links. See the history of this page for an example. It also happened on goings-on. 131.111.195.202 22:38, 25 May 2004 (UTC)[reply]

Also tags keep getting turned into . I'm sure someone has noticed this. - Omegatron 13:56, 26 May 2004 (UTC)[reply]

Heh. The → thing is deliberate, it allows the page to be valid XHTML (although isn't it normal practice to use to ensure older browsers don't get confused?). Although, I'm confused now - your comment has the same thing twice (typo? conversion even of nowiki'd examples?) and looking in the sandbox, the replacement doesn't seem to be happening, at save or render - has the feature been turned off? Or did it never exist? *scratches head* - IMSoP 10:46, 31 May 2004 (UTC)[reply]

Scrub that: implemented as fix for bug 962876; and the fact that it wasn't showing up for me is just weird behaviour of Mozilla's "view selection source" widget - if I view the whole source, it looks fine. - IMSoP 10:57, 31 May 2004 (UTC)[reply]

Edit this page no more

There is no more "Edit this page" link that is the hallmark of wikis and Wikipedia. This phrase and button has been quoted numerous times in news articles and glowing reviews of Wikipedia. It would be a shame to get rid of it. The new "Edit" tab is too subtle and easy to miss. Put our changeability up front and center! 203.218.135.80 23:14, 28 May 2004 (UTC)[reply]

I agree with you; however, I feel I should point out that this problem is only of huge importance on one skin - MonoBook. It is painless to change the skin to another that you prefer, but this doesn't help us attract new users. -- Kwekubo 23:27, 28 May 2004 (UTC)[reply]

This is not a bug, and it only pertains to MonoBook on the english pedia. Any admin could change it if there is consensus. Dori | Talk 16:43, 8 Jun 2004 (UTC)

Link colors

I have finally figured out why, since the new software update, some articles that exist are colored red in links as though no article exists -- the color for a stub and a non-existent article are the same, or close enough as to not make a difference. Since I assume this is not a feature as it makes the stub-marking preference useless, is it a bug or a browser problem? How do I fix it? TUF-KAT 05:23, 3 Jun 2004 (UTC)

I noticed this right after the upgrade and found it very irritating. You can add the following lines to your personal monobook.css:

a.stub {color: Orange; }

a.new {color:#ba0000; }

Use whatever color values suit your tastes. RedWolf 21:31, 4 Jun 2004 (UTC)

Colour of links to stubs

Under the monobook skin (at least by default, still learning about user styles) links to stubs (i.e. those articles of shorter length than the threshold for stub display set in preferences) appear as the same colour as a link to a non-existent article, instead of as a third colour, as is the behaviour of the other skins. It is possible that this is a feature, but if it is I strongly urge that a move back to the more useful three colours be considered. (Moz1.6/WinXP) Pcb21 22:27, 29 May 2004 (UTC)[reply]

It is possible to work around this by customizing your own style sheet... one implementation is at en:User:Pcb21/monobook.css for others that are interested, I doubt this is a best possible implementation! Pcb21 23:03, 29 May 2004 (UTC)[reply]

This cannot be a feature. It is not even elimination of a feature. (That would be to have stubs show identically to full-length articles.) What it has done is turned a feature for power users into a hindrance. I have three choices: CONSTANTLY look at my browser status bar to see if i'm going to link to an empty page or not (NO), turn off stub display (UNDESIRABLE), or switch away from the monobook skin (YES). 65.43.213.94 --en:User:Ed Cormany

Yes - this is very annoying and need to be fixed. The color for regular links is also hard to read. Simply put, the color we had before should be restored. --mav 01:28, 30 May 2004 (UTC)[reply]

I agree with this too. Catherine

I think this was fixed, if not it can be fixed through the monobook.css page. Dori | Talk 16:48, 8 Jun 2004 (UTC)

Category text asTemplate:

With {{Category:MediaWiki User's Guide}}, one can include the text on the category page Category:MediaWiki User's Guide (see below). This seems to work with most namespaces, except the article namespace. -- User:D2

It seems to work for me. Dori | Talk 17:10, 8 Jun 2004 (UTC)

localizations disappeared partly

I translated some of the new system messages that were made available here. Now e.g. the tooltips, like Tooltip-recentchanges don't show up anymore. Instead, the default English message is shown. What's up? And if the namespaces have changed, could someone update the 'All system messages'-page accordingly... it'd be nice if the new translations wouldn't be lost, either. On the other hand, other translations (even new ones) besides tooltips seem to work AFAIK. -- TJ 12:11, 14 Jun 2004 (UTC)

Most of these were moved to Monobook.js, see User styles#Changing access keys. Your translations are still in the MediaWiki namespace, they need to be moved to MediaWiki:Monobook.js. For a start, copy [18] starting after the second comment. -- Gwicke 12:22, 14 Jun 2004 (UTC)

Ok, thanks. Works now! :) -- TJ 13:58, 14 Jun 2004 (UTC)

Capital error in localisation

The names of the tabs are forced to lower case. That may be fine for a some langauges, but those that drop accents when capitalising now find they've lost the accents in the process.
(Is the help-text for unprotect wrong, or is there one help-text for both protect and unprotect?) Aliter 22:27, 28 May 2004 (UTC)[reply]

This is a problem at simple: as well. The "my contributions" link is simplified to say "Pages I worked on" there, but this forced lower case turns it into "pages i worked on" which is just wrong. Angela 03:41, 30 May 2004 (UTC)[reply]

Adding li { text-transform: none; } to MediaWiki:Monobook.css fixed this. Angela 14:57, 24 Jun 2004 (UTC)

IE6 error (line 153) after loading this page

IE v6.0-SP1 (Windows 2000) shows an error after loading this very page - Line 153, Char 5, Error: Invalid argument, Code: 0. Occurred before and after Ctrl-F5 refresh, while not logged in. Meta main page is ok. (Reported to sourceforge.) --Zigger 15:58, 2004 Jun 3 (UTC)

I have the same problem (IE V6.0-xxx, Windows XP). It seems to depend on which skin you use. MonoBook is OK so the error does not appear if you're not logged on. Most of the other skins give this error (though for me it is line 150, not 153). Kjell André 21:02, 13 Jun 2004 (UTC)

Now okay thanks to Brion's "quick hack". --Zigger 12:50, 2004 Jun 28 (UTC)

Maori Wikipedia still missing its special pages

One can call up a list of 500 categories in the English Wikipedia but not the 50 "Short pages" in the Maori. Usual message "Sorry! This feature has been temporarily disabled because it slows the database down to the point that no one can use the wiki." but no offer of a cached version as used to happen. I asked for restoration elsewhere, earlier today. Maybe this is a better place. Robin Patterson 06:00, 2 Jun 2004 (UTC)

Subsequently fixed; thanks to anyone who worked on it Robin Patterson 05:53, 14 Jun 2004 (UTC)

Javascript bug on de:

Original message: (Überaus lästiger JavaScript-Fehler)

Hilfe! http://de.wikipedia.org/style/wikibits.js produziert bei jedem Seitenaufruf eine Fehlermeldung (Win98,MSIE 6.0, Javascriptbestätigung = js-confirm):

Zeile 364, Zeichen 5, "ta" ist undefiniert

da müßte mal jemand "ta" oben im Script einfach vordefinieren (var ta = 0 oder ähnlich), das kann ich nicht mehr aushalten. Pearl 10:03, 10. Jun 2004 (CEST)

Fehler besteht leider weiterhin. Pearl 12:47, 15. Jun 2004 (CEST)

rough translation:

wikibits.js produces very annoying errormessage on every page

the user proposes to predefine 'ta' as 0, this behavior is beyond endurance

and reports that the bug after five days is still not fixed

--WikiWichtel 11:04, 15 Jun 2004 (UTC)

Please reload and (at least one user had to do this to work around an IE bug) clear your cache. IF you know how to test if a variable is set in js without already triggering the IE warning, let me know. -- Gwicke 22:58, 15 Jun 2004 (UTC)

Half a picture missing

Screenshot

I had a weird error when I went to display a picture, only half of it displays. I asked and several other firefox users complained about the same problem. Raul654 19:53, 12 Jun 2004 (UTC)

(From here).

This still affects the standard skin (but not monobook) in Firefox 0.8/Linux. Lupin 12:56, 26 Jun 2004 (UTC)

alt-a shortcut conflict

In my browser, Linux Firefox 0.8, the key shortcut Alt-A is used to select all the text in an edit box (not Ctrl-A, for some reason). However this key shortcut takes me back to the article page via the wiki software. --Nmather 21:03, 23 May 2004 (UTC)[reply]

The shortcut and the tooltip is configurable in the MediaWiki namespace and (if you don't like those values) via js. -- Gwicke 12:17, 24 May 2004 (UTC)[reply]

Links shouldn't have accesskey information in title like that. The shortcut is browser and platform specific, although on most PC browsers it's alt+key, it could be anything on another platform. Browsers should inform users about accesskeys, not authors, as you simply can't guess what the shortcut is. Tom- 18:45, 24 May 2004 (UTC)[reply]

Yeah, they should... Opera is the only browser that does this though, and the accesskeys wouldn't be noticed by most users otherwise. An idea is to set accesskeys and titles with a js, that would allow to show browser-specific instructions, would avoid the repeated download of all those title texts (that are longer than the content for short articles) and (best of all) that could easily be switched off or customized. -- Gwicke 22:29, 24 May 2004 (UTC)[reply]

No, they shouldn't. And the proper place for key control in a multi-platform environment is in the help page dealing with the interface in question. No, most people won't see it there. But most users won't úse it either. If they want to know, the information is available from this page that you make easily accessible, if not, they are not forced to encounter those cryptic letter groups while they read. (And I hope we're not going down the road where all our users are required to know/use js and css.) Aliter 12:44, 29 May 2004 (UTC)[reply]

Nmather: Ctrl-A is not bound to Select All on Unix, as it is used to move the caret "home", that is, to the beginning of the line. This behavior is from Emacs, and I could personally never live without it. :-) Dpol 11:17, 4 Jun 2004 (UTC)

Try http://wikidev.net for a new accesskey system based on js. You can customize the shortcuts in your user js by simply modifying the default array before the function adds he access keys onLoad. The cmd/shift-esc/alt prefix is displayed depending on the browser. -- Gwicke 01:33, 9 Jun 2004 (UTC)

This is now live here, and 'a' and 'b' are no longer used. Also see User styles#Changing access keys for an example of how you can customize these keys in your user js. -- Gwicke 01:36, 14 Jun 2004 (UTC)

Horizontal scrollbar in Safari

With the last batch of changes, there is now a horizontal scrollbar in Safari 1.0.2 on every page. The page doesn't extend horizontally, but there is a scrollbar now for whatever reason. It extends out to the right about the same length as the sidebar on the left does. Behavior does not exist in Firefox, so I'm assuming it's a Safari-specific bug. RadicalBender 14:01, 9 Jun 2004 (UTC)

in ie6 too. ~~but only here in Meta~~ --WikiWichtel 14:46, 9 Jun 2004 (UTC)

i wasnt logged in. maybe a problem with userstyles? --WikiWichtel 15:39, 9 Jun 2004 (UTC)

Everything works for me again. Thanks to whomever fixed it. RadicalBender 15:54, 10 Jun 2004 (UTC)

I am using the following line in localsettings.php to limit read access to users logged in:

$wgWhitelistRead = array("Main Page", "Special:Userlogin");

This line seems to cause browser errors everytime a page not on the whitelist is loaded. When I remove the line from the localsettings.php the errors subside.

Line: 1 Char: 2 Syntax Error Code: 0

Yes, I have tried clearing the browser cache. I am using WXP IE6 SP2. I have seen nothing on google regrading this. Is anyone else seeing this? Its highly reproducible. Didn't see anything about this listed in bugs.

IE6 SP2 Error

I am using the following line in localsettings.php to limit read access to users logged in:

$wgWhitelistRead = array("Main Page", "Special:Userlogin");

This line seems to cause browser errors everytime a page not on the whitelist is loaded. When I remove the line from the localsettings.php the errors subside.

Line: 1 Char: 2 Syntax Error Code: 0

Yes, I have tried clearing the browser cache. I am using WXP IE6 SP2. I have seen nothing on google regrading this. Is anyone else seeing this? Its highly reproducible. Didn't see anything about this listed in bugs.

HI OPERA HELP FOR ME

HI OPERA AM SHEYDA.IMA FROM IRAN . I HAVE NEED HELP YOU. I HAVE DIFFICAL LEAVE IN IRAN.AMIL ME ROSTAMIFAR54@GMAIL.COM

Database error

Hello, I have an issue with the Comments extension, I am using mediawiki REL1_25 and the comments extension in the same version. Mysql Version 15.1 Distrib 10.0.20-MariaDB, and php 5.6.11 on an a computer running Archlinux. Everytime I had <comments /> on a page, it answers :

"Database error

A database query error has occurred. This may indicate a bug in the software."

I must say that I successfully ran the update script but it does not change anything.

Cordially, Steranoid

MediaWiki 1.3 comments and bug reports/Resolved

Meta subpages

Where did the copyright notice go?

External links

Community Portal

timelines, but not chemistry or chess or music

MediaWiki vs. Template: The Insubordination

MediaWiki:Portal

Categories enabled but broken

center and images

problem with interwiki links in the new theme

UTF-8 chars

Database-related errors (linkscc table)

Comparing versions is history

History, diffs, and the Compare button

<pre> behaviour broken

Table problem

IE6 script errors

Showing URL for external links

"It's" with bad apostrophe in alt text

New Style (moved from Talk:Main Page)

Mozilla Firefox 0.8

Search box error in Firefox 0.8

Search function

Superscript entities not rendering properly

Italy is a user?

HTML comments displayed

Opera 7

Mozilla-based browsers

script error

Vietnamese Wikipedia

Errors for logged in users

Errors creating an account

Special:Statistics

Undeleting

PHP error when trying to view history of my own user page

No scrollbars in "Editing help" popup window

Add to watchlist confirmation page

Text before TOC does not display at all

Image right alignment in Safari

Upload file: wrong style

Broken msg's

Template parser broke?

Categories list and right-aligned images at the top

categories and right-floats

Should set off categories

Edit boxes and push buttons

Some sidebar links broken on de

No_system_messages

Skin selection

Replace <br/> with <br>

Problem with paragraph division

Navigation and toolbox rendered improperly

Broken Arabic Shaping for Links

Blank lines appearing in TOCs

Please change the template parameter syntax!

New block after template

Definition lists are broken ( those with ; and : in wikicode)

Nowiki tags in signatures

More resolved cases (heading level not changed)

Safari: conflicts with CTRL-a, CTRL-e, etc.

Tables not working

Table caption formatting?

Vertical space in line drawings / ASCII art

Verdana

Font Selection

Ugly Default Font with Firefox on Win2k/XP

Printable Version

Rollback and page history

Rollback

Anon

Page history bug

subscript rendered as superscript

weird sidebar bug

Edit summary

localurl broken

Timeout

Bugs related to Fonts

It's Greek to me!

No to font enforcement!