MediaWiki 1.3 comments and bug reports/Archive

From Meta

Jump to: navigation, search


Bugs, issues, and feature requests for MediaWiki should always be reported at MediaZilla to make sure they aren't lost or forgotten.

Bugs, issues, and feature requests for MediaWiki should always be reported at MediaZilla to make sure they aren't lost or forgotten.

For emergency problems on Wikipedia & sister projects, try to contact the developers by IRC (#mediawiki on irc.freenode.net) or on the wikitech-l mailing list (please subscribe to ensure that your message gets through and you receive replies).

To get the latest CSS, do a ctrl-f5 (IE, Opera), shift-reload (Moz/Firefox/Gecko), cmd-r (Safari), ctrl-r (konq).

On this page you may discuss the new release of MediaWiki 1.3. Please report any new bugs and issues about this release at MediaZilla. There is another page for discussing old bugs (MediaWiki feature request and bug report discussion), so please check that page for any old issues. Resolved issues may periodically be moved to Resolved in order to keep this page as small as possible so check that page if one of your posts disappears from this page. If you think that it's still an issue, then feel free to move it back.

Please be aware that you are more likely to get a response from a developer if you use the wikitech-l mailing list or IRC (#mediawiki on irc.freenode.net).

If you find yourself dissatisfied with the level of service you are receiving from developers, please take note of the following facts:

  • Developers are not paid.
  • There are hundreds of unfulfilled feature requests.
  • There are thousands of users and only a small number of developers.
  • Developers may, at any time, be doing one or more of the following non-MediaWiki-related activities: working for money, holidaying, sleeping, eating, shaving, having a mid-life crisis, showering, watching a movie, skydiving, changing nappies, baking a cake, having their eyebrows pierced, studying, and climbing a tree.
  • There is no roster for developers to be on duty to answer questions.
  • No developer has entered into a contract to perform any service for you.

Users unhappy with the handling of the upgrade of Wikimedia sites to MediaWiki 1.3 may wish to contribute to a proposed upgrade procedure for future releases.

Post an unsorted comment

Contents


Browser-specific reports

Internet Explorer

Bug "Floating Wonder"
Bug "Floating Wonder"

Top text behaving badly with IE

The links on top ("content page" - "discussion" - "edit" etcetera) go away from their correct places and jump to a vertical alignment over the top left corner of the actual page when I move the cursor over them. I am using Internet Explorer 6.0 under Windows XP. - Andre Engels 09:01, 24 May 2004 (UTC)

Correction: This only happens when one is a sysop (and thus has "protect" and "delete" buttons there), and only when going over "protect", "delete", "move" or "watch", not when going over "content page", "discussion", "edit" or "history". - Andre Engels 09:09, 24 May 2004 (UTC)
This only happens if the tabs don't fit into the window width. It's an IE rendering bug (ignores white-space: nowrap), you could experiment with js to force IE to behave. However, the page is still useable, so this isn't really a showstopper. -- Gwicke 22:59, 24 May 2004 (UTC)
Whether a page is usable when the tabs fall over starting, hence important, part of the text and even links(!), is debatable. I can assure you this is a major irritation, especially each time it starts, as it moves the tab you try to click. Aliter 22:28, 27 May 2004 (UTC)
I agree with Aliter that this is quite inconvenient.--Patrick 14:09, 30 May 2004 (UTC)
I had that problem too, i reduced the fontsize, did some tweaking, its ok now. See my css at my css. look at /*bug-tweaking*/. --WikiWichtel 21:30, 5 Jun 2004 (UTC)
Excellent! Thanks!--Patrick 21:53, 5 Jun 2004 (UTC)
oops, it did it again, the window must be big enough, so it works only in near fullscreen. --WikiWichtel 08:02, 6 Jun 2004 (UTC)

Summary and some additions: With IE6, extra large font, 8 tabs (as sysops have), not all tabs fit on one line. In that case, when the cursor is moved to one of the last few tabs, the menu stacks vertically, obscuring part of the article. They do not jump back, unless the page is reloaded or changed to a smaller font and back. Careful navigation of the cursor around the area that gives this problem is possible but cumbersome.--Patrick 15:53, 30 May 2004 (UTC)

Moved from Tabs don't display properly in IE

Extra large font or 8 tabs are not a requirements; some languages just need slightly longer words. Alternatively, the window might be smaller. The essence appears to be that the tabs run out of room. At first only the part that doesn't fit is displaced, but when onhover is invoked on another, the whole row starts acting up. Aliter 21:15, 13 Jul 2004 (UTC)

No css-changes preview

(On Test: When previewing a change in my personal css, the change does not actually take effect anymore. Instead I have to save then refresh. This used to function, but it may be I used IE 5.x at the time. Aliter 21:15, 13 Jul 2004 (UTC)

IE5:

Ignore the colors; I'm not used to making screenshots under Windows. Note the stacking of the tabs. A SourceForge bug report was filed, but I couldn't attach the image there because I can't log in. If someone would upload the image, I'd be grateful. Grendelkhan 23:27, 26 May 2004 (UTC)

Copied from test:Skin issues[1] (that's another interwiki prefix that needs reinstating, I think) by IMSoP 01:41, 27 May 2004 (UTC) (for context, it had been mentioned that it only appears to happen when using accesskeys or other keyboard navigation to focus the tabs):
Confirmed here as well. IE5 and 5.5 support the display: inline way of horizontal list formatting well (but IE6 has bugs in that area), that might be a way to fix it. I don't remember this happening when it was inline. Update: Tried inline again, doesn't make a difference. Only dropping the display:block on the a fixes it, but that looks like plain text links then. Not a major problem fortunately, if you're using access keys you'll very likely press enter afterwards. -- Gwicke 10:07, 24 Apr 2004 (UTC)

Width problem

My talk page when logged in shows a small vertical menu duplicating the same commands at the top and interferes with/ hides the TOC. When logged out the problem is not there. KRS 15:41, 30 May 2004 (UTC)

I discovered that it is because there is not enought width for all the commands of the menu(since I am watching the page I get an extra command) and hence it comes like a vertical floating menu interfering with the page. When I set the view text size from medium to smaller it became OK. However, it is difficult to read the page with this text size. Any solutions? KRS 16:12, 30 May 2004 (UTC)
As-short-as-possible translations for the tab text can help a bit, and using a less flawed browser of course. -- Gwicke 08:12, 1 Jun 2004 (UTC)

Top text behaving badly in hi and mr

In Hindi and Marathi Wikipedia, the Log in link goes away from its correct places and jumps to a vertical alignment over the top left corner of the actual page when I move the cursor over them. I am using Internet Explorer 6.0 under Windows XP. This also happens when I am logged in for the links on top right. Screenshot --Hemanshu 21:27, 3 Jun 2004 (UTC)

GET-request with non ISO-8859-1 char-encoding

On my macintosh (Mac OS OS 9, Explorer 5.1) it dont work to enter a article name with letters å, ä, æ, ö directly into the browser's URL-space. Is there anyone else experience this behaviour? Are you going to en:æ if you enter:

http://en.wikipedia.org/wiki/æ

directly in the browser (or do yo go to en:3⁄4?)

For me, the characters translate to å → Œ, ä → ·, æ → 3⁄4 and ö → ‰, due to the character encoding. If its not only for me, maybe we should send a feature-request that fixes the character encoding in the GET-request? // Rogper 20:16, 5 Jun 2004 (UTC)

Mozilla Firefox 0.8

Underlined Text

Whenever there's an underlined word in a wiki in Firefox (0.9), the underline is placed slightly too high so that it covers the lowermost portion of the link. It's not like a strike-through, but it does interfere with readability.

--140.122.110.154 07:58, 25 Jun 2004 (UTC)

File a bug against whatever library renders your text, nothing we can do ybout this. -- Gwicke 15:42, 1 Jul 2004 (UTC)

Gecko and tables next to lists on RTL pages

In geco browsers (Mozilla, Mozilla Firefox, Epiphany etc.), with RTL pages, in certain cases where there is a table and a long list next to each other, an unneeded scroll bar is added and the list incorrectly moves way right, and overlaps the navigation and toolbox links. See for example the Hebrew entry for canine.

See a screen shot

Layout of tables, images

In Firefox 0.8 on Win2K I have been having problems with article tables only half-filling the main window. (E.g. Wikipeda: community portal) Also thumbnail images floating in the centre of articles rather than the r.h.s. (Though irritatingly, just fine in the preview!). 193.1.100.104 11:38, 31 May 2004 (UTC)

  • I have the same problem with firefox 0.8 in linux and Win2K and also with mozilla 1.7 in Win2k. A two column-table is displayed with an empty third column. An interesting point is that two identical revisions of the same page are differently displayed. The latest revision is always displayed incorrectly, although the preview is ok. The two revisions of the main page of KU are these: [2] and [3] Erdal Ronahi 12:44, 31 May 2004 (UTC)
The problem with images is caused by the category links - see #Categories list and right-aligned images at the top below. Mozilla is affected even if there are no category links (there is still a "div" element for them in the HTML). --rbrwr 15:46, 31 May 2004 (UTC)
Mozilla didn't like floated thumbs without caption, adding overflow:autooverflow:hidden fixed this. Please reload to get the new css. -- Gwicke 11:21, 8 Jun 2004 (UTC)
Take a look at en:Norman_Foster and particularly en:30_St_Mary_Axe - several firefox-only thumbnail layout nasties. I'm afraid I don't know if these existed before your last CSS tweak. -- Finlay McWalter 21:47, 8 Jun 2004 (UTC)
You'll have to reload the page (changed the css to hidden a few minutes after the auto). Looks fine to me with firefox after removing the narrow table (135px wide table for a 180px image). -- Gwicke 01:27, 9 Jun 2004 (UTC)
Super, works fine. THanks! -- Finlay McWalter 10:15, 9 Jun 2004 (UTC)
  • On Hebrew Wikipedia the usual image template [[תמונה:PictureFileName.jpg|left|thumb|250px|כיתוב תמונה]] no longer work under Firefox 0.8 since the upgrade. Instead of aligning the picture to the left of the text it puts the image on the same line as the text with no aligment. Hmmm 14:42, 8 Jun 2004 (UTC)

Strange errors

I have the Saved Form Information enabled on Firefox 0.8, and whenever the box that shows various possible choices appears, it appears right infront of the logo. This screenshot shows what happens. KirbyMeister 18:16, 5 Jun 2004 (UTC)

This is a mozilla bug we can't influence, try http://bugzilla.mozilla.org/. -- Gwicke 15:51, 1 Jul 2004 (UTC)

Mac brower: display & sidebar atrocities

Hi, someone has terrorized my browsing experience! The following happens sporadically:

  • The sidebar is huge, contains bulleted lists, and shows up at the very bottom of the page.
  • Links at the top, and the logo, don't show up.

The following always happens:

  • Section-editing is broken -- the section headers overlap the "edit" link for each section (it shows up on the left instead of on the right). As a result, editing pages that contain any characters not supported by my browsers (IE5/Mac and NS4.7/Mac) is a pain because I can't tell if I'm accidentally overwriting unrecognized characters with strings of ???.
  • Display is sometimes bizarre... I can open a page for editing, immediately preview (without changing anything), and get a different result. Consider [[4]], whose brokenness I can't explain.

Sj 22:15, 25 May 2004 (UTC)

I can't reproduce any of these problems in IE5.2.3/Mac OS X or IE5.0/Classic. --Brion VIBBER 06:44, 1 Jun 2004 (UTC)

Firefox 0.9 problems

Firefox 0.9.3. Bullet points float onto the image. They should be further to the right.
Firefox 0.9.3. Bullet points float onto the image. They should be further to the right.

When a bullet-list appears to the right of a float-left image, the bullets are half-hidden behind the image. This is Firefox 0.9.3. Grendelkhan 15:44, 9 Aug 2004 (UTC)

Table headings

True of Firefox 0.9.3: Table headings do not automatically align centered with MediaWiki. This is true for both wiki markup tables, and wiki-embedded html tables. However, with standard html (not in a wiki), table headings line up just fine, so I think the bug is in MediaWiki rather than Firefox. Reported here —siroχo 03:09, 12 Aug 2004 (UTC)

Opera 6 problems

I quite like the 1.3 and all. But there's some problems with it in Opera 6. I've tested it in some other browsers I own too, just for the sake of it. Some of them are a bit old and obsolete though. Obviously, most if not all the problems are the browsers' fault, but it'd be nice if my trust Opera 6 coud give me Wikipedia. I apologise for my pathetic whining, and for concentrating on the negatives.

Opera 6.0

Bad News

  • It pains me to report that the new set-up is unusable in Opera 6, because the sidebar links don't work at all. The only thing in the sidebar that works is the search field. Strangely, the sidebar links all work fine in Meta.
    • Works for me in 6.03/Mac. --Brion VIBBER 06:53, 1 Jun 2004 (UTC)
  • The impatient user gets some horrible splurdging if they try to scroll down when the page is still loading, rendering the page unreadable until fully loaded. It's a minor niggle.
  • The images in the footer get lost behind the text.
    • Confirmed in 6.03/Mac. Recommend upgrading. --Brion VIBBER 06:53, 1 Jun 2004 (UTC)
  • Neither of the given footer-tab custom set-ups (for the .css/.js pages) seem to work.
    • Works for me in 6.03/Mac. --Brion VIBBER 06:53, 1 Jun 2004 (UTC)
  • Grotty irritations like clicking on the little buttons in the Edit page jerks the page down past the relevant cell.
  • The new tabs are a bit ugly compared to other browsers.

Good News

  • The thumbnail magnifying glass problem is no more (the little magnifying glass used to float an inch too low in Opera).
  • In-text Edit tabs no longer overlap body-text (though that may have been solved already, I have them turned off normally)
  • No silly little men icons.

Other Browsers

  • Mozilla 1.2.1 appears to be the perfect browser for Wikipedia. Wait, no... in Edit, the buttons plonk their shorthand scripts any-old-where.
  • Netscape 4.x is a mess. It's a good thing this browser is ancient. I'll not list all the problems but I hope there's no-one using this anymore cos everything just looks awful/unreadable.
  • Netscape 6 works about as well as Mozilla (i.e. good). I've no idea what the buttons in Edit are meant to be doing here, though.
  • IE5 looks just like N6, that is to say it looks and works fine. Also, the buttons in Edit actually work properly. So that's good. Can't find any problems at all on a simple run through. No little men icons.
  • Lynx 2.8 is fine, so long as the article you're looking at isn't in too many languages, because the main links are above the language list. Can you only edit by section in Lynx? Perhaps so. This is giving me headache anyway. Bloody text browsers... :)
  • KHTML renderer based browsers such as Konqueror and Safari have trouble with the decoration at the top and left of the page. The whole logo is not shown.

Wider Issues

  • The sidebar doesn't float, but you know that already.
  • The edit tab... the one sorry little edit tab.... at the top. There should be one at the side and one at the bottom like there always was. Especially one at the bottom. Cos I just read the article and now I want to edit it.
  • It's good that the thing is customisable. I hope there'll be a growing list of stuff we can copy and paste, for us less technically minded types.

Thought I'd mention all this. Thanks, Nommonomanac 02:10, 30 May 2004 (UTC)


Image enlarge icon problem in firefox, camino and others

A problem with the enlarge icon of the image display was addressed and fixed at Talk:Thumbnailed_images#TOC_colours, but the fix never made it into the implementation. This should be a quick fix. ✏ Sverdrup 22:28, 31 May 2004 (UTC)

Hm, i thought this was actually a feature (and tried to preserve it). If it's a concensus that the empty caption box is nicer it's a one-line change. -- Gwicke 09:58, 1 Jun 2004 (UTC)


problem in opera 7.5

here is the screenshot from http://wikibooks.org/wiki/Main_Page

Reports from various language wikis

From af:wiki

Why afrikaanse wiki

The volunteers of the afrikaanse wiki wonder why their wiki is now using the new beta software? It seems to be the only one, and came as a bit of surprise.


template

Finally, they also reported a problem with the template on their homepage, but this report is not clear to me. TeunSpaans 21:23, 24 May 2004 (UTC)

Before all this started the page included:
{{msg:{{CURRENTMONTHNAME}}_{{CURRENTDAY}}_selektiewe_herdenkings}}
The intention is to include a variable text-block, which for today would be called: "Mei_25_selektiewe_herdenkings" (in English "May_25_selected_anniversaries").
This somehow got converted, but then caused an error. As a result it has now been temporarily replaced with "[[{{CURRENTMONTHNAME}} {{CURRENTDAY}}]]", to at least offer one form of date-related infomration.Aliter 18:51, 25 May 2004 (UTC)-

I agree and already drafted the below bug report before I saw your message:

{{CURRENTDAYNAME}} works as:

Monday

{{Monday}} works as:

Monday

So then why does {{{{CURRENTDAYNAME}}}} do this:

{{}}


It should display the contents of the below pages based on what day of the week it is.

This works fine with the previous version of MediaWiki by using MediaWiki pages (such as with the selected anniversaries section on the English Wikpedia's main page). Please fix this bug! --mav 19:54, 25 May 2004 (UTC)

This seems to be working now on af:. The version page does however not reflect a version change. (still 1.3.0beta1) --Alias 22:36, 26 May 2004 (UTC)
Update: There seems to be some magic (conversion?) happening when pages are saved. After editing another section on the Afrikaans main page, an (unedited) section namely {{{{CURRENTMONTHNAME}}_{{CURRENTDAY}}_selektiewe_herdenkings}} was replaced with {{__selektiewe_herdenkings}}. Obviously, the template is not working anymore. As mentioned elsewhere on this page, br-tags are replaced by br/. Are these "features" documented anywhere? --Alias 15:15, 28 May 2004 (UTC)


Many problems on Irish wiki

A few problems at ga.wikipedia.org - as far as I know, almost all wikis are experiencing some of these, and it is a whole load of bugs:

  • As on other Wikipedias, the Irish wiki is experiencing problems with numerous PHP error reports appearing on most pages.
  • Something has been changed in the way external links are formatted so that they all now show the URL within parentheses as well as the link itself - see the altlang links on the main page for examples (this doesn't seem to be a problem elsewhere, though - is there some workaround for this that I am not aware of?)
  • Magic words etc. aren't working, e.g. {{CURRENTDAY}}, {{CURRENTTIME}} and so on.
  • No user-created MediaWiki messages are working (see the stub message in the sandbox for an example).
  • On Normal skin, at least, the logo has a big purple link border around it - can this be removed?
  • A MediaWiki has appeared at the bottom of each page within the article zone; in some cases, this is the same copyright message as can be got at the very bottom of the page, whereas in other cases it is a "Retrieved from" message. It's superfluous, and worthy of removal.
  • NOTOC feature doesn't seem to be working.


And general comments:

  • Is the MonoBook skin really stable and functional enough to be the default yet?
  • Make sure that each bug is corrected on all skins (where necessary), especially Normal and MonoBook since most people use those.

Kwekubo 21:03, 28 May 2004 (UTC)


Romanian Wikipedia

This is an also an important issue on the Romanian Wikipedia. Can someone please tell me how to get Magic Keywords and FARACUPRINS (__NOTOC__) to work? More importantly, the Romanian Wiki has very many user-made MSG: (MediaWiki namespace includes). None of the m now work, resulting in a very ugly and unusable wiki. This is particurarly negative because the Romanian wiki is quite large, and therefore is visited quite a lot. Is there a way to automatically convert all {{MSG:sample}} to {{sample}}? I converted a few by hand, and now the includes look really nice with the new skin, but the other old ones do not work at all. Manually converting them would sort of be painful, since there are so many pages to convert. Thanks and please reply quickly, this is really important. Other than that, the new skin is OK, I like the look, a lot more up-to-date design. Ronline 01:40, 29 May 2004 (UTC)

Findings

I have investigated more at the Romanian Wikipedia and it seems magic keywords only work if they are written in English, the problem being that when written in Romanian,or Welsh or Irish they don't work. Therefore, something must be fixed to enable localized versions of Magic Keywords like CURRENTDAY, NUMBEROFARTICLES, etc. The MSJ: includes now work on ro:, it seems the only time they don't work is after a PHP error, of which there are many. Therefore, they don't need to be converted at all (what I said above is no longer necessary), they can just be left at MSG:sample. On the other hand, the PHP errors need to be fixed, they are really annoying when they come up, first thing, on a page. Also, the Magic Keywords need to be made to work if written in local languages (can this be configured by sysops). Also, on ro:, some elements of the new interface/skin are not localized yet. Can this be done by sysops and can the results be felt immediately or do the changes have to be made to the locale file (LanguageRo.php). Ronline 02:27, 29 May 2004 (UTC)

I don't think that those magic keywords are the biggest problem - after all, all MediaWiki messages that are part of the LanguageXX.php file are in English because that is what the program was coded in. Magic words are too tightly integrated to be localised without individually coding the software on each Wiki differently - too fiddly. Just getting them to work would be enough for the moment. - Kwekubo 08:40, 29 May 2004 (UTC)


he [Hebrew] (big) problems

message sent to the "mailing list" by Meir M.

Message

Surprisingly, some of the Wikipedias where upgraded to Version 1.3 beta 1 with the new skin. As I suspected, this skin does not support right-to-left (RTL) languages correctly. Though I kept warning on this issue, it was disregarded.

The result is that currently the Hebrew and Arabic Wikipedias are not usesable! The version should be reversed ASAP !!!

Both me and the other Hebrew and Arabic wikipedians would be happy to help debuging the new skin and version but it is not acceptable to update the live site version without ANY proper tests!

We have long list of bugs that I would be happy to translate to English when it will be needed. But, for now, install the old version that worked fine.

Meir :-(

= Gecko and tables next to lists on RTL pages

In geco browsers (Mozilla, Mozilla Firefox, Epiphany etc.), with RTL pages, in certain cases where there is a table and a long list next to each other, an unneeded scroll bar is added and the list incorrectly moves way right, and overlaps the navigation and toolbox links. See for example the Hebrew entry for canine.

See a screen shot

and answer

Meir Mendelovich wrote:

Both me and the other Hebrew and Arabic wikipedians would be happy to help
debuging the new skin and version but it is not acceptable to update the
live site version without ANY proper tests!

We've been testing it in public for weeks (eg, http://rtl.wikidev.net/). Please, *please* provide specific information about what is wrong (preferably including screenshots) and please *please* say which web browser and what version you are using.

Meir Mendelovich wrote:

We have long list of bugs that I would be happy to translate to English when
it will be needed. But, for now, install the old version that worked fine.

Sorry, no. Then we'll be back to the previous state where nobody's interested in working out the bugs.

Do I understand this correctly: Because you failed to find enough betatesters you decided to just inflict this on all of us? Aliter 12:15, 29 May 2004 (UTC)
That is a terribly stupid policy. --Eequor 13:50, 29 May 2004 (UTC)
Rather than merely adding my voice to the complaints, I've decided to try and do something positive to make sure there is less pain next time a major upgrade is carried out. As such, I've created an upgrade procedure page to discuss and formulate a better way of handling beta testing, bug reporting, new version roll-outs, etc. - IMSoP 14:45, 29 May 2004 (UTC)

List of problems (till now)
  • The toolbox on the top part of the page (edit,watch,etc) is scrambled - Bug already opened in sourceforge
    • The messages need to be translated -- Gwicke 16:22, 1 Jun 2004 (UTC)
  • Search is not working
    • it's disabled in all wikipedias currently -- Gwicke 16:22, 1 Jun 2004 (UTC)
  • changing the textarea orientation while editing is impossible (pressing Ctrl-Shift)
  • This functions:

{{CURRENTDAYNAME}}, {{CURRENTDAY}} {{CURRENTMONTHNAME}} {{CURRENTYEAR}} don't work properly ^^ Dod1 08:37, 29 May 2004 (UTC)

Romanian Wikipedia woes

This is an also an important issue on the Romanian Wikipedia. Can someone please tell me how to get Magic Keywords and FARACUPRINS (__NOTOC__) to work? More importantly, the Romanian Wiki has very many user-made MSG: (MediaWiki namespace includes). None of the m now work, resulting in a very ugly and unusable wiki. This is particurarly negative because the Romanian wiki is quite large, and therefore is visited quite a lot. Is there a way to automatically convert all {{MSG:sample}} to {{sample}}? I converted a few by hand, and now the includes look really nice with the new skin, but the other old ones do not work at all. Manually converting them would sort of be painful, since there are so many pages to convert. Thanks and please reply quickly, this is really important. Other than that, the new skin is OK, I like the look, a lot more up-to-date design. Ronline 01:40, 29 May 2004 (UTC)

I have investigated more at the Romanian Wikipedia and it seems magic keywords only work if they are written in English, the problem being that when written in Romanian,or Welsh or Irish they don't work. Therefore, something must be fixed to enable localized versions of Magic Keywords like CURRENTDAY, NUMBEROFARTICLES, etc. The MSJ: includes now work on ro:, it seems the only time they don't work is after a PHP error, of which there are many. Therefore, they don't need to be converted at all (what I said above is no longer necessary), they can just be left at MSG:sample. On the other hand, the PHP errors need to be fixed, they are really annoying when they come up, first thing, on a page. Also, the Magic Keywords need to be made to work if written in local languages (can this be configured by sysops). Also, on ro:, some elements of the new interface/skin are not localized yet. Can this be done by sysops and can the results be felt immediately or do the changes have to be made to the locale file (LanguageRo.php), because the Wikipedia is in a terrible state now! Ronline 02:27, 29 May 2004 (UTC)

This message has been posted above. See my comment on the original version. -- Kwekubo 08:49, 29 May 2004 (UTC)





Arabic-Indic Digits only for Arabic Wikipedia

It seems that some developer thought that it is a feature for force all Arabic Wikipedia users to use the Arabic-Indic digits. The Arabic-Indic Digits although used in some Arab Countries, they are not used in others. In many Arab countries you will find the Arabic Digits (known as European Digits) in the news papers, and everywhere. Please undo this so-called "feature" and make it an option, instead of enforcing someones "preference" on the whole Arabic Wikipedians. Make it s user-defined option for Display. And not force it. I really hate how they look, and I really hate that I will have to deal with them daily as an active Wikipedian in Arabic. -- Isam 13:56, 28 May 2004 (UTC)



cuestion about http://es.wiktionary.org

Hi there have been some changes in the spanish wiktionary, it switches from iso-8859-1 to UTF-8 and again to iso-8859-1, creating a lot of problems because of the characters used there (ñ, á, etc) , my cuestion is: what will be the definite charset there?

Or where can I find this information?

Well, now i know that the default will be UTF-8, now I only want to know when will it be changed again, or when can I know it?


nl:Wiktionary

The nl:wiktionary is back on line. Currently we have two issues. One minor and known and one major, and particular to the nl:wiktionary.

The minor one is the extra line produced:

  1. Een
    Twee
    Drie

The major one is that we cannot produce articles with words in Chinese, Russian, Hebrew etc. This may mean that the data for nl:wiktionary needs to be converted before anything is changed. It does not have a high priority, but it would be nice to see this one solved. I have waited for the 1.3 upgrade to raise this issue. GerardM 06:00, 8 Jun 2004 (UTC) ---

Bad referral

When you refer to [[w:Turks]] it should refer to the nl:wikipedia. It does however refer to the en:wikipedia.

PS is this something a moderator can fix? If so where can I fix it ?? 09:47, 8 Jun 2004 (UTC)

Try this link: w:nl:Turks ✏ Sverdrup 13:28, 8 Jun 2004 (UTC)
I think that's by design for backwards compatibility. Dori | Talk 15:52, 8 Jun 2004 (UTC)
In the previous version it worked as I specified. w:nl:Turks means changing LOTS of pages (No way of telling which ones. To me it is just wrong. GerardM 06:05, 9 Jun 2004 (UTC)

Message does not work properly

On nl:wiktionary:Turks there are a few instances of the same message that no do not work. They should say m the message is {{m}}. Now they say: [[Sjabloon:M]]. This may solve itself when the update script is run for updating instances of {{msg:m}} and changing useer messages from MediaWiki.. GerardM 08:19, 9 Jun 2004 (UTC)

et.wiktionary

Nor Recent changes function neither New pages function neither All pages function functions at et:wiktionary. Andres 16:57, 13 Jun 2004 (UTC)


fi:wiktionary

fi:wiktionary has namespace problems. Any links to pages that have "Wiktionary:" in the name seem to link to an English Wiktionary article with the name of whatever is after "Wiktionary:". For example, on the front page, the link to Wiktionary:Kahvihuone leads to the English Wiktionary, and manually trying to fetch the page with [5] gives an error message that can be translated as "The page title you asked was false, empty or wrongly linked interwiki link. Return to Front page." The pages that cannot now be accessed are the most important ones in the fi-wiktionary. -- TJ 10:08, 16 Jun 2004 (UTC)

Same happens in pt:wiktionary. --Patrick-br 17:55, 18 Jun 2004 (UTC)

sv:wiktionary

The random page returns also pages in the wiktionary name space, something I understand it is not supposed to do. \Mikez 16:35, 24 Jun 2004 (UTC)

It does indeed. It gets very weird, and returns the php source for the site in some cases, and eventually ends up at a single page that is *always* the random page you get when hitting "random page" --soapy, 23 July 2004

Russian Wikipedia

Comments related to uploading

Lots of PNG uploading errors

For some reason, about half of the PNGs I've been uploading will not display. I click on the filename in the images description page and it says "The image "http://wikibooks.org/blahlbhab" cannot be displayed, because it contains errors."

Loading error - IMPORTANT

Netscape 7.0 blank screen
Netscape 7.0 blank screen

Sometimes the loading of article pages results in the blank screen shown in the image in Netscape 7/Win98 -- only the "[hide]" of the TOC is visible. This occurs most often after article edits. Reloads or aborts in the same tab don't help. One time, forcing a reload resultet in a Netscape runtime error (invalid function call in the C library). -- Tillwe 15:24, 30 May 2004 (UTC)


I second you Tillwe. On my Netscape 7, about once every three time, when I edit a page, I get a blank one and need reload to make the content appear. Anthere

This occured to me once using Firefox 0.9.1 on Linux, but I cannot say more. -- Stw 18:49, 19 Jul 2004 (UTC)

Incomplete 'What links here' on images

I was looking at the image pages for some pictures I uploaded. When I checked the 'what links here', it says the only page that links to them is my user gallery, but I know this is not true.

Examples:

Raul654 04:27, 2 Jun 2004 (UTC)

I think that's been the case for a long time (i.e. not specific to 1.3). Dori | Talk 04:43, 2 Jun 2004 (UTC)
As of a month ago, those pages were fine. Raul654 05:41, 2 Jun 2004 (UTC)
Indeed, the links worked fine before 1.3. It seems that now, any image that is linked to with rescaling (using the options |thumbnail or |250px or whatever) are not shown as having those pages on "the following pages link to this image" list. Pages that link to the image without resizing do show up on the list. This is quite serious because it looks like lots of images are now orphans. -- DrBob 19:37, 2 Jun 2004 (UTC)
That assessment is not correct. My favpics page uses thumbnailing, and it shows up for all of the above pages. Raul654 06:07, 4 Jun 2004 (UTC)
As of a few days or so ago, editing a page that links to the image (even if it resizes) seems to (sometimes?) re-associate the link. Pages that link-with-resize that haven't been edited since the 1.3 upgrade don't seem to show up, as far as I can tell. -- DrBob 20:07, 4 Jun 2004 (UTC)
And then, even if it were correct, those are not the only images in which that bug is present. See, for example, En:Image:HausdorffSpace.png, linked from En:Hausdorff space. --Fibonacci 06:51, 5 Jun 2004 (UTC)
Wikipedia just came back up. When I went to National Gallery of Canada, there are two thumbnail images there, and I know that the "What links here" worked before wikipedia went down, because I took and posted one of the photos, and saw that it worked properly. Now, neither of those photos has any entry; it may be that the entire "What links here" database was lost or the function is not working. -- RealGrouchy 02:48, 8 Jun 2004 (UTC)
It's not just those that are link with a resize.
For example:
Other examples which were definitely working before 1.3:

"What links here" broken for images

As noted above, the "Image links" sections on the Image: pages not been updated so that only newly edited pages appears to update this section. Additionally, the "What links here" link from these pages is not even consistent with this.

For example: this image page has one entry in the "Image links" section since I edited that page after the upgrade, but the corresponding "What links here" page contains no entries.

Conjecture: the "What links here" pages from image pages are always empty. Lupin 08:20, 30 May 2004 (UTC)

It would be very, very nice if this problem could be fixed - finding unused images is a bit hard this way. A remark at sourceforge sugests that this is not a developerproblem, but could be fixed by administrtaors. Does anybody know how? 213.84.115.169 11:39, 19 Jul 2004 (UTC) (see https://sourceforge.net/tracker/?func=detail&atid=411192&aid=968603&group_id=34373)

Comments related to TOC

compactTOC

I am probably being an idiot but...putting compactTOC, NOTOC, etc. directives do not work on my site. For example, putting {{compactTOC}} shows up as a link to Template:compactTOC. Same thing for msg:compactTOC. Any ideas? This is mediawiki 1.3.2 on php 4.3.8. I've tried this on the Wikipedia's sandbox and it works fine...I haven't really changed anything in the site or default php config. Thanks, -Drew

TOC

The Tables of Content have a lot of extra white space at the bottom. I can post a screenshot and more info if this is peculiar to my setup. Dori | Talk 15:49, 22 May 2004 (UTC)

They don't indent any more either? See [6] - the TOC looks really ugly here. Dysprosia 00:40, 23 May 2004 (UTC)

I've removed the uneven spacing there, looks fine to me now- please verify. -- Gwicke 18:56, 23 May 2004 (UTC)
Extra spacing seems to have been fixed, but I still see that indenting problem that Dysprosia mentioned. Dori | Talk 19:20, 23 May 2004 (UTC)
I can't reproduce this, can you make a screenshot of it? Also, browser type and version would be useful. -- Gwicke 20:48, 23 May 2004 (UTC)
Image:TOC-bug-screenshot.jpg (Mozilla/5.0 (X11; U; OpenBSD i386; en-US; rv:1.6) Gecko/20040324 Firefox/0.8) Dysprosia 09:44, 28 May 2004 (UTC)
Some toc styling was missing in the older skins, please report if this fixes it. -- Gwicke 23:39, 2 Jun 2004 (UTC)
Still some weird spacing between the start of a section and it's children in the TOC, though (which looks a little strange between the next section), but indenting works :) If you want a screenshot again, let me know. Dysprosia 23:12, 3 Jun 2004 (UTC)
I likewise yearn for this to be fixed--it makes for a very counterintuitive Table of Contents (the visual breaks don't coincide with the logical breaks), and it takes up a lot of space at the top of an article, where ideally we want the first visible screen to be packed with information. 128.97.178.40 23:33, 4 Jun 2004 (UTC)

TOC

The following is a part of the HTML generated to the TOC of en:European Parliament.

(Commented out since it widens the page in <1600x resolution)

As one sees, the top level TOC entries are defined by their div class only, whereas the sub level TOC entries (2.1) use not only their class tocindent, but also <p></p> -- which means that it is quite easy to format top level TOCs, but if you go down to changing the monobook css for sub level TOC entries, you'll get side effects of changes in the paragraph formating. Could this -- generally! -- be changed to a tidier CSS? -- Tillwe 14:35, 30 May 2004 (UTC)

Should be nested ul's imo (patches accepted). -- Gwicke 23:39, 2 Jun 2004 (UTC)

NOTOC

No [edit] link top of the page

A page with TOC, on 1.2.5 shows [edit] link top of the page, though the page does not start with == section. 1.3 does not show it like this page --Suisui

Right-clicking on the title doesn't work either (if it's configured instead of edit links). -- Stw 18:55, 19 Jul 2004 (UTC)
The lead [edit] link is particularly useful when the page is fairly large, as the entire page has to be loaded otherwise. --Eequor 02:34, 31 Jul 2004 (UTC)

Bug related to spacing before TOC following indented lines

When the new layout was created, there was a problem with the TOC not spacing below the intro text. I see that this was fixed. However, check out en:Hawaii. It appears that no amount of spacing in the edit mode will result in a one line separation of the TOC from the intro text in the rendered page, perhaps because the last line in the intro starts with * (indented)? - (Marshman) 24.94.82.245 04:02, 10 Jun 2004 (UTC)

Comments related to templates

Subst and parameterized templates

Variable substitution is not performed on templates when using subst:.

Example: {{Template test|A variable}} produces

This template requires one paramater, which will be displayed here: A variable

But {{subst:Template test|A variable}} produces

This template requires one paramater, which will be displayed here: {{{1}}}

It's properly including the template, but not substituting the variable.

-- Cyrius 18:05, 22 May 2004 (UTC)

Hmm, still doesn't work Dori | Talk 17:08, 8 Jun 2004 (UTC)

Markup Precedence and template syntax

While working on a new project at Wikibooks, I found a few problems with template syntax. These have all been tested to be a problem at Wikibooks, so please tell me if they have been fixed:

Consider a template named foo with the contents "{{{bar}}}". For some reason, if you try to do something like {{foo|bar=[[1|2]]}}, you get the output "[[1" instead of "[[1|2]]". I don't know if this effect is intended or not, and if so, a way to get around it (after all, I want a link and not disjointed stuff).

Furthermore, there seems to be a problem with including a template inside another template. For example, consider template A with the contents "{{{1}}}" and template B with "foo". Then, doing {{A|{{B}}}} will result in "{{B}}" and not "foo". After some deduction, it's because the braces are matching up incorrectly: {{A|{{B}}}} instead of {{A|{{B}}}}. I'm pretty sure that this wasn't the desired effect. (Worse is if you were doing this in a template page where the triple brace would also be a factor)

Worse is this: Let's try {{A|{{A|B}}}} should render "foo", but instead is rendering "{{A". So a nested template inclusion with parameters still fails to work properly.

One minor feature request is default parameters when parameters are not specified: for example, say template Z contains "{{{1=foo}}}", {{Z}} should render "foo" while {{Z|bar}} should render "bar".

-- kelvSYC

Wikisyntax getting more and more complex and the initial considerations that we had to abbandon HTML or XML syntax, just because it would scare new editors, makes me laugh now adays. Is not this already implemented within XML? (I'm not saying that Wikisyntax should be abbandoned, it gets rather more and more intresting.) // Rogper 13:43, 3 Jun 2004 (UTC)

Brackets suffer from a similar problem. It isn't possible to put a wiki link in brackets as so: [[[User:Eequor]]]; presumably the software is trying to interpret the outside one or two brackets as an external link or a wiki link, finding in each case the next character is a bracket, and then giving up. It should just ignore the first bracket. --Eequor 23:02, 22 Jul 2004 (UTC)

Broken images in templates

When images are used in templates they don't show as expected. Instead there are only links to the image description page. In addition there shows a message "Missing image" when the size argument is used, e.g. 100px. See an example template and its application --Borislav 10:05, 29 May 2004 (UTC)

The syntax [[Bild:{{{image}}}|alternative text for {{{thing}}}]] might not work properly. The syntax [[{{{link}}}]] displays an empty link in the article. (see: de:Landkreis_Barnim -- Triebtäter
I added a sample to Borislav's test. The only way to include them now is to use "image=[[image:Blabla.png]]" as argument for the template. Too bad, it had worked so well on Test:Belgium -- User:D2
On en:Belgium the image inclusion works. -- User:Docu
There is a slight difference ... in en:Belgium the system variable PAGENAME is used to generate the image name and the alternative text, in de:Landkreis Barnim it is a parameter. Triebtäter
Apparently the image isn't located where the template thinks it is - the created HTML has the image source at de.wikipedia.org/upload/c/c7/Brandenburg_bar.png, however the picture is at de.wikipedia.org/upload/e/e3/Brandenburg_bar.png. Ahoerstemeier 15:37, 1 Jun 2004 (UTC)

I tried something similar at en:Template:Mancala 2x6. I expected to be able to use it like {{Mancala 2x6|1|2|3|4|5|6|7|8|9|10|11|12}} since the appropriate image names are defined. However