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.
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 Engels09:01, 24 May 2004 (UTC)[reply]
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 Engels09:09, 24 May 2004 (UTC)[reply]
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. -- Gwicke22:59, 24 May 2004 (UTC)[reply]
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. Aliter22:28, 27 May 2004 (UTC)[reply]
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.--Patrick15:53, 30 May 2004 (UTC)[reply]
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. Grendelkhan23:27, 26 May 2004 (UTC)[reply]
Copied from test:Skin issues[1] (that's another interwiki prefix that needs reinstating, I think) by IMSoP01: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):[reply]
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. KRS15:41, 30 May 2004 (UTC)[reply]
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? KRS16:12, 30 May 2004 (UTC)[reply]
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:
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.
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.
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.10411:38, 31 May 2004 (UTC)[reply]
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 Ronahi12:44, 31 May 2004 (UTC)[reply]
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)
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.
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.
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.
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)
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.
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.Aliter18:51, 25 May 2004 (UTC)-[reply]
I agree and already drafted the below bug report before I saw your message:
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! --mav19:54, 25 May 2004 (UTC)[reply]
This seems to be working now on af:. The version page does however not reflect a version change. (still 1.3.0beta1) --Alias22:36, 26 May 2004 (UTC)[reply]
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? --Alias15:15, 28 May 2004 (UTC)[reply]
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.
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.
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. Ronline01:40, 29 May 2004 (UTC)[reply]
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). Ronline02:27, 29 May 2004 (UTC)[reply]
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. - Kwekubo08:40, 29 May 2004 (UTC)[reply]
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.
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? Aliter12:15, 29 May 2004 (UTC)[reply]
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. - IMSoP14:45, 29 May 2004 (UTC)[reply]
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 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. Ronline01:40, 29 May 2004 (UTC)[reply]
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! Ronline02:27, 29 May 2004 (UTC)[reply]
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. -- Isam13:56, 28 May 2004 (UTC)[reply]
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:
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)
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
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). -- Tillwe15:24, 30 May 2004 (UTC)[reply]
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.
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)
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)
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.
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 | Talk15:49, 22 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)
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)
(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? -- Tillwe14:35, 30 May 2004 (UTC)[reply]
Should be nested ul's imo (patches accepted). -- Gwicke 23:39, 2 Jun 2004 (UTC)
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.
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".
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 --Borislav10:05, 29 May 2004 (UTC)[reply]
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, I end up with this, where it claims it cannot find images I know exist. One syntax which doesn't seem to work was [[Image:Mancala hole ({{{1}}}).png|32px|{{{1}}}]]. Also, when Template:Mancala hole 1 was [[Image:Mancala hole (1).png|32px|1]] the image still could not be seen through syntax like: {{Mancala hole {{{1}}}}} - instead a read link to the Template:Mancala hole 1 was produced. I hope something can get worked out to allow images to be chosen through templates. - Kevin Saff 22:13, 3 Jun 2004 (UTC)
Use of '|' in templates
When using named template parameters it would be very useful to be able to include things like species_image = [[Image:filename.jpg|image description]] . However this is not currently possible because the parser treats '|' like the end of a the parameter value.
There is a potential workaround - split the elements either side of the '|' into separate parameters e.g. species_image_filename and species_image_description, however when I tried this I ended up with problems getting the image to appear.
The image problem is the one mentioned directly above. While it is possible to pass a | into a template by using the HTML coding for it (|), this however only works for plain text (and who ever needs a | in plain text), if one uses this in a wikilink the link will break. So giving [[2004|Now]] will be rendered as [[2004|Now]] instead of making a wikilink. Maybe we need something like escaping - a double || in a template is the same as a single | passed through. Ahoerstemeier 11:01, 3 Jun 2004 (UTC)
Template parameter with pipe link
Templete with parameter {{{para}}} doesn't work use as pipe link. as example {{Temp|para=[[some link|name]]}}. For example {{テスト|日本=[[User:Tomos|Tomos]]}} shows like blow
Links from template variables are broken/become edit links
The link on en:Belgium to en:As_of_2002 is broken, the link is defined on the template en:Infobox_Countries as follows: ([[As_of_{{{population_as_of}}}|{{{population_as_of}}}]]) . This somewhat similar to the image link bug above. -- User:D2
Template in section name shows broken links
A template use in section name does not create correct XHTML. ex, Tnplate:en include only [[English]]. and use it === {{en}} === shows broken HTML see blow. (I'm using Mozilla1.6 on MacOSX )--Suisui 15:37, 11 Jun 2004 (UTC)
Kudos to the developers who put so much time into MW 1.3! I know you've done a lot of hard work, and you continue to do so.
However, it would be seriously nice if templates were more configurable. As things stand, we're looking at making over 100 templates to create for taxonomy infoboxes. (See our discussion for details of why so many.)
Here's a list of enhancements that would make templates valuable to us:
Variable input paramters
Allow input parameters to be optional
Sections of HTML/WikiCode flagged to be activated when optional inputs are present
Fields whose display is controlled from other templates
Until such time as these features are implemented, templates are a big waste of time for us to create to use in taxonomy articles. We'll continue to use HTML tables, configuring each one as we make them. - UtherSRG 17:36, 4 Jun 2004 (UTC)
This would effectively turn MediaWiki into its own programming language. I think we need to keep things as simple as possible. Dori | Talk 17:48, 4 Jun 2004 (UTC)
Not really. It's just that templates have the potential for being something useful, something that can live up to the name "template". Instead of just a bland data formatter, it could be something that interprets how much data is being formatted, and presents the data in the appropriate format... gee, just like what the wiki does to display... but with more control and customization in the hands of the users. I'm not asking for counting or looping or any other sign of a Turing machine. I only want the ability to recognize that data isn't static in quantity, just like it isn't static in value. - UtherSRG 20:02, 4 Jun 2004 (UTC)
Yes, "conditional parameters" sounds like a great idea. I've missed that feature while playing around with "infoboxes." The same also for "default parameters":
{{{GNP_param=n/a}}} (shorthand for {{{GNP_param? {{{{GNP_param}}}} {n/a}}}})
so that omitting the "Gross National Product"-parameter value uses the default value "n/a". // Rogper 20:37, 5 Jun 2004 (UTC)
I hope that conditional parameters would work with:
{{{GNP_param ? { {| |{{{GNP_param}}} |} } { You are lazy! } }}}
i have recognized that templates gets the id 'toc', that conflicts with the toc. I propose to take the name of the template as id and give a class 'template' for a template, that should give possibilities to handle them individual, e.g. to suppress them for printing. --141.53.194.251 20:02, 5 Jun 2004 (UTC)
I've added a class 'toccolours' now that uses the same styling as #toc. Please convert the templates to use that instead. -- Gwicke 11:15, 8 Jun 2004 (UTC)
ah, thanks for that, I had not realised that this id is coded in the templates... -- WikiWichtel 12:12, 10 Jun 2004 (UTC)
Proposal for default template parameter values
I think that this might make a good idea for implementing default template parameter values. While, to some limited extent, this is already possible, it uses up very convienient names quickly. For example, templates for article series navigation may use {{{prev}}} and {{{next}}} as two parameters, and it would be impossible to provide default values in [[Template:prev]] and [[Template:next]] that can suit the various templates that use those two parameters. A quick solution that shouldn't be hard to implement can be the following: use template subpages for this purpose.
For example, if you have [[Template:foo]] with parameter {{{bar}}}, MediaWiki should first look in [[Template:foo/bar]] for a default value before looking in [[Template:bar]] before finally settling for the default fallback.
Since we can't send a pipe into a template I tried sending in two parameters and then piping them together in a link inside the template. This causes the link to be an edit link instead of a regular link. Removing te pipe and keeping the link internal to the template also causes the link to be an edit link instead of a regular link. en:Wikipedia_talk:WikiProject_Tree_of_Life/taxobox_test is my attempt at getting around the various template breakages to make templates as versatile as they should be, but these small breakages make any such efforts meaningless.
Is anything being done to fix the breakages in templates? Or am I wasting my time and energy here? - UtherSRG 12:11, 16 Jul 2004 (UTC)
I also hope it will be fixed. In the meantime, use external link style, that works.--Patrick 12:24, 16 Jul 2004 (UTC)
Bah! Humbug! Ugly kludge! *grumble*, *grumble* Ok, fine.... Still, is anyone working on these issues, or is this simply a place to vent our frustrations and then get more frustrated thinking that someone cares when no one does? - UtherSRG 16:24, 16 Jul 2004 (UTC)
Furthermore, the link is the same regardless if the target exists or not. This adds a random element into Wikipedia. "Is this link going to go to an article, or a blank page?" Is this something that will help Wikipedia or harm us? - UtherSRG 20:11, 17 Jul 2004 (UTC)
Template limit
I have been attempting to tidy up en:Wikipedia:Vandalism in progress using the vip template (which produces a (User page | talk | contributions) block). For some reason it works fine on IP numbers, but breaks on real users. The really strange thing is that the latter seems to have succeeded when the changes are previewed. --Phil | Talk 14:08, 16 Jul 2004 (UTC)
Wait a minute, I think I might have twigged: could it be falling foul of a limit on the number of times any given Template can be used on a page? --Phil | Talk 14:11, 16 Jul 2004 (UTC)
Yes, five is the limit. I think this restriction should be relaxed or removed.--Patrick 19:37, 16 Jul 2004 (UTC)
Definitely. I've seen several articles that have had to use multiple templates in various ways to produce the same text. See en:nirvana, for example. If for some reason six templates causes a strain on the server, templates are poorly designed. --Eequor 06:19, 17 Jul 2004 (UTC)
Please remove the template limit! It provides no benefit at all; if it is meant to prevent DoS attacks, it is a very naive solution (and it doesn't even prevent an attack anyway; see [7]). The limit only interferes with page editing and forces users to resort to bizarre tricks to circumvent it. There are all sorts of things that would be made easier by allowing more than five of a specific template. --Eequor 21:27, 19 Jul 2004 (UTC)
Currently the limit protects against infinite recursion, see en:Template:cp. So if the restriction is dropped, there needs to be another one, e.g. not more than five levels.--Patrick 15:09, 27 Jul 2004 (UTC)
Limiting the number of a particular template is no solution. It's simple enough to keep track of which templates have been visited. It makes no sense to limit all templates just because some templates can be made recursive.
Regarding DoS attacks, it would be much more effective to limit the size of the generated page to 32k or twice the size of the unexpanded page, whichever is larger, though that might not be large enough for advanced uses such as infoboxes. What is to stop an anonymous user from creating megabyte-sized templates for each letter of the alphabet?
It isn't even necessary to upload 26M of templates, given that templates follow redirects. You ought to be far more worried that somebody will do this:
I am sick of the 5-include template limit. See Wikibooks:Music:Scales and Intervals...the source is a mess, needing, what, 7 templates for flat signs? See also Wikibooks:Wikibooks:Staff lounge for some previous discussion. I will refuse to work on music books any longer until it's fixed. At the very least, the limit could be raised to 25. I'm sorry to demand this so rudely, but it appears to me as though nothing is getting done about it. - Furrykef 07:51, 21 Aug 2004 (UTC)
Is there a variable similar to {{PAGENAME}} that returns the base name of a page, with namespaces and directories removed? How is category sort order affected by a link such as [[:Category:Wikipedia:A/B/C|A/B/C]]? --Eequor 21:30, 20 Jul 2004 (UTC)
Colons, templates, and sections
This bug should be obvious from the preceding section. That's ==={{:BASENAME}} variable===. --Eequor 21:34, 20 Jul 2004 (UTC)
New features
Are the feature suggestions on extended template syntax likely to be implemented anytime soon? --Eequor 21:52, 19 Jul 2004 (UTC)
Comments related to Tables
Tables and images
Check fy:Vincent_van_Gogh. All version in history have had one or more images, for lay-out purposes enclosed in a table. Currently, some version do still display the images(IE6), some do on some loads, some never do. The last version I did used the new table style. This worked fine when I saved it, but retrieving it now the tables now have disappeared completely, that is, they are no longer shown in the text. Aliter00:47, 30 May 2004 (UTC)[reply]
Looks fine to me now. -- Gwicke 01:25, 14 Jun 2004 (UTC)
Simple tables on Standard skin
See, for instance, RC under Standard (on IE6/WinXP). The cells have a huge amount of default spacing and padding... or something else that's adding those extra paragraph-breaks between each row. Sj 19:56, 1 Jun 2004 (UTC)
Editing Section in Table Cells
Additional information that bleeds into the next cell shows up.
Try editting 'the first sample section' in the 'first cell' of the following table...
the first sample section
the first cell
the second cell
As you can see the second cell gets included in the edit.
This could be handled in a couple of ways
The section editor could recognize that the scope of a section does not cross certain boundaries, e.g. cell boundaries.
A special section terminator markup could be introduced.
Embassy contains a bunch of interwiki links, and strangely only some are displayed as links, others are showing as if they were in between nowiki tags. Tomos04:31, 23 May 2004 (UTC)[reply]
The reason for this might be that the urls are pasted as urlencoded string rather than utf-8 (copying the first header of a page works very well to get utf-8 links). When i change the link target to utf-8 the link renders fine. -- Gwicke22:57, 23 May 2004 (UTC)[reply]
I've committed a fix that urldecodes the title if a % is found in it. Now those title work as well, but please use utf-8 titles if possible (better to read as well of course). -- Gwicke14:40, 25 May 2004 (UTC)[reply]
When the hand points to an interlanguage link, the letters doesn't show up, do something! - Pumpie, 18:56 (UTC).
On another interwiki link issue, I cannot see the interwiki links during preview mode. If I add a link, the only way to see if it will show up correctly, is to save the page. With the old format, we were able to see the interwiki links during preview. RedWolf20:39, 29 May 2004 (UTC)[reply]
A wonderful feature would be to have an "edit" link on the interwiki links box, similar to the section editing, so that one edit the interwiki links without touching to the article Srtxg22:49, 29 May 2004 (UTC)[reply]
http://en.wikipedia.org/wiki/Computer_mouse has interwiki links at the end, but none of them show up. Removing all links except one of the non-urlencoded ones (for instance, leaving just the de: link) makes no difference, at least in the preview. Isidore 21:16, 17 Jul 2004 (UTC)
Walloon is, you simply hadn't put the interwiki link (wa:); the ln: should work, as the lingala wiki exists, but it doesn't... I guess someone forgot to add it to the interlink database. The other two (ast:, mt:) don't exist yet. Srtxg23:01, 29 May 2004 (UTC)[reply]
Lost links
On a preview page interlingual links were available with previous version. Now they aren't. I feel the lack of interlingual links with a previewed page very inconvinient. In addition, no link to the previous page is available from "Added this page to your watchlist". KIZU
I second the link to the previous page from "Added this page" (as well as the nifty idea of an edit link within the Other Languages box). Catherine
Interlanguage links are red in Edit summary
A langlink in the edit summary with or without colon like en:User:Sverdrup is not interpreted as a langlink in the edit summary, and displays red. ✏ Sverdrup 10:43, 3 Jun 2004 (UTC)
Interlanguage links distorted when title has certain characters
Unfortunately the link in en:Pacific Ocean is correctly parsed (title = Thài-pêng-iûⁿ), thus the mere existence of ⁿ (ⁿ) does not guarantee a bad link.
Update: Workaround from Brion Vibber: use HTML numeric entities. A-giâu 22:31, 5 Aug 2004 (UTC)
Interlanguage links in wrong class
Interlanguage links with classic skin, at the top and bottom of the page, are in class external, while in the page body interwiki links are class extiw.--Patrick 11:06, 29 Jul 2004 (UTC)
Minnan interlinks
The minnan interlinks don not appear on the left like all the others, but below the article text. See en:GNU Free Documentation License for an example. Erdal Ronahi 09:17, 4 Aug 2004 (UTC)
Good -- I moved a couple of links from Category:Movies to Category:Films last night, since there were only a few, but it will inevitably get linked to many more times. A functioning redirect will end up being very important. Catherine
If a category is to be renamed, two things must happen:
All articles in the category must be edited to reflect the change
The category article must be moved to the new category name.
Although the move tab is there, it doesn't seem to work, and I really don't want to cut & paste the category article and then ask to delete the original.
Yes, this is annoying. What would be super nice is if the "Move this page" link worked and also changed all of the articles and subcategories to reflect that change. Lupin 13:18, 1 Jun 2004 (UTC)
Agree that would be nice, but it's a bit scary to me. For now, I'd be happy if I could just move the article itself. I'd be exstatic if I could move the ariticle and redirects worked. --Ssd 13:11, 2 Jun 2004 (UTC)
Unusable Special:Categories
Currently on en:Special:Categories it's totally impractical to browse the categories. Shouldn't this page only list the top-level categories? It seems like it should also have a compact TOC for easy navigation. --Eequor 19:34, 2 Jun 2004 (UTC)
Unless you're really bored or working with the category system itself, I think Special:Categories is probably not all that useful. If you want it sorted by top categories, MAKE a top category. Having said that, what would you call a top category? See en:Wikipedia:Categorization#Top level categories for details and suggestions. It might be nice, however, if there was an automated way to create some of the work I've done in en:Category:Orphaned categories. --Ssd 02:27, 10 Jun 2004 (UTC)
It appears someone has created wikipedia:Category:Categories as a category listing top level categories. --Ssd 14:22, 11 Jul 2004 (UTC)
can't remove an article from a category
en:Warcraft is in en:Category:Computer games although I removed the [[Category:Computer games]] tag. Is this a bug or have I missed something? Lupin 13:48, 1 Jun 2004 (UTC)
I've seen this too; maybe it's some sort of caching thing. Try back in fifteen minutes and it will probably have gone away. However, it should be instantaneous. It's definitely a bug of some sort. Grendelkhan 16:11, 1 Jun 2004 (UTC)
It's still there. :( Lupin 16:37, 1 Jun 2004 (UTC)
Yes, this seems to be a serious issue. I've been trying to remove people from being directly in en:Category:Writers, but they've all stayed. John Kenney 05:50, 5 Jun 2004 (UTC)
Just checked, it's gone now. --Ssd 11:43, 5 Jun 2004 (UTC)
This is still a problem. Articles and subcategories will stay listed on a category page for hours, even over night. I'm tempted to make a test and see how long it will take before the removal takes effect. - UtherSRG 02:29, 16 Jun 2004 (UTC)
This is probably not a problem with categories, but with the cache servers. Perhaps one server is not getting updates or cache invalidation as quickly as others. People who are using that server see the problem, others do not. It may even sometimes make a difference if you are logged in or not. --Ssd 12:44, 26 Jun 2004 (UTC)
Article doesn't appear on category page
The article en:List of cultural and regional genres of music does not show up on en:Category:World music, even though it is a part of that category. Did I do something wrong or is this a bug? (Or a feature?) It's been a couple days since I added the category tags, and every article I added it to except this one are on the category page correctly. TUF-KAT 03:01, 2 Jun 2004 (UTC)
I see it on the World music category page but it's not in sorted order! RedWolf 21:15, 4 Jun 2004 (UTC)
Suggestion: Category sort index display and case folding
Is there any way to have an alternate name listed on the categories page? For example in the Category:Monty Python category, it is confusing to have a Monty Python link and a Monty Python's Flying Circus link. It would be useful if the sort index was displayed instead of just being used to sort the articles, so that (for example) About the group and The TV series would be displayed, instead of the article names. Any thoughts? --HappyDog 17:00, 1 Jun 2004 (UTC)
Agreed. It would work wonders for the new cleanup category. You could say
{{cleanup|reason=Needs wikifying}}
which would translate to
''This page is in [[:category:Cleanup]]. Feel free to improve it and remove the notice when done''.
[[category:Cleanup|{{PAGENAME}} ({{{reason}}}]]
If the sortkey was displayed, this would show "Articlename (Needs wikifying)" in the cleanup category. That said, meta data should be kept out of the Category: namespace. Maybe "Category Wikipedia:"?
with sort_key and display_text defaulting to category_name.
This would work great for timelines: put
[[category:Timeline of World War I|1914-06-28|June 28, 1914: Gavrilo princip assassinates archduke Franz Ferdinand]]
into assassination in Sarajevo, and watch the timeline grow :)
Zocky
The initial of the sort index is case sensitive, unlike everything else on Wikipedia (standard MediaWiki setting). It would be nice if the settings were the same or if the sorting were case insensitive. -- User:D2
It would be cool if category pages had alternate ways to view them. For example, a "link view" and a "sort key view". Perhaps the category's article could specify the default view if the user didn't pick one. --Ssd 12:02, 5 Jun 2004 (UTC)
Odd sorting of subcategories
The sorted articles and subcategories are an improvement, but the subcategories are simply arranged in columns and sorted under C (because all subcategories start with Category:...) --Eequor 04:36, 8 Jun 2004 (UTC)
Category sort orders cannot be changed. That is, a subcategory Category:Gamma categorized as [[Category:Alpha|Beta]] will appear in Category:Alpha sorted under G, rather than under B as one would expect. --Eequor 02:25, 10 Jun 2004 (UTC)
Oh no, it's much worse than that! See Category:Test. I can't figure out what stuff is sorted by, but it's not exactly the sort key or the category name! (Although it is at least somewhat better than it was.) Obviously, the column heading should be the first letter of the sort key, even if the sort key is the category name (i.e., blank), but not 'Category:'. Complex and messy, yum! --Ssd 02:45, 10 Jun 2004 (UTC)
I was going to come back to say the sorting was right and only the column headings were wrong... but Category:Test changed my mind. Yeee! o_o;; --Eequor 02:51, 10 Jun 2004 (UTC)
Nice of you to tell me you already put it in source forge. Good thing I searched carefully. 8) --Ssd 04:35, 10 Jun 2004 (UTC)
Looks like this one has been fixed. --Ssd 00:31, 16 Jun 2004 (UTC)
Except that categories with mixed upper and lower case as a first letter are ascii sorted instead of alphabetically sorted. Several people have complained. This can be fixed of course by adjusting the sort key, but that's a bit ugly. --Ssd 13:41, 19 Jun 2004 (UTC)
There is still some kind of bug with category sorting. The letter headings are right, but there's two lists sorted A-Z with one inserted inside the other. I'm not sure, but possibly the middle list is without a sort tag, and being alphabetized under C still. I have not had time to remake the example as before. I'll link one of the strange categories here next time I see it. --Ssd 05:35, 13 Jul 2004 (UTC)
Subcategories have underscores instead of spaces (resolved)
Subcategories that have spaces in them, have underscores present where spaces should be. For example: w:Category:Biology, the link to Laboratory equipment appears as Laboratory_equipment rather than Laboratory equipment. --Blarney 09:12, 9 Jun 2004 (UTC)
Appears to be resolved as of 09:24, 16 Jun 2004 (UTC) (SF bug report is closed and fix seems to be live now). --Blarney 09:24, 16 Jun 2004 (UTC)
Template category change does not propagate to articles
On de: Kategorie:Zeitleisten (plural) [10] was renamed to Kategorie:Zeitleiste (sing.) [11]
Several templates in this category were updated to the new name, but the articles were these templates are used are still listed on the old category page until they have been edited themselves. Erik Zachte 18:02, Jun 10, 2004 (UTC)
This could be messy to fix unless you can deal with lag between the pages being added and the template being changed. For instance, if a tempalte like en:template:disambig was added to a category, there are a very large number of pages, and it could take a while to add them all... something like that, if implemented separate from a page edit, IMHO should at least be run as a throttled background job. --Ssd 00:36, 16 Jun 2004 (UTC)
flag for categories
We might need a flag or type for categories, to be able something like that: <member_of_cat> is a <foobar>, <member_of_another_cat> is an <other_foobar>. in the english language this could be solved by software which looks at first letter, but in german we have ein/eine which depends on male/female. On other languages there might be more variants. --WikiWichtel 11:34, 10 Jun 2004 (UTC)
Category page incorrect sorting
I tried to submit this just before the "Great Database Crash of '04" and apparently it never came out here.
On category pages, the sorting is incorrect on many of them - mostly the ones that had a lot of additions prior to the adding of the alpha headers. For example, see en:Category:Anime. A lot of the titles have been dumped until the letter "C" despite not starting with the letter "C". A temporary fix involves changing the Category: in the article to something else and then changing it back, but I'm not about to do that with several dozen articles. RadicalBender 14:01, 9 Jun 2004 (UTC)
Some of the entries in the category links table have "Command line script" as a sortkey, maybe an update query like:
UPDATE categorylinks, cur
SET cl_sortkey=cur_title
WHERE cl_sortkey = 'Command line script'
AND cl_from=cur_id
would help (but then maybe it doesn't & crashes the database). -- User:Docu
{{npov}} hides category text
See en:Category:Judaism. Adding {{npov}} to the page prevents the rest of the text from appearing. --Eequor 18:13, 11 Jun 2004 (UTC)
Links of Catalan categories
The links of the Catalan categories are incorrect. See this page: [12]. The link should point to Categoria:Alfabet but points to the edit page of :Alfabet
Categories on et:wikipedia
On et:wikipedia, articles in the Category (Kategooria) namespace cannot be created. Andres 16:53, 13 Jun 2004 (UTC)
category links in standard skin
in monobook category links have an container with id=catlinks, in standard there is only a class catlinks. I'm not very virtuos with js, but I think it would be usefull to also have an id=catlinks for moving issues. Initial request was: user with standard-skin wants to have category links at bottom of page. Could anybody provide a user-js to move them? --WikiWichtel 14:48, 15 Jun 2004 (UTC)
deleting then undeleting category
Deleting then undeleting a category causes the category to appear as its own subcategory (under the "S" heading). - UtherSRG 02:35, 16 Jun 2004 (UTC)
plural vs singular
When an article is in multiple categories, the display on the article is
Categories: foo | bar
When an article is in only one category, the display on the article is
Categories: foo
Shouldn't the single category article display be "Category", not "Categories"? - UtherSRG 02:40, 16 Jun 2004 (UTC)
This can be passed off as a "standard heading" in which case it's providing for the possibility of more entries. Rather more egregious is the message There are 1 articles in this category which cannot use the same excuse. --Phil | Talk 07:35, 16 Jun 2004 (UTC)
Doesn't really seem like any difference to me. Poor grammar is poor grammar. :) - UtherSRG 23:42, 16 Jun 2004 (UTC)
Headings are not sentences, so one cannot assume that sentence (prose) grammar applies to them. I reviewed the 14th edition (1993) of the Chicago Manual of Style, which covers non-prose grammar in considerable detail, but I could find nothing specifically addressing plurality in headings. The closest advice I found was in "General Principles of Indexing", section 17.72, which begins:
The wording for all entries should be clear, concise, logical, and consistent throughout.
This would appear to provide a weak argument for using the plural in all cases, for consistency. (The connotation of logical here is appropriate to topic.) I invite readers to cite authoritative references either for consistent use of the plural or for quantity adjustment of plurality in headings. -- Jeff Q 07:59, 20 Jun 2004 (UTC)
Watchlist strangeness
If you add a category to your Watchlist, the message telling you that you have succeeded shows a blank instead of the name of the article, and has the Article List appended to it. If you then "unwatch" the category, the name of the category appears as normal, but still with the Article List appended.
HTH --Phil | Talk 10:19, 17 Jun 2004 (UTC)
category scanner
I wrote de:Benutzer:Kategobot, who is able to get the structure of the categories and count the articles for each category and the sum. It does it without local copy, so would like to know how much Query-stress this recursive behavior does. How many seconds (minutes? 8-/) should the bot wait between two category pages? --WikiWichtel 12:55, 23 Jun 2004 (UTC)
category page sorting bug
can somebody count the 2U'sW's on this categorypage?
--WikiWichtel 15:47, 25 Jun 2004 (UTC)
If a category link in an article is replaced with another, the article is not removed from the first category. For example, en:Adolphus Hotel is listed under en:Category:Dallas and en:Category:Dallas, Texas even though only the latter is listed in the article. - 63.199.254.32 08:59, 27 Jun 2004 (UTC)
This happens roughly twelve hours later. (!!!!)
deleting of categorie pages
Is there a difference between deleting a category by using admin-function 'delete' and blanking the category page? I think blanking a category deletes this category and therefor it could be done by every user. is that correct? --WikiWichtel 22:58, 1 Jul 2004 (UTC)
Category in template is inherited
When a template is categorised, all articles inherit this category. Would it be possible to extend the syntax thus that a category tag becomes non inheritable? See for example de:Kategorie:Zeitleiste_Sport where one Template is included in 5 articles and all those articles are listed as well. Also those articles now list this category, which caused complaints.
On en:Graphical_Timelines_for_Classical_Composers the same category is even shown 7 times. Erik Zachte 21:31, Jul 2, 2004 (UTC)
Categories are hard to navigate
Currently, categories are a mess and will get messier because they are so hard to navigate. It is hard to figure out which category a page belongs to, and even harder to decide which categories a category belongs to. There needs to be a way to see entire subtrees of the category tree all at once... gracefool 12:32, 30 Jul 2004 (UTC)
Category display: splitting content
There use to be a feature (bug?) that caused the list of categories to be inserted between the CompactTOC and the rest of the content of the category. As I could not find documentation for this anywhere, I suspect it was a bug. However, it was useful. Could we have it back, perhaps as a wikimarkup symbol that causes the category list to be inserted... Maybe something like
<categories/> and <articles/> or something like that... --Ssd 15:11, 1 Aug 2004 (UTC)
Categories with alternative names
Just an example: York is a city founded by Romans.
[[Category:Roman Cities]] would list York in chapter Y als York
[[Category:Roman Cities | Eboracum]] would list York in chapter E as York
[[Category:Roman Cities || Eboracum]] (SUGGESTED!) would list Eboracum in chapter E and link to York - the urgently desired feature.
If you have a redirect from Eboracum to York, it would make sense to list the captured alternative name when it is appropriate.
Could you introduce this feature as quickly as possible? 80.134.124.108 23:11, 23 Aug 2004 (UTC)
Comments related to links
Ugly and confusing links
All the non-edit links look the same except for the annoying and ugly arrow symbol (see the list of language links on RC). Please restore blue links for live wiki links and use the current grayish light blue for external links. Also please drop the ugly arrow symbol. --mav09:42, 22 May 2004 (UTC)[reply]
I agree that in the case of the language links the external link indicator isn't very pretty. I'll add a class to the stylesheets that suppresses them if the class is set on that table cell. If you don't want to see them anywhere or want to change the link colour, you can either do so in your user stylesheet or use the standard/nostalgia/cologneblue skin. -- Gwicke12:13, 22 May 2004 (UTC)[reply]
I agree that the icon should be disabled site-wise as it also messes up links that are supposed to be short (i.e. [http://cnn.com] which shows as [13] instead of [1]) Dori | Talk13:15, 22 May 2004 (UTC)[reply]
There's a class 'plainlinks' now that switches the external link rendering off. You can apply it to a table cell or a div for example. -- Gwicke14:12, 22 May 2004 (UTC)[reply]
I still think it'd be better off to turn them off by default. How do you do what you are saying? What about inline links? Dori | Talk15:15, 22 May 2004 (UTC)[reply]
I agree, I think that the new icon is ugly and should be removed by default. I know I can change it in my personalized skin with a stylesheet and all that jazz, but in terms of usability for newbs and whatnot I think it should be turned off ASAP and that we should return to the colour sytem of differentiating between links. -24.80.6.122 06:12, 1 Jun 2004 (UTC)
Yes, please remove these icons. Having no little confusing icons was one of MediaWiki's advantages over other wiki systems. 82.224.69.16111:53, 25 May 2004 (UTC)[reply]
Please remove the icons by default. They serve no purpose that the muted link color didn't serve before. Now that link color is the default color for internal links! That needs to change because it is hard to read. I'm wondering what the point of useability testing is if the developers don't listen to the users. --mav01:33, 30 May 2004 (UTC)[reply]
"plainlinks" doesn't appear to work, in either IE 6 or Opera 7.5. I was able to make it work by adding:
#bodyContent .plainlinks a {
background: none !important;
padding: 0;
}
...to my monobook.css (the default style doesn't have the !important in it) — 67.165.216.144 20:53, 5 Jun 2004 (UTC)
Thanks for this, i've added the !important to main.css. The icon isn't shown for interwiki links anymore as well, this has made it appear much less often. Some 'other languages' templates use full url links still, please use something like :prefix: instead if you don't want the icon to show up there. -- Gwicke 01:18, 14 Jun 2004 (UTC)
The showing of URLs in parentheses makes reading ugly and disrupts formatting in non-CSS browsers. It's a really bad idea. Users who want to see the URLs can look on their status bars the way they do for all the other web sites on the Internet. Please disable the showing of URLs in parentheses. — 64.110.205.11317:35, 30 May 2004 (UTC)[reply]
I agree with 64.110.205.113. The whole point of a link is to let the computer deal with the big ugly URL, so that the reader need only view appropriate and relevant wording. I thought this point had been settled long ago, back when html was first developed. Opus3316:04, 31 May 2004 (UTC)[reply]
I agree as well, those urls can be added by css in the print view (see the commented out rule in MonoBook's print stylesheet). Afaik IE and some other older browsers don't support this though. A workaround for IE might be possible using js, haven't tried it though. -- Gwicke 01:18, 14 Jun 2004 (UTC)
Links are hard to see
Comment withdrawn. My monitor settings were to blame.
No I have to agree that the links are difficult to see. I keep my monitor's contrast and brightness low because white pages are too intense for my eyes. Thus, the links look almost black. Could somebody please make the links a lighter blue and bold ? Otherwise, I very much like the new layout, arrangement, section editing links, etc.
As for the links that are hard to be seen.
I remember from the Opera7.5beta diskussions that colorblind people got difficulties to see red color or distinguish it from black. So in Opera 7.5 unread messages in the MUA are no longer red but blue. Since in the wikis blue links are for existing articles, could we find a color for wanted articles links that is other then red?
It appears than internal links in wikipedia are no longer underlined. But it looks clear from this vote that more than 2/3s of users want the links underlined.
No, 2/3 want underlined or browser default (i.e., use the browser setting). There is no excuse for any web page to force underlining on people who do not need or wish it. Underlining was added to browsers in 1994 for the benefit of people without color screens. For everyone else, underlining is a distraction. Quota
Under my preferences I have selected Underline Links, but this setting now seems not to do anything. The wiki looks the same whether it is turned on or off. --HappyDog 00:41, 4 Jun 2004 (UTC)
I'm having the same experience. I don't want underlined links. I have them turned off in my Wikipedia preferences and my browser. Any yet all Wikipedia links are now underlined. 216.194.229.187 16:09, 4 Jun 2004 (UTC)
The system wide Monobook.css now underlines links. I believe the initial issue about the underline links preference not being honored is a MediaWiki 1.3 bug. As a workaround, you could modify your personal monobook.css and add a line like:
a { text-decoration: none }
I haven't tried it but what they have now done in the system monobook.css I had done to my personal one several days ago. RedWolf 21:25, 4 Jun 2004 (UTC)
Links are too hard to distinguish
The new layout is great, but I've noticed that on many display screens (LCD and CRT alike) the hyperlink colour is difficult to distinguish from regular text. I strongly recommend that it be changed (preferably to a deeper or bolder blue), as this is a significant usability problem. -- 195.92.67.75 00:37, 3 Jun 2004 (UTC)
Internal links with umlauts
Internal links to headlines containing umlauts do not work anymore. Please see the internal links in the beginning of this article. They worked prior to the switch to 1.3, but now they don't. I suppose the umlauts are responsible for the malfunction. -- Baldhur 15:07, 3 Jun 2004 (UTC)
I think this has to do with the german wikipedia not being UTF-8 (see PI bug elsewhere on this page). Dori | Talk 16:46, 8 Jun 2004 (UTC)
This is related to the bug fix for invalid and only partly supported characters in section anchor names. Please use the section anchor generated in the toc or just before the headline in question (urlencoded + '%' replaced with '.'). I've changed your example page already. -- Gwicke 01:06, 14 Jun 2004 (UTC)
URIs in XML snippets being turned into links automatically
Namespace URIs in XML snippets posted in preformatted blocks are being turned into live links. For example, see Wikipedia:Simple_Object_Access_Protocol, or the following:
In the above example the schemas.example.com URL is actually an arbitrary namespace URI and should not be assumed to produce anything meaningful when fetched via HTTP.
I think this behaviour may have existed before, but the new stylesheet's inclusion of the icon after external links has made it an actual problem by inserting extraneous and unwanted elements in the middle of the XML examples.
I'm not aware of any way for authors to configure the XML snippet text to disable this behaviour, but if there already is such a feature then my apologies and please disregard this.
It would appear that self-links (i.e. links to the article in which they appear), which usually create a bold version of the text without a link, do not work within <code> blocks. For example:
You might expect "MediaWiki 1.3 comments and bug reports" to appear in bold text, given that this appears as a link.
If I use <pre> instead:
You might expect "[[MediaWiki 1.3 comments and bug reports]]" to appear in bold text,
given that [[User:PhilBoswell|this]] appears as a link.
you can see what I entered.
--Phil | Talk 15:09, 12 Jul 2004 (UTC)
Indirect selflinks
Please extend the bolding of selflinks to links to redirects back to the page.--Patrick 10:24, 17 Aug 2004 (UTC)
links with fragment broken
Links with fragment with non-ASCIIunsafe characters (safe characters for fragment are [A-Za-z-_:/] in XHTML) such as [[#道具箱]] can't jump. It must be rendered as <a href="#.E9.81.93.E5.85.B7.E7.AE.B1">#道具箱</a> I think, but currently "%" is used instead of ".". (In TOC, correct fragment is used.) --Tietew 10:30, 9 Jun 2004 (UTC)
I had, I think, a similar problem. I was trying to link to MediaWiki User's Guide: Setting preferences section "7 E-mail, search, etc." from cs: Wiki. The section has anchor "#E-mail.2C_search.2C_etc." However, when I typed [[:meta:MediaWiki User's Guide: Setting_preferences#E-mail.2C_search.2C_etc.]] I got meta:MediaWiki User's Guide: Setting preferences#E-mail.2C_search.2C_etc. - here it doesn't work at all, but see a copy at cs:Wikipedie:Pískoviště#For_my_meta_bugreport. You can see, both there and at that link, that the anchor is repeated twice, which apparently shouldn't happen. Strangely enough the link seems to work nevertheless now, it can even be renamed - am I loony or what? I would swear that back then it didn't; I tried to copy the whole URL and of course it ended up broken at the apostrophe: http://meta.wikipedia.org/wiki/MediaWiki_User's_Guide:_Setting_preferences#E-mail.2C_search.2C_etc. I guess I could make it work by finding the offending apostrophe's ASCII code but it seems a bit much to ask from a humble user especially since it was Wiki itself which used the apostrophe in the article's name.
Also, can somebody explain me how come that both the section en:Wikipedia:How to edit#Links.2C_URLs.2C_images and its Czech counterpart cs:Wikipedie:Jak_editovat_stránku#Odkazy_a_obr.C3.A1zky where a HTML-tags table comes just after a section heading have these separated by a period within paragraph tags (it is visible at the page especially when you mark the region with the mouse, or see the HTML source code) when there is none within the wiki source, and there are other sections just like them that don't have anything such? I thought it might have been some forgotten and invisible CR/LF/eol character, as happens sometimes, but apparently not.
I posted a pache to fix this problem to [14] so please commit it! --Suisui 16:18, 15 Jun 2004 (UTC)
Comments related to navigation - disappeared links, etc.
Cancel link doesn't work
While somepage edit and stop it, clik cancel link under eidt bos. but it does not work at page wich page named UTF-8 code. The link looks like UTF-8 encoded someting bur wrong --Suisui15:50, 29 May 2004 (UTC)[reply]
No edit link at top of page
There's no edit link at the top of the page. To edit an opening paragraph, it seems necessary to edit the entire page. Lupin08:44, 30 May 2004 (UTC)[reply]
Something's apparently broken in the tabs at the top of the page. Or someone's experimenting like crazy and driving me nuts. Hmmm, I see now that the leftmost tab says "article". It didn't say that earlier and it took me a couple of hours to finally figure to click on "about", which is what it said this afternoon, and at some point it also said "module" and I think I remember it saying something else. Why on earth would it ever be anything other than "article"? I went through all kinds of contortions trying to figure out how to get back to the article from the talk page, the history page, the comparision page, etc. My initial solutions were to go to the history page and click on the latest date or to type the title in the search box. Please leave it at "article"! Elf 01:32, 3 Jun 2004 (UTC)
I just recently noticed that although the old template had a link at the top to a "Printer-Freindly Version", the current one doesn't have it. Is there a way to put this back in? --Fern 08:58, 9 Jun 2004 (UTC)
It's no longer needed; now, when you print, the printer-friendly version is automatically sent to your printer. 68.1.106.199 01:44, 10 Jun 2004 (UTC)
Comments related to preview
Preview when adding images links a bit skew-wif
Like the new skin, just a comment that I found that the preview page was somewhat corrupt when I was adding some images to articles in Wikipedia (e.g. Anthony Caro). It might have been due to me missuing the new image link syntax, although the saved page looks fine. Solipsist12:54, 30 May 2004 (UTC)[reply]
I should have mentioned the nature of the preview problem, which were:
Font size increased
Elements from top menus overlaying the page
The actual image is shown as a dead link replace by the image caption
with monobook skin, push prevew button then shows blanks more than 1 pages blow GFDL mark --Suisui 09:53, 1 Jun 2004 (UTC)
Can we have a bigger red font saying "Remember this is only a preview..."
I am now used to watching for the warning, but as a very new user it was easy to miss this warning and I'm sure I forgot to save a few edits I was working on. Even though the warning is red, a much bigger font would keep it from blending in like it does now, for me anyway.
Comments related to image display
Blue frame around images in cologne blue style
In the german wikipedia, images have a blue frame around themselves in the cologne blue skin.
Occurs occasionally on various 'pedias (I've seen it on en, sv and meta) in standard skin. Ususally disappears after a reload or two... \Mikez 12:21, 13 Jun 2004 (UTC)
right aligned images have an white opaque background
Bug on "de" main page
Simple resized and right aligned images become an ugly opaque white background.
On the german main page, these imagese are in front of colored div-containers.
it seems to me, that many div-containers not inherit the background colors
from the parent div-containers and so these div-containers are opaque white. Malteser06:48, 30 May 2004 (UTC)[reply]
Yes I noticed that too and it bothered the hell out of me. I found the cause; someone for some reason, in the css, set there to be a white border around floatright and floatleft images.
But there is a fix! All you have to do is put the following code into your monobook.css file on your user namespace:
The difference: no float on the image (no thumb, left or right argument). -- Gwicke 16:35, 1 Jun 2004 (UTC)
Ok, that's a per user workaround, but not a real bugfix. using an opaque border to avoid displaying a separator bar (i.e. hr) is an conceptual problem. on many pages/articles there are now ugly white and unaligned/unsymmetric borders displayed. the other probleme is the size of the border which replaces the functionality of the attribute margin an/or padding. you should prefer to hide these hr bars (or set z-index to -100000) instead to corrupt the layout. please fix the bug quickly.
Pictures on main page
Why are the pictures on the main page smaller than boxes diplayed around them and not centered in them? Rmhermen 03:48, 1 Jun 2004 (UTC)
ah, thanks for the css font change! hooray.
and whoever re-added the "from wikipedia, the free encyclopedia" message- thanks as well.
Blankfaze 17:37, 1 Jun 2004 (UTC)
Hey, kids, I've got this bug... dunno if anyone else has encountered it...
It's weird. Occasionally (it seems to be random) some random black mess shows up under the Wikipedia logo. It doesn't bother me that much or anything, I just figured I'd report it. Blankfaze 18:00, 1 Jun 2004 (UTC)
I also usually get this on en.wikipedia in Firefox v0.8 since the upgrade, but not in IE v6.0-SP1. --Zigger 16:45, 2004 Jun 3 (UTC)
that seems to have to do wiht your moving of the personal bar. I guess it has a heading which is cut off. --WikiWichtel 21:20, 5 Jun 2004 (UTC)
Image margin, caption problems
Take a look at the image for en:Versine — the margins around the image are way to big, and the caption has a mysterious linebreak inserted between the second and third lines. (I'm using Mozilla 1.6/MacOSX.) 18.19.0.12321:32, 31 May 2004 (UTC)[reply]
Page saved with workaround. See summary at /Break test. --Brion VIBBER 02:01, 1 Jun 2004 (UTC)
Thanks, that works around the linebreak problem, but the margins around the image are still problematic. 18.19.0.123 04:53, 1 Jun 2004 (UTC)
Looks ok to me
Looks fine to me. Can you post a screenshot of it? --Brion VIBBER 00:47, 2 Jun 2004 (UTC)
I've put a screenshot at [16]. 18.19.0.123 02:05, 3 Jun 2004 (UTC)
I've made another edit, check again and see if there are any problems. Dori | Talk 16:40, 8 Jun 2004 (UTC)
Separate captions and alt text
Alternate text serves to describe an image for those who don't see it [17]. The caption serves to tie the image together with the article [18]. Sometimes those two are the same, but more often they should be different. Perhaps the image syntax could be modified to allow separate specification of the alternate text and the caption like this: [[Image:picture.jpg|framed|alt=a fantastic picture|A suitable picture enriches the article.]] -- Ke4roh 12:55, 26 Aug 2004 (UTC)
It may be possible to avoid alternate text and caption conflicts by the simple expedient of coding all captions as tables. (This is how the Wikipedia Roche limit article codes it's captions.) Is there anything special about a caption that distinguishes it from any other sort of layout? This would still require a change to MediaWiki, alternate text would then not display below the image as a caption. And I still think it a good idea that there be default alternate text that's stored with each image, so that alternate text need not be entered each time an image is placed on an article. (Perhaps the alternate text, being a description of the image, should not be allowed to vary between articles.) Likewise, it seems a good idea to store title text (popup on mouseover) with the image, at least as a default.
So:
* 1) Is it a good idea to code captions in tables?
* 2) Should default alternate text be stored with the image on the image's page?
* 3) Should alternate text be allowed to vary from article to article?
* 4) Should default title (popup) text be stored with the image on the image's page?
* 5) Should title (popup) text be allowed to vary from article to article?
The only problem I see with this is that it makes any sort of automatic review of captions, for consistency across the wiki, impossible. (And that many captions in Wikipedia are not coded this way, but backwards compatability looks to be a problem no matter what.) Are there CSS or 'skin' issues? Probably.... -- kop 18:21, 5 Sep 2004 (UTC)
Comments related to text
Headlines are not interpreted
Headlines without a following new line or image-tag are not interpreted and display as equals sign; i.e. =headline=. you can show up this bug (see history of the main page of german wikipedia).
images (not thumbs) have a white background with mono (the margin and/or padding area have a background color of white). the same occurs fpr different div-containers - they doesn't inherit the style of the parent container. see de.wikipedia.org
HTML table indentation mistaken for wikimarkup (pre), causing big gaps
This bug probably existed before, but monoBook skin makes it obvious, because it puts a box around each PRE section.
Given a poem spaced like this
This poem is a test.
This poem is only a test.
If this poem had multiple stanzas
perhaps it would look like this.
Putting spaces on the blank lines does not join the PRE sections to make one box for the whole poem, as it probably should For those not using monobook, I snipped this Image:Poem-bug.png. --Ssd 06:35, 10 Jun 2004 (UTC)
It's probably not a good idea to be using <pre> for poetry (pre is ugly, use : indents unless unavoidable), but however the issue is pertinent with formatting code with multiple functions: it will appear disjointed as shown in the image. Dysprosia
Ugh, using : (dl!) for formatting is worse than using the space (pre).
Pretend this is a limerick
although my sillybles are wrong
but this line is short
and so is this
but it's all spaced very wrong
and the spacing between stanzas is smaller than breaks within a stanza
In short, the : formatting is fine for discussions, but worthless for poetry or code. Any other suggestions? --Ssd 06:23, 13 Jun 2004 (UTC)
Using spaces followed by   is a hack that achieves your (original) goal.
That hack works well for Monobook, but it messes up Standard by adding yet another blank line. The real solution is for Monobook and Standard to have the same line-breaking spacing. Anything else screws up one or the other of these popular skins. The people messing with these system-wide styles are forgetting that Wikipedia is primarily about content, not looks. The more we have to hack content to improve appearances (especially for mutually-antagonistic subgroups), the more unmanageable Wikidom will become. -- Jeff Q 18:47, 15 Jun 2004 (UTC)
Perhaps wiki needs a markup symbol for indented text such as code and poems, separate from the pre formatting and colon formatting? --Ssd 00:46, 16 Jun 2004 (UTC)
span tag
span tags are not recognized like this.
To specify language (lang="foo"), styles (style="color: foo"), direction (dir="foo"), etc. in-line, we've used font or other elements instead of span. But font element is obsoleted at HTML 4.01 strict/XHTML 1.0 strict/XHTML 1.1, which says span must be used. Using other elements is not logical markup in most case.
I request to enable span. Tietew 03:36, 12 Jun 2004 (UTC)
I just noticed that when a user created a page with "!?" in title, the system somehow could not handle it properly. When I clicked a link, I end up arriving at a wrong page, with the title cut off at "!."
Example: ja:特別:Newpages, the page created at 14:41 2004.5.30. by Daimaru and another one at 14:40 2004.5.30. by Daimaru both include !?.
This has been fixed for internal links and regular external/interwiki links. The bounce redirect when given an interwiki (such as the above link) still doesn't work. --Brion VIBBER 02:19, 1 Jun 2004 (UTC)
alien diacritic characters in titles
Some newbie user recently created en:FK Sarajevo and linked a bunch of people's names from there:
Now, it's common practice to write these names without the non-English diacritics so that problems with character sets are avoided. That is, the article names should be:
Vahedin Musemic
Safet Susic
Asim Ferhatovic
Previously I was able to fix this. Since the new version of wiki software was introduced, I can't -- the move page says "Error: could not submit form" and "This action cannot be performed on this page.". The software apparently needs help when it comes to sanitizing its input. Someone please help. --Shallot16:41, 30 May 2004 (UTC)[reply]
pi becomes ugly html
From en.Villagepump:
Pi
What's up at article π ? When did the title start displaying as π ? - Bevo 20:27, 4 Jun 2004 (UTC)
lame indeed! blankfaze | •• 00:03, 5 Jun 2004 (UTC)
Seems like an error somewhere not correctly converting internal database code to HTML? -- Tillwe 19:33, 5 Jun 2004 (UTC)
I think I heard that tidy was being used, perhaps it's trying to do more than it should. Dori | Talk 20:21, 5 Jun 2004 (UTC)
I asked on IRC and Brion says that we'd need to move to UTF-8 to fix this. Apparently a bug in 1.2 allowed this sort of thing to work before, and now the bug has been fixed :) Dori | Talk 02:30, 6 Jun 2004 (UTC)
Symbols (inc. non-Latinate alphabet) in article titles
Articles which have symbols in the article title do not present it properly. An example is en:π (en:pi) - the article title is displayed not as "π" as intended, but as "π"
The page title for the screen confirming a successful login has the word "preview" in it. I assume this is a hangover from some development phase and should now be removed. If not, what is it previewing?? :) --138.37.199.146 07:28, 14 Jun 2004 (UTC)
Comments related to Preferences
Preferences
Special:Preferences has a group called "Date format". This includes only the time setting though.
Not sure what was the default setting for preview, but I prefer it to be before the edit box .. afterall, when previewing, one wants to see the preview.
"Textboxes dimensions" could be called "Editing screen". -- User:Docu
With the Monobook skin, "floating left" is identical to "fixed left" in Safari. I'm not sure if this is supposed to happen, but I prefer "floating left", that's all... w:en:kelvSYC
Yeah, and a few others as well. The idea is to move most prefs to generated js/css for 1.4, but that's not yet done. You can do the same (and much more of course) in your user stylesheet. -- Gwicke21:25, 23 May 2004 (UTC)[reply]
The fixed sidebar didn't work in 1.2 for any skin but standard as well. Imo some of those prefs should be removed- the other skins don't link to user stylesheets yet, but that's not hard to add. We've been working hard on all these things for a long time, and this is how far we got. You can speed things up by writing those things and sending a patch or- if you have the money to do so- by setting up a bounty for some feature to be implemented. -- Gwicke22:16, 23 May 2004 (UTC)[reply]
You can implement a workaround by adding the following line to your monobook.css:
I'm having a problem where I can't turn off the underlined text in links. Is this a known bug? Seems to be the opposite of the reported bug 128.12.82.72 05:19, 4 Jun 2004 (UTC)
Same to me, using standard monobook, MSIE 6. It looks awfully crowded, all these links. Can't believe that would become the default.Erik Zachte 11:46, 4 Jun 2004 (UTC)
Seems to now be always on using the MonoBook skins in en.wikipedia and always off in meta.wikipedia, regardless of user's Wikipedia preferences. En currently has a customised default css to force it on, see en:MediaWiki:Monobook.css. --Zigger 06:27, 2004 Jun 6 (UTC)
I implemented the prefs, the underline option works now. The default for new users is still underlined, a new vote might be a good idea sooner or later. Also setting this pref per-skin would make sense as many people prefer underlined in the old skin but non-underlined in MonoBook. -- Gwicke 16:38, 9 Jun 2004 (UTC)
Cumbersome preferences
The new style of the preferences page is horrid. It's awkward to have different groups of settings on different pages. What is the point of requiring the user to select the group of settings they want to change? It is completely unnecessary. We have seen that the settings can all fit on a single page in a convenient way. --Eequor22:46, 28 May 2004 (UTC)[reply]
Additionally, if you save your preferences you are taken back to the User Data group, instead of the one you were working on. --HappyDog 00:48, 4 Jun 2004 (UTC)
Agreed. unnecessary and cumbersome. It took me a long minute to figure out how to set the "watch pages I edit" preference, since it's under "textbox dimensions", something seemingly unrelated to one's watchlist. The prefs divisions on en: (apparently also running 1.3.0beta3) are better-named. +sj+ 10:23, 24 Jun 2004 (UTC)
Skin problem when first changing settings
I changed a setting in my preferences (underline links) and when I saved it, it jumped back to using the old skin. I then had to go to skins and specify MonoBook. This was particularly confusing, as I assumed that 'standard skin' was the default! -- HappyDog 00:47, 4 Jun 2004 (UTC)
Saving preferences automatically changes skin to Standard
Note that there is a "Skin" preference with radio buttons, none of which is set.
Now go to the bottom and click on "Save Preferences", without changing any setting.
The skin will suddenly be Standard instead of MonoBook.
Mysterious new preference MySkin
What does the "MySkin" preference do?
Given all the fuss about the Monobook skin I thought I'd better check it out before trying,
but I can't find any reference anywhere.
--Phil | Talk 12:00, 10 Jun 2004 (UTC)
That's a blank skin for your own css adventures- all css is pulled from your user stylesheet (myskin.css), no monobook styles are applied. See http://www.csszengarden.com/ for some examples (and templates...) of what's possible. I'm looking forward to see really different css skins developed this way, i'm sure there will be more skins to choose from soon ;-) -- Gwicke 16:44, 10 Jun 2004 (UTC)
Cache problems
Before 1.3, this never happened to me. Now, it happens fairly commonly. I'll edit an article and save it. When the page reloads, it's exactly the same page as before the edit - IE, a cached version. I'll edit it again, see the changes in the wiki text, but the article displays without changes (even if I hard-refresh it). I asked, and I'm not the only one who has exprienced this. Raul654 06:01, 8 Jun 2004 (UTC)
I haven't seen that either, but I think I'd prefer it to getting the database errors I've gotten in the last week. However, I have seen other users complain about things that sounded like cache problems not in their browser, specificly in reference to categories not changing. Can't find the reference in a hurry, let me know if you want me to dig. --Ssd 06:45, 10 Jun 2004 (UTC)
Yes, I know firsthand that this happens a lot with categories as well. Raul654 18:45, 10 Jun 2004 (UTC)
Book background
I don't like the new background used on all the wikis. First of all, where did it come from? As far as I know, this could be a copyvio on every single one of the wiki pages.
The other problem is that wiki is not paper. The book pictured in the background has a beginning and an end. Wikis have no beginning, and they have no end. And they are not made out of paper. Guanaco03:00, 30 May 2004 (UTC)[reply]
Not too concerned about the paper comparison but the image is very poor quality (being a JPEG). Its covered in lots of visible artifacts. The image needs to be a lot cleaner. ed_g2s21:27, 30 May 2004 (UTC)[reply]
Have to say I quite like it. It's the first thing that caught my eye with the new skin. Denni 01:08, 1 Jun 2004 (UTC)
I thought it was a vortex or a flower until I read this section and looked for an empty article to see more of the image. I found the link to the image here. I agree about the quality - it looks like something was spilt. I don't mind the concept of an open book. --Zigger 16:59, 2004 Jun 3 (UTC)
The main reason is image size- the current image is only 34kb 1941x453px- a necessary image size to cater for large/high res screens. -- Gwicke 23:38, 13 Jun 2004 (UTC)
I have never liked those flowering lines in the background. And now that I know what they really are, I hate them even more. Wikipedia is NOT a book! Wiki works in a completely different concept than a book. Let's stay current here. I am reminded of that short-lived era of the Web (early 90s) when people started making their webpages look like three ring notebooks or yellow-lined legal pad paper. Can we please find something more appropriate than an "open book". Man of La Mancha, this is hideous. Kingturtle 19:26, 5 Jun 2004 (UTC)
The body has a namespace-specific class now- you can do something like .ns-0 { background: Red } to get a clearly marked main namespace for example. -- Gwicke14:12, 22 May 2004 (UTC)[reply]
Cool - Now that it is possible to change it we can start to think about which color to use. A light blue or a light gray may work with the new skin but I could also like to try the old pale yellow as well. --mav22:14, 22 May 2004 (UTC)[reply]
I vote for lite yellowish, out of tradition (maybe only the "book", not the white background). -- User:Tillwe
Yeah, but you don't understand me -- I want lite yellowish in the monobook skin -- for everyone who isn't setting it to white in their personalized css. And I hope Mav does want it for all, too. -- 80.131.235.22811:06, 26 May 2004 (UTC)[reply]
Yes - I agree that light yellow (or at least something other than white), should be the default fill for non-article/module/content/entry pages. Otherwise the only visible difference between Sandbox:Daniel Mayer and Meta:Sandbox is a tiny bit of text for the page tab. This will only cause a proliferation of talk pages, project pages and user pages in the article/module/content/entry/main namespace. --mav01:09, 27 May 2004 (UTC)[reply]
Hmmm. I say the "book" background should stay the same but... this area should be the good old vanilla color.--Patrick Mannion 16:35, 2 Jun 2004 (UTC)
Gwicke - we are talking about the defaults. I also tried your .ns-0 { background: Red } thing and it didn't work. --mav01:39, 30 May 2004 (UTC)[reply]
One problem is the semi-colon, .ns-0 { background: Red; } is better. The other is the namespcae-class: for example, User talk is ns-3, and My Watchlist is ns--1 (visible in the HTML source for the page you're interested in, as <body class="ns--1">. Each of these seems to need a special color code (documentation anywhere?) -- Tillwe15:06, 30 May 2004 (UTC)[reply]
I like the new skin, but there are several problems with it as noted all over this page - perhaps it would have been better to deploy it only to users who chose to help work it out before unleashing it on everyone as the default skin? I don't personally have a problem with some interface bugs, but I think if first-time users were to happen by around now certain portions of the side might come off looking very amateurish and reflect poorly on the site overall. -24.80.6.122 06:12, 1 Jun 2004 (UTC)
The user image is the only picture in a line and text interface. It also doesn't do anything, which would only be acceptable for text. Also, since a users can be expected to know their own user name, adding an element to say "this is the username" is of very limited use.
The tabs are a nice idea, even though they are not real, but they shouldn't float: There should not be space between the bottom of the other tabs and the top of the virtual page.
Yellow doesn't fit the scheme and using it to indicate the active tab doesn't work. That is, of course, already indicated by the tab-shape, but often one sees that the active tabs are slightly(!) larger and in slightly(!) stronger text, to give the impression they are nearer to the reader.
Do we need that mysterious +-tab, or is there room for a comment-tab??
Search is a form of navigation. Also, its style here is different from all other elements, and it doesn't mix well. Don't go babushka: boxes inside boxes.
The three box names "navigation", "search", and "toolbox" do not match well, grammar-wise. Their function is also not clear and their layout black, no captial, matches that.
The virtual page runs out of sight to the right, urging you to slide a non-existent slider.
Try a reload, i've removed the full-width footer for IE6 and 5.5 in favour of more solid scrolling behaviour. -- Gwicke23:52, 22 May 2004 (UTC)[reply]
Thanks, but no, it's not the actual page that runs out of sight, it's the virtual one, the one that has those tabs at its top. Its left edge can be seen just to the right of column one, but there's no right edge. On Test: I solved this with some border or margin setting, but at the moment I can't access it to check. Aliter18:22, 25 May 2004 (UTC)[reply]
The real bottom is a bit underused, which will probably fill up later, and is dominated by the "powered by"-graphic, which is not very readable and not centered correctly.
The placement of the options at the bottom of the page are swimming; they should either be aligned differently, or some placehold element should be added. They also appear unbalanced: Is (just) one of them bold?
The footer is improving, here on meta, but it now has a combination of multiple items and centered text that doesn't combine well on smaller screens:
This page was last modified 12:32, 29 May 2004._space_Content is
available under GNU Free Documentation License._space_About
The InterWiki-markers break the flow of reading, and when in groups flood the text, especially in a row of language codes. It appears the colour was a much more silent indicator. On the other hand, for the (colour) blind it might have been too silent. Is there an alternative, or can this be made a preference setting?
Thanks for the note on customization, and I probably will do so in the future, but most of the notes above are about what everybody sees. We don;t want to force everybody into redesigning the entire skin, I presume. The problem here is that once you go graphical things can be wrong with much greater precision. Eg. now that the logo has turned up, it turns out it touches the upper and left edge, so it will need moving it one pixel down and to the right, and the boxes below it similarly are 1 pixel too far to the left. Speaking of which: Maybe the box-titles would do better if placed as is done on the preference page. Aliter15:57, 22 May 2004 (UTC)[reply]
Pixelwise layout that scales with the user's font size and screen size, is accessible, customizable, standards-compliant, works on a pda and all modern desktop browsers and is well cacheable is impossible. The new skin is entirely based on css, the idea is that many skins can be based on the same page structure (see http://csszengarden.com for some examples). If you'd like to do a cross-browser css skin- go ahead, i'm sure many users would like more choice. Once the dust has settled a small css competition might be a good idea. -- Gwicke23:52, 22 May 2004 (UTC)[reply]
the logo appears in front of the content (just following the comments and bugreports link from main page; ie 6). the sidebar navigation links temporarly appear in an ugly looking bold font. Malteser23:55, 22 May 2004 (UTC)[reply]
now the font is very small... is currently anybody playin' with the styles? btw. on the "upload file" page the font appears in the same ugly bold look... Malteser23:57, 22 May 2004 (UTC)[reply]
There was a parser bug as well that was triggered if the image was inside a list (indented using :). The image src stays on one line now, the nesting produced by mediawiki in that case is correct now. -- Gwicke17:24, 23 May 2004 (UTC)[reply]
For some reason a few (and only a few) pages, including this one, looks pretty ugly, and the problem with the logo is still there when using IE 5.1.7/Mac (see screenshot). Also, is the sidebar removed intentionally? Wolfram17:36, 24 May 2004 (UTC)[reply]
The compare button on for finding diffs between old revisions of a page is very ugly. ugliness in Safari shows how bad this looks in Safari (compare to the search button to the left). - Tobin Richard14:43, 23 May 2004 (UTC)[reply]
It's not just the diff button, and it shows weirdly on other platforms as well (i.e. some buttons are not styled). See for example the upload page. Dori | Talk14:50, 23 May 2004 (UTC)[reply]
Some browsers will mess up radio buttons and checkboxes if the 'input' element is styled (submit button is an input as well). This is the case at least for Opera, Safari, Konq and some Versions of IE. Moz works fine (and gets the propers styling for all inputs), but those buggy browsers don't get any border/colour styling for inputs in the main content area. I've tweaked size and padding of the history input a bit for all browsers, but borders are hard to support. -- Gwicke22:59, 24 May 2004 (UTC)[reply]
Bad look in Mozilla The images you have posted here look bad on Mozilla Firefox (also on Mozilla 1.6). Could that be fixed? --Megara18:09, 26 May 2004 (UTC)[reply]
The edit conflict merge page breaks pages (at least it did after I had an edit conflict with myself). Look at [21]. Perl14:01, 22 May 2004 (UTC)[reply]
Something weird happened to me as well on this page: [22]. Somehow a section got removed, and one got duplicated. Dori | Talk 06:15, 2 Jun 2004 (UTC)
This has happened on at least two other pages as well [23], [24]. Andris 04:02, 4 Jun 2004 (UTC)
Dori, let me guess. The section you were modifying got duplicated, and either the section before or after got lost. This happened to me here on this page, and it looked like someone added a new section above the one I was editing, so my edit replaced the section prior to the section I was editing (does that make sense?)-Rholton 06:48, 5 Jun 2004 (UTC)
I've updated the bug tracker with this new(?) variant. Whether or not it's being aggravated by the new code, this seems to be quite a serious bug - which will cause more damage whenever the wiki gets slower... - IMSoP 16:11, 16 Jun 2004 (UTC)
I have been on the receving end of this bug when Michael Snow made this edit. He told me that he was using section editing, and that the section he was editing was duplicated. He removed the duplicate, and my section was gone. – Foolip
General
Like layout a lot. Links you've been down before no long show different colour though. Also I may be able to change it somehow on my browser but the typeface is hard to see compared to the old one. Could we have the old typeface back? I always use WP on a laptop and in the garden it is almost impossible to read now.--AndrewCates06:32, 23 May 2004 (UTC)[reply]
There are two problems for MediaWiki 1.3, on other wikis, when I scroll down a page when I click on a middle part of the mouse button, it doesn't work, and second on ==THIS== and ===This===, it shows underline, so fix this problem, Pumpie 18:31, May 24, 2004 (UTC)
Likewise, the layout is an great improvement. But the font is killing me in my default load of Firefox on a WinXP machine. Some letters are thicker than the norm, others a re thinner. The word and has a normal, thin, and thick letter in sequence. A text seems to vibrate as a consquence. Looks okay in IE, do I have to download some new font for Mozilla Firefox? And where can I get it?
the editor toolbar (buttons) deviates from the rest of the new style (ugly windows buttons are even shown under aqua/os x). if you would use button-tags (html 4), you could use native system buttons combined with the images.
the "printable version" link is missing- should render links as plain text (undecorated) if re-integrated. the print preview looks nice, but another use is to save an article as plain html with images. now you must save the entire wikipedia page with side navigation and header. Another big advantage of the printable page is that it eases importing in OpenOffice (and I guess in MS Office too) a lot. So please re-enable that link.
is it possible (in the final release) to switch the locale in user settings? i. e. can a german user switch to a german ui in the english wikipedia?
and finally... a nice feature would be a possibility to remove a watched article from "my watchlist" (in the "my watchlist" view) Malteser 23:20, 21 May 2004 (CEST)
Kommentar Benutzer:rho Es gibt noch viele Leute, die mit einer alter Browsersoftware arbeiten, Die werden die getrennte Funktion Druckversion in Wikipedia vermissen. Außerdem ist es schwer, aus der dynamisch erzeugten Druckversion eine abgespeicherte Datei zu erzeugen. Auch dafür war die Druckversion gut brauchbar.
Das Entfernen der "printable version"-Funktion ist für mich eine echte Verschlimmbesserung. Ich persönlich habe diese Funktion permanent genutzt um Wikipedia-Seiten auf meiner Festplatte abzulegen, und zwar ohne unnötige frames und links die im offline-Betrieb eh keinen Sinn machen. Bringt also bitte die Wikipedia-"Druckversion" zurück -- please bring back the "printable version"-function!!! -- Maikel
Cursor
On Netscape 7.01 <Mozilla/5.0 (Windows; U; Win98; de-DE; rv:1.0.2) Gecko/20021120 Netscape/7.01>, the cursor in the main edit area sometimes appears not as a bold line, but as a bold line with a dot at the top. -- Tillwe22:53, 23 May 2004 (UTC)[reply]
The Search box doesn't seem to do anything at the moment (IE6), except call up the Google search without an empty query-string. Aliter21:45, 27 May 2004 (UTC)[reply]
The same on all wikis. The problem seems to be that $1 in the googlesearch message is empty, effecting both filling the go button and the filling of the google and yahoo serach boxes. TeunSpaans20:57, 28 May 2004 (UTC)[reply]
Search now has improved. It functions most of the time, but not always. It will still occasionally forget the search terms, but the problem is hard to pin down. Also, I can no longer see any functional difference between the Go and Search buttons, except maybe that Go appears to be slightly more likely to do a query without arguments. Aliter23:58, 28 May 2004 (UTC)[reply]
This was fixed by JeLuF. -- Gwicke 22:52, 13 Jun 2004 (UTC)
Ne plu funkcianta sablona mesago
La sablona mesago : w:eo:MediaWiki:ReVo nun sajne ne plu funkcias car ial (eble gi enkondukas spacon kiu malfunkciigas la ligon ). Ciel la konstruita [[ReVo:vort|vorto]] ne estas legata kiel ligo kontraue de kio antaue okazis . Vidu
tie
en:The template message : w:eo:MediaWiki:ReVo apparently doesn't work anymore because, for some reason (possibly it introduces a space which breaks the link). No matter which way it is written, the constructed [[ReVo:vorto|word]] is not read as a link as opposed to the old status quo. See here.
Some more opticalities (found while using de.wikipedia in new layout)
Empty tables create lot of whitespace.
The lack of color for system pages is a problem (see above)!
Sans-Serife looks cool, but if you start to use it, a serif font would make more sense (maybe there should be a monobook-serife alternative?)
The link colors are problematic: the standard blue links are almost indistinguishable from normal text, if you don't look really close, and a different blue for visited standard links is confusing.
It is already possible to have different default skins. Perhaps MonoBook was rolled out as a default for all Wikis in order to thoroughly debug it from the start, with maximum multilingual compatibility. Kwekubo22:32, 28 May 2004 (UTC)[reply]
Apparently it is, but is it worth bothering thousands of users with what should be done by a groups of beta testers? I'm going to advice the Wikipidae I'm on to revert to the previous standard until this one is out of beta. (And even then I'm not so sure about its looks.)Aliter13:00, 29 May 2004 (UTC)[reply]
In particular, there's a big problem with introducing huge changes without informing anybody prior to the introduction. --Eequor13:56, 29 May 2004 (UTC)[reply]
I agree. I feel the Monobook style makes poor use of the page space, is distracting in its use of color, and generally appears unprofessional. This is an encyclopedia, not a comic book. --Eequor22:38, 28 May 2004 (UTC)[reply]
Monobook also has some serious problems with contrast. In some cases there is too little contrast (for example, links), while in other cases there is too much (thin black lines against white on the main page). The variation in contrast is an eyesore. --Eequor23:05, 28 May 2004 (UTC)[reply]
The use of color in the recent changes page and the watchlist also suffers from inconsistency and poor coloring, apparently in all skins. Light grey on white is hard to read, as is pale blue. What does the light grey text mean, anyway? --Eequor23:13, 28 May 2004 (UTC)[reply]
The light gray text is displayed in an edit summary whenever you enclose some text in /* and */. This is typically used to tell others what section you've edited in particular. For a while now, MediaWikis have included this information as =Section title here= . – [[User:Mxn|Minh Nguye>?n (talk, blog)]] 15:23, 29 May 2004 (UTC)[reply]
Image description pages
The field "Image links. The following pages link to this image: " sometimes contains no page link to this image (when it's not the case). --tsca11:57, 29 May 2004 (UTC)[reply]
It looks like MonoBook skin is the default for people who haven't logged in (the vast majority?). MonoBook sometimes changes line breaks to paragraph breaks. Look at http://quote.wikipedia.org/wiki/Firefly#Serenity in both the MonoBook and Nostalgia skins, and note that the "Wash's Stegosaurus: Yes" line is incorrectly in a seperate paragraph from the "Wash, playing with" line when using MonoBook. This makes it looks like related lines of dialog are completely seperate quotes. Can someone change wikiquote back to the Nostalgia skin as soon as possible, and maybe put it back once MonoBook is fixed. Also, what is the situation with quote.wikipedia.org vs wikiquote.org ? - Jeandré, 2004-06-11t13:29z
Wikipedia redesign
Hey, it's really cool! A great improvement over the previous design. That said, I have a few suggestions that I think might improve on these changes.
The Wikipedia logo looks to be a transparent GIF antialiased against white. With the new background in shades of gray, there's some ugly fringing going on here. The logo needs to be redone against the new background or (ideally) changed to something that's not quite as ugly.
Why no margin on the sides and top of the page? Disconcerting.
Body text is rendered in Verdana, but headings appear to be in the browser's default sans-serif font; this should be corrected.
Not enough spacing between paragraphs, so body text is muddied. I would suggest either double-spacing paragraphs (as before) or adding a first line indent.
Bright red color for links to nonexistent articles is jarring and calls too much attention to phrases that don't deserve it--maybe a dark gray would be better?
I'm not sure if this is the appropriate place for comments, so I apologize in advance if this is out of place. I'd try to fix these problems myself if I knew how. Ideas?
I must say that, as a whole, I like the way the new version looks. However, I've come across a few things that didn't work quite right or look worse (in my opinion) than they did in the previous version. I'll post them here as I come across them:
I've seen that others have brought this up above, but I too dislike the external link arrow icon. I'll do some research into the user styles, but perhaps a poll is in order to see if those should be on by default.
I use two boilerplate templates to welcome new users. In them, while explaining signatures, I use nowiki tags to prevent tildes from being expanded. Now, when I use the subst method to paste the text into a talk page, I've noticed that the nowiki tags get pasted in but the tildes are still expanded, resulting in my signature appearing, but not wikified. Try {{subst:jrwm}} to see what I mean.
Update: I've submitted a bug report for the above problem and changed the templates to the HTML escape code for the tilde to avoid its conversion to my signature.
It seems like something (perhaps the external link icons) on 1.3 is creating a lot more white space than there was before on the top of the Recent Changes page. This is, of course, very minor, but I preferred the way the 1.2 version looked.
I'd prefer the Recent Changes link on the sidebar to be higher up, perhaps second on the list.
I've just noticed as I'm typing in this text box that, at the end of every line just before the text wraps, the left-right scrollbar is added for just a moment and then disappears again. I don't remember this happening before.
For some reason (probably the underlines being gone), I find that the new links (internal links, that is) seem to really blend into the rest of the text, and aren't as obvious as they were before.
About 75% of the time I make an edit, the browser indicates that the page is loading and then stops without the new page (with the new edit) being shown. Clicking on the link again confirms that the edit was made, but for some reason it isn't reloading properly. This could be a problem on my end, but I thought I'd put it here just in case.
For me, I realized I just wasn't waiting long enough. For some reason the browser indicated that the page was done loading, then it paused for anywhere from 2-10 seconds (I'm on dialup), and the page loaded. It sped up and now it's not really an issue here (IE 6), but maybe it is for others. I'll get rid of the strikethrough above. – Jrdioko(Talk)19:15, 30 May 2004 (UTC)[reply]
Maybe it's a different issue: with Netscape 7.0, as mentioned sometimes already somewhere in this document, some pages won't load at all, but show "loading" for hours (and as page content display only the [hide] of the TOC). -- Tillwe20:01, 31 May 2004 (UTC)[reply]
I'm not sure if this was the case before, but I just noticed that the en:Wikipedia:Recentchanges page has a "User Contributions" and "Email this User" link, evidently due to a user named "Recentchanges."
On a User contributions page, the visited link color overrides the non-existent article color. (i.e. I clicking on the username of a user without a user or talk page, then clicked on User contributions, and, on that page, the name of the user after the word "For" at the top of the page appeared violet instead of red.)
I've been paying more attention and it now seems that this is the case for all links (the visited color overrides the red indicating the article doesn't yet exist). I've submitted a SourceForge bug report.
It is inconvenient to have "My Watchlist" -- a function used very often by regulars -- put in the "my ..." something area which is quite inaccessible by GUI standards. I know, it is more logical -- but I use "my watchlist" as a tool for navigation. Why not put the whole personal area in the left tool bar? And maybe search back in the top? -- User:Tillwe
Email notification for changed pages (watch-listed pages and user_talk pages)
I am currently finalising my E-Mail Notification patch based on MediaWiki version 1.3.2. The patch which will be published soon.
--Nyxos 00:44, 31 Aug 2004 (UTC)
Here are interesting features to add to the watchlist eventually. Some features can be somewhat CPU intensive but others are super lightweight:
1) The number of characters and words added/changed/removed(red text when we click on diff) in the article could be displayed so that we can first concentrate on the more extensive edits.
2) Minor edits would be automatically detected and tagged as such in the watchlist. Off the top of my head, some of these minor edits could be:
adding double square brackets around a word
adding a link to another language
adding an external link
adding a double curly braces tag
maybe even typo corrections could be detected and tagged
3) Having the option to hide our own edits from the watchlist
I second this. IMO your own edits should be hidden by default. ··gracefool 13:36, 30 Jul 2004 (UTC)
4) Having the option to add all edits made by a specific user to our watchlist
Also, it would be really interesting to be able to rate each edit surveyed and so keep track of the quality of the work of others. This rating could be an integer, and the average would be computed and displayed. This information would be private by default but could also be made public. The fact that an edit is rated or not would allow us to keep track of what we read. How about writing comments attached to a specific edit instead of bloating the talk page? O.K. I have to stop :) Delta G 17:29, 7 Jul 2004 (UTC)
color of background
In the standard skin, the background is like a pale salmon color. That makes reading much easier on the eyes. In the new skin, the background is white, and makes reading more difficult. Please put the light pale salmony color into the background of the new skin. thanks, Kingturtle21:53, 29 May 2004 (UTC)[reply]
That's such a subtle difference, but you're absolutely right. I couldn't quite place my finger on what was so strange about the coloring on Meta and in Monobook. Pure or saturated colors, especially white, are simply too intense and should almost never be used on web pages. It's poor graphic design. --Eequor00:57, 30 May 2004 (UTC)[reply]
Dah, now it's impossible to be certain what the coloring used to be. I seem to recall the background color stayed consistent between pages in 1.2. I've just noticed it varies between salmony and white. It's really subtle, but the salmon is kinder on the eyes. --Eequor01:28, 30 May 2004 (UTC)[reply]
Standard skin and autocomment
The coloring of edit summary autocomments is almost unreadable under the Standard skin.
It also appears that user css is unavailable for Standard (at least I can't get it to work), so it cannot be overridden. Not being able to override is a non-issue, because it shouldn't be unreadable by default. -- Cyrius22:17, 29 May 2004 (UTC)[reply]
Implemented it tonight, filenames are standard.css, nostalgia.css and cologneblue.css. Likewise with *.js. -- Gwicke 16:32, 9 Jun 2004 (UTC)
Agreed! Also, make the normal wikipedia logo in the left top move down a few pixels so that its incomplete pieces looks as if they could be fitted in. It looks wrong having it sooo close to the top of the page. --203.166.107.24300:12, 30 May 2004 (UTC)[reply]
Copying
Apparently this new version has a mechansim to make sure every copy is attributed correctly, eg, this one line below,
Yn Harns wurdt njonken Frysk en Nederlânsk? ek Stedsk sprutsen.
Foar it lêst bewurke op 15.05, 10 mar 2004. Ynhâld is beskikber ûnder de GNU Free Documentation License.
gets the additional three sentences above added. The group this targets apparently are the ignorant; those who might copy and forget to attribite. But the group most effected are of course the editors, moving bits and pieces between pages and always having to removed this stuff. In my opinion, too impractical to be useful; please remove. Aliter23:00, 29 May 2004 (UTC)[reply]
Localising images in footer
Is there any way for a language to use translated versions of the little images in the footer (the copyleft one and the "powered by" one)? Marnanel23:25, 29 May 2004 (UTC)[reply]
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.
class=urlexpansion wreaks havoc on non-css browsers
The new version seems to use a CSS trick to make printed versions show the external URL next to the link text, while hiding the URL when viewing from the screen. Non-CSS browsers of course don't understand this, and they show all the URLs next to the links.
A side effect of this is that the Wikipedia front page gets blown out of proportion: in the "sister projects" table, all the URLs to the sister projects are rendered next to each other, and their combined length determines the minimum width of the page. Earlier the Wikipedia front page rendered quite fine in my width 800 window, now it hardly fits into 1600.
I'm using Dillo, but I suspect that the issue is similar in all browsers that don't support CSS.
The url expansion could be done with a simple css snippet, but i'm not sure if this works in IE. It's already in the MonoBook print stylesheet, just deactivated currently. Might be possible to add the spans via IEFixes.js. -- Gwicke 12:53, 8 Jun 2004 (UTC)
Orphaned Page with parents?
The orphaned pages option, as mentioned above, does not always succeed. fy:Wiki:Lonelypages In those cases where it does, it now shows a page that isn't an orphan fy:Wikipedy:Gasteboek. If, in Standard skin, reached through this link it's displayed as a white article page. If reached through any other link, eg. from Fy:Haadside third link on the top line, it does show correctly as a yellow community page. Aliter12:45, 30 May 2004 (UTC)[reply]
This behaviour has changed. Now no orphan pages are show at all. And of course, it's only fair that now each and every image shows up as orphaned/unused. No idea whether it's 1.3-related, but I do hope it can be solved. Aliter 01:14, 21 Jun 2004 (UTC)
It appears the pages are no stable where reachabilit is concerned. The entry for Gasteboek has now appeared and disappeared and reappeared more than once, without discernable pattern. The images consistently all show as unused. Aliter 15:28, 13 Jul 2004 (UTC)
edit page
On meta, (netscape 7 - mac), quite often, when I am on a page, idle for a couple of minutes, the page suddently turns into the edit version. That happens to me 100% time after perhaps 15 seconds on "http://meta.wikipedia.org/wiki/Board_vote_interface_text" but also happened on other pages as well. Only on meta. I am in Nostalgia skin Anthere16:16, 30 May 2004 (UTC)[reply]
Now I have to scroll sideways - unacceptable
I had no trouble using my preferences to go back to my old skin, thank God. But now the main page and Village Pump etc no longer fit on the screen even with the 'standard' skin: I have to use a scroll bar simply to read the full width of the page. This will be enough to drive me away from the site if it can't be fixed. Perhaps this is the open source community's way of punishing me for using IE6 ;o) --Bodnotbod17:01, 30 May 2004 (UTC)[reply]
Can't reproduce. Both pages look fine in IE6 on Windows XP with tiny 896x600 screen. --Brion VIBBER 02:10, 1 Jun 2004 (UTC)
I can reproduce in firfox 0.8 and I agree that it's totally unacceptable. -24.80.6.122 06:12, 1 Jun 2004 (UTC)
Need "edit" page nav at bottom of the page
I have been using the MonoBook skin to see if I can find bugs (I test software for a living), and the one thing that's killing me is not having an edit button or link at the bottom of the page. Other issues I have with it include#
the reduction of nav links/buttons in general
cursor doesn't turn into hand over Save & Preview buttons
screen goobers under the top-left logo on many pages (they go away if I refresh)
hate the all lowercase words in the nav tabs and the left nav headings
the inconsistent nav wording (EG "edit" instead of "Edit this page") makes creating/maintaining documentation (EG the tutorial) a real pain. It's particularly a shame to loose Edit this page, which is more clear, and likely to be used by newcomers
assuming it's true, the choice of a font that is less compatible
forcing the more graphics- and javascript-intensive skin on the non-regs
ALT shortcuts disabling my keyboard menu interface (I think the default should be off)
the vague Namespace distinction
the automatic line under == level headers
the lack of the "printable version" link
the default to non-underlined links
green instead of blue links
the external link icon
going to the bother of hiding the Compare button when only two lines of history--K.I.S.S.
similar issues with sectioned Preferences and the hiding Compare radio buttons
changing software and default skin at the same time unwise
visiting non-existant articles changing color from red
I agree with needing edit button at bottom of page. Now I pretty much always have to scroll up to edit a pg, whereas before I was often at the bottom of an article when I was ready to start editing. Elf 01:21, 5 Jun 2004 (UTC)
Copyright Notice Needs Layout Change
This is using the 'standard' skin: the copyright notice on the page, ie:
This page was last modified 16:32, May 30, 2004. All text is available under the terms of the GNU Free Documentation License (see Copyrights for details).
--
Is not distinguished from the article text. As such I keep reading it as part of the article. If it were in italics or in a box I could learn to disregard it as part of the furniture, but the way things are now my eye just drifts onto it, which is vexing. Combined with my new pages which now have a horizontal scroll bar I'm finding things generally a lot less pleasant. --Bodnotbod17:33, 30 May 2004 (UTC)[reply]
It's on a box all of its own. It seems fine to me. Could you post a screenshot maybe? Dori | Talk 16:05, 8 Jun 2004 (UTC)
Kudos overall
I just wanted to let the developers know that, even though a lot of us are complaining, most of us, at least, many of us, like the new skin and all its upgrades.
Sure there's bugs, but this is a good step in the right direction.
Overall it's an improvement (although it was implemented a bit rashly!), however some stuff needs to be changed:
I really think the search function should go back up to the top, and that the "my watched" etc should go to the side, perhaps under 'toolbox'?
What do people think of the idea of making the toolbars on the left scross down with the page so that they are always visible. I realise it can look tacky and is usually used wiht advertising, but I think it could be useful, especially not having to go back to the top just to use the search box.
The sidebar is often too long for the window, so this is not feasible. --Brion VIBBER 02:06, 1 Jun 2004 (UTC)
There are numerous bugs in firefox which needs ironing out which I'm sure you know about, such as the autofill box for the search thing appearing over the wikipedia logo, and the copywrite information on the bottom going all the way across.
The 'printable version' really needs to come back, its very useful and necesary, I don't know why it would be taken out. Put it back next to edit or view source or whatever.
Print formatting is now handled by CSS, so if you use your browser's "print" command it will automatically remove the background, use nice printing fonts, use full URLs etc. 131.111.195.20220:05, 31 May 2004 (UTC)[reply]
Search Box Design
I want to raise an issue with the new main page design: the search box. Search from the main page is the most popular way to access content on WikiPedia, as far as I know. It is also the most intuitive: the first thing a new visitor needs and thinks of. And, as "#Don't forget the primary mission" reminds, it a primary aim of WikiPedia be easy to access, and this means easy to search. Therefore, the search box should be conspicuous on the main page:
It should be at the center top, under the welcome message. For consistency, it should be at the same place for content pages too. I realize that the search box fits nicely in the navigation column, but some browsers (such as W3m and Lynx) render the column at the bottom of the page. Perhaps there is a neat way to accommodate both considerations?
It should be one of the first links/controls, so that users who do not have a mouse can easily focus on it.
It should (probably) be labeled "Search" with large font. (This is debatable.)
It should have only one button, unless there is a good reason to have two buttons, which I don't yet know. Currently, there is a Go button and a Search button. As I understand, the Search button was intended to find all WP articles containining the search term, but I would argue that there is no need for this additional interface complexity. Instead, the search button can be presented to the user in the usual WP search page, only if no article matches the given search term. The administrators can tell us whether this extra match is currently greatly straining the servers, but I would guess that most users need match the article name before searching article text for their search term. I would also guess that few users would make use of the durect search function.
If there are two buttons, the distinction between them should be clear. "Search Article Names" and "Search Article Text" are a clearer alternative to "Go" and "Search". Also, tooltips can be used with the buttons.
The buttons should not be flat, because it is not visually obvious that they are buttons;
preferably they should be standard browser buttons.
The two boxes are definitely badly labelled. It is not at all clear what the difference between 'search' and 'go' is. If you take a random sample of sites with a search feature, half use one and half use the other - they are generally considered interchangeable. Either they need to be labelled better, or one of them needs to be removed. From my own point of view it is more intuitive to leave the search button, because I would expect to be taken to a set of search results to look through (and bear in mind that without it there is no way to get to the advanced search page if the search finds a match...). You could try renaming them 'Go To Article' (or 'View Article') and 'Search Site' - that'd solve it. --HappyDog 10:57, 4 Jun 2004 (UTC)
The search box in its new position (along the side) is hidden and obscured. The search box should be along the top, and made prominent. It needs to be easy to see. Kingturtle 19:35, 5 Jun 2004 (UTC)
Change default style to Standard during 1.3 shakeout
I would suggest that the Wiki administrators have committed a grave error in having MediaWiki 1.3 assume the new "Monobook" style instead of the old "Standard" style during this "gamma test" of the new software. There is an old engineering principle that changing too many variables at the same time can render test results indecipherable. This appears to be borne out by current events here. I don't see why it was necessary or desirable to test both the user interface styling AND the new software at the same time. It must be exceedingly difficult to determine whether problems come from the software, the styles, or some combination of these and other factors (like browser type and version).
Since the new software clearly must be tested, I urge admins for all Wikis to reset the default style immediately to "Standard". I also urge them to announce what they're doing, instead of making both newbie and regular users to wonder why the Wiki universe has become so unpredictable. Experts and adventurous types can easily continue their own test of the new style by changing their preference to Monobook, but why make the entire Wiki world suffer through these pains now? Shake out the software first, then you can impose a default-style change in a few months, once other fires have been put out. -- Jeff Q13:56, 31 May 2004 (UTC)[reply]
And you're here at a wiki? --Brion VIBBER 02:05, 1 Jun 2004 (UTC)
Brion, are you being sarcastic or serious? Wikipedia is not just a wiki. It is becoming a hugely valuable resource to the internet community -- just as is intended. We must always be sensitive to the user experience, especially of those who are non-techie, who do not contribute, or who is only interested in getting the answer they need at the moment. I think Jeff's suggestion is reasonable. If it's too late to implement it now, then we need to remember this for the future. -Rholton 21:32, 3 Jun 2004 (UTC)
It may be too late to change the 1.3 software to use Monobook as default (if that's what happened), but it shouldn't be too late for each Wiki to change the system default to Standard. -- Jeff Q 01:50, 11 Jun 2004 (UTC)
Plenty of people use Wikipedia strictly as a reference. they don't have accounts; they don't want accounts. They just want to access information. It is wrong for us to force them into experiencing our Beta-version. Kingturtle 19:30, 5 Jun 2004 (UTC)
Don't forget the primary mission
In all this discussion of changing skins, formatting, preferences, etc., I wonder whether we've forgotten the main mission here — to provide an easy to use hypertext encyclopedia for the (Internet-using) public, who are invited to make their own contributions. As such, it's absolutely essential that:
New users must be able to read pages and to find and use links without logging in or setting preferences.
Casual users must be able to find answers to basic questions about Wikipedia without major research.
Non-experts should not be so intimidated by the editing process that they never attempt an edit.
Any formatting or style issues that make these basic needs difficult should be considered unacceptable! Regular users can be expected to adapt to complicated processes, but making the simple things hard will merely turn Wikipedia into a small community of self-congratulatory experts.
"The general precept of any product is that simple things should be easy, and hard things should be possible." — Adam Bosworth
To the no-doubt harried folks presiding over the MediaWiki 1.3 update and all its contentious issues, I beg you never to forget for a moment this essential consideration while you are attempting to oil the squeaky wheels. -- Jeff Q13:12, 31 May 2004 (UTC)[reply]
Very well-said. I agree fully. Kingturtle 19:29, 5 Jun 2004 (UTC)
Long articles / left border
On Mozilla/5.0 (Windows; U; Win98; de-DE; rv:1.0.2) Gecko/20021120 Netscape/7.01, the left border of the content area for long articles (like this one) isn't shown completly; looks like an integer overflow in the border drawing engine of Mozilla? -- Tillwe20:12, 31 May 2004 (UTC)[reply]
Feature request: Easier user css configuration?
Is it possible to enable transclusion/templates for the User-css? That way, one could create a user CSS consisting of {{CSS:Rounded corners}} {{CSS:Old link colors}} {{CSS:Serifs}}, which would load template-namespace pages into the CSS. This would adapting user css styles easier (you don't have to know about css, you only have to write the specific transclusion name on your css page), and it would make the maintenance of css elements easier (if, e.g. there is an error in "Rounded corners" and this is fixed, every user css would be fixed at the same time, without the need for watching out and copying). Currently, this doesn't seem to work (see Talk:User styles -- Tillwe20:12, 31 May 2004 (UTC)[reply]
This would be dangerous, as it would be far too easy to make the site unusable for many visitors, or introduce JavaScript and URL loading injections which can be used to steal login cookies / sessions or exploit browser vulnerabilities. --Brion VIBBER 02:03, 1 Jun 2004 (UTC)
If you really trust somebody you can do something like
That imports that user's stylesheet into your one. This is safe if you don't use IE. -- Gwicke 09:28, 1 Jun 2004 (UTC)
Okay, if a simple replacement is unsafe, what about a CSS: namespace that is protected (i.e. editable only by admins), and make this the only namespace usable in css's? Or some other method of "packaging" user css styles into easy administrable modules? On the other hand: if it is unsafe to replace code in the user css, isn't the copy'n'paste method nearly as unsafe? Say, user X tells s/he has devloped a super css-js-extension on the village pump, a hundred people copy it into their user css, and minutes later everybody finds their sessions stolen? And another question: if I understand Gwicke right, something like:
seems to be possible even now. Sound's a lot like the feature request I was looking for, but also sounds pretty unsafe, isn't it`? -- Tillwe 20:08, 1 Jun 2004 (UTC)
All statistics are kaputt!
Usage stats died on the 21st May. Wikistats was last generated on Sunday May 23, 2004 from the SQL dump files of Saturday May 22, 2004. I'm sure you know. --Tagishsimon
The Wikisats is now back. :) But I am anxious to see the Webalizer stats.. Tomos 08:06, 16 Jun 2004 (UTC)
Save you changes
The yellow texty thingy should be "save your changes2 when you click on the save button - typo in code. 144.32.128.73 22:08, 1 Jun 2004 (UTC)
I think this is fixed in Language.php. -- Gwicke 11:37, 8 Jun 2004 (UTC)
Special:Makesysop
I am a bureaucrat at ja., and noticed that Special:Makesysop (ja:特別:Makesysop, to be exact,) does not have the checkbox it used to have. The check box is there to make someone a bureacurat and sysop, rather than just a sysop. So it seems that, for a while, we need a steward's help to create bureaucrats. Tomos 00:31, 2 Jun 2004 (UTC)
I checked this with Cologne Blue skin, and the result is the same. Tomos 08:16, 16 Jun 2004 (UTC)
Moved Pages drop off Watchlist
It used to be that if a Page on "My Watchlist" was moved, the new Page would be added to the watchlist automatically.
Now when a Page is moved, it is not.
This used to be a helpful tool which enabled one to spot when a page was moved in error (or in malice): please put it back.
I have also noticed a couple of pages appearing on my Watchlist which I never recall even viewing: maybe there's a connection?
--Phil 08:38, 2 Jun 2004 (UTC)
I agree that the watchlist should be automatically expanded to include the newly titled page as well as the old one (which becomes a redirect to the new one). That's what the old version did for a while. --Shallot 13:32, 20 Jun 2004 (UTC)
I agree as well. - Omegatron 14:46, 2 Sep 2004 (UTC)
Consecutive newlines should be coalesced
Currently, it seems that if you have more than one newline in a row:
...then the software translates this into multiple paragraphs. I can't remember if this was the old behavior, but I'm suddenly noticing lots of extraneous whitespace in articles due to newlines that crept into the edits. Can you emulate LaTeX behavior and treat consecutive newlines as one? (If people really want to force extra vertical whitespace, which should be rare, then they can use <br> tags or the like.) —Steven G. Johnson 01:46, 3 Jun 2004 (UTC)
Also, with langlinks at the top of the article, and a newline between them and the text start, unneccesary space is added between the article title and the intro text ✏ Sverdrup 14:29, 3 Jun 2004 (UTC)
Database errors destroy history
If a database error occurs while updating a page, the most recent change in the history is completely lost. This has occurred in en:Elagabalus. --Eequor 11:12, 3 Jun 2004 (UTC)
This has occurred for me several times on 2003-04 in English football - only the current of my 5 or so revisions today is in the history. 217.33.253.7 11:54, 3 Jun 2004 (UTC)
I've duplicated the bug. The page update continues despite the database error, overwriting the most recent history item. I had assumed the most recent edit was destroyed without being replaced during the 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:
INSERT INTO old (old_namespace,old_title,old_text,old_comment,old_user,old_user_text,old_timestamp,old_minor_edit,inverse_timestamp,old_flags) VALUES (2, 'Eequor/Logrus', '*α **β ***γ *δ **ε ***ζ', 'Asterism.', 49577, 'Eequor', '20040528134029', 1, '79959471865970','')
from within function "Article::updateArticle". MySQL returned error "1205: Lock wait timeout exceeded; Try restarting transaction".
Clearly, since the page is updated anyway, "restarting the transaction" will be ignored as a non-change. --Eequor 12:14, 3 Jun 2004 (UTC)Yep, this has happened to me too, with my change being credited to someone else. ✏ Sverdrup 14:26, 3 Jun 2004 (UTC)
Surely this must have been 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, as the default, please? Quota
(This is a software problem, as it has changed every Wikipedia today that I have checked.)
It will be hard enought to get people on one wiki to agree on how to handle it, I don't think you can get all of them to agree. A vote can be held on each wiki as to how things should be handled. For english, this is already taking place at en:MediaWiki talk:Monobook.css. Dori | Talk 17:25, 4 Jun 2004 (UTC)
The problem is that the software has changed from the readable font – and, up to now, accepted – font to a less-readable font. I have seen no one ask for this change (at least, a few Google searches did not find anything). So every Wiki now has to undo this change, one by one? Quota
I think I've seen more than a few requests for that here. My understanding is that it's a browser-specified font, so it's probably a problem with your configuration if it doesn't look good. From my end (firefox 0.8 windows/linux) it looks OK, a tad small, but that's not a font type issue. Dori | Talk 18:48, 4 Jun 2004 (UTC)
No, my browser settings have not changed (in fact this is a complete new re-install of WinXP three weeks ago – the only browser setting I have changed is to turn underlines to hover; life is too short to keep customizing after every re-install). It must be caused by a Wiki change (which also overrides the underlining...). Quota
Perhaps the default browser settings have a bad font with regard to sans? Dori | Talk 20:22, 4 Jun 2004 (UTC)
It is the usual Arial/Helvetica look-alike. That is fine as a sans font. The problem is that a sans font is never as readable as an equally good serif font (assuming the serifs can be rendered :-)). That is why serif fonts have serifs, and is why sans fonts are normally only used for headings, occasional emphasis, navigation, etc.. and are not used for bulk text where speed and accuracy of reading is the primary requirement (as in the body of articles). Quota
The best solution is to not specify the body font at all — neighter font face, neighter font family, neighter font size. Is was so before, and nobody complained. Those who liked a particular font, could always set it as the browser default. Those who liked small sizes, could set the default font size smaller. But today everything is broken. — Monedula 00:08, 5 Jun 2004 (UTC)
Absolutely right. So how is the problem fixed? Which Wiki page do we edit so that users’ settings are respected? Quota
I completely agree with parent poster. Sans serif font's if used should only be used on headings etc. Article text should be in a serif font (Ideally CSS should just specify it as serif and not a specific font name). Readability has taken a hit ever since the change.
Please remove Verdana from the all default stylesheets
Now, fortunately, Verdana has been removed from the English Wikipedia style sheet. But it still lingers in many other portions of Wikipedia (e.g. Wikisource and Russian Wikipedia). Could anybody please remove Verdana from all default style sheets, throughout the Wikipedia project?
Verdana is a totally unacceptable font, because it can distort content. You see, it is not about nice looks, but about the factual accuracy of the information presented. — Monedula 00:18, 5 Jun 2004 (UTC)
Until a coupla hours ago, I'd never seen any Verdana on the CSS, now it's suddenly appeared. Please make it go away! :o) — OwenBlacker 03:38, 6 Jun 2004 (UTC)
No-break spaces got eaten up
No-break spaces (U+00A0 or ) are now being replaced with simple spaces (U+0020) (although in preview everything looks OK). The difference between simple spaces and no-break spaces belongs to wikipedia content, not just to good looks. It is not acceptable to distort the contributor's intentions. — Monedula 00:42, 5 Jun 2004 (UTC)
Please have the tab along the top say "edit history" and not "history." I clicked there thinking I'd find information about History. I am sure others will make the same mistake. Kingturtle 19:40, 5 Jun 2004 (UTC)
I think it's fine. Those tab names are supposed to be short, not to mention that having edit and edit history next to each other would look weird. If nothing else, it will get people to learn about the editing capabilities a bit more. You click it once, see what it is, and it ceases to be confusing. Every interface but the nipple has to be learned. Dori | Talk 20:20, 5 Jun 2004 (UTC)
Printable version
I don't know where people are listing compliments....but here's one...
I love the way the printable version formats now. All underlines and text colrs are removed, and the text now wraps around images.
Very well done! Kingturtle 19:41, 5 Jun 2004 (UTC)
on de: it seems as if the user contributions are not sorted altogether in date order: first the contris of the cur-table, and after that the contris of the old-table. thats a little bit annoying to scroll hundreds of records... --WikiWichtel 21:07, 5 Jun 2004 (UTC)
Change Discussion to Discuss
The menu at the top says "discussion, edit, history, protect, delete, move" etc. Most of them are verbs associated with actions, but discussion is a noun. It would be proper if it were "discuss" instead of "discussion". It would encourage readers to discuss about an article just the same way they are encouraged to "edit". Imagine if the menu said "edition" instead of "edit". 203.195.204.132 09:23, 6 Jun 2004 (UTC)
The left two tabs aren't really actions though- they just choose between 'article' (noun) and 'discussion' while the actions to the right operate on the article/discussion. -- Gwicke 11:31, 8 Jun 2004 (UTC)
Yup, my point is : "It would be proper if it were "discuss" instead of "discussion". It would encourage readers to discuss about an article just the same way they are encouraged to "edit"" Discussion is not a word thats going to convey anything to the user, if the noun is to be used perhaps "Article comments", "Talk page", etc. would be better. Best is to use a Verb, the choices are more : "talk", "discuss", "comment", "feedback", etc. 203.195.204.132 16:51, 8 Jun 2004 (UTC)
Recent changes
On et:wikipedia the Recent changes function after the crash shows only the changes since the last query. Andres 06:44, 8 Jun 2004 (UTC)
I don't think that's a 1.3 bug, nor do I think it's repairable (it's generated on-the-fly). Dysprosia 10:15, 8 Jun 2004 (UTC)
Images
All images using the "thumb" syntax now appears in frames which are too small, and thus with scrolling menus. See screenshot. Browser: IE 5.1.7/Mac. Wolfram 15:01, 8 Jun 2004 (UTC) NOTE: It was not like this before the database crash on June 6. Wolfram 16:17, 8 Jun 2004 (UTC)
seems to be resolved Wolfram 22:13, 8 Jun 2004 (UTC)
history of MediaWiki-Templates
On [25] you'll see the history not in date-order. whats wrong? WikiWichtel
logo/sidebar glitch
I posted this bug before, at MediaWiki_1.3_comments_and_bug_reports#merci.21, but it never really got an answer, so I'm going to post it again and see if anyone else can give me anything, coz as time goes on, it get more annoying. -blankfaze
Hey, kids, I've got this bug... dunno if anyone else has encountered it...
It's weird. Occasionally (it seems to be random) some random black mess shows up under the Wikipedia logo. It doesn't bother me that much or anything, I just figured I'd report it. Blankfaze 18:00, 1 Jun 2004 (UTC)
I also usually get this on en.wikipedia in Firefox v0.8 since the upgrade, but not in IE v6.0-SP1. --Zigger 16:45, 2004 Jun 3 (UTC)
that seems to have to do with your moving of the personal bar. I guess it has a heading which is cut off. --WikiWichtel 21:20, 5 Jun 2004 (UTC)
You sure are making a lot of noise for such a small thing. I doubt that duplicating posts and red fonts will make the developers want to fix this bug more. Dori | Talk 03:13, 10 Jun 2004 (UTC)
Yeah... I'm sorry. I was irritable. I was being kind-of immature. I get kind-of obsessive-compulsive sometimes. I apologise, I really do. I managed to fix this, by the way, or at least figure out a workaround. So I'm really sorry for making such a fuss. -Blankfaze
did you read and understand my message? did you tweak the heading of the bar? --WikiWichtel 11:42, 10 Jun 2004 (UTC)
Yes. Your suggestion, while well-meaning, was unfortunately wrong. But thanks for the suggestion. Sorry for making a fuss. -blankfaze
user contribution
on User-pages I don't need the button 'move' (usually). Instead I'm used to have 'user contribution' at hand. this is hidden in the toolbox. Where do I get a script to swap these two links? --WikiWichtel 07:18, 9 Jun 2004 (UTC)
Font size
Font is really too small !!
I really liked the former font better, the new font is really too small
Please don't forget old people and people with sight disabilitie, gess what !? not only young surf Wikipedia !
categories of templates / two similar cats
if a template, eg. timelines, has a category, the article gets this timeline also. Ok, that is reasonable. the sorting of these both in the category page is a little bit confusing. With piping I get the <category:timeline foo|foo> sort under 'f', but the article <bar> gets sorted also under 'f'. So I tried to give the article <bar> the <category:timeline foo|bar>. wow! sorting of the category page works. But now the article <bar> has two category links to <category:timeline foo>. Is it possible to show only one link? example: [26] --WikiWichtel 14:37, 10 Jun 2004 (UTC)
some other user consider it bad to have the transclusion of the categorie of a template to an article, the next tried to use a category:disambiguation to categorize all disambiguation pages and failed because of a database error... do we have/get some more control about this behavior? --WikiWichtel 21:39, 12 Jun 2004 (UTC)
It occurred to me that there is a greater problem, one that I haven't seen discussed, with all this talk of multiple skins and CSS-based style customization. Wikidom runs a serious risk of making pages mutually unreadable between sophisticated users and generally unreadable for the populace if style-customizing contributors aren't aware of how their pages look to regular users or even to each other. This would affect lists, indented paragraphs, images, and probably many other page elements. All of my own arguments against the liberties taken by the Monobook skin come back to how thoroughly they screw up the first two items above in the many pages I've created and contributed to. Bad as that is, I expect the problem to become rapidly worse as people gradually get used to having such fancy styling options.
Web Design 101 says you should design Web pages intended for a general audience to work with generic browser configurations, and that you should test thoroughly with different browsers before signing off on your Web content. If the most style-savvy contributors also happen to be the most prolific, and if they're pressed for time (and who isn't?), we can expect that a substantial number of pages added or edited by such power users will only be checked against their customized styles. (Does anybody test their page creates and edits against different skins, other than to complain about a skin or a bug?) This wouldn't be so bad if Wiki articles were just paragraph text and the occasional image, but we know that's not the case — else why would we want so many styling options?
I think we're heading for readability issues that make the current Monobook debate look like a tempest in a teapot. (I'll have to remember to add that to the not-so-conventional List of idioms in the English language.) -- Jeff Q 02:51, 11 Jun 2004 (UTC)
Redirect oddity
I recently had occasion on the Welsh Wikipedia to hit "sgwrs fi"/"my talk" and was very surprised to find myself redirected to a totally different user's user page. It looks like the problem was that we were earlier discussing REDIRECT and AIL-CYFEIRIO statements (with the leading #) in my talk page -- it looks as though the software finds a valid redirect statement anywhere in the article and promptly redirects to the next article name it finds. Surrounding the directive in <nowiki></nowiki> had no effect -- I had to physically mis-spell the directive in order to get back to my talk page. I think it would make more sense to restrict the effect of the REDIRECT command to the start of an article. -- Arwel 12:11, 12 Jun 2004 (UTC)
E-mail Link
I think it would be a good idea to have a link on each page to e-mail the page to another person.
(someone else) - yes, this would be very cool if the wiki honored the MAILTO: link - very helpful in intranet settings.
The new skin rocks!
I love the new style, it makes Wikipedia look much more real.
All pages function for three namespaces are missing
is there a chance to get a list feature similiar to special:allpages, where you can choose which namespace you want to list? Maybe with dropdown to choose from or checkboxes. --141.53.194.251 18:20, 14 Jun 2004 (UTC)
See namespace for some lists. It would be useful to have automatic lists also for the Project namespace, the Template namespace, and the Help namespace. The following special pages are oddly missing:
Comparison page font too small. Main text wants default size.
Since a few days the text of the compared revisions of an article seems to be in a smaller font. (Standard skin, IE6, W2K). This is annoying to me: with my browser settings (Times & smaller font size), anything smaller than the default font size is hard to read.
I'd argue that everyone choses its default font size to maximize him/her reading comfort. So the main text of each page should be at that size. And the compared revisions of articles are precisely the main text of the comparison pages. Its bad to reduce it. (Unless it's made an option and left off by default.)
I see no rationale for diminishing the compared revisions font sizes. People have big screens nowadays. I've got enough space to read differences comfortably with "only" 1024 pixels wide, and my browser windows do not take up all that width.
The font size was small before, now it's smaller in css instead, relative to min-sized main content text. Quite a few pages still don't fit on my 1024x768 notebook, even with 12px default font size (IE default is 16px). -- Gwicke 23:02, 15 Jun 2004 (UTC)
Isn't there any way, please, to override this ? I've never felt the need for a smaller font for this. I was happy with the situation of MediaWiki 1.2 and the then-by-default-skin. --FvdP 20:22, 22 Jun 2004 (UTC)
new contributors, which use a action=edit§ion=new link, like that one above (post a comment), do often type in the subject/heading and then hit Enter. That seems to save this without text in the textbox but a lonely heading at bottom of page. May we have a mediawiki-text to describe what they should do (hit TAB) or/and could the hitting of ENTER go to the preview/or into the editbox? --WikiWichtel 12:40, 23 Jun 2004 (UTC)
Example
logs
the logs, (delete log and file log) occasionally become ugly large. could there be sent an automatic message to an admin or to a proper mailing list for moving it to archive?
--WikiWichtel 18:37, 23 Jun 2004 (UTC)
category:
On Special:Categories you'll find a link to [[:category:]]. try to find out which article the corrupt category has. (don't use my contribution list) --141.53.194.251 21:18, 24 Jun 2004 (UTC)
image-aligning
Right aligning an image does not work if the text on the left contains a <center> tag. Also, tables do not work if cells contain images - Marshman 03:56, 25 Jun 2004 (UTC)
feature request about interwiki links
I think that 'other languages' links could be better implemented.
Here my thought: since there are a lot of wiki articles without references to other languages and a lot of articles in different languages with references to different links and a lot of articles with a long list of interwiki links (which aren't relative to the real content of articles), it could be build a 'meaning-based' wikipedia (and not words_of_the_title-based).
Here a schematization:
there are meta-articles, univocally identified by a name (the english one?) or by one hash like md5, sha1, ...
each meta-articles contains only the titles (then links) of the articles in the various languages relating exactly the same arguments (pratically it contains the translations in the various languages of the same group of words) [this meta-article is a sort of platonic idea: it is the meaning of the words of the titles of articles regarding exactly the same thing in different languages]
each article localized into a laguage doesn't need the listing of the corrispondents in other languages because of its appartenence to a class of articles (the meaning) and all the articles in the class have listed inside all the others
I think it could a very good thing, however i understand that you cannot do this for all articles, but it could be a sort of 'plus' for whom whant not to make others bored in searching exact interwiki links
history corrupt
I recently saved an article (on de:) without any changes, because there was an image which hadnt a backlink to this article. so I tryed to 'touch' this article. expecting a non-changed history, I was surprised to see my User-account as last record, who had done an orthographic correction. I am very sure that I didnt this correction! whats going on with the history? --WikiWichtel 16:46, 29 Jun 2004 (UTC)
Images without captions make huge white space
I'm still having this problem: Images without captions leave a huge left or right white space margin between it and the text. For example, see Golden Nica Awards 2004. If I add a caption, the spacing becomes correct. I'm using Netscape 7.1 on Mac OS X. I used shift-Reload as specified at the top of this page and it did nothing for me. Elf 18:11, 29 Jun 2004 (UTC)
Three for three of live
What about a special similar and independent type of categories only for the Three of Live project that let make a real Three? It can't be complicated (only make it independent to the other categories and use an other color) and can be very useful I think.
do you mean 'Tree'? --WikiWichtel 15:18, 1 Jul 2004 (UTC)
Maybe :)
Cannot work while logged in.
Ever since the new software, I cannot work while logged in. I am able to log in, but after I do so - pages refuse to load. To be precise: they take forever to load, and never actually finish loading. However, when I am not logged in, pages load immediately with no problems whatsoever.
I reported this on "Village Pump" already (no solution, but one other person said the same thing was happening to them). I also just now found out that (it seems) this is the proper place to report software bugs. Would be grateful if anyone help solve the problem. -- Dovi --
Hi. This is to report that the problem seems to have been resolved (though I'm not quite sure how or why). It may be connected to switching to Mozilla (that is when I started being able to log in and view pages again), but it also works now even when I went back to IE to test it out. In any case, I can log in and work now. At this point I guess it is just important that the software people are aware that a problem of this sort did exist. If somebody behind the scenes fixed it recently - thanx! And also thanks to user:Angela who was very helpful. -- Dovi --
HTML table. Strange behaviour of color scheme
If you try to copy this table in a html file, it is displayed properly in a browser. Then, why doesn't work well here?
CC = cat. central, NO = cat nord-occidental, VA = valencià,
BA = baleàric
CC+NO+BA
VA
CC+NO+VA
BA
NO+VA+BA
CC
sortir
eixir
agafar
agarrar
dolent
roí
cop
colp
mongeta
fesol
vuit
huit
buscar
cercar
gos
ca
gat
moix
borratxo
gat
diners
doblers
got
tassó
granera
escombra
peresa
mandra
arena
sorra
cartó
cartró
Log in inconsistency
I find I can now be both logged in and logged out, at the same time. Or at least, according to the User_styles page I'm logged out, while on others I'm logged in as normal. (No, refreshing does not do the trick.) Aliter 15:42, 13 Jul 2004 (UTC)
Outerlinks do not conform to the broken links setting.
On Monobook, the links outside the virtual page do not conform to the setting for broken links. Eg. there's as yet nothing on my talk page here on Meta, and as a consequence the link is in bright red, pretending to be the most important part of the header, even though I set broken links to question marks to reduce their weight. Aliter 16:00, 13 Jul 2004 (UTC)
This page includes two sections included from templates. Does their inclusion cause problems for any of the skins? They behave properly with Standard, except their headings aren't included in the table of contents. Apparently the templates expose bugs in other skins. --Eequor 13:59, 21 Jul 2004 (UTC)
Nested subst
{{User:Eequor/edit|MediaWiki 1.3 comments and bug reports}}
But that retains the {{PAGENAME}} variable, which will not work if the page containing the {{edit}} template is a template itself. --Eequor 15:41, 23 Jul 2004 (UTC)
I see, so your feature request is that there is something like subst{{PAGENAME}}. Currently that does not work regardless of nesting. One should distinguish a variable from a template.--Patrick 22:56, 23 Jul 2004 (UTC)
No; {{subst:PAGENAME}} does work, producing MediaWiki 1.3 comments and bug reports. --Eequor 00:26, 24 Jul 2004 (UTC)
You are right, sorry.--Patrick 13:09, 24 Jul 2004 (UTC)
It appears that XyMTeX may be considerably more powerful than PPCHTeX; additionally, PPCHTeX depends upon ConTeXt, which has intensive memory requirements. See the XyMTeX manual. --Eequor 17:05, 29 Jul 2004 (UTC)
Wiki links directed to a page section can't be auto-tidied with |]]; e.g. en:WikiTeX#Chem → [[en:WikiTeX#Chem|]]. --Eequor 15:32, 23 Jul 2004 (UTC)
Navigation, show categories
Navigation sure could use a link to the categories feature of mediawiki.
AaronPeterson 22:55, 23 Jul 2004 (UTC)
Probrem on searching with non-ascii keyword
Sorry, some kanji characters are used in this report.
See here. Searching result with non-ascii keyword(for example, "鳩尾" : the pit of stomach) shows wrong. Results in "Article title matches" section, all result don't contain "尾"(Tail), and so on. PiaCarrot 12:34, 2004 Jul 28 (UTC)
The search index code for Japanese currently breaks up sequences of contiguous kana and individual kanji into virtual "words". I realize this isn't quite ideal, but it errs on the side of returning too many results than not returning matches. You can do an exact search for a multi-kanji word or phrase by putting them in quotes [27]. --Brion VIBBER 20:04, 6 Aug 2004 (UTC)
The "what links here" list would be much easier to read if it was properly alphabetized. Would this be difficult to add? --Eequor 22:55, 5 Aug 2004 (UTC)
I think this was recently tried and people hated it. The list, I think, is now in database order ("unsorted"), which seems close to chronological order. If the list for an article gets rebuilt, it ends up alphabetical. --Ssd 02:20, 9 Aug 2004 (UTC)
It might be useful for Special:Recentchangeslinked to behave differently for categories, such as listing changes for all its subcategories and articles instead. Usually there are very few actual links in a category. Interaction with other special pages could be similarly improved. --Eequor 17:27, 9 Aug 2004 (UTC)
MediaWiki 1.3 meta-comments and bug reports
Out of curiousity, how much attention does this page get? What is the process for maintaining it? --Eequor 00:42, 10 Aug 2004 (UTC)
Automatic sandboxes
See MeatBall:AutomaticSandbox. Has this been discussed in Wikimedia before? Would it be practical and/or appropriate for Wikipedia? --Eequor 01:42, 10 Aug 2004 (UTC)
Nesting bold and italics broken?
Apologies if this has already been mentioned somewhere but it seems nesting bold and italics no longer works. For instance '''HMS ''Warspite''''' used to produce HMS Warspite.
This was being discussed at the Village Pump - I've filed a bug report. Seems to be affecting quite a few aircraft and ship articles. --Rlandmann 07:21, 13 Aug 2004 (UTC)
Feature request: print article
As the quality of wikipedia gets better and better, I find myself printing aritcles to read on the bus. I have made a simple perl script to convert articles into pdf format using latex. This should be a feature of wikipedia itself. There is also another implementation written in python. The perl script requires wget, xsltproc and imagemagick. It can be found here: [28]. The python version is here: [29]
Special:Watchlist is broken on en
en's "Display and edit the complete list" no longer functions properly. It still displays the list, but checking boxes to unwatch articles has stopped working. The form seems to simply return to Special:Watchlist without making any changes. --Eequor 19:16, 12 Aug 2004 (UTC)
Mine seems to be dropping articles I haven't unwatched, and picking up ones I haven't watched, on both en and wikibooks. The articles in question are ones that I have looked at, though, and were interested in, so maybe I am just losing my mind and not remembering which ones I clicked. I have too many to keep track of whether they are really getting lost. Has anyone else noticed this? - Omegatron 00:32, 13 Aug 2004 (UTC)
Mine is definitely dropping articles that i have not unwatched. No one else has noticed this? I just added Wikibooks:How to Play the Violin to my books list, and read it, pressed edit without pressing submit and went to the nonexistent discussion page. after some of these actions, but not all, and quite randomly it seems, i go back to my watchlist and it is not on it anymore. i have "watch all pages that i edit" selected. - Omegatron 14:24, 2 Sep 2004 (UTC)
I took these steps on wikibooks:
go to violin article
press watch
go to watchlist - it's on my watchlist
go to violin through watchlist
leave it open for a bit
click on discussion
click on watchlist
the first time i did it, it was no longer on my watchlist. every time since, it is still there. is this maybe related to having more than one wiki page open in tabs? cookies? editing a different article in another browser instance? i can't isolate the problem but it's definitely happening. - Omegatron 14:51, 2 Sep 2004 (UTC)
And today two articles were on my wikipedia watchlist, en:Rose Island and en:Republic of Minerva which i DID read yesterday, but did not edit and did not push watch. this is not my imagination... - Omegatron 13:45, 3 Sep 2004 (UTC)
People don't believe me :-), and want examples. I will add them when it definitely happens. (No I do not have "hide minor edits" checked.):
the votes for deletion page for en:Hutchison effect on en. I edited it, it was on my watchlist. Someone else edited the votes for deletion page, I viewed their edit by clicking on my watchlist, went back to my watchlist afterwards and it was no longer there. - Omegatron 15:18, 8 Sep 2004 (UTC)
BAM! wikibooks:User talk:Omegatron/sandbox/watch3 - Clicked on hist in my watchlist, looked at history for a little bit, clicked on discussion tab. unwatch tab magically turned into watch tab. Proof! I am not crazy!
As an experiment, I started these test articles. I will never ever press unwatch on them. So far they have stayed on my list. Possibly it has to do with other people editing? So please add an edit or two for testing purposes. Minor edits, discussion edits, etc. 1 2 3 4 5 - Omegatron 15:22, 8 Sep 2004 (UTC)
Almost reproducible results
I'm using Firefox.
Watch my test articles: User:Omegatron/sandbox/watch1User:Omegatron/sandbox/watch2. Open watchlist. Test articles are on it. Middle click on article 1 and 2 "hist" links to open history for each in a new tab. Keep an eye on the unwatch tab at the top. Anything I do after this has variable results.
Click any of the "cur" links in 1. Click any of the "cur" links in 2. Edit 2. Unwatch tab *sometimes* turns into watch tab. If it doesn't work try editing 1. It almost always works to one or the other. If it doesn't try doing it again from the beginning.
Hmm. I am trying to reproduce it and it still isn't exactly reproducible. However, if I follow these steps and then go back and forth between the pages, editing or pushing history, one of them will become unwatched. This must have to do with cached pages or cookies or multiple tabs or something. VERY nebulous. - Omegatron 16:26, 8 Sep 2004 (UTC)
Unification and reorganization
All the Wikimedia projects really need to be organized better. It isn't sensible to have every language in a project crammed into one namespace when they could have separate domains instead, as with Wikipedia. Special:Randompage on Wikisource demonstrates the problems inherent in using one namespace. --Eequor 02:13, 14 Aug 2004 (UTC)
The current divisions of the various projects -- so distinct from each other that they each require entirely separate user accounts -- have also been poorly planned. Since a single database contains all the projects, it's absurd that the projects can't keep track of which users have been logged in on other projects.
Beyond that, the very idea of "projects" is a mistake. While it might seem that Wikipedia, Wikibooks, Wikisource, Wiktionary, and Wikimeda have nothing in common with each other beyond the Mediawiki software, they in fact do. There is a shared community of users who contribute to multiple projects. Ignoring that, the community is divided arbitrarily; contributions on a particular project tend to occur independently of changes in other projects, in isolation from each other; potential work is lost; and progress is slowed for all projects. Wikimedia needs to be reorganized to improve collaboration between projects and to avoid the tragedy of the anticommons. --Eequor 02:13, 14 Aug 2004 (UTC)
Feature request: Tools for cross-language colaboration
The unfortunate fact is that today the wikipedias reinvent the wheel for every language. The only relationship that sometimes exists, is that articles get translated from one language to another. Each of the changes that are then made in both versions of the article benefits only the wikipedia of one langauge.
This is not only a problem for the smaller wikipedias. Especially local information is much better represented in the wikipedia of the regional language, and it would be beneficial for the english wikipedia, if that information were to be imported. Also some pages (I only know about german) in foreign language versions are written from an interesting other perspective or just have more work done, because some people speaking that language happened to be very interested in the subject.
The reason why I personally don't translate wikipedia articles, is because I feel that instead of benefiting wikipedia, I split up the manpower between the english and the german version. This would change, if the work in one language would benefit the wikipedia of another.
What I suggest is:
(1) The possibility to maintain a relationship to the link of the article in other languages, like
translated from (this article is a translation of the article in that language)
translated to (this article has been translated to that language)
independent (the content of the article is language specific)
unmerged (no translation in either direction known)
merged/corresponding (people work on the article in both anguages, changes in both articles get applied to the other one)
(2) A counter that counts up from the last edit made with a special keyword, an trans-langual edit could then be called something like "cross-language [german] in: Added new section, out: rearrangement of introduction". Such a counter could either count the changes made in the other language, the changes made in this language, both added up, or preferably both beside each other to get a glimpse on which one is more dominant.
(3) A special page, that lists the topics that have the highest counter between this and another language, for people interested in translating articles.
The better the articles get, the more sense does it make to translate the content. Making translation more attractive is beneficial for both the main (adding local information) and the language (more/higher quality content) wikipedias.
Feature request: Templates for cross-language colaboration
I would like to see the wikis grow in the number of translations, and to do so, I'd like to see greater linking between different language versions of the same article, but hosted on the different wikis, so that in an English article on Lance Armstrong, you can click on "German" and be directed to the German wiki's article on Lance, written in German.
I would also like to see that for a new language's wiki, to start off, it would have a template main page and welcome page, in the language chosen by an adiminstrator or someone else, or requested by the main translator for the language, and perhaps the 100 articles every wiki should have, written in the same language, so the main translator can translate those articles, and have a solid foundation for his wiki to grow upon.
These would basically be template articles on these topics to allow a language to grow more quickly in number of articles and depth of subject matter.
Would it be possible to incorporate the Special:Whatlinkshere results into the message informing the user that a page move was successful, or even check for and correct double redirects automatically during the move? It's certainly possible for Special:Whatlinkshere to detect them. --Eequor 07:15, 16 Aug 2004 (UTC)
Two feature requests (threaded forums and WYSIWYG)
WYSIWYG:
This is really a request on behalf of my grandfather. I showed him Wikipedia and he got very excited about the concept and wanted to start posting. The man is an incredible source of knowledge on countless topics, but unfortunately he's not tech-savvy enough to use the wikipedia text-based formatting. I know the idea of a WYSIWYG editor has been thrown around...has any progress been made? Without it my grandfather (and I'm sure many others) is left unable to contribute.
Threaded forums:
Some of the talk pages are really unruly...any chance there'll be a threaded forum option for discussions?
Thanks
Alex (cypherx)
What links here
I try to use this feature on the page en:Colombia (see en:Special:Whatlinkshere/Colombia) but it does not list all pages that link there. More specifically, it does not list my user page, which DOES link there. Why is this? --Fibonacci 02:49, 24 Aug 2004 (UTC)
Not more than 500 pages are listed.--Patrick 05:58, 24 Aug 2004 (UTC)
Is there any way to change this? --Fibonacci 01:24, 25 Aug 2004 (UTC)
Feature suggestion: Styling links to stubs etc.
This is an idea that I think would be useful - maybe it is already suggested or possible, if so, please advise.
The idea would be to ultimately allow a skin to colour code or otherwise discern links to articles that are marked with {{stub}} and/or {{disambig}} (perhaps others). This would assist in identifying links that need more work (in the case of a stub), or correcting (in the case of a disambig). Such an option wouldn't need to be a default, it could be enabled either through a custom skin, an option in the user's preferences, or by some addition to the URI such as &showstubs=1 etc.
Periodically (about one time in 20), I will click on a page, and be prompted to download the page, rather than having the page displayed normally.
I'm running version 1.3.0, php 4.3.6, mysql 3.23.54 on freebsd.
I run another PHP based CMS on the same site (xoops), and it does not have this problem, which suggests to me that this is a media wiki problem.
Has anyone else seen this? Does anyone have a fix?
Thanks.
Recalcitrance of developers and Cabalism
WHAT DO I HAVE TO DO TO GET SOME REASSURANCE AROUND HERE?!! As long as this problem exists, work is not being done! If the problem isn't going to be fixed immediately, I'd at least like to know. - Furrykef 00:15, 22 Aug 2004 (UTC)
Likewise. If any developers are regularly monitoring this page (hopefully they are), they should be regularly leaving feedback. If comments on this page will actually not be seen by anybody they're directed to, this page should be deleted to discourage users from wasting their time. --Eequor 19:46, 27 Aug 2004 (UTC)
Lack of appropriate attention to this page only provides further evidence for the existence of a Cabal. If there is any work being done, failure to provide or invite feedback means that any decisions are being made in private, restricted to a small select, exclusive, and secret group who nonetheless control the progress of MediaWiki.
This page is essentially a façade to maintain the illusion of community involvement without the fact of it. As the existence and length of this page prove clearly that developers are not only fallible, but persistently so, refusing to communicate with the outside world is illogical and counterproductive. --Eequor 20:11, 27 Aug 2004 (UTC)
Actually, we try, over and over again, to get people to stop wasting their time posting on this page. SEND BUG REPORTS AND CODE TO THE BUG TRACKER WHERE WE CAN ACTUALLY KEEP TRACK OF IT PLEASE!! --Brion VIBBER 23:42, 27 Aug 2004 (UTC)
Exactly what have you done to ask users to not post here? It sure doesn't work too well. *points up at all the unanswered commentary*
This page exists and will likely continue to exist until everything on it is resolved. Deal. --Eequor 04:29, 28 Aug 2004 (UTC)
As it says at the top of the page, "Bugs in MediaWiki should always be reported at MediaZilla to make sure they aren't lost or forgotten." (And until recently, it said "Bugs in MediaWiki should always be reported at our bug tracker to make sure they aren't lost or forgotten" for months). If people don't read this message, it's their problem. Feedback is given in the bug tracker, when developers have time. Most developers never wanted this page, and I doubt they monitor it. As for using words like recalcitrance and cabal, forget it. You'll get more attention from our overworked volunteer developers if you're not demanding and hysterical. -- Jeronim 08:42, 28 Aug 2004 (UTC)
As seen above, being polite hasn't worked for anybody in a long time. Whining about users who demand accountability is at least some kind of attention.
The message says bugs should be reported at MediaZilla. It says nothing about feature suggestions or general comments. Would you prefer to only receive negative feedback? --Eequor 18:34, 30 Aug 2004 (UTC)
As far as I know this particular issue was fixed ages ago in CVS. Can you please check and see what is or isn't still working? --Brion VIBBER 23:42, 27 Aug 2004 (UTC)
The template limit is stil there: {{tc}}{{tc}}{{tc}}{{tc}}{{tc}}{{tc}} gives inininininin.--Patrick 01:48, 28 Aug 2004 (UTC)
That was fixed over a month ago, with Parser.php 1.210. See [30]. As I said on the village pump today, it won't go live until 1.4. -- Tim Starling 09:07, 28 Aug 2004 (UTC)
Feature suggestion: Barebones pre-made help pages
I'm putting together a modest wiki using MediaWiki and it seems like a bit of a burden to have to write a complete set of help files just so that my co-writers can get up to speed with fairly straightforward and basic usage how-to. At the moment I'm just linking to the Wikipedia help pages, but that's a bit too cumbersome and includes debate over higher-level issues which don't really matter for my usage.
I think it may be a useful idea to have an option setting so that those who choose it can at least have a barebones couple of help pages automatically set up. Of course they can be edited and modified by the wiki as needs be, but it seems like at least something, however inadequate, is still better than nothing at all. I'd rather spend the first days of my wiki working on content structuring instead of creating all the ancillary pages which are given links upon creation of the wiki.
Does this seem a reasonable suggestion? Thanks, --~~
Feature suggestion: Automatic unit conversion
I see lots of pages where a certain measurment is given in two different units but it still doesn't cover all of the possible ways that that value could be expressed in. For example, many ship articles have the top speed in knots and km/h, but this leaves out mph. For planes, mach, mph, km/h. Putting all of the possible ways that the value could be expressed would just clutter up the article.
I suggest having a type of special page where if someone links a value in an article, ie "40km/h", then clicking on this link will take the reader to a page that lists all the possible conversions of this value, ie 21.6 knots, 24.9 mph, 11.1 m/s, etc. This lets the writer only use one value, but if the reader would prefer it in another unit, all they have to do is click on it to find what they want.
Feature suggestion: changing the displayed title
Due to some technical problems, some pages, e.g. http://en.wikipedia.org/wiki/EBay and http://en.wikipedia.org/wiki/C_plus_plus I suggest being able to insert text into the main body and thus change the title displayed at the h1 level at the top of te page but not the url of the page e.g. [[Title:eBay]], [[Title:C++]]. Duncharris 22:04, 1 Sep 2004 (UTC)
Wouldn't this confuse people that are putting links in other articles? I usually do a search to check if what I want to link exists and then just copy the title and link to that. With "eBay", this wouldn't be a problem, but it wouldn't work with C++. You may say that I should just look at the edit page, but without knowing which pages had their titles changed, I'd have to do it with every single article.
I don't think so, atleast not to the point at which someone else cannot come along later and fix it (it is a wiki after all). [[C++]] produces C++, so one has to use [[C plus plus|C++]] to give C++. As for the others, it would only have a few uses, but IMHO it's better than the text has to be used at the moment explaining the problem. Duncharris 18:16, 2 Sep 2004 (UTC)
![[16]](http://fftw.org/~stevenj/versine-margins-bad.png){kind=link}
