Wikipedia:Village pump (technical)/Archive 3

User ID number
Three questions on this number (you can see your user ID number in your preferences).


 * 1) ) Do they serve any actual purpose?
 * 2) ) Can you search on users by their User ID in any way?
 * 3) ) I know users are assigned a User ID number sequentially in order of account creation. What account has the user ID 1?  100,000?  1,000,000?  (This would tell use who the hundred-thousandth and millionth users were).  Neil   ☎  14:43, 30 October 2007 (UTC)
 * I'm not too familiar with the subject, but I believe it has to do with the design of relational databases. The user ID is a primary key unique to every user (except anons). If your user name is changed, your ID won't be. A user name can be retrieved from a user ID with a database query like  You could probably ask a developer to execute such a query if you want to know. (IANA[SQL-fluent person], though...) See User table for more information.  Grace notes T § 15:38, 30 October 2007 (UTC)
 * There used to be a tool to do this, and some of the toolserver tools give you this when you ask for other things. Anyway, the lowest I have found so far (by guessing) is Magnus Manske, with 4. Prodego  talk  22:13, 30 October 2007 (UTC)
 * Nope. User:Damian Yerrick has user_id 1. Strange -- would have thought it was Jimbo :) @Gracenotes: Yes, the user_id's are used as part of the relational db configuration. One table provides user names, email addresses, etc. in relation to user_id; other tables, such as recentchanges, use this user_id to refer to the user. They serve few purposes on wiki; the only one that comes to mind is that they can be used by stewards to change a user's rights without needing the username (in cases where the username consists of complex unicode, etc.) There isn't anything built into mediawiki to look up user id's, and so the only way to search for a particular id would be with database access or toolserver access. AmiDaniel (talk) 22:52, 30 October 2007 (UTC)
 * Thanks guys. So how could I go about finding the 100,000th and 1,000,000th account? (ie, those accounts with user ID 100000 and 1000000). Ask a dev? Neil   ☎  23:48, 30 October 2007 (UTC)
 * Yes, or someone on the toolserver. May I ask why you would need to know this? FWIW, user_id 100000 is User:Wakmah, and user_id 1000000 is User:Jchriscampbell. Note that these are not necessarily the 100,000th and 1,000,000th users. A more accurate, albeit still not certainly correct, way to determine the 100,000th and 1,000,000th user would be to sort by user registration timestamp, and select the 100,000th and 1,000,000th user in that list. Unfortunately, however, we only began storing registration data fairly recently, and as such, there is no registration_timestamp for many users, including Wakmah (user_id 100000). AmiDaniel (talk) 00:08, 31 October 2007 (UTC)
 * Curiosity I suppose. I imagine I can't convince you to recreate the useless userid->name (and vise versa) tool. While you are at it, who is 225883? That would be exactly half of mine. :) Prodego  talk  00:16, 31 October 2007 (UTC)
 * Oh, god damn it :) 225883 would be User:Taromsn. And no, I won't write it, because it's useless, and I have better things to do with my time :D Maybe you can talk someone else into it. AmiDaniel (talk) 00:44, 31 October 2007 (UTC)

Meetup advert
There's a typo in the notice for the New York City meetup on 3rd November. It currently says: Shouldn't it say: If this is in the wrong place or is supposed to happen, just say so.  N F 24 (radio me!Editor review) 22:39, 30 October 2007 (UTC)
 * The next New York City is on November 3rd
 * The next meetup is on November 3rd
 * Nope, this is just the place. The message is generated by a script that looks up the geographical location of your IP address and correlates it to upcoming meetups; it's called a geonotice. I've left a note here about this typo, so hopefully it will be taken care of shortly. Grace notes T § 23:13, 30 October 2007 (UTC)

User:CyclePat/monobook.js
I have trouble everytime I logon to my account. Wikipedia keeps loading and then internet explorer crashes. I think it's my monobooks. Here is a copy of what I currently use (any help greatly appreciated) --CyclePat 16:24, 26 October 2007 (UTC):


 * I've removed everything from your monobook. You can start adding stuff back in one at a time to help figure out what the culprit is. EVula // talk // &#9775;  // 16:22, 27 October 2007 (UTC)

Best Regards! Thank you EVula. --CyclePat 18:26, 31 October 2007 (UTC)

siteNoticeBig won't hide again
Anyone got a fix for this, "hide this message" is not working anymore. — xaosflux  Talk  14:04, 30 October 2007 (UTC)


 * Works for me. --brion 14:41, 30 October 2007 (UTC)


 * Just cut and paste this into your monobook.css

table.fundraiser-box {display:none} div#siteNotice {display:none}
 * User: (talk • contribs • email) 15:38, 30 October 2007 (UTC)
 * Tried in IE and in Firefox, and on firefox on a second computer, still won't dismiss. I've hacked it out manually for now with

display: none; }
 * 1) siteNoticeBig {
 * in my own css file, but would rather not have to use a hack. Any other suggestions? — xaosflux  Talk  16:39, 30 October 2007 (UTC)
 * After putting that CSS code into your monobook.css, did you refresh the page being sure to bypass the cache (Ctrl-Shift-R or Shift-ReloadButton in Firefox)? I don't use IE, so I can't tell you how to refresh-bypassing-cache in there off the top of my head.  Might be Shift-F5...?  -- Mike  Vitale  16:58, 30 October 2007 (UTC)
 * Oh yea, I cleared that cache, my own .css file hack works perfectly at removing the entire notice, my only issue is that the "hide" link that is native to the notice doesn't work. — xaosflux  Talk  22:09, 30 October 2007 (UTC)
 * Can you verify that you are accepting a cookie from Wikipedia (i.e., that Wikipedia's not blocked from sending you cookies)? Do you have javascript enabled? AmiDaniel (talk) 18:09, 31 October 2007 (UTC)
 * Got it to go, had to log out, delete all cookies, then log back in. Thanks, —  xaosflux  Talk  01:22, 1 November 2007 (UTC)

Transcluded categories
How does one transclude a page without including the categories inserted by templates on the transcluded page? For example, WP:AIV currently has the backlog template, which causes the admin backlog page to display all the User / User Talk pages that have AIV transcluded to them. How would I make it so that the userpages display the AIV page without also adding those userpages to the Admin Backlog category? I fooled around with includeonly/noinclude on a userpage with no avail. /Blaxthos 17:12, 30 October 2007 (UTC)
 * It can't be done from the userpages themselves. It can be done the other way round though, by placing the category in noinclude tags on AIV itself. --ais523 17:36, 30 October 2007 (UTC)
 *  , anyone? (to clarify: it doesn't exist yet, and I have no idea how hard it would be to implement something like that) Publicola 18:05, 30 October 2007 (UTC)
 * Or something like  , along the same lines as   (which is now unfortunately nearly useless because it doesn't handle &lt;includeonly> and &lt;noinclude> sensibly). --ais523 18:12, 30 October 2007 (UTC)

It is doubtful that those applying the  template would do so with msgnw: or <tt> </tt> and <tt> </tt> tags. Too bad there's not a way to contron this via the template itself (or is there?). The more I think about it, the more I think it would be wise to have the ability to tag a transclude with something that says "don't include the categories" or "don't include categories within templates". /Blaxthos 22:04, 30 October 2007 (UTC)

would do it in this case; however, this will require the cooperation of the bot running on WP:AIV. I've made a feature request on the bot's page. --- RockMFR 00:33, 31 October 2007 (UTC)
 * Nevermind. Was just a missing noinclude tag. --- RockMFR 18:57, 31 October 2007 (UTC)

Something badly wrong with animation handling, 15-fold size increase
It seems there is something wrong with animation handling. The following animation is 64 KB in size: Image:Foucault_pendulum_plane_of_swing_semi3D.gif The animation has been included in the Foucault pendulum article. However, when I click the properties, it says that the size of the animation is 1000 KB, more than 15 times as large! Clearly, something has gone wrong.

Worldwide, many people have a dial-in connection to internet. Currently the Foucault pendulum article contains several files with a humongous size. Is it wikipedia policy to be accessible? It is wikipedia policy to be accessable especially for the benefit of poor people? It seems to me that to blow up a file from 64 KB to 1000 KB (that effectively can only be viewed via a broadband internet connection) is a sign of disdain towards people who can only afford dial-in connection to internet.

Can anyone please tell me who I should contact so that this problem is looked into? --Cleonis | Talk 22:32, 30 October 2007 (UTC)


 * You could file a bug, see Bugzilla. Aside from that, what browser are you using? Some are faster than others, so you may be able to compensate for the problem a bit by using a different browser. —Remember the dot (talk) 22:43, 30 October 2007 (UTC)


 * Obviously it's not a browser issue. It's not the browser speed that is at stake, but the internet connection speed. I'm wealthy, I have broadband connection, I'm fine. Many people in the world are poor; in many countries most people have dial-in connection to internet (if any). Dial-in connnection is too slow to get a file that is bloated from an original 64 KB to 1000 KB. My concern is accessability of wikipedia to poor people. --Cleonis | Talk 23:39, 30 October 2007 (UTC)

Have reported this as 11822 → Aza Toth 23:46, 30 October 2007 (UTC)


 * It's not a bug. When you use <tt>thumb</tt> the image is resized to 180px.  The bloat occurs when it's transcoded from original format to 180px; no idea how all that works... maybe since you have the original rastor data you can render it optimally, whereas a resized animation that is deconstructed and reconstructed causes significant bloat.  The fix:  either render it at 180px, or change the type to <tt>frame</tt> (as I have now done).  /Blaxthos 23:56, 30 October 2007 (UTC)
 * I have submitted same to bugzilla and cancelled the report. /Blaxthos 00:03, 31 October 2007 (UTC)


 * Yeah, the original gif animation (that was manufactured by me) is optimized. My objection concerns the bloating. In my opinion, if deconstructing and subsequent construnction results in bloating, then the original file should be used, and the thumbnailing dismissed. Whereas a thumbnail version of a PNG-file will usually be smaller than the original, I think it's questionable to even try and thumbnail an animation. The bloating from 64 KB to 1000 KB shows that the algorithm used by the current wikipedia software is woefully inefficient.
 * I have extracted the individual frames from the bloated version. In that version, each frame is stored as an entire GIF image. In the optimized version, all that is stored for each frame is a rectangle containing the pixels that changed as compared to the preceding frame.
 * I'm in favor of making thumbnailing unavailable for animations.
 * I suppose I can render a parallel 180x180-version of the animation and upload it. Should there be a majority among the editors to "thumbnail" the animation, then the 180x180 version can be used. --Cleonis | Talk 00:46, 31 October 2007 (UTC)


 * Yes, that would be the best solution. I brought up your browser because, though it's probably insignificant here, some browsers (and some underlying operating systems) do work faster than others. So, I figured this might be a good opportunity to look at that issue as well. If you view this as overkill, then I apologize. —Remember the dot (talk) 04:30, 31 October 2007 (UTC)


 * It's a known issue that thumbnailing upconverts all PNGs (even 2 color ones) to 24 bit color. I assume the process and problem with the animated GIFs is similar, though since GIFs are limited to 8 bit color, I suppose it could be worse.  The essential issue is that the software has no intelligent way of deciding whether it needs to use anti-aliasing or not in order to make a recognizable/appealing thumbnail, so it always applies anti-aliasing and uses as many colors as possible.  For what is is worth, some simple images (like large 4 color logos) do look ugly and pixelated if shrunk without anti-aliasing.  However, right now there is no logic for deciding whether some images, such as your animation, should be rendered with reduced colors to conserve image size.  Dragons flight 04:44, 31 October 2007 (UTC)


 * Good grief, so the thumbnailing is causing bloat everywhere. My animation does need anti-aliasing; the original 256x256 version does employ anti-aliasing. I kept the size down to 64 KB by optimizing the animation. I find it disappointing and frustrating that wikipedia software can bloat an animation from 64 KB to 1000 KB. Effectively, wikipedia is hogging bandwidth by design. As a consequence, wikipedia is effectively barring users with dial-in connection from some of the content. I'm stunned that this is policy. --Cleonis | Talk 09:15, 31 October 2007 (UTC)


 * I've argued for a long time that the image syntax should, where necessary, permit us to specify the bits per pixel and other encoding parameters of the thumbnail image (such as quality for JPEGs). It currently aims to produce a high-quality (and consequently large filesize) thumbnail all the time. Another similar issue is that sometimes RAW format photos are uploaded as PNGs to prevent loss; their thumbnails should be rendered as JPEGs. Conversely, sometimes very small thumbnails of JPEGs should be rendered as high quality to prevent loss of detail. Dcoetzee 09:21, 31 October 2007 (UTC)


 * Is the actual thumbnail process? If so, would using a table instead of a thumbnail resolve the issue?  --—  Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  13:46, 31 October 2007 (UTC)

I think I can answer this one from a technical viewpoint. For some background, I should probably first note that MediaWiki doesn't really scale images by itself: it relies on the ImageMagick image processing tools for that. Now, ImageMagick is a very nice and generic image processing system that can handle just about any format, but it handles some of them better than others. In this case, it happens that, at least in older versions, animated GIFs are one of the types it handles less well.

Another bit of technical background worth explaining is that there are essentially two kinds of animated GIFs: optimized and unoptimized. The unoptimized kind simply contains a sequence of independent images, all of the same size, that are displayed one after another. This, of course, wastes a lot of bytes if the images are mostly identical. In optimized GIF animations, some (often a lot) of this waste is avoided by storing on the first image in full, and for the subsequent images storing only the parts that change. If you extract one of these partial images and view it alone, you'll see that it's usually smaller than the full image and often mostly transparent. When the animation is played, these partial images are then each drawn on top of all the previous ones.

Back until about May 2006, MediaWiki used to scale down animated GIFs by calling ImageMagick with a default set of options that work for most ordinary images. With these options, ImageMagick would treat an animated GIF as if it were simply a set of static images and scale down each one independently. This worked just fine for unoptimized animations, but broke optimized ones very badly: after scaling down, the partial images would no longer overlap the previous one as they should have, leading to animations that had the images breaking into pieces, jumping around in an epilepsy-inducing manner and generally looking like a TV set that's about to blow up.

Anyway, about one and a half years ago, I committed a change to MediaWiki that fixed this problem, sort of. The fix was simply to pass an extra option ("-coalesce") to ImageMagick which made it turn optimized animations into unoptimized ones before scaling them. This made the scaled-down animations look right, but the price, of course, was that the unoptimization would increase their file size, often dramatically. This is, in fact, the behavior you're noticing above.

Now, as it happens, later versions of ImageMagick do have an option to (re)optimize GIF animations before saving them. If I remember correctly, the reason I didn't make use of it back in 2006 was that it was a rather new feature then, possibly new enough that even the Wikimedia servers didn't have that version of ImageMagick yet. Since I wanted a solution that would work everywhere, including MediaWiki installations running on shared web servers with an old ImageMagick version that the wiki owner might not even be able to upgrade, I went with just the "lowest common denominator" solution. Besides, the change was really only intended to fix those cases, such as image categories, where the uploader had no control over the scaling; in articles, the general expectation at the time (enforced by the brokenness of the scaling until then) had been that one should upload animations at the size they're meant to be shown.

Anyway, what about fixing it? It's been 1.5 years now, and a lot of ImageMagick installations have probably been upgraded since, so it might be reasonably safe now to make MediaWiki use the new optimization feature. Alternatively, we could of course leave the default as it is and simply enable that feature in the custom configuration used on Wikimedia servers only. That's of course assuming that we have a sufficiently recent version of ImageMagick, but I'd expect we do, or, at least, can upgrade if necessary. There could, of course, be some unexpected problems, but if not, this may in fact be rather easy to fix. —Ilmari Karonen (talk) 15:52, 31 October 2007 (UTC)


 * Sounds good. I'd suggest either having it as an optional feature, disabled by default, or simply checking the ImageMagick version before passing its args. AmiDaniel (talk) —Preceding comment was added at 18:02, 31 October 2007 (UTC)

(+606) in watchlist
How do I turn these off? Thanks.--Porcupine (see my userpage for details) 16:06, 31 October 2007 (UTC)


 * You want to delete articles in your watchlist? --—  Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  17:08, 31 October 2007 (UTC)


 *  Adrian M. H.  17:20, 31 October 2007 (UTC)

Doesn't seem to work; does it go in my monobook?--Porcupine (see my userpage for details) 17:54, 31 October 2007 (UTC)


 * Yes, your monobook.css. And you likely need to press CTRL+F5 to bypass your cache. AmiDaniel (talk) 18:03, 31 October 2007 (UTC)

Yep, it works. Cheers!--Porcupine (see my userpage for details) 19:06, 31 October 2007 (UTC)

Question about interface
Input boxes in Wikimedia, apparently, have a code identifying them.

For example, [ the signup page] can have [ &wpName=Testing] tacked on the end of it, and "Testing" will automatically be placed in the "Username:" box. A similar thing happens for [ &wpEmail].

I can't remember who told me the codes for these, so I can't ask them. What I'm wondering is, what are the codes for the "Subject/headline:" field and, (if possible) the main message text field, when writing a new message ([ example])? It would greatly assist me in notifications for various activites.

Cheers,  Daniel  23:24, 31 October 2007 (UTC)


 * The "subject/headline:" field is "wpSummary"; it's just the edit summary field in a different place. The main text field is "wpTextbox1", just as it is when you're editing the whole page. This isn't a Wikimedia-specific thing, these are just the "name" attributes of the, or whatever. You can see them by viewing the source of the document – Gurch 01:10, 1 November 2007 (UTC)


 * Parsing URL parameters into default loaded values is entirely developers choice and I don't think it's documented anywhere (and yes, parameter name is usually chosen the same as input field name/id in HTML). To see which parameters are "passed" you have to take a look at the source code and look for those  statements that are "outside"  . For example, in SpecialUserlogin.php it's wpName and some other values, in SpecialUpload.php you can set wpDestFile, wpIgnoreWarning and wpUploadDescription (by the way, the last one could be well used in Upload Wizard), in EditPage.php you only see well known parameters like oldid, section, editintro. Also see mw:Manual:Parameters to index.php.
 * To answer your last question: looks like you cannot set "Subject/headline:", and you can only populate textarea by using  (see mw:Extension:Inputbox) ∴ AlexSm 02:00, 1 November 2007 (UTC)

Simple Question
Are administrators able to salt images to prevent people from uploading an image with that name? --əˈnongahy ♫Look What I've Done!♫ 23:40, 31 October 2007 (UTC)
 * I don't know, but it occurs to me that it would be a pointless exercise. The variation available in the name of any given image is far greater than the choices available for a given article.  Adrian M. H.  00:10, 1 November 2007 (UTC)
 * Yes, admins can salt any title, including images. — Edokter  •  Talk  • 02:12, 1 November 2007 (UTC)

XBM, VML and more.
I think it is a great idea to upload an example on all files, atleast image files, but I am not allowed to, it is wrong type. Can someone help me upload?

Also take a look at this:, and this: ! Helpsloose 01:12, 27 October 2007 (UTC)


 * Well, as far as your first question, we use PNG and SVG instead of XBM and VML. —Remember the dot (talk) 01:24, 27 October 2007 (UTC)


 * [edit conflict]This is the technical board and has nothing to do with content disputes.


 * For the purposes of an encyclopedia there's not much reason to support more formats than we already do. XBM is not a terribly useful format for illustrating articles, and VML is not a web standard. Wikipedia supports its successor format SVG.


 * If you want to demonstrate XBM, it can be simulated with a 2-color GIF or lossless PNG. SVG lacks none of VML's features; since any VML image can be duplicated in SVG there's really nothing to show. But note that both XBM and VML are actually text files. You can simply paste a sample into an article if you feel the need. (Whether other editors on the relevant articles agree they should be there is a different subject, and is not the focus of this board.) TCC (talk) (contribs) 01:33, 27 October 2007 (UTC)
 * It was just to show an example in the articles about the files, nowhere else. And so peoples can see the real thing, not a "fake".Helpsloose 03:47, 27 October 2007 (UTC)
 * There is no visual difference whatsoever. The distinctive thing about these formats is the way they represent image data. But you're not seriously asking for all of Wikipedia to allow these formats just so you can show them in one article, are you? TCC (talk) (contribs) 03:51, 27 October 2007 (UTC)
 * If that is necessary, I taught Wikipedia was free and open and all that.Helpsloose 03:56, 27 October 2007 (UTC)
 * It's not so open that everyone can edit the config files. That would be -- how shall I put it? -- unwise. If you run your own, you can allow whatever uploads you like. This installation of MediaWiki, they don't. TCC (talk) (contribs) 09:30, 27 October 2007 (UTC)

I think using VML as an alternative to SVG is a good idea. More peoples have support for VML than SVG I guess. I usually use an browser with SVG, but when I use Internet Explorer. It is irritating to not be able to see the images like with SVG. See for example browser timline SVG and the details. Helpsloose 18:27, 30 October 2007 (UTC)


 * Lack of SVG support is a major criticism of Internet Explorer. We avoid the issue on Wikipedia by exporting SVGs to PNGs, making them easily viewable on any browser. —Remember the dot (talk) 18:45, 30 October 2007 (UTC)


 * What about exporting them to VML too? So Internet Explorer users can have the same functionality. And if a browser does not suport neither SVG, VML or PNG, are there something Wikipedia can do with that? Helpsloose 19:07, 30 October 2007 (UTC)


 * Internet Explorer users do get the same functionality as other browsers: PNG copies of the images. VML is proprietary and not worth trying to use. All browsers should support PNG. PNG has been around since 1996. For the record though, Internet Explorer 6 has trouble with alpha transparency, so IE6 users should upgrade to IE7 or use a different browser. —Remember the dot (talk) 20:20, 30 October 2007 (UTC)


 * But PNG is maybe not always the best Internet Explorer users can get. VML might be in some cases. And if some find a SVG to VML converter, then there is no problem letting Internet Explorer users get some VML images. OK? Helpsloose 21:36, 30 October 2007 (UTC)


 * First, it is the general policy to use free and open formats when possible. SVG and PNG are free and open formats. VML is not. Second, the developers are not going to go through the effort to integrate an SVG→VML converter into the MediaWiki software. If you are frustrated with Internet Explorer's bugs and shortcomings, as many are, then don't use it. Use a different browser like Firefox or Opera. —Remember the dot (talk) 22:47, 30 October 2007 (UTC)


 * Well, I usually use a browser with SVG, but what about the majority that does not? And do you say you are not allowed to use VML? Sounds strange. The converter does not need to be put into MediaWiki. What if someone searched Altavista to find an on-line converter, just copy and paste, click convert and copy and past back to Wikipedia. Not neccecery for all images of course, not something to use very much time on. Helpsloose 15:54, 31 October 2007 (UTC)


 * All SVGs are exported to PNGs to compensate for buggy or nonexistant SVG implementations. It is not currently worth it to send SVGs directly.
 * VML is a proprietary format. Microsoft could theoretically sue us if it didn't like the way we were using it. We have no such problem with SVG.
 * The difficulty of finding/creating a free JavaScript-based SVG→VML converter, the great decrease in performance it would create, the extremely low benefit, and the difficulty of maintaining it do not justify the addition.
 * —Remember the dot (talk) 18:38, 1 November 2007 (UTC)

Seeking technical collaborator
Hi. I'd like to set up a page to track disputes, the level of dispute and efforts at resolution. The page would track disputes involving Israel-Palestinian topics (or a subset of those). What do I have in mind? Many projects currently track the article Quality assessments: unrated - B - A- GA - FA. I'd like to have a way to track Dispute data. For instance, a listing of articles and dispute-related protections, RfC, 3PO, 3RR blocks, etc. With this kind of data, we'd then be able to see where are the contentious hotspots in the topic area. Does this make sense? Please ask me clarifying questions. Who would be interested in helping set up this kind of page? Feel free to contact me directly. Thanks for your consideration. HG | Talk 20:52, 28 October 2007 (UTC)


 * Well, I've gotten no response. Suggestions on where else I might turn? thanks. HG | Talk 18:42, 31 October 2007 (UTC)


 * First, you're going to do this as a user page (subpage), right? Second, the most likely place to find others interested in helping is at relevant WikiProjects; post a note on the talk/discussion page(s). And third, before you do either, think about whether the information you're coming to come up with is actionable. Let's suppose that you find that there are 25% more disputes (if you're able to somehow summarize disputes into a single measure) in October than in June.  So what? Do you envision that the community will say "oh my!" and jump in and actively solve the problem? That an administrator will lock down all articles? Or what? (The only thing worse than not having data is spending the time to actually collect data and then find that it's not useful at all.)  -- John Broughton  (♫♫) 14:08, 1 November 2007 (UTC)

Edit links now appear on the left
So what's with moving the edit links to the left side of the headings? Is this an attempt to solve the "bunch up" problem when an article has a large number of images on the right hand side? Where was the discussion to make this change? Slambo <small style="color:black;">(Speak) 13:04, 31 October 2007 (UTC)


 * I don't see this. Is there a specific article?  --—  Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  13:13, 31 October 2007 (UTC)


 * Mine are still on the right too. What skin are you using?User: (talk • contribs • email) 13:16, 31 October 2007 (UTC)


 * Some prankster hasn't turned your monitor upside down have they? ;) ('course not!) Are you looking at a page that has ed2 on it? That gets placed on the left.  Adrian M. H.  13:29, 31 October 2007 (UTC)


 * Not sure what happened yet, but they appear to be back to normal. I was looking at a wide range of pages and seeing it on all of them when I posted my question.  I don't see any changes in the history for Monobook.css or Common.css today, and I haven't overridden them with my own versions yet, so I'm still at a loss to find the root of the issue. Slambo <small style="color:black;">(Speak)  16:05, 31 October 2007 (UTC)


 * Okay, it's doing again for me. It seems to be happening on all pages (including this page).  Here's a partial screenshot of the California Zephyr article to show what I'm trying to describe.   I don't know if it matters in this issue, but I'm currently on a Kubuntu 7.04 box running Firefox 2.0.0.8.  The last time this happened, I was using a completely different workstation (that one was using WinXP, but Firefox again).  Slambo <small style="color:black;">(Speak)  19:27, 1 November 2007 (UTC)
 * Also, as I take a quick look back at the screenshot's image page, the borders on the file history table at the bottom of that page are missing. Slambo <small style="color:black;">(Speak) 19:29, 1 November 2007 (UTC)


 * And just as quickly, it's back to normal again, so it's not something to do with my session since I haven't logged out yet. It seems like someone is testing something on one of the style sheets but it's creating these little side effects. Slambo <small style="color:black;">(Speak)  19:35, 1 November 2007 (UTC)


 * This is something of a known bug, though I seem to recall that it was an IE problem. Notice that *all* styles are missing from the screenshot you've provided -- the links are all underlined, the boxes all have sharp corners. The edit link on the left is just one of many hideous things :) When it occurs, simply bypass your cache with CTRL+F5. I'm not aware of any "permanent" fix, so this is the only advice I can give you. AmiDaniel (talk) 21:00, 1 November 2007 (UTC)

Switching off watch-list notices
I have various hacks in my standard.css (for classic skin) to switch off unwanted messages. Unfortunately it doesn't seem to work for the latest arbcom message. I see this is now at MediaWiki:Watchlist-details rather than MediaWiki:Watchdetails. Can anyone suggest what other css changes I might need please? Thanks. – Tivedshambo (talk) 07:57, 1 November 2007 (UTC)


 * This has been sorted by User:ST47. – Tivedshambo (talk) 11:23, 1 November 2007 (UTC)

Duplicated word in display of citation
In the article Theophilus Hastings, 7th Earl of Huntingdon, the reference under "Further reading" displays a duplicated word, sometimes. It uses. If I look at it with the window maximised, the encyclopedia title "Oxford Dictionary of National Biography" appears with "Biography" duplicated, either side of a line break. If I click to reduce the window size, the duplication goes away... but if I reduce the width gradually I can hit a point where "Dictionary" is duplicated instead! I'm using IE 7 under Windows XP. I've never noticed any duplicated words before. Any ideas? PamD 19:30, 1 November 2007 (UTC)
 * It sounds like a browser problem to me. Maybe the browser fails to delete the old copy of a word when the window is resized and the word displayed in a new place. I have IE 7 under Windows Vista and cannot replicate the problem. PrimeHunter 21:50, 1 November 2007 (UTC)

I've seen this sort of thing happen before in other situations when using IE, and yeah, I'm seeing it happen when using IE6. Just a browser bug. --- RockMFR 11:13, 2 November 2007 (UTC)

Template escaping issue
I'm having a problem with an infobox template. If one of the parameters used to generate a table heading cell includes a double exclamation point, this creates an unwanted extra table heading cell. See Template:Infobox Album/testcases. Can anyone think of a good way to escape double exclamation points or otherwise avoid this problem? Wrapping the entire parameter in  won't work as the parameter value sometimes includes   or. Thanks in advance. --PEJL 19:03, 2 November 2007 (UTC)
 * Does writing one of the exclamation marks as &amp;#33; solve the problem? (It will certainly prevent a new table cell being created, but it might break something else, so check first to make sure.) --ais523 19:10, 2 November 2007 (UTC)
 * Thanks, but I'm looking to fix this in the template, rather than where the template is used. (I can use  where the template is used.) --PEJL 19:20, 2 November 2007 (UTC)
 * I suppose you could translate all the table markup in the entire template to HTML. (This technique is used on some other templates IIRC.) --ais523 19:22, 2 November 2007 (UTC)
 * Hmm, I guess that's an option. Are there other advantages/disadvantages to doing so? I was hoping for some magic template like Template:Escape th that would escape just what's needed in this context. ;-) --PEJL 19:33, 2 November 2007 (UTC)
 * Advantages: your template works better if given in a parameter of another template, sometimes. Sometimes becomes easier to maintain. Disadvantages: Sometimes also becomes harder to maintain. Usually uses up slightly more pre-include limit. You have to go to the trouble of converting the entire template (just converting bits is usually unwise). --ais523 19:39, 2 November 2007 (UTC)
 * Thanks for explaining. What effect would using up more pre-include limit have? Note that this is a fairly common template, probably used on about 50000 articles. --PEJL 19:51, 2 November 2007 (UTC)
 * A slightly slower page render time, unless the page was only just below the limit beforehand, in which case it would cause templates later on the page not to render. It's not much of an issue on templates that are only designed to be used once per page, though. See Template limits. --ais523 19:56, 2 November 2007 (UTC)
 * OK then, I guess I'll prototype a conversion of this template to HTML, to see what effect this has on maintainability. Thanks for the help! --PEJL 20:03, 2 November 2007 (UTC)

Mouse
My mouse isn't working properly. I move it around, and sometimes it just stops moving entirely. All of the wires are secure in the back of the computer. What's happening? -Yancyfry 22:02, 29 October 2007 (UTC)


 * Is it a mechanical, aka "ball" mouse? Maybe it needs to be cleaned. - BANG  !  02:51, 30 October 2007 (UTC)


 * Is it a wireless mouse? (Yes, he mentioned wires.  Even wireless mice need a wired component in terms of the receiver for the mouse signals.) Does it need new batteries?  -- Mike  Vitale  16:59, 30 October 2007 (UTC)

It is a ball mouse, but the problem is I already cleaned it. Got all the gunk out of the rollers. But it still continues this problem. -Yancyfry 21:35, 30 October 2007 (UTC)


 * cough AmiDaniel (talk) 18:11, 31 October 2007 (UTC)
 * Could be loose wires or connections, could be broken circuitry, could be age, could possibly be spyware or viruses. I doubt it's the last, though.  x42bn6 Talk Mess  14:14, 1 November 2007 (UTC)


 * Clean the mouse with canned air. Not an air horn, but actual "canned air".
 * Ensure your antispyware/virus software is up-to-date. Some of these can slow down your computer.
 * WINDOWS ONLY: Monitor Task Manager to monitor CPU usage. ("System Idle Process" having more than 95% is normal - that's how much of the CPU is not being used.  Firefox is often a memory hog, so while you're at it, check "memory" too:that's a known issue.)
 * ~user:orngjce223 how am I typing? 14:25, 2 November 2007 (UTC)

Heh, thanks for your imput, but I can't output.

Yeah, it was some malware that was in my compy, but I removed it. Thanks. -Yancyfry 04:49, 4 November 2007 (UTC)

Hiding the fundraiser box
I changed User:NE2/monobook.css when the fundraiser started to hide it, but now it's showing up again. I assume something was changed; how do I hide it now? --NE2 04:32, 4 November 2007 (UTC)
 * There should be a "[Hide this message]" button while logged in.  Cbrown1023   talk   05:09, 4 November 2007 (UTC)
 * That doesn't hide the box that shows how many people have donated. --NE2 05:19, 4 November 2007 (UTC)
 * I've seen an odd bug in Firefox (2.0.0.9) that the show/dismiss does not work unless it is in Tab#1. — xaosflux  <sup style="color:#00FF00;">Talk  05:27, 4 November 2007 (UTC)

For hiding:


 * 1) siteNoticeBig { display: none; }
 * 2) siteNoticeSmall { display: none; }

Should do it. Dragons flight 05:30, 4 November 2007 (UTC)
 * Yep, that did it. Thanks. --NE2 05:34, 4 November 2007 (UTC)

Peerreview
I added User:AndyZ/peerreviewer tool to my User:Siddhant/monobook.js.

The the does not seem to work i.e. it does not show the peerreview link next to log out. (I use Opera.) --Siddhant 10:31, 26 October 2007 (UTC)


 * Are you in edit mode, rather than normal (viewing) mode? -- John Broughton (♫♫) 14:17, 1 November 2007 (UTC)

Even in the edit mode mode the link dosen't show up. Please have a look at my User:Siddhant/monobook.js. --Siddhant 15:17, 4 November 2007 (UTC)

Photo overlaps
Here is a screenshot of what I see at United States presidential election, 1976 using Firefox 2.0.0.9. This fairly large photo, about halfway down the article, overlaps a candidate gallery pretty obnoxiously. I took a look using Internet Explorer 6, and it did not overlap. Instead, it pushed a ton of white space between the headline "Candidates Gallery" and the gallery itself. Tempshill 06:04, 4 November 2007 (UTC)
 * Browser bugs... gotta love'em. I moved the photo down to the convention section. — Edokter  •  Talk  • 18:14, 4 November 2007 (UTC)

What's in a name?
What is the full range of allowable formatting for image names? I've found the following are all allowed on the English Wikipedia: See User:Carnildo/sandbox4 for some examples of this. Is there anything I've missed? --Carnildo 06:16, 4 November 2007 (UTC)
 * The first letter of the "image" prefix may be uppercase, lowercase, or the Turkish "I with dot".
 * The first character of the image name may be uppercase or lowercase. The Turkish "I with dot" is not permitted if the character is an "I".
 * Spaces and underscores are equivalent.
 * Anywhere where there's a space, any number of spaces may be used.
 * Spaces between the "Image" prefix and the ":", and the ":" and the image name, are permitted.
 * Characters in the image name may be percent-encoded (URL-escaped).
 * Characters in the image name may be HTML-encoded.
 * Characters in the image name may be named HTML entities.
 * Unicode left-to-right and right-to-left markers may appear anywhere in the image name. Presumably, other Unicode directional-rendering markers can too.
 * Well, I know that an image name with two or three consecutive apostrophes is allowed, but such an image then can't be included. I consider this to be a bug in the software (see 8932). Various characters are banned in image names (at least, and possibly others). I don't know what the full rules are, though; I suppose looking at MediaWiki's code would be the only way to find out. --ais523 11:30, 4 November 2007 (UTC)
 * I have looked at it. The "I with dot"/"I"/"i" equivalence isn't in there, and neither is any mention of Unicode directionality markers.  I was wondering what else I've missed. --Carnildo 17:54, 4 November 2007 (UTC)
 * I haven't tested it, but I suspect images with multiple consecutive apostrophes in their names will work if you replace some or all of the apostrophes with .  Certainly it works that way with ordinary wikilinks.  But yes, for the full details you'll probably need to check the source (specifically  ) and  ).  —Ilmari Karonen (talk) 22:23, 4 November 2007 (UTC)
 * By the way, one thing you missed is that namespace names are completely case-insensitive: "IMAGE:" or even "iMagE:" works just as well as "Image:". Incidentally, the "I with dot" issue may be a bug in the way   does normalization.  (It probably should use   instead of  .)  —Ilmari Karonen (talk) 22:50, 4 November 2007 (UTC)

Tables' columns misaligned
In List of war crimes, there are multiple tables with the same columns, but due to the tables' structures, the columns are all mis-aligned. This makes the article look very choppy, not at all nice. How can these columns be lined up so they are on the same verticals? Hmains 04:28, 31 October 2007 (UTC)


 * You need to explicitly set the column widths. See the tables in Tangerine Tree for an example of how I fixed the same problem.  --—  Gadget850 (Ed)  <sup style="color:darkblue;">talk  -  13:16, 31 October 2007 (UTC)


 * I tried to follow Tangerine Tree, but as you can see in the List of war crimes, my attempts were not very successful. Any further suggestions would be appreciated Hmains 00:06, 3 November 2007 (UTC)

If you fix too many column widths, it will risk damaging usability, particularly for users with narrow viewports or large text sizes. At the most, specify a percentage to allow a degree of flexibility. The quantities of cell content are very different between some of those tables, which will hamper efforts to make their widths identical. I don't think that it looks bad as it is apart from the number of columns, which are cramped on narrow viewports.  Adrian M. H.  13:38, 31 October 2007 (UTC)


 * OK, how do I use percentages? Where is an example? Hmains 00:06, 3 November 2007 (UTC)


 * The same way as px, but with %.  Adrian M. H.  00:43, 3 November 2007 (UTC)


 * I prefer to set table widths using em spaces. The problem with percentages is that sometimes tables look terrible with a widescreen monitor (16:10 or 16:9 aspect ratio) instead of "normal" (4:3 aspect ratio) screens.  The beauty of em spacing is that the tables scale properly with the browser font size.  The only thing you have to be careful of is that you can't simply use  ; you need to use  .  Hope this helps, Andrwsc 20:52, 5 November 2007 (UTC)

Messy messy messy
as seen by an anonymous viewer.]] Hello. I was wandering the site without signing in, and I noticed how little things seem to have accumulated to generally make it look messy. When I'm signed in, I don't see these things and Wikipedia generally looks great. However, when a user without an account views an article, they see the image I'm included here. And this is when viewing a decent featured article. The text of the introduction doesn't start until halfway down the screen. Given the effort that goes into presentation, it seems a shame that we are presenting such a poor face to newer and less involved users. Is there anyone responsible for the general look of the site? It feels like little things have been added, each not that intrusive, which between them have spoiled the look. Skittle 13:12, 1 November 2007 (UTC)


 * With regard to the semi-protected tag, I thought there was a preference for just using the little padlock symbol, which is much better. The ugly begging banner will disappear soon. The combination of those two large banners is unfortunate.  Adrian M. H.  13:46, 1 November 2007 (UTC)


 * Maybe a bot should go around and remove the warning banner, replacing it with a padlock? (As for the begging, I think that's scheduled to last for roughly two months, which is an unfortunately high percentage of the year.) -- John Broughton (♫♫) 13:52, 1 November 2007 (UTC)


 * Incidentally, it would appear that you are using Internet Explorer version 6. This browser has many known bugs that will diminish your ability to view Wikipedia properly. I would encourage you upgrade to Internet Explorer 7 or use a different browser such as Firefox or Opera. All three of these programs can be downloaded free of charge. —Remember the dot (talk) 18:42, 1 November 2007 (UTC)
 * Safari is another acceptable alternative to IE. EVula // talk // &#9775;  // 21:08, 1 November 2007 (UTC)


 * Yes, but there is not currently a stable version of Safari for Windows. —Remember the dot (talk) 02:05, 2 November 2007 (UTC)
 * Just out of curiosity, is there some sort of organized framework wherein Wikipedia makes technical decisions about which past browser versions which have known bugs will be supported with workarounds to those known bugs? I ask this because on a website I manage I see a visitor browser usage breakdown of 62.37% IE, 34.26% firefox, 2.79% safari, 0.35% opera, 01.2% mozilla, and 0.12% netscape, and I presume that Wikipedia is seeing similar breakdowns. The 62.37% of users using IE break down as 63.87% 6.0, 35.20% 7.0, and the rest 5.x versions. So, 100*.6237*.6387=39.84% of the users who hit my site are using IE 6.0.  Has Wikipedia made a considered marketing & technical decision to turn their back on known-browser-bug-workaround support for 4 out of 10 users and decided to just advise those users one-by-one to upgrade or change browsers? One wonders. -- Boracay Bill 03:10, 2 November 2007 (UTC)


 * We do support Internet Explorer 6 as much as possible, sometimes through workarounds. But workarounds are imperfect and can quickly become nasty hacks. The best way to experience Wikipedia both from a technical and a user standpoint is though an up-to-date browser, so it is recommended that users avoid using Internet Explorer 6 when possible. We would not turn our backs on 4 out of 10 users if we can help it. —Remember the dot (talk) 05:21, 2 November 2007 (UTC)


 * Back to the point, yeah, this is unfortunate. The begging banner sucks and should be banned.  And I never realized the padlock banner problem was this annoying before, but, yes, it's annoying.  I'm not even certain it's a great idea to replace it with a padlock icon, though - unless this banner with all its text will appear when the user tries to click "edit"?  Tempshill 06:09, 4 November 2007 (UTC)


 * Thanks. So, is there someone or some group responsible for the general look, or do we just hope? I'd thought we prefered the little padlock too, and I'm pretty sure people get explanatory text if they try to edit, but I wasn't sure if there were some instances when we prefer the banner. Sounds like not. And thanks Remember the dot, but I made a conscious decision not to upgrade when IE7 came out. I might do so in a while, but I prefer the layout of 6 (most things I need are easily accessible) and I wanted to give IE7 time to get as stable as possible (when my family installed IE7 to their computer, it crashed it quite horribly and took some effort to sort out. I imagine that isn't a problem any more, but I wait...) Skittle 17:31, 5 November 2007 (UTC)