Jump to content

Wikipedia:Village pump (technical)/Archive 57

Add links
From Wikipedia, the free encyclopedia
Village pump (technical) archive  

This page contains discussions that have been archived from Village pump (technical). Please do not edit the contents of this page. If you wish to revive any of these discussions, either start a new thread or use the talk page associated with that topic.

< Older discussions · Archives: A, B, C, D, E, F, G, H, I, J, K, L, M, N, O, P, Q, R, S, T, U, V, W, X, Y, Z, AA, AB, AC, AD, AE, AF, AG, AH, AI, AJ, AK, AL, AM, AN, AO, AP, AQ, AR, AS, AT, AU, AV, AW, AX · 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25, 26, 27, 28, 29, 30, 31, 32, 33, 34, 35, 36, 37, 38, 39, 40, 41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 59, 60, 61, 62, 63, 64, 65, 66, 67, 68, 69, 70, 71, 72, 73, 74, 75, 76, 77, 78, 79, 80, 81, 82, 83, 84, 85, 86, 87, 88, 89, 90, 91, 92, 93, 94, 95, 96, 97, 98, 99, 100, 101, 102, 103, 104, 105, 106, 107, 108, 109, 110, 111, 112, 113, 114, 115, 116, 117, 118, 119, 120, 121, 122, 123, 124, 125, 126, 127, 128, 129, 130, 131, 132, 133, 134, 135, 136, 137, 138, 139, 140, 141, 142, 143, 144, 145, 146, 147, 148, 149, 150, 151, 152, 153, 154, 155, 156, 157, 158, 159, 160, 161, 162, 163, 164, 165, 166, 167, 168, 169, 170, 171, 172, 173, 174, 175, 176, 177, 178, 179, 180, 181, 182, 183, 184, 185, 186, 187, 188, 189, 190, 191, 192, 193, 194, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215, 216, 217

Math rendering error

I had a momentary math rendering error on the Water, gas, and electricity page where the math was rendered as:

Failed to parse (Cannot write to or create math output directory): n=6
Failed to parse (Cannot write to or create math output directory): m=9

It returned to normal shortly afterwards. Dcoetzee 21:19, 20 February 2009 (UTC)

That's the sort of error a purge normally solves. Algebraist 22:45, 20 February 2009 (UTC)

Downtime

We had some site downtime from about 00:50 to 01:50 UTC February 21 due to a combination of a failed fileserver and some sloppy old configuration entries which caused the web servers to stall waiting for the file server. Service has been restored; web servers are no longer as dependent, plus the fileserver is back online. --brion (talk) 02:31, 21 February 2009 (UTC)

Outlet for PHP/MySQL skills

I am fairly well skilled in PHP and MySQL and wanted to know if there were any outlets available on Wikipedia where I could use my coding skills? I would be willing to provide samples of my code if necessary. Thanks in advance! kilbad (talk) 05:11, 21 February 2009 (UTC)

See How to become a MediaWiki hacker at MediaWiki.org for info about writing code for MediaWiki. Graham87 05:44, 21 February 2009 (UTC)

Automatic text to SVG conversion tool?

Currently you cannot rotate table column headers vertically except using an IE-only CSS attribute. The cross-browser solution is to use SVG and image maps (see here for an explanation). Is there a tool or extension that will allow such text to be created automatically? SharkD (talk) 01:27, 15 February 2009 (UTC)

I'm envisioning that it would work somehow like MathML does on Wikipedia. SharkD (talk) 01:39, 15 February 2009 (UTC)
Because SVG creates an image from a kind of XML markup, it would be pretty simple to do with php. Create an image containing text in whatever image editor you use and save as .SVG. Then open the file in a text editor. Make the content into a series of echo statements and replace the example text with a variable. You can then call the script by sending the variable in the URL.
(edit) - I have tried this - see example below:
<?php
header("Content-type: image/svg+xml");

/* this file is svg-text.php */

echo "<?xml version='1.0' standalone='no'?>\n";
echo "<!DOCTYPE svg PUBLIC '-//W3C//DTD SVG 1.1//EN' ";
echo "'http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd'>\n\n";

echo "<svg width='100%' height='100%' version='1.1' ";
echo "xmlns='http://www.w3.org/2000/svg'>\n\n";

echo "<g transform='rotate(90)'>\n";
echo "<text id='TextElement' x='0' y='0' style='font-family:Arial;font-size:24'>".($_GET['text'])."\n\n";
echo "</text>\n";
echo "</g>\n";
echo "</svg>\n";

?>

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">

/* this file is rotated-text.php */

<?php function rotateText($text) {
   echo '<embed src="svg-text.php?text='.$text.'" type="image/svg+xml">';
 }
	
?>

<html>

<head>
<title>Rotated text with SVG and php</title>
</head>

<body>

<h1>Using SVG to create rotated text with php</h1>

<p><?php rotateText("Hello World!"); ?></p>

</body>

</html>
See the example in use here. Every time you want a piece of rotated text to appear, insert
<?php rotateText("Whatever text you want"); ?> -=# Amos E Wolfe talk #=- 12:32, 15 February 2009 (UTC)

Hello Amos, how many character sets "scripts" does this this support? If you can get it to select an appropriate font based on this it may be useful in the discussion above. — CharlotteWebb 12:27, 15 February 2009 (UTC)

The example above selects the font-family in the same way as CSS. If the font is not available it will not display in that font. It is always advisable to use generic font descriptions such as "serif", "sans-serif", "monospace", etc. which will display whichever font has been set for that type on the user's system. -=# Amos E Wolfe talk #=- 12:57, 15 February 2009 (UTC)
I was referring to the PNG renderer which (after experimenting with it) I discovered will not render any non-latin letters. I tried a Russian word and got a raster image with several squares in it. — CharlotteWebb 13:12, 15 February 2009 (UTC)
Try using these fonts instead. SharkD (talk) 13:45, 16 February 2009 (UTC)

That is a list of fonts installed for rsvg or ImageMagick or whatever Brion uses to convert SVGs to PNG. These may or may not be the same as fonts AmosWolfe's tool has. The link I tried was:

http://www.northantscamra.org.uk/signature.php?text=русский&size=24

And it gives me seven squares because the tool either does not have an appropriate font, one that includes the Cyrillic character set (the f'reign word is how one writes "Russian" in Russian), or it has one but fails to select it for rendering. I got the same result with all other non-Latin scripts I tried, which is bad because these are the cases where an image placeholder might be desired . — CharlotteWebb 17:55, 16 February 2009 (UTC)

Er, what are you trying to do exactly? And, how were you able to manage to "switch" fonts using the above tool? SharkD (talk) 03:56, 18 February 2009 (UTC)
Trying to get somebody to develop something that will choose the appropriate font before converting from SVG to PNG. Uh, I didn't manage to do anything—did you not notice PNG images had rectangles in place of non-latin letters? You can't tell me that problem is on the client side (and I know it isn't), as it is converted from vector to bitmap before being sent back. — CharlotteWebb 09:14, 21 February 2009 (UTC)
Well, I noticed that the particular font used (an uncommon one that few users will likely choose in any case) doesn't have the characters needed to render the text correctly. This can be resolved by making Unicode-capable fonts available to users, of which there are a sufficiently large number. There are resources available on the Web (such as this one) that can be used to determine which fonts are suitable for rendering a particular script. SharkD (talk) 14:42, 21 February 2009 (UTC)

PNG compression

Resolved

I'm aware that PNG is already a compressed image format, but I read that it can be compressed further. What programs should I use? Is the additional compression lossless?Smallman12q (talk) 02:27, 18 February 2009 (UTC)

pngcrush is a program for optimizing the compression of PNGs; it's lossless. --Golbez (talk) 02:34, 18 February 2009 (UTC)
I use PNGOUT. It only does lossless compression. It works very well and is easy to use. --- RockMFR 02:35, 18 February 2009 (UTC)
I think using these utilities is pointless, as Wikipedia will resize the images at some point anyway, thereby "undoing" your efforts. SharkD (talk) 01:02, 19 February 2009 (UTC)
As well as attempting to increase compression of a png, a utility like pngcrush can remove unwanted embedded data chunks in the png. A useful discussion of using pngcrush or similar to address the problems Internet Explorer has with displaying some pngs can be found here. --RexxS (talk) 02:14, 20 February 2009 (UTC)
I don't believe resizing undoes compression, it simply takes the current image and extrapolates. It does not add additional info to the picture.Smallman12q (talk) 13:41, 21 February 2009 (UTC)
Resizing the image involves creating an uncompressed "working" copy. This copy will then be re-compressed using whatever compression scheme Wikipedia uses by default once the operation is complete. Since Wikipedia doesn't use PNGCRUSH by default, the result will be the same as if you hadn't used the utility to begin with. This can be tested by uploading a "crushed" image and then comparing it to a resized version served by Wikipedia. SharkD (talk) 18:12, 21 February 2009 (UTC)

Template:Convert

Resolved
 – duplicate section ηoian ‡orever ηew ‡rontiers 05:43, 18 February 2009 (UTC)

Something has happened to the {{convert}} template which is causing it not to work at all all across wikipedia. For example, {{convert|123|ft|4|in|m|2}} gives this result:- 123 feet 4 inches (37.59 m) This template is used in millions of Wikipedia articles. Mjroots (talk) 05:42, 18 February 2009 (UTC)

Issue already noted, see above section, not one template. It is wiki-wide ηoian ‡orever ηew ‡rontiers 05:43, 18 February 2009 (UTC)
In future, please substitute templates in cases like this, so that the results of the error are preserved, even after the template's behaviour changes. Brian Jason Drake 09:59, 21 February 2009 (UTC)

30 seconds to load a normal page

It consistently takes 30-40 seconds to load a full-length article (try USA or Canada for example). What exactly is causing these long pages to take so much time to load (table layout? css? javascript? lack of server hardware? images? etc)? It's driving me insane, and causes me to use Wikipedia far less than I otherwise would. It breaks the flow of conversation when I try to look something up quickly, and horribly breaks usability standards.

"Research on a wide variety of hypertext systems has shown that users need response times of less than one second when moving from one page to another if they are to navigate freely through an information space." - http://www.usabilityviews.com/uv000116.html

"Note that the 1 sec. response time limit is required for users to feel that they are moving freely through the information space. Staying below the 10 sec. limit is required for users to keep their attention on the task." - http://www.useit.com/alertbox/sizelimits.html

Oh, and I couldn't find anything in the FAQs about this. Thanks.96.50.4.248 (talk) 18:35, 19 February 2009 (UTC)

The articles United States and Canada are veeeeery long. I'd recommend moving some of that content into more specific articles per Wikipedia:Summary style. —Remember the dot (talk) 18:46, 19 February 2009 (UTC)
30% of the html content is navboxes. (150kb of navboxes in the 650kb USA article (according to "view source")). That's a bit daft.
I have a reliable highspeed cable modem (600kbps standard download speed), so it's not a problem at that level. My browser is stock firefox, so everyone else with default setups is experiencing similar slowdowns. (I'll fiddle with pipelining/layout settings now, see if that helps.) 96.50.4.248 (talk) 18:33, 20 February 2009 (UTC)
Applying all the firefox about:config tweaks gets the load time down to between 15 and 25 seconds. Still not good. 96.50.4.248 (talk) 18:41, 20 February 2009 (UTC)
Took about five seconds for me to get United States shown, and I'm both logged in (wikipedia is much faster for logged out users, for much bigger cache arena, etc) and in some remote corner of the world. USA article has ~300kb of content (though rendering starts sooner) - so either you are using browser that is incapable of dynamic rendering, or you have very very slow network link. Wikipedia page opening times are way better than any web average, except for some rare occasions when huge articles have to be re-rendered (or simply people with slow slow links). Domas Mituzas (talk) 09:05, 20 February 2009 (UTC)
Approx 17 seconds for United States for me. DuncanHill (talk) 13:26, 20 February 2009 (UTC)
20 seconds. Someone who doesn't know about this might've given up far before then. ~user:orngjce223 how am I typing? 23:10, 20 February 2009 (UTC)
For me, if its already cached in the browser, it takes about 4 seconds, about 9.5 when purging the browser cache, and that's including all of my custom JS; with JS disabled, the browser cached version is <2 seconds and the uncached version is <4. Purging the parser cache (action=purge) of course takes a lot longer. Mr.Z-man 23:38, 20 February 2009 (UTC)
Logged in using Opera: 17 seconds before data transfer begins, followed by 8 seconds to download and render. Logged out using Lynx: 2 seconds total. --Carnildo (talk) 02:42, 21 February 2009 (UTC)
If it's not cached: <!-- Served by srv187 in 23.038 secs. -->. That is unusually long, and I'm not quite sure what's causing it on that page. --Amalthea 13:09, 21 February 2009 (UTC)
Using Chrome, so fast I'm not sure, about 2 seconds, and it wasn't cached in the browser. dougweller (talk) 13:35, 21 February 2009 (UTC)
Both pages take about 6 seconds logged out (using Firefox), when logged in it increases to 17 seconds (Canada) and 27 seconds (United States). During this additional time, the status bar shows "waiting for en.wikipedia.org". It seems to be taking longer recently than in the past, I've noticed this on subpages of List of United Kingdom locations. —Snigbrook 15:01, 21 February 2009 (UTC)

Article history cross outs

What is this cross out in contribution histories→[1] and what does it mean?—70.19.73.184 (talk) 09:21, 21 February 2009 (UTC)

I was about to ask the same question. wodup 10:03, 21 February 2009 (UTC)
That's what "oversight" now looks like. --NE2 10:04, 21 February 2009 (UTC)
So there's now a public log of oversightings? Is this a permanent change? wodup 10:09, 21 February 2009 (UTC)
It means the content was removed for apparently containing "threats of violence against an editor" [2]. Granted if somebody was threatening violence against me, I'd like to know about it (rather than be attacked by complete surprise) but that's just me. I'm guessing the edits were nuked due to personal information accompanying the threats, because in all other cases it would be more helpful to have a diff to point at when contacting the police. However in my own experience the police tend not to consider words actionable, and are reluctant to do anything until sticks and stones are involved, other than smile like Eddie Haskell and say "yes ma'am" and "have a nice day ma'am" and assure you that when seconds count they'll be only minutes away… so maybe the evidence value of such edits is over-rated. — CharlotteWebb 10:10, 21 February 2009 (UTC)

Double redirects now work

Look what happens when you go to Interoceanic Railway and look how the redirect page displays. This doesn't work with more-than-double redirects. There might be a further benefit to this, in that redirects can be made to subtopics that may be split out in the future, but the double redirect fixing bots would need to be stopped. --NE2 10:03, 21 February 2009 (UTC)

That would be a good reason to block any that are currently running. Human editors will be harder to negotiate with. There are quite a few who "don't see any reason to ever link to a redirect", and who think "piping" every link makes the servers go faster (maybe because the internet is a series of tubes). We really need to need to update the page-move interface, etc. to conspicuously say "you don't really need to fix 'double redirects', in fact there might be a good reason to leave them as-is". Maybe link to a page explaining this. — CharlotteWebb 10:25, 21 February 2009 (UTC)
MediaWiki:Movepage-moved and MediaWiki:Movepagetext need to be changed. Algebraist 10:29, 21 February 2009 (UTC)
Updated them. I'm very glad to see this feature finally enabled. Happy‑melon 11:20, 21 February 2009 (UTC)
Hang on, this is not supposed to be happening (T19570). Happy‑melon 11:23, 21 February 2009 (UTC)
Uh, what? I thought this was normal behavior these past couple weeks or so. You mean they gave us a new feature by accident? — CharlotteWebb 12:11, 21 February 2009 (UTC)
Yes, that's exactly what happened. The feature has been available since we had those issues with the broken redirects, but it was supposed to be disabled. However, a one-character error in the code meant that one more level of redirection was allowed than the config setting specified (so currently only single redirects are supposed to work, but actually double redirects are now allowed (triple redirects still shouldn't be)). The bug has now been fixed and so we'll lose this functionality on the next code update. Unless we get the devs to change the config for en.wiki to explicitly allow them, of course... Happy‑melon 12:29, 21 February 2009 (UTC)
Oh bloody hell. Yes, changing the config would be more sensible than changing double redirects which were created intentionally with the knowledge that they'd work as expected. — CharlotteWebb 12:37, 21 February 2009 (UTC)
I'd absolutely support changing the config. I personally would even allow triple-redirects since there a number of frequent cases with music articles where they would be very handy, as I've previously explained here, and where the work and edits currently needed to keep those redirects working certainly outweighs the performance impact of resolving those redirects. --Amalthea 12:57, 21 February 2009 (UTC)
Yes, someone get onto the devs (well I guess it's the system administrators really, but in practice it seems to come down to the same thing) to let us keep at least double (if not triple or quadruple) redirects. I thought this was the second long-awaited change finally come to fruition this week (alongside category redirects) - sorry to hear it was only an accident. Something seems badly wrong in developer-editor communications if changes like this can be made to the software and the community not even made aware of it so it can decide whether it wants them turned on or not (or how to begin using them). This is the sort of thing we should see announced at the top of our watchlists - far more relevant than announcements of elections for various degrees of !bureaucrats or the millionth discussion on date linking.--Kotniski (talk) 18:46, 21 February 2009 (UTC)

see also Wikipedia_talk:Tools/Navigation_popups#popups_contribs_link_invalidation

I am a sysop at zhwikip, we found that the navigation popup's contribs link become invalid after we changed the link "Special:Contributions" to "Special:用户贡献". See this screenshot:zh:File:Wikicontrib.PNG. I checked zh:MediaWiki:Gadget-popups.js and found I have to ask for help here. --Kegns (talk) 13:19, 21 February 2009 (UTC)

Oversight logs

[3] It appears logs of oversight remain visible. Is this a recent change? Gimmetrow 19:26, 21 February 2009 (UTC)

Yes, RevisionDelete is now active on all Wikimedia wikis; rendering the Oversight extension obsolete. Hopefully the entries that were oversighted under the old system will eventually be restored to visibility in the same fashion, greatly improving transparency. Happy‑melon 20:43, 21 February 2009 (UTC)
This is a very cool feature, it's nice to see the recent stuff installed here. Gary King (talk) 21:37, 21 February 2009 (UTC)

CSS problem

If you look at the bottom box here, you'll see that the header DIV is missing its top border in IE7. I was wondering if anyone knew of a fix for this. If I change the DIV's position to static then the border is rendered properly but the "hide" text becomes misplaced. I've also tried adding a top to the DIV, but it has no effect. SharkD (talk) 02:53, 18 February 2009 (UTC)

Have a look at the NavFrame code in Common.css; I see a lot of styling code conflicts, especially in padding and margin. Have you tried without any styling (except color) to see how it comes out? — Edokter • Talk • 03:16, 18 February 2009 (UTC)
The style changes are intentional. Is there a way I can keep the hide/show functionality without using the NavFrame classes? SharkD (talk) 03:33, 18 February 2009 (UTC)
Any ideas? SharkD (talk) 15:13, 21 February 2009 (UTC)
I'm on a Mac, so I can't test IE, but I'm wondering what would happen if you changed the 'top' parameter in <div style="position:absolute;top:0;right:50px;"> to a higher number. I've never had good luck with nested divs on IE, I'll confess. --Ludwigs2 07:27, 22 February 2009 (UTC)
A higher "top" value would just place it X number of pixels away from the top; currently, the code states that the element should be 0 pixels from the top. EVula // talk // ☯ // 07:42, 22 February 2009 (UTC)

Is there a way of having bot edits show up as regular edits, on a per-bot basis?

I ask because there's are a few bot unusual work descriptions. Specifically I have ArticleAlertbot in mind, which updates special reports called Article Alerts for subscribing wikiprojects. I understand that you can show/hide bot edits because most of these edits are page maintenance, placing dates in {{fact}} and other cleanup templates, page archiving, etc... However, for bots like ArticleAlertbot, which updates pages that are for the most part only edited by bots, hidding bot edits seems counterproductive. The only way you can see the page was edited is enabling ALL bot edits to show up, and then you get watchlists full of Cluebot vandalism reversions and the like. This also applies to bots which deliver newsletters like User:Ralbot. These bots aren't making maintenance edits, these bots are posting actual content which is meant to be read. Headbomb {ταλκκοντριβς – WP Physics} 01:07, 20 February 2009 (UTC)

The obvious solution is for the bot to not be in the group 'bots'. This would also strip it of other rights it might need, however. Algebraist 01:09, 20 February 2009 (UTC)
What would those rights be (typically)? If ArticleAlertbot runs on the toolserver, does that make any difference here?Headbomb {ταλκκοντριβς – WP Physics} 01:24, 20 February 2009 (UTC)
According to WP:User access levels, the rights of the group 'Bots' are the rights of autoconfirmed users plus apihighlimits, autopatrol, bot, markbotedit, and nominornewtalk. The only one of these ArticleAlertbot might need is apihighlimits. Algebraist 01:32, 20 February 2009 (UTC)

Use the edit API. MER-C 01:29, 20 February 2009 (UTC)

Well, the bot does use the edit API. (Not sure how that solves the problem though.) For the rights, the bot might, at some point, need to use apihighlimits; namely, when its subscription category becomes very large (>500 entries). --B. Wolterding (talk) 13:59, 22 February 2009 (UTC)
OK, I need to correct myself: The bot uses JWBF, but for some reason JWBF skips the API when writing pages (it uses index.php). No wonder it doesn't expose a "mark as bot edit" parameter. So there might be a way here - though it would be a major rewrite. --B. Wolterding (talk) 18:01, 22 February 2009 (UTC)

Pages moved from userspace to the mainspace should be included in Special:NewPages

It has occurred to me that a vandal who's familiar with the mechanics of Wikipedia could easily create a hoax or an attack page in his personal userspace, then wait a few days, then perform a page move to the article space. This is a very simple way to make a page virtually invisible to newpage patrollers. I'm not saying it is done on a regular basis, just that it can be done. And there is a simple way to fix this problem: Special:NewPages should include, in addition to pages newly created in the article space, any page move to the article space from any non-article namespace, listed at the time of the page move and not that of the page creation.

And, uh, before you throw WP:BEANS at me, please be aware that I am quite aware of it. Somehow, I don't think vandals come to this page very often. -- Blanchardb -Me•MyEars•MyMouth- timed 23:21, 20 February 2009 (UTC)

NewPages isn't designed to catch any and all subtle vandalism. That's what RC is for. --- RockMFR 02:43, 21 February 2009 (UTC)
At 160 items per minute, RC is not adequate for this purpose. -- Blanchardb -Me•MyEars•MyMouth- timed 05:04, 21 February 2009 (UTC)
This is already on bugzilla somewhere, actually. Someguy1221 (talk) 03:06, 21 February 2009 (UTC)
Glad to hear that, but I went there, and the place looks rather... dead... -- Blanchardb -Me•MyEars•MyMouth- timed 05:04, 21 February 2009 (UTC)
It's bug 12363. Bugzilla is most certainly not dead, but progress on individual bugs there can be glacial. Graham87 05:48, 21 February 2009 (UTC)
The user namespace can be selected in Special:Newpages, although it isn't very effective for this purpose as users often replace the redirect created by the move with a new article. Until moves appear in Newpages, the easiest way to find these moves is to search the move log for "moved User". —Snigbrook 14:33, 21 February 2009 (UTC)

The determined hoaxer could create the article, delete it immediately, then undelete (a month or so?) later when it would no longer appear on Special:Newpages. Does that mean Newpages should also be cluttered with freshly undeleted pages? Or there could be a redirect which is over-written by an article long after the redirect was created. Does this mean every redirect should be included in Newpages? Or would that be enough? Maybe you'd need to include every edit to every redirect, to make sure you catch every redirect being changed into an article. I assure you there are a dozen other ways to sneak things under "the radar" of new page patrol. Some are more plausible than others, but where would you draw the line (short of making Newpages completely redundant to Recentchanges)? — CharlotteWebb 09:36, 21 February 2009 (UTC)

Suspecting admins of sneaking in hoaxes seems excessive. Algebraist 10:30, 21 February 2009 (UTC)
Oh, does the name "Wonderfool" not ring a bell? — CharlotteWebb 11:09, 21 February 2009 (UTC)
No. Care to be less obscure? Algebraist 11:07, 22 February 2009 (UTC)
I could be wrong, but I was under the impression that recreated articles that had previously been deleted already appeared in Newpages. I support the idea of having pages moved from userspace appear in Newpages, listed as per the time of the move. Trying to watch all userpages or all moves just isn't adequate. How about listing pages that are changed from redirects into articles? ☺Coppertwig (talk) 16:28, 21 February 2009 (UTC)
I think recreations appear in Newpages, but if a page is restored after being deleted the undeletion doesn't (i.e. it's something that can only be done by admins). —Snigbrook 16:39, 21 February 2009 (UTC)

Hiding the title of the Nedersaksisch WP's main page

I really can't get this right... on the nds-nl wikipedia the heading "Veurblad" (main page) used to be hidden and the tab "artikel" (article) used to say "veurblad / vuurblad" (main page) but it doesn't work. Anyone know why or what I can do about it? Thanks in advance Sεrvιεи | T@lk page 21:13, 21 February 2009 (UTC)

The English Wikipedia hides it with these lines in MediaWiki:Monobook.css:
/* Don't display some stuff on the main page */
body.page-Main_Page #deleteconfirm, body.page-Portal_Wikipedia #deleteconfirm,
body.page-Main_Page #t-cite,
body.page-Main_Page #lastmod, body.page-Portal_Wikipedia #lastmod, 
body.page-Main_Page #siteSub, body.page-Portal_Wikipedia #siteSub, 
body.page-Main_Page #contentSub, body.page-Portal_Wikipedia #contentSub, 
body.page-Main_Page h1.firstHeading, body.page-Portal_Wikipedia h1.firstHeading {
    display: none !important;
}

You can remove some of these assuming don't have many idiots who become admin just to delete the main page over in Overijssel or wherever you're calling from. I think this phenomenon has been strictly limited to English projects. Something like this would be enough to just hide the "Veurblad" heading: 

body.page-Veurblad h1.firstHeading { display:none !important; }

If there's anything else you really need to remove, it can be added as well, to nds-nl:MediaWiki:Monobook.css. — CharlotteWebb 22:07, 21 February 2009 (UTC)

I think this would have worked [4] except you forgot the "}" at the end. — CharlotteWebb 14:57, 22 February 2009 (UTC)

RSS Reader on Linux

Does anyone have any suggestions as to what would be a sufficient program to run RSS through on Linux? I can't seem to get RSSOwl to work because I seem to be missing Java Runtime Environment despite having it installed in all applicable directories. ---AmaraielSend Message 21:22, 21 February 2009 (UTC)

My old username isn't redirecting

Resolved
 – Fixed. rʨanaɢ talk/contribs 16:06, 22 February 2009 (UTC)

I recently changed my username from User:Politizer to User:Rjanag, and for the most part it is working fine, but I still occasionally get messages at User talk:Politizer, mostly from new users but once from an established user as well—see the revision history. I'm not sure how people are ending up at that page, since it's supposed to redirect—can certain people's browsers be set to ignore redirects or something? And even if that is the case, all these messages are from people clicking on my signature after I changed my name, and my current signature doesn't link there anyway; the code of my signature is below:

'''[[User:Rjanag|r<font color="#8B0000"><span class="Unicode">ʨ</span></font>ana<span class="Unicode">ɢ</span>]]''' <sup><small>[[User talk:Rjanag|talk]]</small></sup>/<sub><small>[[Special:Contributions/Rjanag|contribs]]</small></sub>

Any idea what is causing this? rʨanaɢ talk/contribs 15:10, 22 February 2009 (UTC)

Ah, MagicWiki fixed it. I feel like a douche! rʨanaɢ talk/contribs 16:06, 22 February 2009 (UTC)

ambox problem

Resolved
 – Nothing to see, just a self-inflicted problem. --—— Gadget850 (Ed) talk - 19:47, 22 February 2009 (UTC)

Something seems to have happened to {{ambox}} and derived templates. --—— Gadget850 (Ed) talk - 16:46, 22 February 2009 (UTC)

Er, all seems fine to me. What, exactly, do you think has "happened"?? Happy‑melon 17:10, 22 February 2009 (UTC)
Maybe an error on your end? §hepTalk 17:32, 22 February 2009 (UTC)
What occurs immediately to me is that you should try clearing your cache. {{Nihiltres|talk|log}} 17:38, 22 February 2009 (UTC)
I had already bypassed and purged. It is OK in Opera and Safari, but it is mangled in FireFox. I just deleted my cache with no change. --—— Gadget850 (Ed) talk - 19:26, 22 February 2009 (UTC)
It looks fine for me in FF 2.0.0.14 (or something close to that). What version of FF are you using? §hepTalk 19:33, 22 February 2009 (UTC)
Sigh. If I'm going to screw around with my .CSS in an attempt to figure out a printing problem, then I might have a clue that it could interfere with my viewing enjoyment. --—— Gadget850 (Ed) talk - 19:47, 22 February 2009 (UTC)

Canon PowerShot S

I don't quite get what's going on here. I made an edit, saved the article, and now, see also/references section (at the bottom) now shows up in the middle between the first and second tables. screenshot of what I see. I've tried to purge the cache but it still shows up like that. hbdragon88 (talk) 18:28, 22 February 2009 (UTC)

Tables close with |}, templates close with }}. §hepTalk 18:35, 22 February 2009 (UTC)

Editing a png file

{{shouldbeSVG}}

I created Image:Linear regression.png from a postscript file using a unix shell script call ps2png. Is there any simple way to carve off the blank margins? Michael Hardy (talk) 20:25, 22 February 2009 (UTC)

Eh, no. Do you have one called "ps2svg"? A vector format would be far more efficient for this type of image, and easier to manipulate (adding more columns to the graph as time passes, for example). Generally speaking though, I agree that it would be nice to have some kind of command for cropping images, something like [[Image:Linear regression.png|thumb|crop=5,10,200,225]]. It would be easy to do as the accessory programs MW uses to generate the thumbnails already have command line parameters for where-to-crop-it. Anyone think this is worth bugging Brion about? — CharlotteWebb 20:38, 22 February 2009 (UTC)
At first I liked the idea, but that would make uploading a new version of an image a real bother, since you'd have to check all cropped usages of the image. With a commons image, that would be hell. --Amalthea 21:23, 22 February 2009 (UTC)
To answer your question the simplest way available right now is to download it, open it in MS Paint etc. crop out the ugly gutter-space, and upload it again at the same title, which isn't really very simple. — CharlotteWebb 20:40, 22 February 2009 (UTC)

I managed to get rid of most of the left and right margins by editing the postscript file by hand (i.e. with a text editor), then running ps2png again and re-uploading. Best I've got SO FAR. Michael Hardy (talk) 21:15, 22 February 2009 (UTC)

Chillum already cropped it, have a look at the file history of File:Linear regression.png. I'd recommend reverting to his version, it's probably closer to what you want. You might have missed it since it was still cached in your browser. --Amalthea 21:22, 22 February 2009 (UTC)

It appears that I uploaded an edited version after Chillum did, without noticing that someone else did so first. But isn't there still a huge lower margin in Chilum's version? (Just as there is in my latest?) Michael Hardy (talk) 21:44, 22 February 2009 (UTC)

Oh. I see Chillum's version looks good; I've reverted to that. Michael Hardy (talk) 22:03, 22 February 2009 (UTC)
Since it is a png the cropping was lossless. Chillum 22:24, 22 February 2009 (UTC)

Smaller Wikipedia Logo files

I have managed to compress the current wiki logo by 39 bytes. See the comparison

  • The smaller wikipedia logo.
    The smaller wikipedia logo.
  • The current wikipedia logo.
    The current wikipedia logo.

This should save wikipedia a small amount of bandwidth.(I would appreciate being notified when the logo is updated.) Cheers!Smallman12q (talk) 18:14, 21 February 2009 (UTC)

You managed to reduce its size by 0.24%? Er, that's great... Happy‑melon 21:45, 21 February 2009 (UTC)
without commenting on the phenomenal effect this will having on load times and bandwidth usage, it does seem like the improved image is more clearly defined, sharper lines and whatnot--Jac16888Talk 21:49, 21 February 2009 (UTC)

I have compressed all of them...the user icon by 70%...the overall savings is roughly 2kb.(Not much but its still quite a bit).

Yes it would save bandwidth, but I wonder if it's negligible or not. Visitors to Wikipedia (English one in this case) would have cached the logo unless they're regularly cleared. I'll do a simple maths here: 39 bytes × 193 million page views/day × 0.01% of them loaded the logo = 752700 bytes/day = 735 kB/day = 21.5 MB/month = 262 MB/year
The percentage who load the logo is a rough and conservative estimate, and the 193 million is for January 2009. My bottom line here is, it may not save much bandwidth on a daily basis, but it accumulates in the long run. Thanks for your effort anyway, just curious how would others see this.
Update: After seeing more response, I think it may save a chip of bandwidth after all. Feel free to criticise on my calculations. xP HУтaяtalk2mecontribs 21:58, 21 February 2009 (UTC)
T he difference it makes will accumulate, but will this massively inflate the job queue? The logo is on every page, after all. Dendodge TalkContribs 22:03, 21 February 2009 (UTC)
It may not save much...but it helps. Could an admin update the current images with my compressed ones? That's mainly what I'm looking for.Smallman12q (talk) 22:02, 21 February 2009 (UTC)
I'd rather wait and see some general consensus for this--Jac16888Talk 22:26, 21 February 2009 (UTC)
Not to be rude, but what kind of consensus? The images are the same except smaller. Unless people enjoy having larger copies with the exact same resolution, I don't understand what you mean by consensus? What would be the reason not to change them?Smallman12q (talk) 22:45, 21 February 2009 (UTC)
well for starters, as dendodge says, its possible this will have a huge impact on the job queue, so it might not actually be worth doing in terms of cost vs benefit--Jac16888Talk 22:55, 21 February 2009 (UTC)
I believe that the site logo is loaded only when needed (not pushed to everyone when it's updated), but I'll wait for conformation of that.
In the meantime, I've updated all of the sister project logos on the main page. Thanks, Smallman12q! —David Levy 23:18, 21 February 2009 (UTC)
Thanks! Are you going to upload the rest when you get confirmation?Smallman12q (talk) 23:30, 21 February 2009 (UTC)
I'm unable to update the images used at http://www.wikipedia.org, and I don't know of a way to replace the user icon. I can update the Wikimedia/MediaWiki icons at Commons, but I'll wait for confirmation that this won't cause any problems. —David Levy 23:46, 21 February 2009 (UTC)
For the physical wikipedia.org site, it's likely to be a devolper or founder as they'll need access to the physical wikipedia.org domain. I'll be uploading a few more compressed popular images. I'm just happy to see that someone was willing to help me. Thanks again!Smallman12q (talk) 00:38, 22 February 2009 (UTC)
For the main site, you'll need a meta-sysop. See http://meta.wikimedia.org/wiki/Talk:Www.wikipedia.org_template Smallman12q (talk) 01:38, 22 February 2009 (UTC)
I would also like to thank you for giving me credit. Cheers!Smallman12q (talk) 14:21, 22 February 2009 (UTC)
The icons on the www.wikipedia.org page can be changed by an admin at meta at www.wikipedia.org template. File:Wiki.png will update the logo here; it has no effect on the job queue. The "Powered by MediaWiki" logo, small RSS icon, and user icon can be changed by a developer, a sysadmin would need to change the "A Wikimedia project" icon (I'm not sure where the big RSS icon is actually used). Mr.Z-man 01:53, 22 February 2009 (UTC)
Good to hear it doesn't affect job queue.Smallman12q (talk) 01:56, 22 February 2009 (UTC)
Actually AFAIK updating File:Wiki.png will not update the site logo here; whether the logo is 'coupled' to that file is a config setting that is, I think, disabled here. I could be wrong though; does someone want to check by putting a 1px dot in one of the corners and overwriting Wiki.png with it? Given that the job queue has been overhauled recently and so is now running much more quickly; it shouldn't be an issue, especially with caching. Happy‑melon 11:29, 22 February 2009 (UTC)
I checked the config files before commenting (as well as looking in the page source, which refers to Wiki.png in the en Wikipedia upload directory), as I said, the logo has absolutely nothing to do with the job queue. Its part of the interface, its not a template. Mr.Z-man 03:30, 24 February 2009 (UTC)

I've noticed that most of the images on wikipedia including those in the actual mono book at http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_13/phase3/skins/monobook/ are uncompressed. I believe that compressing the top 500 images would help reduce bandwidth noticeably. I'm not quite sure where to start garnering support for a policy change, but I'm quite sure that the current state is simply unproductive is costing needless bandwidth and is a greater hassle for the greater wikipedia community.Smallman12q (talk) 02:48, 22 February 2009 (UTC)

You might also want to add the steps you took to achieve the additional file size reduction in the image descriptions so that future editors can reproduce these effects. SharkD (talk) 04:39, 22 February 2009 (UTC)
Also, don't forget to crush the favicon. SharkD (talk) 04:41, 22 February 2009 (UTC)
Well the source image for the main page is derived as following:
<a accesskey="z" title="Visit the main page [alt-shift-z]" href="/wikipedia/en/wiki/Main_Page" style="background-image: url(http://upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png);"/>

so I believe they are the same. Still, the wiki.png has not yet been updated. I also would like to comment that put a dot on the wiki logo would not be the appropriate method of determining whether it is indeed the logo.Smallman12q (talk) 14:21, 22 February 2009 (UTC)

With regards to the image compression, I'm using a pngcrush I modified...however, I have seen that pngoutwin and pngguantlet have similar compression ratios. I would propose that the Wikimedia Foundation compress the images in the mediawiki software prior to distribution or at least optimize the image. Beyond that, for Wikipedia, a bot can be written to compress the "heaviest" (the ones that use the most bandwidth) images. I would like to note that png compression is very intensive and requires quite a bit of processing time. Still, I'm quite sure that there will be a noticeable savings in terms of both page loading times and bandwidth usage. Smallman12q (talk) 14:21, 22 February 2009 (UTC)
The image thumbnails for the Main page should also be compressed especially "Picture of the day".Smallman12q (talk) 14:56, 22 February 2009 (UTC)
I have compressed all of the wikipedia barnstars...and it comes out to roughly 50% of their current total size. I don't have the rights to upload them to the commons, and its probably not worth the hassle of posting them here and then having an admin repost them to the commons. But it does show that a number of userpages/talk pages could be loaded a lot faster. ^.^Smallman12q (talk) 15:21, 22 February 2009 (UTC)
If anyone is interested, I have created a bot request at Wikipedia:Bot_requests#Image_Optimization_and_Compression_Bot.Smallman12q (talk) 18:10, 22 February 2009 (UTC)
There is an online optimizer with which you can see how the number of colors affects size. See http://tools.dynamicdrive.com/imageoptimizer/index.php .It seems the current wikipedia logo is 32 colors so it could be optimized a bit more. And the user icon can be compressed even further to about 15% of the current size. I have looked at the wikipedia favicon and it can be compressed. In fact, some of the other mediawiki icons can be losslessly compressed by 70%. Cheers!Smallman12q (talk) 19:38, 22 February 2009 (UTC)

Still need a WP:Developer to update the images.Smallman12q (talk) 00:51, 23 February 2009 (UTC)

I have compressed them a bit further

The savings are several kilobytes. Also, I would appreciate if you gave me credit when you update the pics. Thanks!Smallman12q (talk) 23:48, 23 February 2009 (UTC)

Subst without the extra code in the text?

I seem to remember that there was a way to subst a template without including remnants of parser functions, like ((#if:}} statements, but can't find any mention of it anywhere. — Bellhalla (talk) 23:32, 22 February 2009 (UTC)

You want the SubstAll extension (and so do I actually). — CharlotteWebb 02:48, 23 February 2009 (UTC)
If it's a template that's always substituted, it can be written so that no parser function remnants remain, by substing them, too. --Amalthea 02:52, 23 February 2009 (UTC)

There are templates which are designed to be subst'ed but still leave other live templates, so maybe it would be good to have a way to specify the level of recursion (rather than just 0, 1, or "all"). — CharlotteWebb 03:20, 23 February 2009 (UTC)

Special:Expandtemplates fits the bill for the original question. Graham87 04:02, 23 February 2009 (UTC)
Yes, but that requires copying and pasting back and forth. — CharlotteWebb 03:34, 24 February 2009 (UTC)

Where is this link?

At Glass reinforced plastic, a redirect page pointing to glass-reinforced plastic, I click on "what links here", and I see this: RAF Horham. I can't find that link in the article nor in any template used within the article. What's going on? Michael Hardy (talk) 05:30, 23 February 2009 (UTC)

interesting. also, on the RAF Hornham page, the 'what links here' doesn't list any transclusions, though I count four templates being used on the page. I'm going to try a dummy edit on that page to see if it clears things up. --Ludwigs2 05:46, 23 February 2009 (UTC)
ah, ok. the Glass_reinforced_plastic link is there, in the civil use section (the text is simply GRP). still doesn't explain why the transclusions don't show, though. --Ludwigs2 05:52, 23 February 2009 (UTC)
Special:WhatLinksHere doesn't show what is transcluded in the page, it shows what the page is transcluded in directly or indirectly. —Snigbrook 13:02, 23 February 2009 (UTC)

North Korea

If any nice editor has a few minutes to fix some reformatting, please take a look at North Korea. The large infobox is, I believe, the source of a text overwriting problem, as it is shoving some graphics down further than they're supposed to be. Note the Baekdu Mountain photo and the text overwriting its top; also to its right there's one of those "[edit] [edit] [edit]" jumbles that sometimes occur. I toyed with it and couldn't come up with a satisfactory solution. Thanks - Tempshill (talk) 17:05, 23 February 2009 (UTC)

Should all be fixed now. See the FAQ at the top for how to fix the edit link bunching in the future. Cheers, Amalthea 17:35, 23 February 2009 (UTC)

All the templates and project templates include links to the project or appropriate page. But the photo request template doesn't link to the appropriate photo request page on Wikipedia. I think this would be great to fix. Thanks. Drop me a note if there are any questions. ChildofMidnight (talk) 20:27, 23 February 2009 (UTC) {{photoreq}} I wasn't sure if this should go on the proposals page or here. Feel free to move as appropriate. Gracias. ChildofMidnight (talk) 20:29, 23 February 2009 (UTC)

probably better to have put this request on the templates talk page. make a new entry over there and tell me what page(s) do you want to add links for; I'll see what I can do. --Ludwigs2 21:34, 23 February 2009 (UTC)

An ARBCOM-proposed RfC on date linking/autoformatting

There has been an ongoing arbitration case on (de)linking chronological items. One of the clerks has started the framework for perhaps the most intricate RfC on the issue yet, which includes date autoformatting and other definitions of said feature. Please see User:Ryan Postlethwaite/Date linking RfC for the draft of the RfC and discuss its scope and questions at its corresponding discussion page. Opinions on the formatting of such an RfC are welcome here. Dabomb87 (talk) 23:48, 23 February 2009 (UTC)

Cite error: <ref> tags exist, but no <references/> tag was found

This message has recently started to appear in red at the bottom of pages. It's easy to fix in articles, but it often appears on talkpages as well. I am thinking of filing a Bot request asking that sections of talkpages with ref tages be appended with

References

{{refs}}
or similar coding so that references cited would show up in the relevant areas. I thought it might be prudent to ask for suggestions/comments here first. Skomorokh 17:59, 16 February 2009 (UTC)

That was fixed already, or should be (see Help:Cite errors). Where are you seeing this message in non-articles? Algebraist 18:04, 16 February 2009 (UTC)
Because people will often make a comment on a talk page, and provide a <ref> for it. Or they may copy part of the article to the talk page to discuss it, and it might contain a ref also. — CharlotteWebb 18:06, 16 February 2009 (UTC)
Yes, I know that happens, but it shouldn't be causing this message to display, since the message is now namespace-dependent. Algebraist 18:08, 16 February 2009 (UTC)
It's definitely a problem in the Wikipedia namespace. I'm sure I've seen it in Talk as well. Skomorokh 18:13, 16 February 2009 (UTC)
I'm not seeing that message on that page. Have you cleared your cache? Algebraist 18:17, 16 February 2009 (UTC)
I believe I have; how do I make sure? The message appears at the foot of the linked page for me. Skomorokh 18:24, 16 February 2009 (UTC)
WP:Bypass your cache. Algebraist 18:31, 16 February 2009 (UTC)
Yeah, I've done that; I still see red at the above link and at Talk also. Skomorokh 18:36, 16 February 2009 (UTC)
I don't see the error messages either. It was removed from non-articles on 31 January [5] and the linked versions are from 16 February and 13 February, so I don't see how a users cache could cause the message to appear. Is it possible that Skomorokh is getting pages from a server which hasn't registered the MediaWiki edit? PrimeHunter (talk) 18:47, 16 February 2009 (UTC)
How peculiar. I tried the same page at secure here and the red warning still appears. Skomorokh 18:53, 16 February 2009 (UTC)

That would work well only if you also run a bot to continuously move the {{reflist}} to the bottom of the page every time somebody adds a new section to the talk page. Or get the devs to fix whatever bug causes all refs appearing after the <references/> tag to be ignored (they won't get picked by by a second <references/> tag either, as this will only duplicate the first one… I think). — CharlotteWebb 18:06, 16 February 2009 (UTC)

With the latest update to cite.php, you can now include multiple <Reference /> tags; they will list the references after any previous <Reference />. This is probably only useful for talk pages where you want to list the references, but not mess with groups. --—— Gadget850 (Ed) talk - 19:06, 16 February 2009 (UTC)
I'm not sure I understand this. Rather than asking you to explain it, is it documented somewhere? mw:Extension:Cite/Cite.php doesn't seem to have any recent edits related to this. — CharlotteWebb 19:20, 16 February 2009 (UTC)
Ah, you are right. Skomorokh 18:12, 16 February 2009 (UTC)
Well you could set it to "lazy mode" and have it act only when it has to, which would be the small sub-set of edits where a <ref> tag is added below the reflist. Might not flood the edit history so much that way. — CharlotteWebb 18:58, 16 February 2009 (UTC)
FYI, multiple <references/> tags have worked for a while. Multiple {{reflist}}s don't work as you would expect, because MediaWiki caches the output of parameterless template transclusions; multiple {{reflist|1}}s will work as expected. Anomie⚔ 02:38, 17 February 2009 (UTC)
This problem is showing up in some articles as well. For example this version of Eau Claire, Wisconsin. There was a ref tag in the external links section (which seems a little odd, but I'm not sure there is any proscription against doing that). older ≠ wiser 00:11, 20 February 2009 (UTC)
Well, theeeeoretically the lower sections such as "See also", "External links", categories, stub templates, interwiki links, navboxes, persondata, etc. should not express contentious claims requiring inline reference… let's see how that works in practice. — CharlotteWebb 09:22, 21 February 2009 (UTC)
There are also a few navboxes that include reference tags. If the box is intended to be placed at the bottom of the page, then that it seems wrong to put references in the box intending that they should display in the article. Can there be a <references/> within such a navbox template so that the navbox could be somewhat self-contained? older ≠ wiser 13:49, 21 February 2009 (UTC)

Still a problem

I am still seeing this red error message. Is anyone else having this problem? I'm running the latest version of Firefox, Monobook skin. Skomorokh 22:27, 24 February 2009 (UTC)

Do you see that everywhere, or only in particular articles? If the latter, which articles? —EncMstr (talk) 23:57, 24 February 2009 (UTC)
Everywhere that <ref></ref> tags are used after or without <references/>. It's at the bottom of AN/I right now, for example. Skomorokh 00:30, 25 February 2009 (UTC)
I don't know how the message is generated, but have you tried to clear your entire cache and not just to reload the page? PrimeHunter (talk) 00:46, 25 February 2009 (UTC)
Yes I have, as mentioned above. Thanks, Skomorokh 01:10, 25 February 2009 (UTC)
I'm now having a similar problem editing Tom Molineaux. I use Internet Explorer 7. I think I've formatted the inline citations correctly, so I don't understand what's gone wrong. Motacilla (talk) 14:03, 7 October 2009 (UTC)

One article isn't updated in the search index?

Just under a month ago I went on a rampage against the misspelling "assymetric", and updated many files. This included, oh, 20 or so, which described various defendants vs. George W. Bush, and contained the exact same phrase "Camp authorities called the deaths "an act of assymetric warfare", and suspected plans had been coordinated by the captive's attorneys..." These all very rapidly passed out of the results when I do a search for "assymetric", and now Wikipedia searches are clean of the term, except for redirects --- and one article... Abdulsalam Ali Abdulrahman Al Hela v. George W. Bush. The article is fixed, has been fixed for a month, but it still indexes with an excerpt that includes the misspelling. It's not protected or anything... what's the story? Happy debugging... Wnt (talk) 10:02, 19 February 2009 (UTC)

The search results clearly show that the search index contains the version of the article in place just before you made your spelling correction. So clearly the index isn't real time (no surprise there); the question then is when it uses a more current version of an article. I'm guessing it's not (at least solely) time-driven, since you made your correction roughly a month ago. Perhaps the search index is changed (updated) only where the byte count of an article changes by a certain amount (e.g., more than 5 or 10)? -- John Broughton (♫♫) 23:38, 23 February 2009 (UTC)
Well, that's what's odd - I changed all the other instances of the word the same way and they were updated immediately. I see now that you made an edit to the article (3 bytes), and now it is indexed properly. So just that one edit of mine [6], made at 16:32, 23 January 2009, just didn't trigger the index. I wonder if there is a way to locate other articles with last edits at that same time and see if they were updated - maybe the index updates are turned off at a certain time? I suppose it shouldn't matter much, but it does look like a bug. Wnt (talk) 23:13, 24 February 2009 (UTC)
I don't know how search indexing is designed to work but I looked at a few edits from the same minute and found two which are the last to the page: [7][8]. Searches [9][10] show the index time is from the preceding edit for both. PrimeHunter (talk) 23:52, 24 February 2009 (UTC)

Wiki Traffic Statistics Tool

I know that there is a number of Wiki tools out there that functions as search engines that can show you the traffic statistics of articles on various wikis, but I have yet to find any that can provide me with results for specialised wikis such as Commons or Wikisource (all language wikisource, not just the English version). Can anyone provide me with a link for such search tools? --Saddhiyama (talk) 00:36, 21 February 2009 (UTC)

Lucky that I found it to explain the topic below, and to use it here too! Here you go. HУтaяtalk2mecontribs 22:02, 21 February 2009 (UTC)
Thanks a lot. Is there anything more article specific like this one, but usable on wikimedia commons and wikisource? --Saddhiyama (talk) 10:13, 24 February 2009 (UTC)
See http://stats.grok.se/commons.m/latest/Main_Page and http://stats.grok.se/da.s/latest/Forside for example. --- Best regards, Melancholie (talk) 13:21, 24 February 2009 (UTC)

locator map.svg

How do you mark a place in locator map.svg's? For example link the same image is used on several articles to show places. How to do that(mark places without editing the file in something like GIMP/Photoshop/MS Paint)?—Magic.Wiki (talk) 16:10, 22 February 2009 (UTC)

The places are generally marked using an infobox. You supply the coordinates of a location in format the infobox accepts and the box will add a dot over the location. For an example using the map you described above see Naroda. The coordinates are inputted via
|latd = 23|latm = 05
|longd= 72|longm= 40

§hepTalk 17:30, 22 February 2009 (UTC)

Yes, 2009 Gujarat hepatitis outbreak. I edited the image with GIMP and (somehow) it is now a PNG instead of SVG. Though I was more interested in the technique they have used in those infoboxes. —Magic.Wiki (talk) 06:32, 23 February 2009 (UTC)

Template:Superimpose does what you want. If you prefer to not use a template OR infobox, you could view the source code of Template:Superimpose, it has the basics if you know wikimarkup ;) -- penubag  (talk) 03:52, 25 February 2009 (UTC)

no transclusions in 'What Links Here' special page

in addressing the above issue, I noticed that transclusions don't seem to be showing in the 'what links here' page on any of the pages that I've checked (total of four, so far). can anyone else confirm this? --Ludwigs2 05:59, 23 February 2009 (UTC)

Correct me if I'm wrong, but what links here only marks transclusions if the page being checked is transcluded on other pages, not if other pages are transcluded on it and always has done so. For example, {{USAAF 8th Air Force UK}} is transcluded on the bottom of RAF Horham - what links here marks the link to this template and doing the same on the template shows all the pages it's transcluded on. Nanonic (talk) 06:15, 23 February 2009 (UTC)
you may be correct (though that would sort of belie the 'what links here' title, since that would really be 'what here links to' ). I've honestly never given it thought. if someone can confirm, then I apologize for the mistake. --Ludwigs2 06:24, 23 February 2009 (UTC)
Maybe you read it as "what links [are] here" . If you want the opposite type of transclusion list, containing all the templates directly or indirectly used by a certain article, you can find it about a screen and a half below the textbox when editing the page (should be right below the GFDL footnote). — CharlotteWebb 18:10, 24 February 2009 (UTC)

Template:PNG version available

Why do we use {{PNG version available}} on GIF files? They both have benefits and both are free formats, as the patents on GIF expired, so why? Do we only want to use PNG and SVG? Was there as consensus to start using this tag? ~ JohnnyMrNinja 01:49, 24 February 2009 (UTC)

The only thing after found after looking so far is Wikipedia:Preparing images for upload which mentions not using GIFs unless they're animated. §hepTalk 01:53, 24 February 2009 (UTC)
Sometimes gif files are smaller than png though...perhaps this should be reevaluated.Smallman12q (talk) 02:00, 24 February 2009 (UTC)
GIFs rarely compress better than PNGs. They are also limited to 256 colors whereas PNGs can hold the full range of colors and transparency. —Remember the dot (talk) 02:32, 24 February 2009 (UTC)
POP QUIZ!!!
Which is better?
  • Original GIF with long history
    Original GIF with long history
  • Recent PNG version
    Recent PNG version
  • The recentest (actual word) version, SVG
    The recentest (actual word) version, SVG

I personally don't see the need for the PNG version at this point, or really even the GIF. Thoughts? ~ JohnnyMrNinja 03:44, 24 February 2009 (UTC)

Actually, the PNG version is the best there, because .gif resizing is currently disabled on Wikimedia for performance reasons (TPTB ultimately hope to disable resizing just for animated gif). That 198x145 gif then is shown at 150x110 and looks like absolute shit in many browsers.
Having said that, I seriously hate people superseding anything for no reason. Some people feel the pedantic need to rename or reupload a file for a few bytes of "savings" (see This for an attempt to head this off). If there are good reasons, then it should be done. If there are only stupid reasoning like "It is policy" - "I want to have a big upload history" - "I have nothing better to do than crunch files all day"... then no, it should not be done.
If it looks perfect in gif (binary or no transparency, no more than 256 colors in the original file, no dithering needed to create) then just leave it as a gif, the servers will thank you. IMHO ... --Splarka (rant) 08:49, 24 February 2009 (UTC)
Weird, in my browser (Firefox beta) the PNG looks a mite fuzzy, and the GIF looks best. The PNG version was done by a bot. I don't get the point. If need be, we can stop new users from uploading non-animated GIFs, that would be sensible, but I don't see the point in these bots and tags. Now, uploading to Commons, that's when you should update the format and name and all that. ~ JohnnyMrNinja 10:45, 24 February 2009 (UTC)
The sharpness of the resized GIF image is because of the shitty browser resizing in this case, which can look better with some kinds of images than the allround bicubic interpolation that ImageMagik will be using, but in extreme cases GIF browser resizing will look like File:Segmentedpediment.gif.
Also, if the PNG version is resized by MediaWiki it will also increase in file size since it's no longer stored as a palletized PNG.
So, with the current MediaWiki setup: there are a number of reasons to dump the PNG with this specific image; with most others, a PNG will be better. In general, I'd say don't worry about it, it's MediaWiki's job to do get it right. --Amalthea 11:32, 24 February 2009 (UTC)

Rollback on Watchlist really needs to go...

I can't be the only one who finds it too easy to accidentally click it. AT the least, it should be a setting in prefs (and please, do NOT spout about custom CSS or whatever). I don't want to get my rollback taken away because I clicked in the wrong place and didn't even notice. ♫ Melodia Chaconne ♫ (talk) 03:18, 24 February 2009 (UTC)

You can always revert the (wrong) rollback... You're allowed to do that if you muss up. --Izno (talk) 03:56, 24 February 2009 (UTC)
I was informed on my talk page that I'd rollbacked an edit, and I'd had no clue. Thankfully, I could rollback that edit, but still, it's possible to not notice. I don't see what's so objectionable about a custom CSS solution, though. EVula // talk // ☯ // 04:12, 24 February 2009 (UTC)
Exactly, I've at least once rolled back an edit that I only saw later, and almost did it again right before I posted that. What's wrong is that it's a 'dangerous' as it were item that was put on there without an option, and should be at least turn-off-able without a weird workaround. ♫ Melodia Chaconne ♫ (talk) 04:34, 24 February 2009 (UTC)
An option to disable it might be an idea, but I have to say that I have found the new link extremely useful in terms of reverting vandalism, and would really regret losing it. --Ckatzchatspy 07:21, 24 February 2009 (UTC)
There is code above to disable it on your own watchlist, I'll sniff it out and repost shortly. I would have done it myself but I too have found it quite useful after my initial fears. I still use popups to look at the diff, but if it's obvious, I now click the rollback link on the watchlist as a new window, then chase down the vandal's other edits from the new window and keep watching them. Franamax (talk) 08:20, 24 February 2009 (UTC)
Ah yes, longer ago than I thought. contained herein is the appropriate code needed to disable the option in your monobook.css. Franamax (talk) 08:37, 24 February 2009 (UTC)
OOPS, yes, I'm spouting on about custom CSS. Melodia, it's actually pretty easy to do. I'll try talking to you about it off-pump. Franamax (talk) 08:42, 24 February 2009 (UTC)
I have to agree; too often I found myself almost accidentally clicking the rollback link. What is the point of having it on the watchlist anyway? You can't decide if you're going to rollback an edit until you see the diff, so it's basically pointless (unless you have some script that shows diffs in a popup). Why not an Undo button, so you can see what you roll back? — Edokter • Talk • 18:23, 24 February 2009 (UTC)
I find it very useful, used in conjunction with pop-ups (which don't need a script, just the ability to click on a box in gadgets). DuncanHill (talk) 18:30, 24 February 2009 (UTC)
Agree. It works good with popups, allows you to be faster than having to load the diff. Also, sometimes the edit summary ("replaced content with hahaha" etc.) allows you to determine vandalism quickly as well. SoWhy 18:39, 24 February 2009 (UTC)
I agree it is useful, I think it should stay. ·Add§hore· Talk To Me! 18:40, 24 February 2009 (UTC)
Since it is only usefull for editors using Popups, why not build it in Popups instead of having it site-wide? — Edokter • Talk • 20:44, 24 February 2009 (UTC)

Well, when I see something on Special:Watchlist or Recentchanges like this it is obvious that the diff will take way too long to load and not tell me anything I don't already know:

Anyone using CSS to hide the [rollback] link on certain pages should also use javascript to unhide it when there appears to be an automatic edit summary. — CharlotteWebb 18:47, 24 February 2009 (UTC)

Indeed. It is not just useful to editors with Popups, it is useful to an undetermined number of editors who feel that the benefits of having the link immediately-accessible outweigh the risks of accidentally clicking on one of the links. As such, the onus is on those who feel that they would be happier without the links, to remove them; and as noted it is really an incredibly trivial thing to accomplish with CSS. If there was evidence (from a proliferation of "oops I clicked the link by mistake" log entries) that accidentally clicking the links was a significant problem that affected the majority of users, then we could think about hiding them by default; but there is no such evidence as far as I'm aware. What I have personally done is add the following CSS:
.page-Special_Watchlist .mw-rollback-link,
.page-Special_Watchlist .mw-usertoollinks  {font-size: smaller;}
Which has the effect of shrinking both the rollback link and the talk/contribs/block links. I've found that this both makes the links harder to click by mistake, and less obtrusive in general. Each to his own; we should not be trying to impose such personal preferences on users indiscriminately. Happy‑melon 22:18, 24 February 2009 (UTC)
You do have a point. Shouldn't 'Undo' be added as well then? — Edokter • Talk • 01:09, 25 February 2009 (UTC)

old article version displayed

The last edit on The Passion of the Jew (South Park episode) happened two days ago and was a rollback to remove vandalism [11]. However, the article main page still displays the previous version to me, with the vandalism line at the bottom of the page. Clearing my browser cache does not solve the problem. What's wrong? -- 790 ♫ 19:45, 24 February 2009 (UTC)

I just looked and do not see the words "fuck this" in the current version. If you still see it, it's a cache problem. If you don't see it anymore now, maybe somebody fixed it with a purge or a null edit of the page, or it could be a coincidence. Couldn't prove either way as these actions are not logged, they just poke the server a bit and tell it to re-render the page from scratch. — CharlotteWebb 20:06, 24 February 2009 (UTC)


DB error

Resolved

Getting error A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "IndexPager::reallyDoQuery (PageHistoryPager)". MySQL returned error "1054: Unknown column 'ts_tags' in 'field list' (10.0.6.22)"." at http://en.wikipedia.org/w/index.php?title=Characters_in_Resident_Evil_2&action=history --Oscarthecat (talk) 22:22, 24 February 2009 (UTC)

Yes, me too. Apparently someone broke the database for histories. I'm sure it will be fixed soon^^ SoWhy 22:23, 24 February 2009 (UTC)
Devs are aware and are working on it. Stifle (talk) 22:24, 24 February 2009 (UTC)
Just came here to ask why my histories were all busted with some SQL database something-or-other error message. Glad to know it's not just me. Mahalo. --Ali'i 22:24, 24 February 2009 (UTC)

(removed several dupes)

This has been fixed. I made an error in disabling a Recentchanges/log/history tag filter feature which has some performance issues; a side effect of the disabling broke page history view. It's been corrected now. --brion (talk) 22:31, 24 February 2009 (UTC)

multiline indented preformatting

I can't seem to get multiline indented preformatting to work. Am I missing something or is this a bug? 

This
works
This too
This

doesn't

--Pascal666 (talk) 12:15, 21 February 2009 (UTC)

You're not, and I think that there's a bug somewhere. What I'm sometimes doing is using HTML indentation instead:
But
this
does
Very very ugly, though, in particular if you want to indent farther. --Amalthea 13:00, 21 February 2009 (UTC)

Well it starts out like this: 

:<pre>This
doesn't</pre>

Then the parser decides to wrap the dl tag around all consecutive lines starting with ":", in this case just one: 

<dl>
:<pre>This
</dl>
doesn't</pre>

Then removes the colon(s) and wraps a dd tag around each line: 

<dl>
<dd><pre>This</dd>
</dl>
doesn't</pre>

After all wikitext becomes html, the sanitizer.php cleans up mis-matched tags: 

<dl>
<dd><pre>This</pre></dd>
</dl>
doesn't

This is exactly the same issue that is identified here. With tags other than pre, this sort of thing can be dealt with more easily.

If you only need the indentation and not any kind of bullets/numbering, you can do something like this: 

Multiple
lines
indented

— CharlotteWebb 16:08, 21 February 2009 (UTC)

Do you know if this bug has already been filed? --Pascal666 10:25, 22 February 2009 (UTC)
No. Go ahead? Or maybe I'll do it later. — CharlotteWebb 14:47, 22 February 2009 (UTC)

This also happens with <source>: 

@media print {
sup, sub, p, .documentDescription { line-height: normal; }
}

--—— Gadget850 (Ed) talk - 12:25, 25 February 2009 (UTC)

I know. It happens with any html tag, but with tags other than pre and source you have the option of putting everything on one line (thus within the same <li> element), beginning to end. — CharlotteWebb 15:49, 25 February 2009 (UTC)

Over at the Help Desk, we have had some several reports that pages are blank when an article is printed. I have been able to reproduce this:

  • It only happens in Internet Explorer 7
  • It does not happen in FireFox, Chrome or Internet Explorer 8rc1
  • It occurs with any printer driver: laser, inkjet or PDF
  • Print preview shows the problem just as well as actually printing
  • The pages that are missing can be varied by changing the margins or print zoom
  • Headers and footers will print, but the content is missing

Example: Print or preview Batu Lintang camp with margins of 0.75, with the zoom set to shrink to fit. Pages 5, 6, 16, 22 are blank except for the header and footer.

If I print the same article from Nationmaster, no pages are missing.

Any ideas? --—— Gadget850 (Ed) talk - 14:09, 22 February 2009 (UTC)

I had a similar problem in early/mid-December when printing a successful WP:RFA nomination. I had the problem in several browsers. I finally got around it by using the Opera web browser in "user mode." I didn't investigate, but I think it has something to do with style sheets. By default, Opera's user mode disables server-provided style sheets in favor of the user's own style sheets. davidwr/(talk)/(contribs)/(e-mail) 14:37, 22 February 2009 (UTC)
I considered stylesheets and have been overriding MediaWiki:Print.css in my .css this morning. I'm going to pick at commonPrint.css next. --—— Gadget850 (Ed) talk - 15:28, 22 February 2009 (UTC)

I've identified two bits of CSS that are causing problems: 

sup, sub {
    line-height: 1em;
}

(from MediaWiki:Common.css) 

p, .documentDescription {
    margin: 1em 0 ! important;
    line-height: 1.2em;
}

(from commonPrint.css)

By removing these lines, I can print all pages of Batu Lintang camp. I'd say that the line-height declarations, possibly in combination with something else on the page, is causing the problem. --- RockMFR 19:32, 23 February 2009 (UTC)

Thanks! I had installed Wiki on a stick and have been playing around. I'm going to be off the net this morning. How would you override these in your personal CSS? --—— Gadget850 (Ed) talk - 10:51, 24 February 2009 (UTC)

This should fix it: 

@media print {
sup, sub, p, .documentDescription { line-height: normal; }
}

--- RockMFR 04:47, 25 February 2009 (UTC)

Thanks: that did the trick! --—— Gadget850 (Ed) talk - 11:51, 25 February 2009 (UTC)

bugzilla:16890 and bugzilla:12291 likely related. Is the problem/solution the same with other skins? Mr.Z-man 05:43, 25 February 2009 (UTC)

This does not look like a MediaWiki issue; I have reported this at MediaWiki talk:Common.css#Printing issues with IE7. --—— Gadget850 (Ed) talk - 16:34, 25 February 2009 (UTC)
commonPrint.css is part of MediaWiki, so if that has the same problem as Print.css, then it is a MediaWiki bug. Mr.Z-man 16:48, 25 February 2009 (UTC)

Wikipedia search ranking?

What is the ranking algorithm used in wikipedia search to display the search result? --Ans (talk) 08:58, 23 February 2009 (UTC)

Black magic. --Carnildo (talk) 09:27, 23 February 2009 (UTC)

Something along the lines of mw:User:Rainman/search internals. --rainman (talk) 11:02, 23 February 2009 (UTC)

We used to use Lucene not too long ago but I'm not sure if that's the case anymore. The developers have either greatly improved or changed our search engine. -- penubag  (talk) 03:59, 25 February 2009 (UTC)
In a nutshell: we are still using lucene, but with our own scoring scheme, distributed search/text snippet extraction and spell-checking. --rainman (talk) 10:52, 25 February 2009 (UTC)

More history problems

I'm clicking on history for different pages and it's giving me outdated lists. It's not a matter of a cached version, because that hasn't caused it before and because this is happening on pages where I've never checked the histories. It's fairly widespread. It happened several times to me here and here. Enigmamsg 03:58, 25 February 2009 (UTC)

Sometimes when it happens to me, purging the server's cache solves the problem. Your mileage may vary, however. Graham87 10:57, 25 February 2009 (UTC)

G cut off at bottom

Resolved
 – ukexpat (talk) 21:26, 25 February 2009 (UTC)

I'm noticing in the DMX (music) article, just above "References," tat the g's are getting cut off at the bottom.Vchimpanzee · talk · contributions · 19:58, 25 February 2009 (UTC)

Okay, I went back to it and the g's weren't getting cut off.Vchimpanzee · talk · contributions · 19:59, 25 February 2009 (UTC)

Multiple #ifeq:s

Is there a way I can make multiple parameter inputs trigger an #ifeq: statement, without having to embed multiple statements within each other? Specifically, I have

{{#ifeq:{{{sig|no}}}|yes|do something}}

and I'm wondering if I can make sig=1, as well as sig=yes, work. rʨanaɢ talk/contribs 02:24, 26 February 2009 (UTC)

{{#switch:{{{sig|}}}|1|yes=''do something''}} --- RockMFR 02:31, 26 February 2009 (UTC)
(ec) Exactly. mw:Help:Extension:ParserFunctions#.23switch: --Amalthea 02:33, 26 February 2009 (UTC)
Ah, that guy. Thanks! rʨanaɢ talk/contribs 02:36, 26 February 2009 (UTC)

Getting the text readable version of the wikitext- hopeless?

I keep stumbling over this and I have never figured out a solution. Perhaps someone here has? Is there any way from a template to strip the square brackets from the values in a parameter?

{{#magicfunction:{{{1|[[Los Angeles]], [[California]]}}} }} -> Los Angeles, California

So why am I asking. I was using #titleparts: for passing a string array, which is a great hack for numbers or plain text but it doesn't like square brackets for some reason. So it's pretty useless for general purposes.

Of course, the fallback is to gracefully fail these and have a bot pass add a parameter later, but that increases the template's footprint- making wikitext more cumbersome for human editors. This is not an advertisement for string functions, but while on the subject, if anyone wants to vote one way or the other, take a look at bugzilla:6455. -J JMesserly (talk) 16:37, 22 February 2009 (UTC)

Sure, infoboxes for example would benefit from being able to do something like

[[{{#delink:{{{1}}}}}]]

to put one big link around text which might already be entirely or partly linked. String functions can approximate this to some extent, for example

{{#replace:{{#replace:{{{1}}}|[|}}|]|}}

will properly remove brackets from "straight links" e.g. change

[[Foo]] and [[Bar]]

to

Foo and Bar

but this won't work for piped links. You'd want it to do something like (sorry I mostly speak javascript)

.replace(/\[\[(?:[^\]\|]+\|)?([^\|\]]+)\]\]/g, "$1")

to only keep the right-hand string if the link is piped. Ultimately you'd be able to do something like:

[[{{#delink:[http://gov.georgia.gov/ Governor] of [[Georgia (U.S. state)|Georgia]]}}]]

and get

[[Governor of Georgia]]

— CharlotteWebb 18:03, 22 February 2009 (UTC)

Now that I think about it, a similar feature for stripping out bold/italic and other html tags would have niche uses as well. — CharlotteWebb 20:44, 22 February 2009 (UTC)
Yes. As an alternative to injecting regular expression string handling, the "#magicfunction:" from my example above might be something like, parse the wikitext, hand me back the plain text string. It would help simplify wikitext. The alternative is to require users to redundantly specify the same parameter in a different form. As we add more and more functionality with templates, this clutters the markup making it progressively more difficult for average contributors to comprehend how to improve the article. -J JMesserly (talk) 18:28, 23 February 2009 (UTC)

Sounds like you'd prefer one function called "{{#striphtml:}}" or similar. That would be fine too. — CharlotteWebb 03:31, 24 February 2009 (UTC)

Well Charlotte, I think I was all wet about simply wanting the rendered text. Maybe your first reaction was the correct one. In your example, for most cases in templates I don't want "Georgia", I want "Georgia (U.S. state)". Eg I can't do a localurl on square brackets, I can't do a #time on square bracket date, etc. etc. It would be nice to resolve html entities, strip template decorations etc. You are right- there is some marvelous artillery that will blow all of these problems away, but of all the arcane languages I know, regex's are perhaps the most effective at creating the Frankenstein reaction. As an engineer, I love them- they have the persuasive force of a 16 inch gun on a superbattleship, but they are just as intimidating for neophytes to manipulate or even gaze upon. So how about a wikitext evaluation restriction that they are only post expansion evaluated if the function source wikitext occurred on a Template page? To make them compilable, you probably would want to restrict any dynamic elements. Armchair engineering perspective, it would not be trivial at all, but if the compilations of the regexes are cached, the performance hit is negligible. On the benefit side, we can continue to add wizzy wp features through use of procedural elements without violating the whole intent of wikitext- to keep the markup as simple as possible so that everyone can be an editor. So what do you think of regex's only in templates? We certainly wouldn't see it for years even if everyone agreed, but we have to start somewhere. So maybe this help request ought to morph into a feature proposal? Has this been discussed ad nauseum before? I know about bugzilla:6455 and have used these functions on the wikia, but regex is without question my heavy weapon of choice. -J JMesserly (talk) 17:15, 25 February 2009 (UTC)
The previous discussion was at bugzilla:8161. Allowing arbitrary regexes would be very powerful, but with a price; since you can't guarantee that an arbitrary regex will ever finish, regex injections from the wikitext would bring down the site. The approach I took in that bug was to implement an XML tag that applies the same stripping process that's already done on image captions; the method could be done as a parser function, as well. -Steve Sanbeg (talk) 18:34, 25 February 2009 (UTC)
So this would be the right-side string of any piped link, to answer J.J.'s question. — CharlotteWebb 18:51, 25 February 2009 (UTC)
That's what I see from Steve's code[12]. As with any system allowing procedural functionality, there is a generic problem of looping etc. as you get to more powerful functions. There are well understood implementation approaches due to the popularity of programmable applications that in our case probably was unneeded due to the predictability of the more simple extensions currently permitted. As a former operating systems engineer, I know that it is nontrivial to put in timeout features such as this "compile time"-like error check (in our case executed when the page is cached). If it exceeds N milliseconds to evaluate, you externally kill that thread, and fail the function. It only would execute when the cache was refreshed on the page, so no huge hit for this n millisecond duration sanity check. Like I said it would be years before we saw this even if everyone was wildly enthusiastic- you'd want to get some real world usage on small wikis using the wikimedia engine before getting permissive on foundation wikis with extensions with known computational complexity issues. Anyway, it is good stuff because it is generic functionality applicable not just for this but to other extensions that might have computational complexity/ DoS attack issues.
The tech staff have their hands full and it's their call if they climb that mountain. The view is excellent but it is no stroll in the park either. For my part, I just want the left hand side of the square brackets to be evaluated in #time, localurl, and a few other functions. Thanks for everyone's advice. I hear iron is nice, but I got what I've got so I am going back to plow my field with my fire hardened sticks. Warm regards, and by the way nice work steve. -J JMesserly (talk) 19:58, 25 February 2009 (UTC)
Thanks. Yes, I missed the change in direction in the thread. A similar approach could be taken to get a link target from wikitext, I'd think. The thing to take away from the code in that case is that trying to extract anything from raw wikitext is impractical; the obvious method would probably work 99% of the time, but you'd have to reimplement most of the parse to catch all of the weird cases. Better to just use what's there; either hook into something to work with the wikitext, or parse the chunk into html and extract what you need from that.
Adding generic regex support to mediawiki, however, is quite hopeless. I oversimplified that a bit before, it's not sufficient to guarantee you'd finish the evaluation eventually; parsing time really needs to be reasonably bounded on input size, which regexes clearly are not. A millisecond is a full thousandth of a second. That means that simply putting a thousand small, pathological regexes on a page would add an N-seconds, plus the costs of checking/killing a thousand times. In a frequently used template, that would be huge. -Steve Sanbeg (talk) 21:01, 25 February 2009 (UTC)

(undent) Well, grin. I guess I show my age. It was during a time when folks didn't spend weeks obsessively figuring out how to lock up their word processor or spreadsheet so that they couldn't use it anymore. -J JMesserly (talk) 16:08, 26 February 2009 (UTC)

Ah, yes, back before the script kiddies; I remember it too. good times -Steve Sanbeg (talk) 23:14, 26 February 2009 (UTC)

Weird breakage - should this happen?

I innocently typed in "<syntaxhighlight lang="">" in a talk page comment, to indicate where a <ref> entry should appear. Imagine my suprise at the results, scroll to the bottom here. "Invalid language" - but I'm no invalid, I can still run and jump despite the rumours, and I talk quite cromulently.

If you don't see it, I use IE7 and a red box appears explaining how to use the <syntaxhighlight lang="xx"... tag.

My question here revolves around my thought that the MediaWiki software was relatively bulletproof. Why didn't the <syntaxhighlight lang=""> tag get filtered? How did I break it so easily? Franamax (talk) 01:37, 25 February 2009 (UTC)

<syntaxhighlight lang=""> is the tag for the GeSHi Syntax Highlighter. Mediawiki is quite correctly giving you an error message saying you aren't using GeSHi properly. Dragons flight (talk) 02:06, 25 February 2009 (UTC)
The tag says something about incomplete syntax with parameters missing and closing tag missing as well. Which is precisely what I see in what you entered, and the result was a template that notified you about the problem. Looks to me like the software is doing its job. I guess what you had in mind was a {{fact}} tag. -- Blanchardb -Me•MyEars•MyMouth- timed 02:10, 25 February 2009 (UTC)
Actually I think Franamax just meant say "<source>" as in "[source]" as in "this is a placeholder where an actual source should be cited", and was unaware that we had tag called "source". Even if you are using them incorrectly the HTML "sanitizer" will only convert them to plaintext if they are explicitly not allowed in the wikitext, such as <a> or <blink> or <title>. In other cases it will generally assume you meant to use the tag and pick a good spot to close the tag when you leave it open. This is probably what it did here as an empty <syntaxhighlight lang=""></syntaxhighlight> set makes the same error, which will always occur unless you enter a recognized lang="foo". — CharlotteWebb 20:08, 26 February 2009 (UTC)

What can i help in the community?

Hi everybody, I have skills in programming and Quality Assurance. I would like to contribute these technical skills to wiki.

Does anybody have work for me here?

If not, can you please direct me to a place where I might be needed?

Thanks, Nemohcm —Preceding unsigned comment added by Nemohcm (talk • contribs) 00:36, 26 February 2009 (UTC)

Wikipedia:Bot requests is a place where editors needing assistance from the technically skilled go for help, so that might be a place to start if you think you can get an understanding of how bots work on Wikipedia. Regards, Skomorokh 01:26, 26 February 2009 (UTC)
How to become a MediaWiki hacker is the place to find out how to contribute to MediaWiki development,. There is also WikiProject User scripts, which has info about making custom scripts for Wikipedia. Graham87 08:02, 26 February 2009 (UTC)

Whatlinkshere

Hey. Since when has Special:WhatLinksHere not shown links that are incomming from templates such as navboxes? See Semlin,_Poland and Special:WhatLinksHere/Semlin,_Poland. Is this a bug or is it mean to happen? ·Add§hore· Talk To Me! 11:49, 26 February 2009 (UTC)

If you do a null edit to each page listed on the navbox, they will then be recognized as linking to each of the other articles. I tested this with Baby Dolly and it now appears in the whatlinkshere list for Semlin. Maybe you could ask the operator of KotBot to do null edits to all these towns in each Voivodeship after the last article in the navbox group is created, then your bot will not think any of them are orphaned. — CharlotteWebb 15:00, 26 February 2009 (UTC)
Thanks for the reply. ·Add§hore· Talk To Me! 19:07, 26 February 2009 (UTC)

Well, the navbox template will show up in whatlinkshere/article_x anyway (unless wacky parser-functions or includeonlys are used), so if the bot sees no articles but at least one template, it can assume it is probably a navbox, then check whether at least one other article uses the same template, and skip the current page as "not an orphan" if so. If you really cared you could also fix the discrepancy in most cases by doing a null edit for each page which uses the navbox but did not appear in whatlinkshere/article_x. — CharlotteWebb 19:38, 26 February 2009 (UTC)

History pages again

Resolved

A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "IndexPager::reallyDoQuery (PageHistoryPager)". MySQL returned error "1054: Unknown column 'ts_tags' in 'field list' (10.0.6.26)". Enigmamsg 05:51, 27 February 2009 (UTC)

I saw it too, for every history I tried to visit. It's pretty bad. For example, the Main Page history had it. But it stopped (got fixed?) within the last minute or two. Eubulides (talk) 05:59, 27 February 2009 (UTC)

Backwards signature

In this edit, [13], my signature is rearranged, with the time and date before my name - how did this happen? DuncanHill (talk) 02:27, 26 February 2009 (UTC)

Because you typed eight tildes (i.e. four tildes twice). Signing with three tildes produces your sig, signing with four tildes produces your sig and the date/time, and signing with five tildes produces only the date/time. When you sign with eight tildes, the software interprets it as 5 + 3 tildes, thus giving the date/time followed by your sig. Graham87 07:48, 26 February 2009 (UTC)
I've made up a demo of this at User:Graham87/sandbox10. I wrote one tilde in the first line, two tildes in the second, three tildes in the third, and so on, up to eleven tildes. Graham87 07:53, 26 February 2009 (UTC)
Thanks! Now, if anyone could tell me why I typed eight tildes ... DuncanHill (talk) 17:55, 26 February 2009 (UTC)
Maybe you double clicked on the ~~~~ tag (beside all the special symbols – — … ‘ “ ’ ” ° ″ ′ ≈ ≠ ≤ ≥ ± − × ÷ ← → · §) or on the signature edit button? —EncMstr (talk) 22:12, 27 February 2009 (UTC)
Unlikely, I never use those. Probably I was just tired and angry. DuncanHill (talk) 22:29, 27 February 2009 (UTC)

PDF generation enabled for live testing on en.wikipedia.org

I've enabled the article-to-PDF generation extension here on en.wikipedia.org for live production testing. This is still slightly experimental, so the PDF download link and multi-article book collection part of it are currently limited to logged-in users only to let the load grow gradually.

We're going to be keeping an eye on load on the PDF generation server in case we need to pull it temporarily. :) --brion (talk) 19:32, 26 February 2009 (UTC)

Seems to ignore CSS classes. E.g. infoboxes with class="infobox" do not float in the upper right or have the gray background they should, but manual CSS style attributes show up fine. — CharlotteWebb 19:50, 26 February 2009 (UTC)
Brion, where should we report bugs/issues? Thanks. – ukexpat (talk) 19:52, 26 February 2009 (UTC)
Bugs/issues with the rendering should go to http://code.pediapress.com/wiki/report (or, in a pinch, into our Bugzilla and we'll make sure they make it over there too). It's pretty good now, but still not perfect. --brion (talk) 22:45, 26 February 2009 (UTC)
Issues and questions can be reported & discussed at the feedback page --He!ko (talk) 23:02, 26 February 2009 (UTC)
SVG files are rasterized within the generated PDF, not sure if there's a way to have them stored as vectors in the PDF (well, there is a way I'm sure, I just mean an automated one, heh), but it would cut down on file sizes for articles which use SVG. —Locke Cole • t • c 19:56, 26 February 2009 (UTC)
Also, not sure if this is by design or not, but templates which are normally omitted in the "Printable" version are being included in the PDF. See Dolby TrueHD which has a {{navbox}} derived navigation box at the bottom which is included in the PDF (but is removed from the printable version). —Locke Cole • t • c 20:06, 26 February 2009 (UTC)
Anything having the CSS class navbox will be removed from PDF output with the next update. -- Volker.haas (talk) 14:45, 27 February 2009 (UTC)
I noticed the same as CharlotteWebb. Navboxes are printing the entire contents. Persondata and contributors print after the references. I see the Spoken Wikipedia logo where the article does not have a spoken version. I'm guessing this does not honor some or all of the CSS print rules. --—— Gadget850 (Ed) talk - 20:13, 26 February 2009 (UTC)
As well as the above, I saw on Ellen J. Kullman that the References are appearing at the very end of the article, with a second External links heading. – ukexpat (talk) 20:17, 26 February 2009 (UTC)
There is a Ticket for that. -- Volker.haas (talk) 14:48, 27 February 2009 (UTC)

Love this, but it seems we still have quite some work to do to make all the intrinsics of Wikipedia transpose properly into PDF. infoboxes, floating images (left floats seem to make all following images left floats?). no print CSS (atm would need all noprint CSS to be templated, and added to Category:Exclude in print apparently. The external links section seems to take ALL ext. links from the page (including the coords link for instance). Ext. links sections only contain the text of the links, not the links themselves, and refs seem to end up in Ext. links. A lot of work, but it is still fun :D. (Oh and lets not forget about the humongous amount of space these extra options require in the left sidebar). Example that shows most of these issues --TheDJ (talk • contribs) 21:11, 26 February 2009 (UTC)

how does twinkle...

How does Twinkle do stuff without even opening a browser window? Like when I tag an article for CSD, Twinkle does everything without ever leaving the page. It tags the article, notifies the user, etc.

Also, I'd like to have a button for using this do-it-without-even-opening-a-new-window method to welcome new users. Like, just inserting {{welcome}} into a new user's talk page and pressing save, but automatically (like TW does). I have no knowledge of Java (which is what I assume this would be written in), so could someone give me some pointers? flaminglawyer 03:49, 27 February 2009 (UTC)

Twinkle adds a bunch of javascript to Wikipedia windows. Use your browser's "page information" function and you'll see it loads quite a few pages, including something like
 <script type="text/javascript" src="/w/index.php?title=MediaWiki:Gadget-twinkle.js&action=raw&ctype=text/javascript"></script>
If you look at the code, you'll see it hooks the OnPageLoad function where it hooks the additional functionality it uses. —EncMstr (talk) 04:08, 27 February 2009 (UTC)


(ec) Have a look at WP:FRIENDLY for adding welcome messages, it's a tool based on the Twinkle code. As for the how, start reading at Ajax (programming). Cheers, Amalthea 04:09, 27 February 2009 (UTC)
And more technically, it uses a background HTTP connection to the server to send and receive data, without actually rendering that data/html. See XMLHttpRequest --TheDJ (talk • contribs) 11:49, 27 February 2009 (UTC)

I often correct hatnotes in articles, changing them from using syntax like :''For foo, see [[bar]]'' to template syntax like {{For|foo|bar}}. This has the advantage of standardizing the format and phrasing of the hatnotes and using the {{dablink}} meta-template which applies a CSS class to the output (which, in turn, styles the hatnote properly). All of the main hatnote templates use {{dablink}}.

I noticed recently that section hatnotes, applied using templates like {{main}}, {{see also}}, or {{further}}, do not have any such standardization. While they are generally applied consistently using templates, the templates themselves don't share much in terms of standardization. Would it be desirable to apply some sort of standardization to this general family of templates? If so, how should we go about it? I would suggest either using {{dablink}} straight or creating some equivalent template. If one thinks that we should not do such a thing, why is that so? {{Nihiltres|talk|log}} 16:58, 27 February 2009 (UTC)

I would recommend making something like Template:Rellink (relatedlink) that works just like Template:Dablink. That way they can be styled differently if need be, even though they'll probably just use the same style in Common.css. --- RockMFR 18:19, 27 February 2009 (UTC)

In mediawiki is it possible to style the representation of a link, for example, through manipulation of CSS stuff in monobook?

Goal: I need to add an attribute to an <a>link tag. Example, to represent the "spouse" XFN metadata relationship between article Michelle_Obama and article Barack Obama, instead of the current wikimedia output of

<a href="/wiki/Barack_Obama" title="Barack Obama">Barack Obama</a>

It needs an additional attibute:

<a href="/wiki/Barack_Obama" rel="spouse" title="Barack Obama">Barack Obama</a>

Maybe I can establish some mumbly class rule then put a span with a class around [[Barack Obama]] or {{fullurl:Barack Obama}}?

Why would I want to do this? Because it is possible to do the same kind of graph relationships as in XFN with articles on individuals and events in Wikipedia. -J JMesserly (talk) 18:35, 27 February 2009 (UTC)

Semantic MediaWiki allows this. I don't know if there are any plans to add it to Wikipedia though. -=# Amos E Wolfe talk #=- 18:50, 27 February 2009 (UTC)
Right. I am not looking for a heavyweight solution, just want to insert the crummy rel attribute. That's all. Any way to do it in wikipedia? -J JMesserly (talk) 18:53, 27 February 2009 (UTC)
That appears to be a microformat. Check out Wikipedia:WikiProject Microformats. —EncMstr (talk) 18:59, 27 February 2009 (UTC)
Silly me: I see you are already a member of that project. I believe the proper way to do it is wrap such instances in a template which will emit the proper XML class. Perhaps something like {{relation|name|relationship}}? —EncMstr (talk) 19:11, 27 February 2009 (UTC)

(undent) Correct. That is the way most of the microformats work, but not all. The span or div class thing is what I am doing in {{start-date}}, {{map-loc}} and {{event}}. However, some microformat encoding uses atributes on html tags. This is one of them. I need a way to add the dang rel attibute as in the example above. More info on XFN encoding. -J JMesserly (talk) 19:14, 27 February 2009 (UTC)

I see. Using the fullurl construct will prevent links from being entered into the links table—which is how special:WhatLinksHere works. What is needed is a wikilink attribute modifier. I found one site which is experimenting with it. Sorry it's not much help. —EncMstr (talk) 19:49, 27 February 2009 (UTC)
About the fullurl, I would hide it in span display none and the normal link would remain. The jspwiki pointer you gave would get me what I want, but I need something I can use on foundation wikis. So- no known way to do this using any CSS chickanery or other feats of mediawiki arcanery? -J JMesserly (talk) 19:57, 27 February 2009 (UTC)

Category containing members of other categories

Hello ! I have created the Category:Quality chess articles, and now I would like it to contain the members of the categories Category:FA-Class chess articles, Category:A-Class chess articles and Category:GA-Class chess articles. At first I thought I would rewrite entirely the Template:WPBannerMeta, but maybe there is a better way :-) Any idea ? SyG (talk) 19:34, 27 February 2009 (UTC)

Why don't you just put those categories in the new category? That doesn't make the individual entries appear there, just the subcategories. But it's still a logical hierarchy. —EncMstr (talk) 19:42, 27 February 2009 (UTC)
As you state, this would add the categories to my category, not their members. No big deal for a hierarchy, but problematic when I want to use automated things like User:LivingBot/ProjectSignup that rely on the number of articles in the category. SyG (talk) 19:56, 27 February 2009 (UTC)
You can add custom functionality to Template:Chess-WikiProject - see Template:WPBannerMeta/hooks. --- RockMFR 19:49, 27 February 2009 (UTC)
Indeed the Template:WPBannerMeta/hooks/cats would seem very promising, but I have no knowledge in programming, I have tried a few times in my sandbox but I am unable to make it work :-( SyG (talk) 20:17, 27 February 2009 (UTC)

Messed up multiple columns

Resolved

I edited a section in adult standards and if I try to edit the section, the multiple columns are there. But when the full article displays, the columns are at the bottom. When I try to edit the last section, they're not there. I happened to see an article with multiple columns and figured I should just do what was done in the article.Vchimpanzee · talk · contributions · 20:45, 27 February 2009 (UTC)

See List of rivers of Oregon for a supported way that works in most browsers. —EncMstr (talk) 20:54, 27 February 2009 (UTC)

It's not working. The information is back where it was, and there's a bunch of junk where I want the second and third columns to start.

I fixed the problem when I realized the columns could be considered a table, even without headings. The sample I tried used headings.Vchimpanzee · talk · contributions · 21:04, 27 February 2009 (UTC)

Okay, fixed. It could look better, but I'll leave it for now.Vchimpanzee · talk · contributions · 21:07, 27 February 2009 (UTC)

Watchlist dead @ 21:02?

Resolved

My watchlist's last entry is showing as at 21:02, which means its appeared to have frozen. Anyone else getting the same? D.M.N. (talk) 21:29, 27 February 2009 (UTC)

I've got the same thing. The last action I show is 17:01 UTC and no updates since then. TNXMan 21:39, 27 February 2009 (UTC)
I was coming here to ask about the same thing, or at very least, to see if someone else was having the same problem and had posted here already. Acalamari 21:41, 27 February 2009 (UTC)
Ditto. Very annoying... Ealdgyth - Talk 21:42, 27 February 2009 (UTC)
How annoying, I'm 42 minutes ahead of the Wiki time. Admiral Norton (talk) 21:44, 27 February 2009 (UTC)
It's the same for Related changes on the pages I checked. Recent changes still works. PrimeHunter (talk) 21:45, 27 February 2009 (UTC)

Back now. D.M.N. (talk) 21:51, 27 February 2009 (UTC)

Edit-conflicted when trying to say the same thing. Acalamari 21:53, 27 February 2009 (UTC)

Parser help

I think parsers is what I need. (Geez, that looks smart.) If anyone would like to help me, here's what I'm trying to do. I think I've figured out a way for Signpost subscribers to modify its appearance on their talkpage. It would all theoretically work off of subpages. I would like to check for {{FULLPAGENAME}}/Style; if that page exists I would transclude the page's content as a parameter to effect the appearance. ie if /Style has "plain" they would see this, if the page has "old" they would see this, and if there was nothing they would see this; all under the same header. Would this be possible/do I need to explain that better? Thanks, §hepTalk 23:02, 27 February 2009 (UTC)

Yeah, sure. {{Wikipedia:Wikipedia Signpost/{{#ifexist:{{FULLPAGENAME}}/Style|{{{{FULLPAGENAME}}/Style}}|Default}}}} ought to work. If the /Style subpage exists, it'll transclude Wikipedia:Wikipedia_Signpost/<contents of /Style>, otherwise it'll transclude Wikipedia:Wikipedia_Signpost/Default. Algebraist 23:09, 27 February 2009 (UTC)
That sounds like an awful lot of almost useless pages to me. Why don't you have them subscribe different lists for different styles, or offer an alternative way of subscription via transclusion of a different template per style on the user or user talk page, like transcluding {{Wikipedia:SIGNPOST/Subscribe/Old style}}. If a bot is substing them on the talk pages anyway then it's just as easy. --Amalthea 23:16, 27 February 2009 (UTC)
Because there's only been a handful of user who have a problem with the new look. If there was a substantial amount then I would look into mutliple lists, until then I think this isn't too bad. Thanks for the above, I'll try to test it out. §hepTalk 05:32, 28 February 2009 (UTC)
It worked once, but now it's not. I should be able to use subst:#if.....right? §hepTalk 06:03, 28 February 2009 (UTC)

Watchlist

Changes newer than 17415 seconds may not shew - not only that, but it was an older version of my watchlist than the one displaying before I refreshed! DuncanHill (talk) 03:26, 28 February 2009 (UTC)

Same here: there seem to have been some watchlist troubles today. Acalamari 03:30, 28 February 2009 (UTC)
"Due to high database server lag, changes newer than 16992 seconds may not appear in this list." -- I'm seeing changes at the top of my watchlist from 7 hours ago. Equazcion •✗/C • 03:30, 28 Feb 2009 (UTC)
I don't know if it would be enough to make an impact, but I just edited a number of cleanup templates ([14])... does that have some relation to the lag? If so, my bad. -Drilnoth (talk) 03:34, 28 February 2009 (UTC)
I doubt it... The job queue prevents that kind of problem, I think. Equazcion •✗/C • 03:39, 28 Feb 2009 (UTC)
Okay; I just wasn't sure if the job queue was related to the amount of lag or anything. Thanks for the clarification. -Drilnoth (talk) 03:40, 28 February 2009 (UTC)
Same problem here. As of 10 minutes ago or so, my watchlist was working fine. Then, all of a sudden, everything from the past 7 hours disappeared from my watchlist, and I started getting there weird errors. Something must have gone funky with the indexing of the database orr something. Clearly, the edits are being logged, seeing as we are essentially discussing this in real time, but the changes are getting flubbed up in the database. --Jayron32.talk.contribs 03:45, 28 February 2009 (UTC)
Now might be a good time to ask for a feature request to have it break the database lag time down into hours, minutes and seconds. :P —Locke Cole • t • c 03:46, 28 February 2009 (UTC)
WP:VPR#Database lag times reported in hours/minutes/seconds. :) Equazcion •✗/C • 03:51, 28 Feb 2009 (UTC)
No kidding, I had to break out the calculator! -- Kendrick7talk 04:10, 28 February 2009 (UTC)
Me as well. :P -download | sign! 04:12, 28 February 2009 (UTC)
I just shrugged and called it a long time myself.Eeekster (talk) 04:52, 28 February 2009 (UTC)
Seems to be slowly catching up - though I've had the "pleasure" of seeing things come through my watchlist twice all evening, I'm now down to 10446 seconds behind. For the record, it would be nice to have the lag time formatted; it would also be nice to have it discard excess precision - if the lag time is multiple hours (3600 seconds per, folks!), nobody will care about the stray seconds, though minutes would still be useful. — Gavia immer (talk) 04:36, 28 February 2009 (UTC)
2956 for me now. Equazcion •✗/C • 04:50, 28 Feb 2009 (UTC)
And we're back. Equazcion •✗/C • 04:59, 28 Feb 2009 (UTC)
It cleared up at exactly midnight Eastern time. I wonder if there's any correlation. Equazcion •✗/C • 05:03, 28 Feb 2009 (UTC)
Just when it was starting to grow on me... rʨanaɢ talk/contribs 05:03, 28 February 2009 (UTC)
I know what you mean. I was getting used to being able to make changes without anyone knowing. Equazcion •✗/C • 05:05, 28 Feb 2009 (UTC)
I think it was the Y2K bug. It just caught up to us now... --Jayron32.talk.contribs 05:12, 28 February 2009 (UTC)

Blue tinge

Can someone explain why the backgrounds of all non-mainspace pages on enwp have a blue tinge? The same is not true on any of the sister projects (as far as I know). —Anonymous DissidentTalk 11:25, 25 February 2009 (UTC)

Because people here like to have fun with Mediawiki:Common.css and Mediawiki:Monobook.css? Foxy Loxy Pounce! 11:37, 25 February 2009 (UTC) TBH, I'm not sure why, but I believe it is set in one of those files. Foxy Loxy Pounce! 11:40, 25 February 2009 (UTC)

The non-mainspace page backgrounds are styled in MediaWiki:Monobook.css. There has been occasional discussion on MediaWiki talk:Monobook.css about either removing the colouring, making it more prominent, or changing the namespaces that are coloured, but nothing has ever gained any consensus. I would support a more clear distinction between "reader-facing" pages (white) and "editor-facing" pages (blue); but there is some dispute over what the distinction is. I'd say that the Article, Category, Portal, Help and File namespaces are reader-facing, while the others are editor-facing; and would support amending the colouring accordingly. Thoughts? Happy‑melon 11:40, 25 February 2009 (UTC)

I think it should be all white, as the other projects are. But that comes from my aesthetic preference; I think the blue is ugly. After all, why do we need a colour to indicate the namespace? We already have it before the colon. —Anonymous DissidentTalk 12:08, 25 February 2009 (UTC)
Why then do we need the tabs at the top of the page to change to say "project page", "article", etc? It's not necessary by exactly the same argument, but it is nice. If the interface did only what was absolutely necessary, wikipedia would be a very dreary place indeed. Happy‑melon 12:22, 25 February 2009 (UTC)
I agree with Happy Melon on this. I think the colored background is a good as an indicator and looks aesthetically good (for me). A good example where other wikis have made the color darker is on the German Wikipedia and the Esperanto Wikipedia; theirs are dark blue and orange, respectively. Since you mention the color as ugly, maybe a grey or desaturated color better? After all, Wikipedia's supposed to look grey-scaled like a book. -- penubag  (talk) 02:53, 26 February 2009 (UTC)
What you say is fair enough, HM, but I think the argument that the color scheme would somehow be useful or even "nice" in differentiating namespace is moot. —Anonymous DissidentTalk 05:11, 26 February 2009 (UTC)

I think more contrast would be better personally. I suppose that's because on my lappy I have to tilt the LCD screen backward about 30° to notice the difference in color. From straight-on it might as well all be white. — CharlotteWebb 15:22, 26 February 2009 (UTC)

I've never noticed any difference between the namespaces, in particular, this supposed blue tinge. Simplicity is generally a good thing; if we're going to complicate things with different colours, surely we can at least make them visible. Brian Jason Drake 10:17, 28 February 2009 (UTC)

Too-wide text

I noticed today or yesterday that now many Wikipedia pages have too-wide text spacing. Example screenshot from the Sino-Soviet Non-Aggression Pact article, from my Windows XP machine using Firefox 3.06:

Note the too-wide spacing between characters in the top 2 lines of text, starting with "was signed on...", and the normal character spacing in the 2nd paragraph.

How can I fix this? To my eye it looks horrible. I do think it just started occurring, so I jumped to assume it's a Wikipedia issue and not a Firefox issue. Tempshill (talk) 23:17, 25 February 2009 (UTC)

There's no code in the HTML that could cause this, so it isn't Wikipedia related. It also shows fine in IE. My guess is, as the widening starts right after the Chinese characters, that Firefox has a small problem (Unicode) rendering a cobination of Chinese and Latin characters in the same paragraph. — Edokter • Talk • 02:12, 26 February 2009 (UTC)
if you could look at the relevant lines of code from the page source, that might be useful. in Safari it's:
<p>The <b>Sino-Soviet Nonaggression Pact</b> (中蘇互不侵犯條約) was signed on August 21, 1937, between the <a href="/wiki/Republic_of_China" title="Republic of China">Republic of China</a> and the <a href="/wiki/Soviet_Union" title="Soviet Union">Soviet Union</a> during the <a href="/wiki/Second_Sino-Japanese_War" title="Second Sino-Japanese War">Second Sino-Japanese War</a>.</p>
if you see something different in your browser, that might indicate a Wikipedia problem, otherwise it's surely a browser issue as Edokter suggests. --Ludwigs2 02:30, 26 February 2009 (UTC)
It could also just be a font thing. I have a jank computer with stuff that got messed up when I installed language files, so sometimes when I switch back and forth between Chinese and Latin script I end up in a funky font that looks a bit like that. Have you tried editing that page and just re-typing the problem part in regular text? rʨanaɢ talk/contribs 02:32, 26 February 2009 (UTC)
This has come up before, see /Archive_49 for example. It apparently is due to a mixture of unicode and html in a paragraph, and only in certain versions of Firefox (near 3.0.3) in Windows XP, and might be related to the font you're using. --Splarka (rant) 09:03, 26 February 2009 (UTC)
What browser are you using? I have seen and reported this as well. It has something to do with the Chinese characters. The XP box I am on right now does not have Asian languages installed (never been able to get it to work), so I will check on a different box in a bit. --—— Gadget850 (Ed) talk - 12:27, 26 February 2009 (UTC)
What browser are you using? I've never known this to be more complicated than a download and a drag-and-drop to the "Fonts" folder whenever I see a bunch of f▯▯▯▯▯▯ unrecognized characters—don't even need to restart Firefox. Granted I'm in Windows 2000 SP4 but I doubt XP could be much different. — CharlotteWebb 15:13, 26 February 2009 (UTC)

The page cited above renders fine for me using Firefox 3.0.6 on Debian Lenny; perhaps this is an interaction between Firefox and Windows? -- The Anome (talk) 15:25, 26 February 2009 (UTC)

Well, it also looks fine in Firefox 3.0.6 on win2k. — CharlotteWebb 15:36, 26 February 2009 (UTC)
It looks fine on Firefox 3.0.6 and XP with Asian language but I have seen this before. --—— Gadget850 (Ed) talk - 18:16, 26 February 2009 (UTC)

Original poster here. Grr, a restart of Firefox fixed it for me. I just submitted this as a Firefox bug; it's bug 480419. Thanks all for the comments. Tempshill (talk) 23:07, 26 February 2009 (UTC)

For the record, the problem appears in a number of other articles as well, such as Agape and Philadelphia (mostly in relation with IPA pronunciation characters). - Mike Rosoft (talk) 21:23, 28 February 2009 (UTC)

Template talk:ArticleAlertbotSubscription

Could someone take a look at the code and confirm that there's no problem in using comments in #ifeq: statements? Headbomb {ταλκκοντριβς – WP Physics} 14:51, 26 February 2009 (UTC)

There is no problem using html comments anywhere. The parser strips these out of the wikitext before doing anything else. For example, [<!-- foo -->[this]] is no different than [[this]] valid link.— CharlotteWebb 15:33, 26 February 2009 (UTC)
Alright, I thought so. Thanks a bunch.Headbomb {ταλκκοντριβς – WP Physics} 17:46, 26 February 2009 (UTC)
Not strictly true. Compare the following:
x
<!-- 1 --><!-- 2 -->
y

x
<!-- 1 -->
y
--Splarka (rant) 20:06, 26 February 2009 (UTC)
Don't know how the hell you found this but it looks like a bug to me. I see no reason why two directly adjacent html comments should behave differently than one. — CharlotteWebb 20:13, 26 February 2009 (UTC)
m:Migration_to_the_new_preprocessor#Expected_differences. We found it when checking differences in the preprocessors. It is not a bug, just an expected difference. This is sort of because with one comment, the whole line is ignored, but with two, there is some part of the line in the middle there, treating it like a blank line (and interpreted as paragraph break). Or something. --Splarka (rant) 08:16, 27 February 2009 (UTC)
That doesn't make any sense. Both of these should be identical to x\n\ny after comments are removed, unless there is some reason it would make sense to behave differently. — CharlotteWebb 08:59, 28 February 2009 (UTC)

Bug in the redirect-tracking system?

(Moved from WP:AN.)

I agree it is very strange. This link shows the error more clearly. Martinmsgj 11:29, 27 February 2009 (UTC)

Look at it in edit mode. Whoever made the redirect didn't delete the previous text so it still shows up in the search because it is the current version. John Reaves 12:04, 27 February 2009 (UTC)
It's still not a redirect to 9/11 though! Anyway, this is clearly not in the right place, so I'm going to move it to WP:VPT. Martinmsgj 13:12, 27 February 2009 (UTC)
It's behaviour is documented in bug 7304, and causes all sorts of weird and wonderful problems, as described in the comments at the Bugzilla entry. Graham87 13:53, 27 February 2009 (UTC)
To clarify with an example, if you typed "#redirect [[Bar]] I think [[chocolate]] bars are the best" in the "foo" article, a check of what links to "chocolate" would say that foo is a redirect to chocolate, when in reality foo would be a redirect to bar. This can cause problems when an automated script tries to add text to a redirected user talk page, as I've discussed before. Graham87 14:04, 27 February 2009 (UTC)
Or if "Bar" exists but "Chocolate" does not, the example above could be mistaken for a "redirect to a deleted page" and automatically deleted by some bot. — CharlotteWebb 11:10, 28 February 2009 (UTC)

I'm racking my brain trying to remember how someone created a double-bracketed (internal) wikilink which pointed to a diff. But while I'm at it, I might as well also ask if it is possible to point an article's history page or past revision using an internal wikilink. ←Spidern→ 14:09, 27 February 2009 (UTC)

I'm not aware of any way to access diffs and past article revisions using an internal wikilink. However, it is possible to make an external wikilink look like an internal one, by using the span tag with the plainlinks class. For example: <span class="plainlinks">[http://www.example.org example]</span> produces the text example, in the style of an internal link. Graham87 14:48, 27 February 2009 (UTC)
That's still a different colour to internal links, though. You can make links to http://en.wikipedia.org/ the same colour as internal links with plainlinks2: <span class="plainlinks plainlinks2">[http://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&action=history VPT history]</span> produces VPT history. Algebraist 16:03, 27 February 2009 (UTC)
That's not the same colour to me. DuncanHill (talk) 17:03, 27 February 2009 (UTC)
What's not the same colour as what? Under uncustomized monobook, my 'VPT history' link should be the same colour as unvisited internal wikilinks, while Graham87's 'example' link should be a different colour. Algebraist 17:13, 27 February 2009 (UTC)
Unvisited internal links are "colour A", Graham's is "colour B" and yours is "colour C" (A, B, and C are all shades of blue). Mind you, I use blackscreen to protect my eyes. DuncanHill (talk) 17:17, 27 February 2009 (UTC)
If you mean you're using the green-on-black gadget, then that's as expected. That gadget renders links as #7070FF, while the default (and that of my link above) is #002bb8. Algebraist 02:47, 28 February 2009 (UTC)
I don't think that is possible. What would you use it for? It wouldn't work in data users. Could you have seen {{Diff}} in use and not a wikilink? PrimeHunter (talk) 17:19, 27 February 2009 (UTC)
I really wish I could remember. The syntax that sticks in my head was something like [[somearticle?diff=11111|title]]. I remember finding it peculiar that someone was displaying a diff without using an extlink. All things considered, the {{Diff}} template looks useful too. ←Spidern→ 18:49, 27 February 2009 (UTC)
Could you be thinking of fullurl: [{{fullurl:Wikipedia:Village pump (technical)|action=history}} VPT history] produces VPT history? Algebraist 19:02, 27 February 2009 (UTC)
No, because as we can see, that produces an extlink icon. ←Spidern→ 19:27, 27 February 2009 (UTC)

I was unable to convince anyone to adopt a version of Template:Diff with fewer redundant parameters. Diff2 is much easier to use, e.g. {{diff2|247090972|very long comment}} → very long comment. Also it uses auto-numbering if no title is given, e.g. [15]. — CharlotteWebb 11:18, 28 February 2009 (UTC)

I'm sure there's some reason why we can't use a wikilink prefix like [[diff:247090972]] or [[es:wikt:diff:275824]] for other projects, etc. but I haven't found it. — CharlotteWebb 11:24, 28 February 2009 (UTC)
I believe that format in wikilinks is only used for namespaces, diff is more of a function so it makes sense for it to use a template --Nezek (talk) 12:52, 28 February 2009 (UTC)

Problems with PDF rendering of books

Resolved
 – Posted at Help:Books/Feedback. Admiral Norton (talk) 19:18, 28 February 2009 (UTC)

I have tried out the new book feature and it's satisfying and indeed quite good, but not perfect. Some templates, like {{Geographic location}}, pose big problems in reading the text (check out User:Admiral Norton/Books/Zagreb County sample book to see what I'm talking about). Admiral Norton (talk) 21:42, 27 February 2009 (UTC)

Please leave your concerns at the correct venues through Wikipedia:Books at Help:Books/Feedback, this is where the developers of the extension will see your issues. Thanks, §hepTalk 21:49, 27 February 2009 (UTC)

Image problems?

I know I uploaded File:Braid-dk.jpg but as of now (21:50 on 2-27-09) the servers act like its not there, and there's no record of any action until that name (no log entries pop up when checked). I wonder if there's any weirdness with the watchlist hiccup from above. --MASEM (t) 21:52, 27 February 2009 (UTC)

Rather odd. The image is still accessable (and the thumb). Google's cache of the page from Feb 27, 2009 04:53:51 GMT shows it just fine:
<div class="thumb tleft">
<div class="thumbinner" style="width:182px;"><a href="/wiki/File:NonFreeImageRemoved.svg" class="image" title="A screenshot from Braid, showing a homage to Donkey Kong"><img alt="" src="http://upload.wikimedia.org/wikipedia/en/thumb/b/b7/NonFreeImageRemoved.svg/180px-NonFreeImageRemoved.svg" width="180" height="101" border="0" class="thumbimage" /></a>
<div class="thumbcaption">
<div class="magnify"><a href="/wiki/File:NonFreeImageRemoved.svg" class="internal" title="Enlarge"><img src="/skins-1.5/common/images/magnify-clip.png" width="15" height="11" alt="" /></a></div>
A screenshot from <i>Braid</i>, showing a homage to <i><a href="/wiki/Donkey_Kong" title="Donkey Kong">Donkey Kong</a></i></div>
</div>
</div>
But new thumbnails can't be generated, and {{#ifexist:Media:Braid-dk.jpg|yes|no}} shows "no" as of this writing (and "{{#ifexist:Media:Braid-dk.jpg|yes|no}}" now). --Splarka (rant) 08:59, 28 February 2009 (UTC)

New message

Why was this annoying new message

"Code that you insert on this page could contain malicious content capable of compromising your account. If you are unsure whether code you are adding to this page is safe, you can ask at the appropriate village pump. The code will be executed when previewing this page."

above .js and .css pages added? — Aitias // discussion 23:53, 27 February 2009 (UTC)

Because it's an important fact that people should be aware of? If you don't like it, kill it with 
#jswarning {display: none};
Algebraist 23:57, 27 February 2009 (UTC)
See MediaWiki_talk:Jswarning. And it doesn't look very new, that warning looks to have been around since October of last year, according to the histories. --Splarka (rant) 00:14, 28 February 2009 (UTC)
Yeah, it was in response to a specific incident - someone was going around telling people that they had to blindly edit .js pages, and a certain percentage did. Sice we can't stop people beforehand from believing such social engineering attacks, we make the interface yell at them not to do it. It turns out that the same people who blindly believe they should make mystery edits also will blindly obey any part of the interface that looks official and authoritative, with the net result that we've had no major problems since. — Gavia immer (talk) 04:29, 28 February 2009 (UTC)
Actually I think the warning message is more likely to reduce the number of social engineering attempts, but not make the number of remaining attempts any less successful. See dancing pigs, banner blindness, etc. — CharlotteWebb 09:08, 28 February 2009 (UTC)
I'm not sure, CW. If you were inexperienced with Javascript, and you were adding a code snippet on instruction, then I think one would pause upon seeing the pointy red message box above the edit window, and impulsively have a quick scan. I think the group who would be caught out by such a ruse would be those who were both fairly novice in the realm of Javascript, and not fully acquainted with the MediaWiki engine: just enough experience to infer a sense of slight over-confidence, but not enough to deduce the functionality of the hostile code, or realise the implications of blindly using it. Then again, anyone who adds a user script manually is taking a leap of faith that the script doesn't include any malicious code – even those Wikipedians with a knowledge of Javascript (and I imagine that that would be a fairly high proportion of active contributors, although perhaps I'm reaching for the "computer-wiz" stereotype too readily) aren't always inclined to check through scripts line-by-line before implementing them. haz (talk) 09:31, 28 February 2009 (UTC)
Seems to be working: Wikipedia:Help desk#Can not delete a user page. --—— Gadget850 (Ed) talk - 16:18, 28 February 2009 (UTC)

New way to redirect?

Hi! Not a big problem, just a curiosity. As in Wikipedia:Articles for creation/Redirects#Redirect request: NGC6820 & NGC6823 & NGC6820 and NGC6823 & NGC6823 and NGC6820 & NGC 6823 and NGC 6820 (all pointing to NGC 6820 and NGC 6823) several legitimate variations of spelling, etc., can exist for the title of an article. One (hopefully the best one) is chosen and a bunch of redirects are created.

It seems that an extension(?), or similar, could be implemented such that a list of alternative names could be placed in the target article and the db updated when the article is saved. A lot less fussy from the editors' standpoint.

Is this a feasible feature request? Or is it too fussy from the programmers' perspective? Thanks. Saintrain (talk) 15:48, 28 February 2009 (UTC)

You don't have to go to Wikipedia:Articles for creation. You can quite easily create a redirect yourself by creating a new article with
#REDIRECT [[Link to target page]]
as its only content. (It's also tidier if you replace underscores with spaces).
A proper redirect system based on metadata would be nice but would also probably involve substantial changes to the core software. You might want to try asking at bugzilla. — Blue-Haired Lawyer 16:36, 28 February 2009 (UTC)
Thanks. I didn't go there to ask for a redirect, but to create the redirect(s)for other users (You can help).
My idea of a stop-gap was to create 'hard' redirects at target-article save-time. I wanted to float the idea here before bothering bugzilla. Saintrain (talk) 18:58, 28 February 2009 (UTC)
This seems like quite a small thing to write into mediawiki. It's more the sort of thing you'd use a script or AWB for. Algebraist 19:01, 28 February 2009 (UTC)

An unusual redirect

In the 07:36, 28 February 2009 edit by User:BuickCenturyDriver of A. J. Burnett (disambiguation), he redirected to a file by transcluding it instead of by #redirect! Anthony Appleyard (talk) 18:27, 28 February 2009 (UTC)

Firstly, he didn't transclude, he substed. The substing failed because Template:Allen James Burnett doesn't exist. Secondly, why are you posting this here? Algebraist 18:38, 28 February 2009 (UTC)

Category:Uncategorized pages

(Cross posting from WP:HD on recommendation)

Am I halluncinating? This category used to be filled to the brim with articles just a few days ago and now it suddenly has subcategories with no indication in the history of either parent or child cat how they came to be there. Special:UncategorizedPages doesn't update properly. Did I visit the wrong cat or what? - Mgm|(talk) 12:59, 27 February 2009 (UTC)

Yeah, I checked Category:Category needed as well, and I don't see anything there. Either folks at the categorization WikiProject have been working extra hard over the past few days (unlikely but possible) or there is a glitch in the system somewhere we are missing. Perhaps a post at WP:VPT or something may get someone's attention with more technical savvy?!? I am confused here as well. --Jayron32.talk.contribs 13:09, 27 February 2009 (UTC)
Special:WhatLinksHere/Template:Uncategorized has only pretty few pages, seems like just the amount that are in Category:Uncategorized pages. Similar with Category:Uncategorized stubs. It does appear to be up to date though, Tughlaq Tamar Khanwas tagged today and is in the category, Blastosaurus is from today and can be found in Special:UncategorizedPages. No idea if they were really all cleaned up. You don't have an example of a page that should be in the Category, but isn't?
You should probably check with the people at WT:WikiProject Categories/uncategorized. --Amalthea 21:27, 28 February 2009 (UTC)
See Template:Categorization progress and click on "Show". Seems to've been cleared out by someone. --Amalthea 21:32, 28 February 2009 (UTC)
  • The day before I asked there were literally hundreds of pages. I really doubt a single person cleared it out. Also, it doesn't explain the sudden appearance of subcats without any indication of them (the subcats) being categorized in recent days. - Mgm|(talk) 23:07, 28 February 2009 (UTC)
Maybe something bottish going on. Anyway, that thing doesn't seem to count subcats very well. - Mgm|(talk) 23:08, 28 February 2009 (UTC)

"Proxy-Connection:keep-alive -- Cache-Control: max-age=0"

I've been seeing this a lot in anonymous edits recently, and I've been watching anonymous edits for five years (example). What is this, and why does it happen? Sometimes the edits are done in good faith, but this extra bit of information gets saved with the edit; invariably a vandalism-patroller rolls them back. Is it some sort of misconfigured proxy? Antandrus (talk) 01:36, 1 March 2009 (UTC)

See also Wikipedia:WikiProject on open proxies and meta:WikiProject on open proxies. Not sure whether this is a proxy issue or not, maybe a buggy web browser extension? --- Best regards, Melancholie (talk) 02:47, 1 March 2009 (UTC)
[16] was explained in [17] as: "That's some weird mess-up by FireFox for Mac. In fact, I'm not connecting via a proxy per se; simply using a standard router from a major ISP". I don't know whether the explanation is right. PrimeHunter (talk) 03:29, 1 March 2009 (UTC)
Well, it does happen for me on Firefox for Mac ... Calvin 1998 (t·c) 03:42, 1 March 2009 (UTC)

Help:Javascript

Hellow, I need some help for using javascripts in HTML. I am trying to make collapsiple unordered lists. Please see the following unordered list. I want that if I click on "Windows", then 1998, 2000, XP and Vista will be shown; and if I again click on "Windows", then 1998, 2000, XP and Vista will be collapsed. I want to apply this to all components of the list. If you can help me, you can contact me to my talk page. --Amit (Talk | Contribs) 11:33, 26 February 2009 (UTC)

  • Computer
    • Windows
      • 1998
      • 2000
      • XP
        • SP1
        • SP2
        • SP3
      • Vista
    • Linux
    • Mac OS

You would need to write a script that does this, then add it to MediaWiki:Common.js, because there is no page-specific javascript. You would need to wrap the list in some sort of <div class="listcollapsable"> or whatever, so that the script can check for this and know when and when not to do anything. If you come up with something good, the same code could also be used for tables of contents. — CharlotteWebb 11:02, 28 February 2009 (UTC)

Actually I am a novice JavaScript editor. So I want the JavaScript code that is needed to make such a collapsible list. --Amit (Talk | Contribs) 13:31, 1 March 2009 (UTC)
I suggest putting an onclick for each item, which calls the scrpit which sets the element's .childNodes.(all of their)style.display = 'none'.

example: 

function showHide(elmt){
var children=elmt.childNodes
for(i=0;i<children.length;i++){
if(children[i].style.display='none'){
children[i].style.display='inline'
}else{
children[i].style.display='none'
}
}

}

Here is your HTML: 

....
<li onclick="showHide(this)">
inner list goes here......

</li>
....

ManishEarthTalk • Stalk 14:07, 1 March 2009 (UTC)

Hotcat problem

I've used Hotcat for a while, but recently I have found that it has not been offering me any suggestions. Also, whatever I type (even a valid category) I still get the ☒N, rather than the checkY. Are others having problems with Hotcat, or am I missing something obvious? Gwinva (talk) 04:27, 1 March 2009 (UTC)

Just tested, no problems here. How are the other javascript aspects of Wikipedia working for you? Do the search bar suggestions work? Equazcion •✗/C • 04:31, 1 Mar 2009 (UTC)
Is your browser reporting any javascript errors (tools/error console in FireFox)? Algebraist 11:47, 1 March 2009 (UTC)
Ah! Thanks for the pointer Equazcion: I disabled the search bar suggestions ages ago since I prefer having my history there. I've not used any of my own scipt to do so: just the [my preferences-search options-Disable AJAX suggestions] gadget. By reabling it, I find hotcat works. But, strangely, while I disabled it ages ago (within days of the search suggestions being implemented), I've only noticed hotcat problems recently. Is this a new problem, or has the one gadget always affected both and I am just a bit slow to notice? Anyway, it seems I must either be annoyed by the search box or annoyed by hotcat.
(Thanks for your pointer too, Algebraist. Being computer illiterate, I never knew that error console was there. I have checked it over, and while I didn't find anything pertinent to this problem, I will look there first next time!) Gwinva (talk) 21:03, 1 March 2009 (UTC)

Secure server

Just for interest and because I can't find information elsewhere (sorry if it is actually in an obvious place), could someone explain to me the advantages of using the secure server? Are there any if one is not on a public computer (see Special:UserLogin)? —Anonymous DissidentTalk 06:18, 1 March 2009 (UTC)

The secure server uses a protocol called HTTPS, which means that all the HTTP information (such as passwords, cookies) is sent encrypted. This will decrease the chance that some eavesdropper somewhere on tghe internet will be able to pick up the information and compromise your account. No idea how big a risk this is, but I don't think it applies to public computers any more than to private ones. עוד מישהו Od Mishehu 08:33, 1 March 2009 (UTC)
If you're accessing Wikipedia through the secure server, it's not possible for anyone to censor it except by blocking Wikipedia entirely. --Carnildo (talk) 08:33, 1 March 2009 (UTC)
In fact, they can't do so without blocking all Wikimedia foundation sites. עוד מישהו Od Mishehu 09:41, 1 March 2009 (UTC)
Help:Logging in#Immediately logging out says the secure server can fix that in some cases. PrimeHunter (talk) 12:35, 1 March 2009 (UTC)

Special:Export rate limits?

I'm trying to work out how to build some kind of partial Wiki dump of some articles updated since October 08 (the last full dump date), without putting undue load on the Wikipedia cluster. I'd make the raw update publicly available on Amazon S3 or somewhere.

One naive way to do this is by using Special:Export to reexport some limited set of "important" articles (e.g., FAs); another is to watch Special:Recentchanges and download (a subset of?) changed articles daily or so. For efficiency, we're talking current versions only, batching export requests, and avoiding duplicate requests for the same page.

I figure that bots that monitor content changes (like SineBot) must be doing something like this, so the concept must be viable.

Question is, how much use of Special:Export is too much? Is there some articles/second limit I should respect? Should I feel free to pull down as much as I can over a single HTTP connection (i.e., without making requests in parallel)?

And is there a better way to do this? 67.119.195.43 (talk) 08:25, 1 March 2009 (UTC)

Template:Handel operas

I'd appreciate some help getting this set up: A couple werd display bugs, like the last item in the list dropping down a line. I don't think I quite have it right yet. It might also be nice if I could change the default colours. Shoemaker's Holiday (talk) 08:35, 1 March 2009 (UTC)

Source tag being too technical

I just found out that the source tag does not support the language 'html'. You have to type in 'html4strict' or something like that

Doesn't support "lang=HTML" 

blah



Or even "lang=html4" 

blah




It supports lang=html4strict 

blah

Shouldn't those languages be added so that people don't have to hunt for it? ManishEarthTalk • Stalk 14:12, 1 March 2009 (UTC)

It isn't that simple. The GeSHi MediaWiki extension is just a wrapper for the external program (GeSHi). See bugzilla:10201 and bugzilla:10967 --Splarka (rant) 14:30, 1 March 2009 (UTC)

On moving a page, whether or not to leave a redirect behind

For the most part, leaving a redirect behind is the correct thing. Limiting this ability to admins and bots is a good way to prevent abuse of this feature, which should rarely be used. עוד מישהו Od Mishehu 14:55, 1 March 2009 (UTC)
This is not a technical issue. Admins gain their rights by earning the trust of the community. Moving pages without leaving a redirect is a useful tool, but dangerous. This is little different from the admin right to delete a page. --—— Gadget850 (Ed) talk - 14:58, 1 March 2009 (UTC)
(edit conflict) Only admins can delete redirects and other pages. Not leaving a redirect behind when moving a page is basically just a simplification of first moving and then deleting the resulting redirect. It can be used to clean up page move vandalism in a nicer way. If non-admins could move without redirects then vandals and inexperienced editors could cause serious problems like moving a validly named page so it breaks all incoming links and becomes hard to find. I think moving without leaving a redirect should usually only be done in cases where a redirect could be speedily deleted per Wikipedia:Criteria for speedy deletion, and any user can tag a redirect for speedy deletion. PrimeHunter (talk) 14:59, 1 March 2009 (UTC)
Non-admin users can decide whether to leave a redirect behind by first moving the page, then using one of the deletion methods (speedy or RfD) to request deletion of the redirect. At RfD, it's all users, not just admins, who get to decide whether the redirect is deleted or not. ☺Coppertwig (talk) 15:20, 1 March 2009 (UTC)

It is my understanding that this "suppress redirect" feature was intended for use when reverting a page-move that was obviously vandalism (of the "…on wheels", "…is communism", "massive H.–.–.–.–.R.??", "so-and-so's phone number is…" variety). Anything else should at least be deleted in a way that leaves an entry in the deletion log. — CharlotteWebb 16:23, 1 March 2009 (UTC)

Duplicate Name

There's already a David Karp article. How do I create an article on a different David Karp (the Fruit Detective)? —Preceding unsigned comment added by RogerTaft (talk • contribs) 01:17, 2 March 2009 (UTC)

See WP:DISAMBIG. Algebraist 01:23, 2 March 2009 (UTC)

I find it annoying that the new "create a book" box in the side bar is placed above the much more important "toolbox" with its frequently used links (such as logs, user contribs and others). On my laptop screen, the toolbox has now been pushed below the margin of the screen, forcing me to scroll down each time I need it. Can we please put the book box below the toolbox, not above it? Fut.Perf. ☼ 07:42, 27 February 2009 (UTC)

It isn't possible to easily move the "create a book" section. However, it is easy to move the toolbox above it. Direct suggestion to -> MediaWiki talk:Sidebar. --Splarka (rant) 08:30, 27 February 2009 (UTC)
If you want to hide the box completely, you can for now insert something like
#p-coll-create_a_book { display: none; }

into Special:MyPage/monobook.css. Probably there is going to be some kind of gadget to enable/disable the box. Jbeigel (talk) 09:40, 27 February 2009 (UTC)

You can move stuff around with javascript. For example, the following code in Special:MyPage/monobook.js will move that box to the bottom of the sidebar:
addOnloadHook(function(){
   var book=document.getElementById("p-coll-create_a_book");
   book.parentNode.appendChild(book);
});
Algebraist 10:36, 27 February 2009 (UTC)

I added above workarounds to the FAQ. --He!ko (talk) 12:00, 27 February 2009 (UTC)

Thanks to everybody who replied for their helpful hints. I've done some of that display:none stuff; works for me. Fut.Perf. ☼ 17:53, 27 February 2009 (UTC)

I moved the toolbox above the "create a book" box just now. Hopefully no one will revolt. By the way, any thoughts on moving the search box to the top of the sidebar? —Remember the dot (talk) 19:00, 27 February 2009 (UTC)

"...any thoughts...?" Why, yes, there are. --Splarka (rant) 23:46, 27 February 2009 (UTC)
I proposed to revert this change here. --He!ko (talk) 16:56, 2 March 2009 (UTC)

Template autocollapse behavior modification

I started a topic in Template_talk:Navbox#Autocollapse_modification. Current autocollapse feature in templates collapse all templates in an article. Instead first of the templates should be expanded when all templates are autocollapse. Cited third page (talk) 07:04, 2 March 2009 (UTC)

Presentation of disclaimer on a table

Can anyone offer any suggestions on the best way to arrange the presentation of a disclaimer on a table? This will be used on about 150 similar tables and applied though pre-existing templates, so I'd like to take a little care in geting it right.

What I want is a block of small-ish print text which fits neatly at the bottom of the table without appearing to be part of it. I think it should constrained to the width of the table, but I haven't found a satisfactory way of doing this.

I have done a few doodles at User:BrownHairedGirl/table disclaimer sandbox, but none of them seems very satisfactory, and I'd welcome any suggestions on how to go about it.

--BrownHairedGirl (talk) • (contribs) 15:45, 2 March 2009 (UTC)

It is not "constrained to the width of the table" because the table has no set width. The default to assume the width of whichever row would be the widest by itself (in this case the footnote text) and try to keep the text on one line unless this would exceed screen width (at which point it begins wrapping around). — CharlotteWebb 17:28, 2 March 2009 (UTC)

Setting the background to white will only work if you know that the background behind the table is also white, which is not necessarily true depending on the users' skins/settings. Setting the cell in the last row to "background:transparent" doesn't work either because that would just mean "continue letting the gray of the table show through rather than covering it with anything else". I haven't found any way to cut a hole in it so to speak. — CharlotteWebb 17:47, 2 March 2009 (UTC)

Fall-through values in #switch statements

Resolved
 – My mistake. rʨanaɢ talk/contribs 19:56, 2 March 2009 (UTC)

The documentation for switch functions at mw:Help:Extension:ParserFunctions#.23switch: says:

It is possible to have 'fall through' values, where several case strings return the same result string. This minimises duplication. 

{{#switch: comparison string
 | case1 = result1
 | case2 
 | case3 
 | case4 = result2
 | case5 = result3
 | case6 
 | case7 = result4
 | default result
}}

Here cases 2, 3 and 4 all return result2; cases 6 and 7 both return result4.

Is this true, or has something changed? In a template I just worked on (User:Rjanag/DYKfile) it didn't seem to work when I tested it (see here for the version where I tried to have fall-through values). If it doesn't work any more, we should update the documentation.... if it does still work, then I'm probably just being an idiot (wouldn't be the first time). Thanks, rʨanaɢ talk/contribs 19:52, 2 March 2009 (UTC)

Try using the code as written in the documentation. You've got some extraneous equals signs in there. Algebraist 19:55, 2 March 2009 (UTC)
Oh, you're right. Thanks. rʨanaɢ talk/contribs 19:56, 2 March 2009 (UTC)

Article invisible to search

If I search (not "Go") on the three words "Frank Harris Hitchcock" (or on any two of them), the article Frank Harris Hitchcock does not appear as a hit. Any ideas why? PamD (talk) 23:41, 2 March 2009 (UTC)

I can't get it to show up in search results either. Hmm. I'm intrigued. Equazcion •✗/C • 23:57, 2 Mar 2009 (UTC)
I tried a null edit. Perhaps now it will show up in a couple of days. --TheDJ (talk • contribs) 00:09, 3 March 2009 (UTC)

Category:Temporary infobox road category

I happened to run across and create this category: Category:Temporary infobox road category and it looks like it has several articles with infobox problems. Could someone that knows how to fix the articles or the {{Infobox road}} template help out? Thanks much! --Funandtrvl (talk) 03:12, 3 March 2009 (UTC)

Revision history tidy

Slight modification would tidy up the article revision history page. Suggestion is to move "bytes info" before username.

Example current history format: 

   * (cur) (last) 03:53, 21 November 2008 Raise lkblr (Talk | contribs) (25,910 bytes) (→Ulsoor lake photo) (undo)
   * (cur) (last) 22:37, 20 November 2008 Lihaas (Talk | contribs) (25,663 bytes) (→The name-change debate, again) (undo)

Example suggested(bytes info moved back): 

   * (cur) (last) 03:53, 21 November 2008 (25,910 bytes) Raise lkblr (Talk | contribs) (→Ulsoor lake photo) (undo)
   * (cur) (last) 22:37, 20 November 2008 (25,663 bytes) Lihaas (Talk | contribs) (→The name-change debate, again) (undo)

It would make it easy on eyes to compare bytes of adjacent revisions, to see if article size increased or decreased. Also it would give impression that revision size and revision link are together, compared to userpage & talk links to the next. Since usenames are of different length currently bytes info looks cluttered, and both bytes and edit summary being un-hyperlinked adds more clutter. I think this is definitely worth a try! Raise lkblr (talk) 08:16, 2 March 2009 (UTC)

Just wanted to point out that byte length will be different sometimes too, though not nearly as often as usernames. Could be good idea. Equazcion •✗/C • 08:22, 2 Mar 2009 (UTC)
If you're interested I think I remember posting a javascript gadget here several months ago which would subtract the byte counts and include the net +/− change for each edit (with the same color/boldness as on watchlists/recentchanges). — CharlotteWebb 17:04, 2 March 2009 (UTC)
I will be most of the times not-logged in, so i would like wikipedia change instead. +/- i have enabled in my watchlist, thanks Raise lkblr (talk) 03:11, 4 March 2009 (UTC)

Cites and disambiguation

I just tried to make an edit that read in part:

<ref>{{cite book ... | publisher=[[Doubleday (publisher)|]] }}</ref>

But when this was expanded in the article's <references/> section, it did not become a wikilink; the [[Doubleday (publisher)|]] came out as ordinary body text.

Experiment revealed that there was no problem if I made any of three changes:

  1. Don't use the <ref> ... </ref> tags, but just use {{cite book ... }} directly.
  2. Link to [[Doubleday]] instead of the correct page
  3. Write the link [[Doubleday (publisher)|Doubleday]] out in full.

But writing it exactly as shown above produced the wrong result. --208.76.104.133 (talk) 08:58, 2 March 2009 (UTC)

  • I don't remember the exact article I saw it in, but I've experienced a similar issue. - Mgm|(talk) 10:22, 2 March 2009 (UTC)
    • I have been experiencing the same thing recently, having returned from an 8-month wikibreak, and I don't recall it in the past. It isn't tied to use of the pipe trick within a template, but applies to any wikilinks inside <ref></ref> tags, e.g. <ref>See [[Doubleday (publisher)|]]</ref>.
      Is there are any particular reason why the pipe trick could not be enabled in refs? --BrownHairedGirl (talk) • (contribs) 14:11, 2 March 2009 (UTC)
This issue is documented at Wikipedia:Footnotes and Help:Pipe trick. --—— Gadget850 (Ed) talk - 14:17, 2 March 2009 (UTC)
Fair enough, a long-standing known bug. I had obviously forgotten that it had been there before.
Pity it hasn't been fixed, because refs are very important but the syntax is difficult for new editors and this only makes it harder for them. The existence of a long-standing a bug in cite.php doesn't fit well with the high priority given to WP:V. :( --BrownHairedGirl (talk) • (contribs)

I know there is a page on bugzilla about this because I remember seeing it, but I can't seem to find it [18]. — CharlotteWebb 18:03, 2 March 2009 (UTC)

It's here. — Blue-Haired Lawyer 16:14, 3 March 2009 (UTC)

New namespace proposed

It's proposed to create a new namespace for books, see Wikipedia:Village pump (proposals)#Namespace for books. Cenarium (talk) 18:55, 3 March 2009 (UTC)

MediaWiki:Talkpagelinktext

Any objection to making this message lowercase to be consistent with the others? (talk | contribs | block) instead of (Talk | contribs | block). --MZMcBride (talk) 09:31, 2 March 2009 (UTC)

Sounds reasonable to me. — TKD::Talk 15:06, 2 March 2009 (UTC)
Just do it. I'd like to see if anyone is daft enough to revert (saying "zomg this wasn't discussed"). — CharlotteWebb 17:54, 2 March 2009 (UTC)
Done. --MZMcBride (talk) 23:07, 2 March 2009 (UTC)

Oh thank God! That's been bugging me for literally months; I was wondering where to find it! Happy‑melon 14:50, 3 March 2009 (UTC)

Now we also need to change MediaWiki:Blocklogpage and MediaWiki:Log. These occur together with the talk page link in places such as the subheader at Special:Contributions. haz (talk) 15:59, 3 March 2009 (UTC)
 Done, but it doesn't seem to have taken effect at Special:Contributions, etc. Hmn.... Happy‑melon 16:14, 3 March 2009 (UTC)
No, but I can see where it has... looks like I got one of the pages wrong. Can you revert this? (And where the deuce is the block log text..?!) haz (talk) 17:19, 3 March 2009 (UTC)
It's at MediaWiki:Sp-contributions-blocklog. No longer I couldn't find it... the page doesn't exist yet! haz (talk) 17:29, 3 March 2009 (UTC)

 Done and  Done. I also did MediaWiki:Histlast and MediaWiki:Histfirst. Special:Allmessages is very useful in this situation, although it takes aaaaages to load. Happy‑melon 17:38, 3 March 2009 (UTC)

Indeed... I actually got the links from Allmessages in the first place, but found the wrong "block log" message since both the log page title and the contribs link text were the same at the time! Anyway, the new links look good imo. haz (talk) 19:51, 3 March 2009 (UTC)

Hold on... doesn't the casing rely on which skin is being used? Monobook already automatically makes the top links lower case through CSS; don't know about other skins. But if we're going to lower-case all text, I need to edit common.js as well to correct the 'main page' link. — Edokter • Talk • 02:02, 5 March 2009 (UTC)

Never mind... These are user links. — Edokter • Talk • 02:12, 5 March 2009 (UTC)

First the "cite book" thing, then this.

Go to Wikipedia:Reference desk/Archives/Humanities/January 2009 and look under January 14. All the items for the same day are supposed to be links to different points within that page, so the fact that one of them is broken is not critical, but it still should be fixed. --208.76.104.133 (talk) 00:14, 3 March 2009 (UTC)

Link corrected and notified the author of the Bot that is assembling this page, of the error. --TheDJ (talk • contribs) 00:28, 3 March 2009 (UTC)
It's a known bug, which I (the maintainer of that bot) have been dragging my feet on fixing, based on the following lame excuse.
Before this bot took over, those items were not links to different points within that page. (See, for example, the older Wikipedia:Reference desk/Archives/Humanities/January 2007.) Making them all "hot" was an idea I had for an improvement, which ended up being easy for the bot to do. (Or, seemed to be easy -- but it was easy because it was incomplete.) But, figuring that having 99% of the links "hot" was better than nothing, fixing the bug that causes the remaining 1% to be broken has (alas) never been at the top of my priority list... —Steve Summit (talk) 01:19, 3 March 2009 (UTC)
Prodded by this exchange, I spent some time addressing the bug. I think it's mostly fixed. If people notice broken links like this in future, feel free to let me know. (There's lots of ways they can be broken, and I suspect there are probably a few more lurking around that I still haven't fixed.) —Steve Summit (talk) 02:14, 5 March 2009 (UTC)

Intitle search with the API

Resolved
 – ukexpat (talk) 20:07, 3 March 2009 (UTC)

I can do an intitle search for articles with "Smith" in the title by typing "intitle:smith" in the search box. The direct link is a bit long: http://en.wikipedia.org/w/index.php?title=Special:Search&search=intitle:smith&ns0=1&ns4=1&ns10=1&ns14=1&=MediaWiki+search&fulltext=Search

I'm trying to use the API to do this, but I can't figure out how to get it to work. The Opensearch option would indicate I should use this: http://en.wikipedia.org/w/api.php?action=opensearch&search=intitle:smith

But it returns no records. Is there a way to use the API to do an intitle search? Thanks, – Quadell (talk) 00:29, 3 March 2009 (UTC)

Opensearch is a different critter. You probably want list=search, eg: list=search&srsearch=Smith. Note that there is srwhat=title but it is disabled (which might be a permanent configuration setting, or might temporarily be a result of replication lag). --Splarka (rant) 08:38, 3 March 2009 (UTC)
Gah, how'd I miss that? Thanks so much! Works like a charm. – Quadell (talk) 11:53, 3 March 2009 (UTC)
Roan also pointed out, the srsearch= parameter also just passes on arbitrary terms to the search backend, so anything that works in the search box at the side should work there too, including intitle:. --Splarka (rant) 08:14, 4 March 2009 (UTC)

Toolserver namespace counts not working

I just checked my edit contributions on tool server and under "Namespace counts" I am getting "ERROR: No result returned." What's up with that? kilbad (talk) 20:44, 3 March 2009 (UTC)

Which of the edit counters on the toolserver are you using? Algebraist 11:28, 4 March 2009 (UTC)
Please check http://status.toolserver.org before asking here. --Dschwen 17:12, 4 March 2009 (UTC)

2 things

1st my "you have new messages" bar seems to be popping up on any page I go to (even my talk page) and when I click either option it takes me [[19]].... Iv'e cleared all caches and the such like but its still there.


2nd the user bar at the top of the pages I see ocasionaly floats around whenever I try to click on it (ie it floats away from the cursor).... not sure why its doing that.  rdunnPLIB  12:06, 4 March 2009 (UTC)

Wow, same problem as me, and right above my post. Not sure how I missed this. I did the "purge" thing, and still no luck. Crotchety Old Man (talk) 13:51, 4 March 2009 (UTC)

Talk page "new message" notification

Anyone else having trouble with this? I keep getting the orange "new message" notification, when I don't have new messages. FWIW, I've had this problem happen today on two separate computers, which are on completely different networks, which leads me to believe it's on Wikipedia's end. Crotchety Old Man (talk) 13:36, 4 March 2009 (UTC)

Did you try to purge the Wikipedia cache? I have a lot of pages coming in outdated versions today so that might be connected. SoWhy 13:39, 4 March 2009 (UTC)
Purge the cached version of what page? Algebraist 13:41, 4 March 2009 (UTC)
Same happening here, The "You have new messages (last change)" notification has been popping up all day but no messages / changes. Have purged server cache, bypassed FireFoxes's cache and deleted temp files but to no avail, most strange... Badgernet  ₪  14:33, 4 March 2009 (UTC)
I got around six new messages message today, none of which were true.--Megaman en m (talk) 14:50, 4 March 2009 (UTC)

Talk pages: the repeating table of contents (TOC) problem

Can anyone help with a talk page-related bug? At the moment multiple, repeating tables of contents (TOCs) are generated either on the talk page itself or in banner windows displaying assessment comments. Here are some examples:

Hopefully this will encourage solutions, and not a round of techy recriminations, declarations of innocence etc! Thanks and best to all! --Kleinzach 00:41, 27 February 2009 (UTC)

Moving the content in the subpage to the talk page? Martinmsgj 12:30, 27 February 2009 (UTC)
This is just the TOC-creating software doing its job. It creates a TOC listing all the section headers present on the page, and places this table immediately before the first header (or, as in Talk:Ludwig van Beethoven, places it where instructed to do so by __TOC__). No-one told the software that some of these headers were hidden with javascript, or that the same sections would be transcluded onto the page two or three times by banner templates. I agree with Martin: the solution is to put comments on the talk page, instead of in transcluded subpages. Algebraist 13:26, 27 February 2009 (UTC)
Unfortunately that's exactly what we don't want to do. We need to have the (actually misnamed) 'Comments' (really assessments) accessible from the banners (which display the assessments). If we can't use subpages then the material will just be buried with other talk page discussions. (I may be missing something here, but I can't believe the TOC-creating software is supposed to merge the TOCs of different pages.) --Kleinzach 01:08, 2 March 2009 (UTC)
Remove the headings (== or <h#> style) from the /Comments subpage; you can emulate them with appropriate inline styles on a <div> if you really want. The problem is that multiple WikiProject banners on those pages transclude the /Comments subpage, so MediaWiki (correctly) includes them in the TOC multiple times. Anomie⚔ 13:33, 27 February 2009 (UTC)
Thanks. We'll look at that as a potential solution. Much appreciated. --Kleinzach 01:09, 2 March 2009 (UTC)

To my surprise there seems to have been a WP-wide change to the way TOCs appear on talk pages. Is this a coincidence? It seems TOCs only appear now if they are called up. Does anyone know what is happening with this? --Kleinzach 08:38, 4 March 2009 (UTC)

I don't see any such change. TOCs are only automatically displayed when there's a minimum number of headers present on a page (I think it's 4 or 5). Otherwise you need to explicitly call it. It's always worked that way. Could you simply be looking at pages with too few headings? Equazcion •✗/C • 08:44, 4 Mar 2009 (UTC)
No, I don't think so. Look for example at Talk:George Frideric Handel. This has 16 topics and no TOC. --Kleinzach 15:01, 4 March 2009 (UTC)
The TOC is there, it's just hidden inside the WikiProject Opera banner's "Comments" section. This happened because the /Comments subpage contains section headers, and MediaWiki puts the TOC just before the first section header on the page; replace them with non-header markup, possibly purge the talk page, and your problem should be fixed. Anomie⚔ 18:09, 4 March 2009 (UTC)
I'm baffled. The Talk:George Frideric Handel TOC is now displaying correctly on the talk page — without the 'Comments' subpage TOC! That's exactly what we want, but is it just a transitory phenomenon? Not only that, but the Comments are displaying properly within the banner boxes. I may be an atheist, but if someone can show me the way to the shrine of our patron saint, I will go and offer my respectful thanks! --Kleinzach 01:30, 5 March 2009 (UTC)
Equazcion has carried out Anomie's suggestion above. Algebraist 01:35, 5 March 2009 (UTC)
Was this [20] the change? A change in the banner? I thought Anomie was talking about emulating with inline styles on a <div>. No? --Kleinzach 09:33, 5 March 2009 (UTC)
No, this was it. Equazcion •✗/C • 10:10, 5 Mar 2009 (UTC)
Ah, thanks. I'll make a note of that. We've got a few hundred of them but we'll look at a way of converting them. --Kleinzach 11:30, 5 March 2009 (UTC)

How to test templates by supplying test argument values on the template page?

I've created a userbox template that accepts optional arguments. However, I can find no way of testing it without involving a second page to invoke the template and supply argument values. Is there a way to test this on the template page itself by introducing some temporary test code and using the Show preview button? Thanks. Jim Ward (talk) 23:39, 3 March 2009 (UTC)

You could call the template from itself, surrounded by &lt;noinclude&gt; tags. Gary King (talk) 23:48, 3 March 2009 (UTC)
Gary, I haven't tried that, but I did think about it. Wouldn't that have the effect of invoking the saved version of the template, rather than the one I'm presently editing and attempting to test using Show preview? Thanks, Jim Ward (talk) 23:55, 3 March 2009 (UTC)
if you've made a documentation page using the {{documentation}} template, you can include a version of the template on the document subpage. sometimes a good idea regardless (so people can see it in action) but certainly useful for testing. --Ludwigs2 00:02, 4 March 2009 (UTC)
p.s. to your other question, you can fix that problem with a null edit. just edit the page, then hit the save button without making any changes. --Ludwigs2 00:04, 4 March 2009 (UTC)
I think I get what you're saying. You want to be able to test your edits to the template, with arguments, using only "show preview", rather than having to save each time. I really don't think there's any way to do that. When I'm writing a template I usually test arguments by saving edits, then trying the arguments on a separate page. It's a minor inconvenience. But then, that's why we get the big bucks. Equazcion •✗/C • 00:12, 4 Mar 2009 (UTC)
You can't do that directly— only the saved version can be transcluded. A testcases subpage can be created for testing. --—— Gadget850 (Ed) talk - 00:40, 4 March 2009 (UTC)

You can define fallbacks for them, temporarily, like {{{1|TEMPORARY VALUE}}}}. You can also change {{{1}}}} to <noinclude>default</noinclude><includeonly>{{{1}}}</includeonly> temporarily. Then they work testingly in preview (generally). --Splarka (rant) 08:20, 4 March 2009 (UTC)

Easiest alternative:
Secondarily,
Insert dummy values (fallback values per Splarka's suggestion sans html nesting) to test logic.
For example to check the output stream built if {{{1|}}} is a particular value in an if statement:
...#if:|then|else...— hand override the null value of {{{1|}}} by giving it the value you want to test:
"{{{1|value}}}"
  • Same technique works with ifeq, switch etc. parser functions...


Hope that helps // FrankB 18:07, 5 March 2009 (UTC)

This helps; thanks to all who replied. I've settled with using test values for defaults, which is imperfect but practical. Jim Ward (talk) 21:27, 5 March 2009 (UTC)

Say When!! (game show)

I would like to move Say When!! (game show) to Say When!!. However, when I try, it tells me that the title "Say When!!" is protected from creation, when there is absolutely nothing showing in the log for that title. What the heck is up? Ten Pound Hammer and his otters • (Broken clamshells • Otter chirps • HELP) 20:14, 4 March 2009 (UTC)

I ran into that problem before and it turned out to be the title blacklist. — jwillbur 20:41, 4 March 2009 (UTC)
Looks like the "EXCESSIVE PUNCTUATION OR REPETITION" section is hitting ya here. --brion (talk) 18:06, 5 March 2009 (UTC)

major weakness in your search engine.

when i type 'miami vice film' i should get the same result or results as when i type 'miami vice (film)'. 71.102.2.128 (talk) 07:29, 5 March 2009 (UTC)

The Search engine results are the same; you're just hitting the "Go" button, which takes you directly to the named article. In this case, the former does not exist, even as a redirect. The "Go" button is only as useful as the redirects and phrasing used by the querent. -Jeremy (v^_^v Cardmaker) 07:45, 5 March 2009 (UTC)
If you press Enter on your keyboard after writing in the search field then the Go button is activated. PrimeHunter (talk) 13:41, 5 March 2009 (UTC)

Media

Why do media files on Wkipedia use .ogg which seems not to be a common sound file thingy? How about using .wav? Simply south (talk) 18:33, 5 March 2009 (UTC)

.Ogg is free format, .wav is developed by MS and is also limited to audio whereas ogg isn't necessarily. -- Mentifisto 19:00, 5 March 2009 (UTC)
.ogg is also compressed and thus smaller for the same audio quality. Surprised the OP didn't ask about Mp3 though... ♫ Melodia Chaconne ♫ (talk) 20:03, 5 March 2009 (UTC)

How to add B-class assessment details to a WikiProject template?

I'd like to update Template:WikiProject Poland to be similar to Template:WikiProject Germany - with B-class expandable menu for in-template review (seen at "Additional information:" expandable box in the German template). How can I do it? Perhaps somebody who knows could do it as a request for me (and WPPoland)? --Piotr Konieczny aka Prokonsul Piotrus| talk 20:21, 5 March 2009 (UTC)

 Done [21] It's really very straightfoward with WPBannerMeta. Happy‑melon 22:47, 5 March 2009 (UTC)
Thanks! --Piotr Konieczny aka Prokonsul Piotrus| talk 23:59, 5 March 2009 (UTC)

Large article won't load

I noticed that I am unable to load List of Liberty ships: G-L. The article is apparently a single enormous table populated by templates. I'm not sure what the exact cause is, since apparently the article has not been edited in some time. Unfortunately I don't have time to debug it. But the issue may be Template:dts, which seems somewhat painful. Or it could just be the length of the article. The best thing would probably be to split the article and its sisters into smaller chunks. — Carl (CBM · talk) 02:35, 4 March 2009 (UTC)

It took 120 seconds to load for me, all of that spent waiting for the Wikimedia server to do something. The relevant sections of the page seem to be
<!-- 
NewPP limit report
Preprocessor node count: 558195/1000000
Post-expand include size: 915549/2048000 bytes
Template argument size: 234719/2048000 bytes
Expensive parser function count: 0/500
-->

<!-- Saved in parser cache with key enwiki:pcache:idhash:3629748-0!5!0!default!1!en!3 and timestamp 20090304025855 -->

<!-- Served by srv202 in 0.097 secs. -->
--Carnildo (talk) 03:04, 4 March 2009 (UTC)
As a temporary slapdash solution I split the article into 2 parts. They seem to load in a reasonable time for me. Equazcion •✗/C • 03:10, 4 Mar 2009 (UTC)
  • The parameters (NewPP limit report) aren't really all that large... I've seen much larger, so suspect the real demon is class="wikitable sortable"... which nicety, the user pays for, whether needed or desirable or not. // FrankB 18:16, 5 March 2009 (UTC)
The classes "wikitable sortable" only affect the CSS and JS, and are completely clientside and the symptoms would be completely different. This is a failure of the server-side parsing/rendering of the page. --Splarka (rant) 08:43, 6 March 2009 (UTC)
I would definitely hazard that it's Dts which is causing the issue (either Dts or class=sortable; one of the two). One of the bugs of templating is that using a template x within a template y within a page z doubles the how much the page transcludes of template x. It becomes especially painful with parserfunctions to boot... There's just too many templates on the pages, I would say. I drastically reduced both post-expand and template argu by substing out {{SS}} from the G-Je list. It saw a benefit of 25kb change in post-expand include size and a 7kb change in template argument size. And that was just SS, which isn't the complex template that dts is. --Izno (talk) 20:23, 5 March 2009 (UTC)

Wikipediaholism Test

Every time I go to the automated version of the test it logs me out. Abce2 (talk) 02:56, 4 March 2009 (UTC)Abce2

The page looks like it's at Wikipedia, but in fact (if you look at the address bar, where the url is) what is being displayed is via the toolserver: http://toolserver.org/~merphant/cgi-bin/wikiholic.cgi So yes, the screen doesn't show (upper right corner) that you're logged in, except for unusual cases where you have a toolserver account. -- John Broughton (♫♫) 02:06, 7 March 2009 (UTC)

Lots of outdated revisions shown today?

Is it just me or does the software output a lot of outdated revisions today? I was going through C:SD and I got pages where the tagged version did not show, recreations where it shows "create this page", revisions histories where the last edit is missing. Even on my watchlist it does not show pages I just moved as blue links. I have to purge every page all the time. Am I the only one experiencing this? SoWhy 13:43, 4 March 2009 (UTC)

Yup, see the same issues. Likely related to the few reports above. I dropped a line in the IRC room and am waiting for a dev to bite, but it seems none of the sysadmins are present atm. --TheDJ (talk • contribs) 13:58, 4 March 2009 (UTC)
Ditto. For some reason it's decided to give me pages as if we were back in mid-february... yandman 14:40, 4 March 2009 (UTC)
The problem is being dealt with now. Should disappear after a while if it has not already. --TheDJ (talk • contribs) 15:02, 4 March 2009 (UTC)
Yes same thing happening. Happened before and I deleted my internet temp files causing it to purge and load the correct page but this time that solution is no good. Anyone got any IE8 related solutions ? ~ R.T.G 11:35, 6 March 2009 (UTC)

Help with template please

Resolved

Hi, I don't want to muck up a template so am asking for wikignome on a tech level. On {{rescue}} we have a feature - adding page=____ - so that we can aim to the correct AFD (articles for deletion) discussion when it's the secord or third AfD. We'd like to be able to have an XfD so we can also aim to other deletion discussions including deletion review, categories, etc. Something like Xfd page=_____. Anyone up for the challenge? It may be dead easy but I certainly haven't figured it out. -- Banjeboi 21:50, 4 March 2009 (UTC)

I would be happy to help, if I knew what you were asking. I will post on Template talk:Rescue and maybe you can clarify. Martinmsgj 23:05, 4 March 2009 (UTC)
  • Looking at the current template code, I think he means that currently the template has the AfD path hard-coded, so the template can't be used on any page type other than articles. He'd like the template to automatically point to a page's deletion discussion no matter what type of page it's placed on. In addition he also wants a DRV link to be automatically shown if the deletion was taken there.
  • The first part could be achieved using ifs or a case statement, to change the address of the deletion discussion link according the the namespace of the page. I'm not sure how much use the rescue template is on anything but article pages though. Projects and templates are either a good idea or they're not, and there isn't much chance or motivation to "save" them by altering their content.
  • The DRV part would be tricky and possibly not feasible, since DRVs are grouped on a dated page, rather than each having their own page. Testing for the existence of a section on a page isn't something that can be done currently with wiki code, as far as I know. Equazcion •✗/C • 23:15, 4 Mar 2009 (UTC)
I think this is resolved now - big props to Msgj! -- Banjeboi 14:53, 6 March 2009 (UTC)

Backup Policies?

I was wondering what Wikipedia's policies on backing up its data are. Are you using continuous data protection, nightly backups or something else? 173.95.137.49 (talk) 22:58, 4 March 2009 (UTC)

The server structure is here and shows at least 8 slave database servers (named here). I assume the storage for those use some reliable replication scheme. The last major loss of data was many years ago. —EncMstr (talk) 23:09, 4 March 2009 (UTC)
For accurate information, i would contact the wikitech mailinglist. The developers and sysadmins should be reading that and might be able to give the most accurate information. --TheDJ (talk • contribs) 23:15, 4 March 2009 (UTC)

Indeed. The Wikimedia databases are duplicated in real-time between a master and eight slaves; there is also usually replication with a few minutes' delay to the slave databases of the Wikimedia Toolserver. Cached raw wikitext is stored on 147 separate Apache servers, and rendered HTML, from which the raw wikitext could ultimately be reconstructed, is further duplicated on 52 SQUID servers located in four server farms on three different continents. The Wikimedia databases are also periodically dumped and are available for download from an entirely separate server; although the en.wiki database has not been successfully dumped for months, in general this database backup is at maximum three or four weeks old. And finally, of course, our content could in the worst case be recovered from the hundreds of legal and illegal mirrors and forks that exist on innumerable datacentres in probably every country of the world, not to mention the offline copies on people's personal computers, company servers, and even CD and hardcopy. I think it's no exaggeration to say that if human civilisation were to completely collapse, Wikipedia's content would be one of the last things to go. Happy‑melon 23:26, 4 March 2009 (UTC)

Think you mean one of the last electronic things to go. :)
Without electrical power, there will be no computing. --BrownHairedGirl (talk) • (contribs) 01:57, 5 March 2009 (UTC)
damn. I suddenly feel like I've been assimilated. Wikisitance is futile! --Ludwigs2 02:04, 5 March 2009 (UTC)
Maybe in the next remake of Planet of the Apes, our hero should unearth the last, barely functioning, PC, still logged on to the Main Page served up by the last surviving Wikipedia server... – ukexpat (talk) 20:39, 5 March 2009 (UTC)
Which, I rather suspect will be rather familiar... Happy‑melon 22:43, 6 March 2009 (UTC)

Category containing members of other categories

Resolved
 – SyG (talk) 07:48, 6 March 2009 (UTC)

Hello ! I have created the Category:Quality chess articles, and now I would like it to contain the members of the categories Category:FA-Class chess articles, Category:A-Class chess articles and Category:GA-Class chess articles. At first I thought I would rewrite entirely the Template:WPBannerMeta, but maybe there is a better way :-) Any idea ? SyG (talk) 19:34, 27 February 2009 (UTC)

Why don't you just put those categories in the new category? That doesn't make the individual entries appear there, just the subcategories. But it's still a logical hierarchy. —EncMstr (talk) 19:42, 27 February 2009 (UTC)
As you state, this would add the categories to my category, not their members. No big deal for a hierarchy, but problematic when I want to use automated things like User:LivingBot/ProjectSignup that rely on the number of articles in the category. SyG (talk) 19:56, 27 February 2009 (UTC)
You can add custom functionality to Template:Chess-WikiProject - see Template:WPBannerMeta/hooks. --- RockMFR 19:49, 27 February 2009 (UTC)
Indeed the Template:WPBannerMeta/hooks/cats would seem very promising, but I have no knowledge in programming, I have tried a few times in my sandbox but I am unable to make it work :-( SyG (talk) 20:17, 27 February 2009 (UTC)

← My problem hereabove has not been solved and I have not found a roundabout, so please forgive me if I post it again. Any idea how to create a category containing the members of subcategories ? SyG (talk) 08:18, 5 March 2009 (UTC)

I've implemented a solution by editing Template:Chess-WikiProject. I think there's a time delay on including articles into categories, but Category:Quality chess articles should be full in a while. NB: The category will be full of the article talk pages rather than the articles themselves. — Blue-Haired Lawyer 11:53, 5 March 2009 (UTC)
Give it a week. — Blue-Haired Lawyer 12:01, 5 March 2009 (UTC)
That seems to work great, many thanks to you, Happy-melon and WOSlinker ! SyG (talk) 07:47, 6 March 2009 (UTC)

Articles created

What happened to the articles created page at the bottom of my user contributions page? I am also getting a "page not found (404)" message when I click on my edit and action count (or any other editor's). Is there another way to see the articles I have created? Copana2002 (talk) 22:41, 5 March 2009 (UTC)

A number of toolserver tools have been temporarily disabled due to "abuse". Hopefully they'll be back soon. Happy‑melon 22:50, 5 March 2009 (UTC)
Oh, that's too bad. I use those tools constantly. Thanks for the information. Copana2002 (talk) 22:53, 5 March 2009 (UTC)
You can get a list of articles you have created with this tool. It has a few quirks though: it's partially in French, it can be slow because it doesn't use the toolserver to get a user's contributions, it lists articles where your first edit was a redirect, and it requires you to capitalise the first letter of your username. Graham87 08:40, 6 March 2009 (UTC)
Or you can use this tool that has some more features (still somewhat slow though).--Saddhiyama (talk) 21:36, 6 March 2009 (UTC)

Imasge problem

Resolved
 – ukexpat (talk) 18:08, 6 March 2009 (UTC)

In the article Radio Free Europe/Radio Liberty, in the image in the infobox, the legends "200 pix" etc. are coming up neven though I can't find them anywhere in the code! Anybody have a solution to this? Herostratus (talk) 16:59, 6 March 2009 (UTC)

The 'image' and 'map' parameters of {{Infobox Organization}} should be just the names of the image, without brackets or the Image: prefix. Fixed. Algebraist 17:03, 6 March 2009 (UTC)
Thank you! Herostratus (talk) 17:05, 6 March 2009 (UTC)

template for needs pronunciation?

Is there a template that can be added that marks a word as needing pronunciation added and puts the article in a category of articles needing pronunciation? RJFJR (talk) 17:20, 6 March 2009 (UTC)

{{Pronunciation needed}} adds to Category:Wikipedia articles with nonstandard pronunciation but is not the only template doing that. You can also track the use with Special:WhatLinksHere/Template:Pronunciation needed. PrimeHunter (talk) 18:05, 6 March 2009 (UTC)

help: spacing in infobox

Hello, thank you for the help, I have one more issue to address. In the infobox of the article that I am editing Radio Free Europe/Radio Liberty the official languages links are spaced out in a strange way, there are large spaces between the first line and the second line and between the last two lines. Please help with this formatting adjustment. —Preceding unsigned comment added by Jkos2010 (talk • contribs) 17:31, 6 March 2009 (UTC)

I think the main problem is all those external URLs in the infobox, they should be removed and the languages left as bare text. – ukexpat (talk) 17:49, 6 March 2009 (UTC)

Site slow-down

Is anyone else having slow-down issues with the site? It seems to be OK for a few minutes, then painfully slow to load even a small article. Other non-WP sites seems fine for me. Lugnuts (talk) 19:56, 3 March 2009 (UTC)

I've been seeing that for a long time now. It somethings takes minutes just to save an edit and that can be quiet frustrating (especially if it results in an edit conflict). Eeekster (talk) 03:07, 8 March 2009 (UTC)
Me too, and I have high speed for everything else. I have been wondering why this site is so slow. —Mattisse (Talk) 03:19, 8 March 2009 (UTC)

Spaces around unnamed parameters

A template I am developing needs to be able to take a large number of unnamed parameters, but unfortunately it seems that they get expanded differently to named parameters.

Help:Template#Template_usage says that "Whitespace characters (spaces, tabs, returns) are stripped from the beginnings and ends of parameter values, but not from the middle" .... but unfortunately this seems to apply only to named parameters. Unnamed parameters are expanded with leading and trailing whitespace intact. This breaks the calls I want to make to other templates, of the form {{{{{1}}}/meta/color}}

To demonstrate this, I created two test templates: User:BrownHairedGirl/param_test1 and User:BrownHairedGirl/param_test2. Both take three parameters, and both expand them one per line surrounded by % signs. However param_test2 takes named parameters but param_test2 takes unnamed. That's the only difference between them. So:

To my mind, this is a bug. However I can't find it listed on bugzilla. Does anyone else agree that it is a bug?

The only workaround that I can find is to enter the parameters without any whitespace around them, e.g.

This is a nuisance, because my usage may require a dozen or more parameters, some of them quite long. If they are all entered without spaces then result is a hideously unreadable long string, like this:

{{User:BrownHairedGirl/param_test1 |salmon|haddock|halibut|perch|herring|mackerel|tuna|red mullet|sea bass|trout|sardine|pilchard|pollock|whiting|roach|shark|conger eel}}

Sure, I can put a warning in the documentation, but I'd much prefer that the template could be used in a human-readable way, like this: 

{{User:BrownHairedGirl/param_test1 
 | salmon
 | haddock
 | halibut
 | perch
 | herring
 | mackerel
 | tuna
 | red mullet
 | sea bass
 | trout
 | sardine
 | pilchard
 | pollock
 | whiting
 | roach
 | shark
 | conger eel
}}

--BrownHairedGirl (talk) • (contribs) 01:11, 5 March 2009 (UTC)

I would indeed consider this a bug. For the moment, I've created the hackish {{str_trim}} template which you should be able to wrap around the parameters to remove leading and trailing whitespace. Dragons flight (talk) 01:33, 5 March 2009 (UTC)
sorry about the Help:template page: I'm in the process of revising it to be more readable, but it seems I've missed a few details on the way. I'll make a note of this in a couple of minutes. this is actually a long term (errr...) 'feature' of the software, from what I can gather. I'm not sure what the original justification was, but named parameters trim while unnamed parameters don't. you can use DF's template above, or use one of the parser functions, which mostly strip whitespace (for instance, {{lc:{{{1}}}}} or {{#if:{{{1|}}}|{{{1}}}}} should both return trimmed text, though the first will be lowercased). alternately, you could use explicit positional parameters, like so: {{User:BrownHairedGirl/param_test1 | 1 = salmon | 2 = haddock | 3 = halibut |...}} which works the way named parameters do. there ought to be a 'trim' parser function somewhere; not sure why that wasn't included in the mix. --Ludwigs2 01:47, 5 March 2009 (UTC)

Thanks, folks. The clever {{str_trim}} hack does the job perfectly. It has made some ugly code even uglier (see inside the test template {{Irish TD table begin4}}), but that's a price worth paying. I much prefer complex code that makes an easily-used template than simple code which will infuriate editors who try using it in article, and increase the chance of errors.

Now I've got what I wanted: editors can use the template with a simple syntax, and whatever whitespace they like. Thanks again. --BrownHairedGirl (talk) • (contribs) 02:26, 5 March 2009 (UTC)

you know, looking at your code, you could make this a lot simpler (and a lot prettier). just create a new template called (say) ITDhelper that does use a named parameter like so: <span style="background-color: {{{{{param}}}/meta/color}}"> </span>'''{{{{{param}}}/meta/abbrev}}''' = {{{{{param}}}/meta/shortname}}. then call that from your template. it would look like:
         	{{#if: {{{1|}}} | {{IDThelper | param = {{{1}}} }} }}<!--
         -->{{#if: {{{2|}}} | {{IDThelper | param = {{{2}}} }} }}<!--
         -->{{#if: {{{3|}}} | {{IDThelper | param = {{{3}}} }} }}<!--
         -->{{#if: {{{4|}}} | {{IDThelper | param = {{{4}}} }} }}<!--
         -->
this would have the same effect of trimming whitespace, as well sa making things easier to read. --Ludwigs2 07:10, 5 March 2009 (UTC)
That's a very good idea. I was starting to worry about the illegibility of the template code, and this will help a lot. Thanks! --BrownHairedGirl (talk) • (contribs) 23:24, 7 March 2009 (UTC)

"However I can't find it listed on bugzilla." -> bugzilla:11375, bugzilla:8533? As I recall, this (not a bug or a feature, really, lets call it a "behavor") was specifically preserved and supported in the new preprocessor for historical compatibility. --Splarka (rant) 08:24, 5 March 2009 (UTC)

Well you know I've found a lot of interesting things using the bugzilla search, but never any related to what I was looking for. I can think of some obscure and possibly degenerate cases where keeping the white-space comes in handy. For example one might use a script which adds, based on the article content, certain categories and templates but only if they exist. The goal is to always put each added item on a separate line, and never add blank lines. I've only found one way to make the line-break part of the conditional without having the parser-function strip it away as unwanted white-space: 

{{subst:#ifexist:Category:Foo|{{subst:Show1|[[Category:Foo]]
}}}}{{subst:#ifexist:Category:Bar|{{subst:Show1|[[Category:Bar]]
}}}}{{subst:#ifexist:Template:Foo-bar-stub|{{subst:Show1|{{foo-bar-stub}}
}}}}

This is basically the opposite of the {{str_trim}} hack above. — CharlotteWebb 00:11, 8 March 2009 (UTC)

feature request?

you know, I don't know if this is possible, or if it's already been implemented in a way I don't see, but is there any way to get a link on edit pages that points back to the section that you're editing? I'm trying to find a solution to two minor irritants:

  • opening a section in a separate browser page (to see the current version of the the section, without modifications)
  • dealing with edit conflicts (which currently opens an edit window with the entire contents of the page - worse than useless)

thoughts or ideas? --Ludwigs2 21:34, 5 March 2009 (UTC)

Just hit "Show Preview" before you start editing. That should do it. -- Blanchardb -Me•MyEars•MyMouth- timed 21:38, 5 March 2009 (UTC)
that doesn't help with edit conflicts, or with sections where I've already started editing, does it? well, maybe the first, if I remember to hit it first thing (or set show preview as the default). --Ludwigs2 23:19, 5 March 2009 (UTC)
The present edit conflict situation has been considered a problem for a very long time. See https://bugzilla.wikimedia.org/show_bug.cgi?id=4745, which has been around since, oh, January of '06. Talking about it just pisses me off at this point. Equazcion •✗/C • 03:45, 6 Mar 2009 (UTC)
I understand where you're coming from. Any time a discussion is moving quickly, the conflicts are inevitable. I've gotten in the habit of putting my edit in the paste buffer before saving, every time I edit a talk page.
A link to the section you were just editing would be a truly marvelous feature to have. Is it technically difficult to add this as a feature, I wonder? (Will this edit itself be a conflict? Oh the irony...) Antandrus (talk) 03:49, 6 March 2009 (UTC)
If we're gonna do that we might as well have that happen automatically upon detection of the conflict -- make the edit conflict screen display just that section for editing, rather than the entire page. That's basically what the bug report suggests, and what we've been waiting for. For 3 years. Argh. Equazcion •✗/C • 03:55, 6 Mar 2009 (UTC)
lol - sorry to bring up a sore point. would it help to bug the bugzilla people about it some more? technically speaking, the link shouldn't be a problem. the server already knows what section's being fetched, so it's just a matter of writing the link into the html. I'd even be tempted to take a quick dig through the source code and see if I can figure out the correct change myself and submit it as a request. making the edit window catch the conflict and display the correct section might be more complex, or it might just be a simple change in an SQL request. eh, the more I think about it, the simpler this seems. what's up with that? --Ludwigs2 04:29, 6 March 2009 (UTC)
The problem is that's basically the same argument for fixing the edit conflict window. The software knows which section you're editing, so why not have it just take you back there at the conflict? The problem as I understand it, is that the edit that caused the conflict could have altered the sections of the page, which are actually referenced by number rather than by name, so even an added section above the one being edited would cause the numbers to change and make the whole thing screw up. There are ways to deal with that, but I'm just illustrating why it's a bit more complicated than you might think. You, and everyone interested in getting this dealt with, should vote for the bug via the bugzilla page (requires registration), and if you want to bug the developers about it some more, then sure, leave a comment at that page as well. Show 'em how much we need this. Equazcion •✗/C • 04:38, 6 Mar 2009 (UTC)
PS, I also submitted this bug, which is a request to have conflicts reported on previews. It's a much easier thing to implement and would help a little for the time being. Equazcion •✗/C • 04:57, 6 Mar 2009 (UTC)
interesting. ok, I'll give it a vote and see what happens. --Ludwigs2 05:00, 6 March 2009 (UTC)

Yeah if you have an edit conflict your best bet is to reload the same url and start over. Sometimes this is as easy as doing "copy", "back", "reload", then "paste" in your browser. Unfortunately if you have hit "preview" once or several times before getting the edit conflict, the url in the address bar will no longer indicate which section you are in. This is the locus of the bug. If the section number were still present, any javascript tool could pick up the slack from there. — CharlotteWebb 00:17, 8 March 2009 (UTC)

image question

How do I make the dimensions of an image a percentage instead of a pixel value? LetsdrinkTea 03:13, 6 March 2009 (UTC)

You don't. By specifying a pixel size, you let the Mediawiki do high-quality resizing of the image and serve the smaller result, rather than forcing the browser do a (usually low-quality) resizing after downloading the full-sized image. --Carnildo (talk) 03:36, 6 March 2009 (UTC)
Depending on what you meant: Percentage of the full image size would be easy as specifying "50%" for a 600px image would be the same as specifying "300px". Percentage of font-size or window size or available space be nigh impossible as the server doesn't know these numbers. — CharlotteWebb 00:26, 8 March 2009 (UTC)
And what happens when replaces your 20%-scaled 1000x1000 album cover with a 300x300 album cover? The image in the article goes from a reasonable 200px to a tiny 60px. --Carnildo (talk) 02:02, 8 March 2009 (UTC)
Well the user didn't explain what the percentage would be based on, so I made the ambiguity a bit clearer. I agree that this would probably be more useful on other mediawiki projects where image sizes are less likely to change, or where it is important to keep several irregularly sized images at the same scale (architectural drawing for example). — CharlotteWebb 03:04, 8 March 2009 (UTC)

False Cite error

At the bottom of Residential college it says, "Cite error: <ref> tags exist, but no <references/> tag was found". But it does have a <references/> tag. Nurg (talk) 05:12, 6 March 2009 (UTC)

The problem seems to be the {{cite web}} templates used in the "External links" section. The <references/> tag only works for citations that appear before it. Any that appear after it don't get picked up, so mediawiki sees them as orphaned. External links sections generally use a simple bulleted list of links, rather than appearing as citations, so that would be a good way to fix the problem. Alternatively you could also move those citations into a "notes" section above the "References" section. Equazcion •✗/C • 05:28, 6 Mar 2009 (UTC)
The problem isn't the {{cite web}}s in the ELs section. That template has no connection to the reference-making code. The problem is the ref tags in the ELs section. Algebraist 09:14, 6 March 2009 (UTC)
Thanks. All sorted. Nurg (talk) 10:12, 6 March 2009 (UTC)
See Help:Cite errors for more information. --—— Gadget850 (Ed) talk - 17:17, 6 March 2009 (UTC)
This come up a lot. Would it be possible to include a link to Help:Cite errors in the error message? — Blue-Haired Lawyer 11:30, 7 March 2009 (UTC)
Links do not work in this particular message; see Help:Cite errors#Links. --—— Gadget850 (Ed) talk - 11:49, 7 March 2009 (UTC)

OGGHandler

Did this change recently? Can't seem to get the Cortado player to work anymore. I hit play, and then get nothing but the more link to change the player, no applet. Java is working in FF, but just not here.

Java: 1.6.0_12
Firefox 3.0.7

Q T C 08:52, 7 March 2009 (UTC)

I just tried creating a new profile in Firefox to see if that would help but no-go. Q T C 09:13, 7 March 2009 (UTC)

Another, hopefully easy - template fix

Resolved

{{ARS/Tagged}} provides a list of articles from a category. The default is expanded with a click to hide feature. I'd like to have a parameter added so the default could be also set to the compacted version and one would have to click to expand. I think this should be easy but I have been ever so wrong before. Any takers? -- Banjeboi 16:48, 7 March 2009 (UTC)

I've done this for you, basically you change it to use the class "wikitable collapsible collapsed" as shown at Help:Collapsing. Nanonic (talk) 17:10, 7 March 2009 (UTC)
Alternatively, to collapse the category tree, add depth=0 (see mw:Extension:CategoryTree). Hope that helps, mattbr 17:15, 7 March 2009 (UTC)
Genius - best village pump board - ever! -- Banjeboi 17:31, 7 March 2009 (UTC)

technical template question

I've been revising help:template recently to de-jargon it (comments welcome, by the way) but I've run across a technical question that I don't know the answer to. if someone could clarify it for me, that would be nice. what I want to know is the distinction between the following three things:

  • a normal template, created in template space:
    • e.g. Template:Templatename, referenced by {{templatename}}
  • a template created in a different namespace (using a colon at the start of the name to signify it's a template):
    • e.g. User:Sombody/:templatename, referenced by {{user:sombody/:templatename}}
  • a transcluded document that's not explicitly a template
    • e.g. User:Sombody/Pagename, referenced by {{user:sombody/Pagename}}

In particular, what is the difference between the last two? is the preceding colon simply a convention, or is there something particular about a template that distinguishes it from other types of transclusions? --Ludwigs2 22:34, 6 March 2009 (UTC)

There is no difference, and indeed the leading colon is no convention that I've ever seen. The leading colon is most commonly used when a mainspace article is to be transcluded: {{:Foo}} will transclude the article foo. Happy‑melon 22:41, 6 March 2009 (UTC)
ah, ok. I went back and reread the original version of the help page, which says to use a colon before the name if you want to create a template in the main namespace, not generically in any other namespace (which makes sense; I just misread it). thanks for clarifying. --Ludwigs2 22:58, 6 March 2009 (UTC)
To restate what Happy-melon said, a template is simply a page that is intended never to stand on its own, but rather always to be transcluded into another page. Almost all of these pages are collected in the template namespace, among other reasons because the MediaWiki software understands that when no namespace is specified to the immediate right of the leading two curly brackets, then it should look in templatespace. (Note that the software will first look in mainspace, because sometimes what is desired is simple transclusion of all or part of one article into another; thus templates need to be named in such a way as to not collide with the names of mainspace articles.) -- John Broughton (♫♫) 00:57, 7 March 2009 (UTC)
You're wrong about that last part. For example, typing {{fact}} doesn't transclude fact. Anomie⚔ 01:39, 7 March 2009 (UTC)
yeah, that's what I just learned. to transclude the 'fact' article you have to use {{:fact}} --Ludwigs2 02:11, 7 March 2009 (UTC)
Interesting; I'd remembered not using a colon back in 2006, but I just found my edit, and in fact when transcluding from mainspace, I did in fact use a colon. Thanks for clearing this up. -- John Broughton (♫♫) 19:41, 7 March 2009 (UTC)
You remembered doing something in 2006?? I can only remember the vaguest details of what I was doing back then (mainly embarassing myself in AfDs on fictional topics, IIRC :D). Happy‑melon 17:41, 8 March 2009 (UTC)

Double redirects

Are double redirects now properly working? Do we have a system for marking deliberate double redirects so they are not "fixed" by a bot? (I know category redirects are starting to work as well, but we've discussed that at WP:CAT. What happens when you get a double category redirect I don't like to think about...)--Kotniski (talk) 11:27, 7 March 2009 (UTC)

They "work" now because of a bug; the problem was fixed in r47512, and once brion scaps (at this moment, we're at r47457) redirect behavior will go back to normal. If you want double redirects to keep working, post at WP:VPR to try to get consensus for raising $wgMaxRedirects setting from its default 1. Anomie⚔ 12:51, 7 March 2009 (UTC)
OK, thanks, I'll try. --Kotniski (talk) 13:38, 7 March 2009 (UTC)
A !poll is now in motion on this at WP:VPR#Double redirects. Doesn't seem to be any controversy so far, but please come and add your views to the list so that the devs can see what the consensus is.--Kotniski (talk) 12:24, 8 March 2009 (UTC)

Edit and action count

There used to be a couple of links at the bottom of my contribs page called "edit and action count" and "edit summary". I found the "edit and action count" quite informative, but now it seems to have been removed and a new page added which is just called "edit count" and which seems to be the same or a very similar page to the one found under "edit summary". Is this some sort of glitch or has the "edit and action count" page been deliberately removed? Gatoclass (talk) 07:17, 8 March 2009 (UTC)

Oops, I see the question has already been answered in the section above. Gatoclass (talk) 07:19, 8 March 2009 (UTC)

Large archive page stuck on CAT:CSD

The archive page Wikipedia:Upload log archive/August 2004 (2) has been stuck on CAT:CSD for some time now. I suspect the page is not intended for deletion but is appearing in the category because of the presence of three {{cc-by-nd-nc}} templates in the page itself (which themselves contain {{sd-copyvio}}. It's hard enough to load the page in the first place (it's some 1.3MB long) and it's not possible to edit the page (to protect the templates with {{tl}}, for instance) as the PHP engine complains that its memory allocation limit has been exceeded when the page is saved (sometimes - more often it simply returns an HTTP 500 error (internal server error).

Can someone take a look at what's going on, firstly to see why this page appeared in the CSD category at all after four years, and secondly to get it off there?

Thanks Tonywalton Talk 14:01, 8 March 2009 (UTC)

We could try any of these:
1. Lots of pages link to {{cc-by-nd-nc}} but only one, the above log file, transluses it so we could replace the hard redirect with a soft one. This would work assuming the sever process which fixes categories included in templates, can read Wikipedia:Upload log archive/August 2004 (2), which given its size is no sure thing.
2. Get someone from Wikipedia HQ to split the logs into smaller pages that we could then edit.
3. Delete them. Not much point having log files no one can read. — Blue-Haired Lawyer 14:54, 8 March 2009 (UTC)
The problem with 1) is editing the *!(&( thing at all. It's so big that the Apache server, refuses to handle the HTTP POST request. 2 looks like an option - how would one go about it? As for 3 I'd happily delete it but I'm not sure about the GFDL implications. I suppose if required (and I agree it's unlikely, 4½ years afterwards that the page will ever be required) it could be recreated. Tonywalton Talk 15:11, 8 March 2009 (UTC)
Option 1 would involve editing this page (which is only 28 bytes). As I said it is widely linked to but not transluced. You may wish to ask on the talk page before making any changes! — Blue-Haired Lawyer 15:29, 8 March 2009 (UTC)
It's not transcluded because pages that transclude it get deleted in short order. --Carnildo (talk) 01:11, 9 March 2009 (UTC)
For option 2 you'd need to go to the wikitech mailing list and ask there. — Blue-Haired Lawyer 15:32, 8 March 2009 (UTC)
I split the log in two and added {{tl}} to the templates. It should be ok now. -- User:Docu
Well it crashed every time I tried to edit it! You might want to do this (however you did it) to the other logs which don't display properly. Btw you've managed to change lots of templates to {{tl|tl|random template}}. — Blue-Haired Lawyer 19:01, 8 March 2009 (UTC)
I wasn't going to start digging about in the internals of templates (Tony departs, shivering...) Tonywalton Talk 19:10, 8 March 2009 (UTC)

forbidden page moves

Is there something broken about the page move function? We're getting a lot of people at Wikipedia:Administrators' noticeboard#Legitimate pagemove being blocked by title blacklist who are getting "This page-move has been blocked by the title blacklist" messages in situations that don't seem to call for one. Has some faulty RegEx been added to the file (wherever that file may be)? - Nunh-huh 20:45, 6 March 2009 (UTC)

MediaWiki:Titleblacklist; NawlinWiki (talk · contribs) made a copule of edits to it a short while ago, and I think one of them is responsible. I dropped a note on his talk page, and he's already responded at WP:AN (haven't read it yet, though). 「ダイノガイ千？！」(Dinoguy1000) 20:54, 6 March 2009 (UTC)
NawlinWiki fucked up the title blacklist again. At a rough estimate, 60% of all pagemoves were blocked for a 20-minute period. --Carnildo (talk) 23:09, 6 March 2009 (UTC)
If we used the abuse filter to test this first, such messups would be prevented. עוד מישהו Od Mishehu 10:24, 9 March 2009 (UTC)

Template not appearing in category

Resolved

Why does Template:Irish TD table party key not appear in Category:Ireland constituency article templates, even though the template pade lists that as its only category? --BrownHairedGirl (talk) • (contribs) 08:12, 9 March 2009 (UTC)

It just needed a null edit. Happy‑melon 08:54, 9 March 2009 (UTC)
Thanks. I should have thought of that! --BrownHairedGirl (talk) • (contribs) 08:57, 9 March 2009 (UTC)

Error message

I received the following error message around 2000 UDT while trying to save comments to an article talk page (and while reporting this here):

"A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was: (SQL query hidden) from within function "ExternalStoreDB::store". MySQL returned error "1114: The table 'blobs' is full (10.0.2.161)"."

Has there been a recent update to the software? --Ckatzchatspy 20:28, 9 March 2009 (UTC)

I got the error message too. Not sure about updates, but it was closely followed by a read-only mode for a few minutes, so I am guessing it was a database glitch that required a server synch. – ukexpat (talk) 20:39, 9 March 2009 (UTC)
Some of our text storage databases were misconfigured and hit up against a default size limitation -- this was causing the error messages on save. For the moment we've worked around by storing text to the primary databases while reconfiguring/rebuilding the databases with the bad config. There'll be no lost data, just for some minutes pages couldn't be saved on this wiki. :( Other wikis were not affected. --brion (talk) 20:41, 9 March 2009 (UTC)
For a second there I thought Wikipedia had finally exceeded available server space -:) I'm amazed how these things are solved so quickly. Keep up the good work! — Blue-Haired Lawyer 22:33, 9 March 2009 (UTC)
We've also gotten some reports of some funky broken redirects created during page renaming in this period. Should be fixable; give a shout if problems seem to persist. --brion (talk) 23:31, 9 March 2009 (UTC)

This used to happen every month or so, eons ago in about 2001–2005, when one did not assume that if a person was literate then they'd heard of Wikipedia. But even then there'd be some suitable message telling you the system was down; today the error message did not resemble that until the problem had been there for a while. Michael Hardy (talk) 02:10, 10 March 2009 (UTC)

SVG text problem

The SVG renderer is screwing up the legend of File:Bart-map.svg. --NE2 02:50, 8 March 2009 (UTC)

Works for me. §hepTalk 04:27, 8 March 2009 (UTC)
Under "BART map", you see "station" and "transfer station"? --NE2 06:28, 8 March 2009 (UTC)
I see 'sbbn' and 'bnsesbbn' (with various accents on them) in the map key. Using Chrome & Vista. ManishEarthTalk • Stalk 07:34, 8 March 2009 (UTC)
Doesn't work for me in Firefox 3, IE 7, and Navigator 9, either. Definitely a rendering error. But isn't the SVG renderer part of the browser, and not WP? Maybe its a problem with the image itself or the software used to produce it. ManishEarthTalk • Stalk 07:40, 8 March 2009 (UTC)
No, Mediawiki renders SVG as PNG, since not all browsers support SVG, and those that do may take a long time to render large SVGs like File:CSX Transportation system map.svg. --NE2 08:21, 8 March 2009 (UTC)
Definitely not a rendering error. All of the previous versions of the map work fine. Probably whoever revised it made a mistake or his software bunged it up. ManishEarthTalk • Stalk 07:43, 8 March 2009 (UTC)
I already asked him and he said it has to be a rendering error; it looks fine everywhere but rendered by Mediawiki. --NE2 08:19, 8 March 2009 (UTC)
Mediawiki's SVG render has a long history of buggy behavior rendering text. Dragons flight (talk) 08:24, 9 March 2009 (UTC)
Opera's native SVG renderer does just fine. --Carnildo (talk) 08:00, 8 March 2009 (UTC)
So does Firefox 3. For the record, if you see errors like this, check the file page against the actual image on upload.wikimedia.org - if the bug is only on the (PNG) file page, that means a bug in the Mediawiki renderer. — Gavia immer (talk) 20:50, 10 March 2009 (UTC)

Category:Replaceable non-free use Wikipedia files

The tracker for this at C:SD doesn't seem to be picking up that there is a 4-day backlog. I'm thinking it might have been something to do with the big category rename we had recently. Can someone see if they can figure out what's wrong? Stifle (talk) 09:07, 9 March 2009 (UTC)

Never mind, fixed it myself. Stifle (talk) 09:08, 9 March 2009 (UTC)
Sorry about that one. I probably should have asked for help when I decided I couldn't do it, at the time when I fixed the others. עוד מישהו Od Mishehu 15:25, 10 March 2009 (UTC)

New magic word

The Signpost is reporting about a new magic word, but it doesn't seem to work. When will it be implemented and will I be able to use it in templates or userspace to display who edited a certain article last? =- Mgm|(talk) 10:40, 10 March 2009 (UTC)

The signpost states that it was implemented in r48149. Once brion scaps to that revision or higher, you can use it (see Special:Version#Installed software). Anomie⚔ 11:17, 10 March 2009 (UTC)

Help with Template:Press

Hmmmmmm... when added to a mainspace talk page, I believe the template should read "This article has been mentioned..."

I added the template to a talk page, and it simply (awkwardly) reads "This has been mentioned". Did I do something wrong?--The Fat Man Who Never Came Back (talk) 13:25, 10 March 2009 (UTC)

It is fine grammar. That said, it is more unambiguous to indeed say "This article" or even "<name of article>". I'll tweak accordingly. --Izno (talk) 13:31, 10 March 2009 (UTC)
It was supposed to say 'this article', but someone forgot that the proper name of the main namespace is "", not "Article". Algebraist 13:35, 10 March 2009 (UTC)
That looks much better. Thanks, people!--The Fat Man Who Never Came Back (talk) 13:46, 10 March 2009 (UTC)

I have noticed that there are some namespace redirects that go to other sites, eg. scores: goes to the IMSLP, wikia: goes to Wikia, uncyclopedia: goes to Uncyclopedia, etc. Where can I find a list of these? LetsdrinkTea 00:03, 11 March 2009 (UTC)

With the exception of some shortcuts for foundation projects, they're all at meta:Interwiki map. Algebraist 00:09, 11 March 2009 (UTC)

Google Summer of Code 2009

Just a quick note -- I'm applying Wikimedia for Google Summer of Code again this year. We should know within a week or two if we're in. Those interested in coding, please feel free to poke a bit at the project ideas list on mediawiki.org! --brion (talk) 00:19, 11 March 2009 (UTC)

I'm not up for coding or supervision, but how about adding multiple watchlists to the project ideas? It's on the persistent proposals list at WP:PERSISTENT#Multiple_watchlists.
Alternatively, the similar idea of Wikipedia:Village pump (proposals)#Categorised_watchlist. --BrownHairedGirl (talk) • (contribs) 00:47, 11 March 2009 (UTC)
just add it at mw:Summer of Code 2009. Or, rather, wait for someone else to do it. Calvin 1998 (t·c) 01:39, 11 March 2009 (UTC)

Smaller Wikipedia Logo files

Unresolved
assuming 2000 requests per second for the logo (which seems high), this would save 78KB/sec. i highly doubt this will have any effect at all on our bandwidth cost. if you're looking for something useful to do, there are plenty of open bugs on bugzilla that you could have a look at. BTW, how much bandwidth was wasted with this discussion? kate.

I have managed to compress the current wiki logo by 39 bytes. See the comparison

  • The smaller wikipedia logo.
    The smaller wikipedia logo.
  • The current wikipedia logo.
    The current wikipedia logo.

This should save wikipedia a small amount of bandwidth.(I would appreciate being notified when the logo is updated.) Cheers!Smallman12q (talk) 18:14, 21 February 2009 (UTC)

You managed to reduce its size by 0.24%? Er, that's great... Happy‑melon 21:45, 21 February 2009 (UTC)
without commenting on the phenomenal effect this will having on load times and bandwidth usage, it does seem like the improved image is more clearly defined, sharper lines and whatnot--Jac16888Talk 21:49, 21 February 2009 (UTC)

I have compressed all of them...the user icon by 70%...the overall savings is roughly 2kb.(Not much but its still quite a bit).

Yes it would save bandwidth, but I wonder if it's negligible or not. Visitors to Wikipedia (English one in this case) would have cached the logo unless they're regularly cleared. I'll do a simple maths here: 39 bytes × 193 million page views/day × 0.01% of them loaded the logo = 752700 bytes/day = 735 kB/day = 21.5 MB/month = 262 MB/year
The percentage who load the logo is a rough and conservative estimate, and the 193 million is for January 2009. My bottom line here is, it may not save much bandwidth on a daily basis, but it accumulates in the long run. Thanks for your effort anyway, just curious how would others see this.
Update: After seeing more response, I think it may save a chip of bandwidth after all. Feel free to criticise on my calculations. xP HУтaяtalk2mecontribs 21:58, 21 February 2009 (UTC)
T he difference it makes will accumulate, but will this massively inflate the job queue? The logo is on every page, after all. Dendodge TalkContribs 22:03, 21 February 2009 (UTC)
It may not save much...but it helps. Could an admin update the current images with my compressed ones? That's mainly what I'm looking for.Smallman12q (talk) 22:02, 21 February 2009 (UTC)
I'd rather wait and see some general consensus for this--Jac16888Talk 22:26, 21 February 2009 (UTC)
Not to be rude, but what kind of consensus? The images are the same except smaller. Unless people enjoy having larger copies with the exact same resolution, I don't understand what you mean by consensus? What would be the reason not to change them?Smallman12q (talk) 22:45, 21 February 2009 (UTC)
well for starters, as dendodge says, its possible this will have a huge impact on the job queue, so it might not actually be worth doing in terms of cost vs benefit--Jac16888Talk 22:55, 21 February 2009 (UTC)
I believe that the site logo is loaded only when needed (not pushed to everyone when it's updated), but I'll wait for conformation of that.
In the meantime, I've updated all of the sister project logos on the main page. Thanks, Smallman12q! —David Levy 23:18, 21 February 2009 (UTC)
Thanks! Are you going to upload the rest when you get confirmation?Smallman12q (talk) 23:30, 21 February 2009 (UTC)
I'm unable to update the images used at http://www.wikipedia.org, and I don't know of a way to replace the user icon. I can update the Wikimedia/MediaWiki icons at Commons, but I'll wait for confirmation that this won't cause any problems. —David Levy 23:46, 21 February 2009 (UTC)
For the physical wikipedia.org site, it's likely to be a devolper or founder as they'll need access to the physical wikipedia.org domain. I'll be uploading a few more compressed popular images. I'm just happy to see that someone was willing to help me. Thanks again!Smallman12q (talk) 00:38, 22 February 2009 (UTC)
For the main site, you'll need a meta-sysop. See http://meta.wikimedia.org/wiki/Talk:Www.wikipedia.org_template Smallman12q (talk) 01:38, 22 February 2009 (UTC)
I would also like to thank you for giving me credit. Cheers!Smallman12q (talk) 14:21, 22 February 2009 (UTC)
The icons on the www.wikipedia.org page can be changed by an admin at meta at www.wikipedia.org template. File:Wiki.png will update the logo here; it has no effect on the job queue. The "Powered by MediaWiki" logo, small RSS icon, and user icon can be changed by a developer, a sysadmin would need to change the "A Wikimedia project" icon (I'm not sure where the big RSS icon is actually used). Mr.Z-man 01:53, 22 February 2009 (UTC)
Good to hear it doesn't affect job queue.Smallman12q (talk) 01:56, 22 February 2009 (UTC)
Actually AFAIK updating File:Wiki.png will not update the site logo here; whether the logo is 'coupled' to that file is a config setting that is, I think, disabled here. I could be wrong though; does someone want to check by putting a 1px dot in one of the corners and overwriting Wiki.png with it? Given that the job queue has been overhauled recently and so is now running much more quickly; it shouldn't be an issue, especially with caching. Happy‑melon 11:29, 22 February 2009 (UTC)
I checked the config files before commenting (as well as looking in the page source, which refers to Wiki.png in the en Wikipedia upload directory), as I said, the logo has absolutely nothing to do with the job queue. Its part of the interface, its not a template. Mr.Z-man 03:30, 24 February 2009 (UTC)

I examined the wiki logos closely and the new one shows some pixelation in the globe shading. I'm not sure if it's anything people are gonna really notice but I thought I'd mention it. The old one has a smoother gradient from light to dark, and I think it's because the compression method involved removing more color shades from the palette. Equazcion •✗/C • 01:24, 2 Mar 2009 (UTC)

Just want to add that I think we should be careful about removing shades from the palette in order to reduce image sizes. Even though each time you do it you don't notice much of a difference, after doing it a couple times, image quality is going to suffer noticeably. If we're only talking about saving 300MB a year I really don't think it's worth it. Even a gig a year wouldn't be, in my opinion. Equazcion •✗/C • 02:02, 2 Mar 2009 (UTC)
I see the same issue; it strikes me as dishonest to claim that a lossless compression was done when in fact the compression was not lossless. Anomie⚔ 03:21, 2 March 2009 (UTC)
I see some nasty Dithering with a 5x magnification myself... ew. --Splarka (rant) 09:19, 2 March 2009 (UTC)
That's going to be killing the compression ratio, too. --Carnildo (talk) 09:43, 2 March 2009 (UTC)
You're right...I didn't notice that. I didn't mean to claim it was lossless if it wasn't, I did it manually, so you'll have to forgive me if I didn't see the difference. However, I'm still certain that certain images were compressed losslessly (by reducing the pallette size). I would like to point out that the png compression alone is always lossless. It is the reduction of the pallette size which may introduce these issues.Smallman12q (talk) 20:03, 2 March 2009 (UTC)
When we refer to compression we are generally referring to whatever steps were taken to reduce the image size -- just as you meant it when you said you had "managed to compress the current wiki logo by 39 bytes." Generally whichever compression method the artist chose would have automatically reduced the palette to the lowest size that could adequately support the colors used in the image. As Tim Starling notes below, now that we know you achieved these new sizes by further removing colors manually, ie., a method that could (if not did) result in quality loss, we would need to go examining each image before using them. It's not worth it for a few hundred megs a bandwidth saved per year. I don't mean to sound harsh, I'm sure we all appreciate your effort. Someone really should have inquired much earlier as to the specific methods you were using to get these new sizes. Much of this could have been avoided then. Equazcion •✗/C • 20:32, 2 Mar 2009 (UTC)

I first compressed the images using truly lossless png compression and then proceeded to manuelly compress the color pallettes. (If you would like me to upload only the lossless copy...please let me know). The 39 bytes was achieved using lossless compression, whereas greater compression was achieved through manual color compression(possibly lossy as you pointed out). My main concern, and the reason I created this thread was to point out that the current images used in the acutal wikipedia mediawiki software can and should be optimized. You should compress the images used in wikipedia (especially the ones in the official branch.) Now for a simple display of lossless compression I have compressed the bold button as seen below

  • Original 978B button
    Original 978B button
  • Lossless compression 229B
    Lossless compression 229B

(apologies on using a gallery...but its harder to prove my point otherwise). While the savings may appear nominal at first...there is a lot that can be compressed(and it may in fact add up). A quick look at Commons:Protected_toolbar_buttons shows that virtually none of the images are compressed.

Here it is 10x smaller...and exactly the same image quality. I simply ask that the developers have a look around to see what can be compressed. Or maybe its simply me...and my mind is still stuck in the days of dialup and when every byte literally did count.Smallman12q (talk) 02:02, 3 March 2009 (UTC)

I haven't checked all the images on that page but a few random clicks generally showed sizes below 500 bytes. You're right about that particular image though; There's no reason something so tiny should be 3k. Anything not compressed at all should be replaced with compressed versions, but only losslessly.
I wouldn't bother trying to squish anything down further that's already been compressed. Saving 39 bytes on a 16k image is, as you say, still thinking in terms of dial-up. We waste more bandwidth on this conversation.
The problem now, and I hope you don't take offense, is that I don't really think everyone is gonna trust you to handle this task. I know I personally would want to have your work checked over to make sure the compression was indeed lossless, since you've made that mistake once already. That would be a painstaking process. I think it's simpler to have an editor do it who's done work on the mediawiki images before, or just put this on the developers' task list, etc. Again I appreciate your effort and willingness to help, but the way I see it, there's no pressing need for this to be done now by you. Equazcion •✗/C • 02:37, 3 Mar 2009 (UTC)
I understand your concerns and am not looking to be entrusted with the task. I simply want to bring attention to the problem. And I do agree that the images should indeed be losslessly compressed. There are ~1000 images that need to compressed. And png compression alone is always lossless(the lossy compression was achieved when I tried to modify the color pallete's manually). While I use a modified pngout, there is software such as PNGOUTWin(15 day trial and PNGGuantlet(free) that do the job just as well. I strongly encourage you to try compressing the images using this software and you will see exactly how I achieved these results. Getting this put on the devolpers' task list would indeed solve this concern.Smallman12q (talk) 12:34, 3 March 2009 (UTC)


Other images

I've noticed that most of the images on wikipedia including those in the actual mono book at http://svn.wikimedia.org/svnroot/mediawiki/branches/REL1_13/phase3/skins/monobook/ are uncompressed. I believe that compressing the top 500 images would help reduce bandwidth noticeably. I'm not quite sure where to start garnering support for a policy change, but I'm quite sure that the current state is simply unproductive is costing needless bandwidth and is a greater hassle for the greater wikipedia community.Smallman12q (talk) 02:48, 22 February 2009 (UTC)

You might also want to add the steps you took to achieve the additional file size reduction in the image descriptions so that future editors can reproduce these effects. SharkD (talk) 04:39, 22 February 2009 (UTC)
Also, don't forget to crush the favicon. SharkD (talk) 04:41, 22 February 2009 (UTC)
Well the source image for the main page is derived as following:
<a accesskey="z" title="Visit the main page [alt-shift-z]" href="/wikipedia/en/wiki/Main_Page" style="background-image: url(http://upload.wikimedia.org/wikipedia/en/b/bc/Wiki.png);"/>

so I believe they are the same. Still, the wiki.png has not yet been updated. I also would like to comment that put a dot on the wiki logo would not be the appropriate method of determining whether it is indeed the logo.Smallman12q (talk) 14:21, 22 February 2009 (UTC)

With regards to the image compression, I'm using a pngcrush I modified...however, I have seen that pngoutwin and pngguantlet have similar compression ratios. I would propose that the Wikimedia Foundation compress the images in the mediawiki software prior to distribution or at least optimize the image. Beyond that, for Wikipedia, a bot can be written to compress the "heaviest" (the ones that use the most bandwidth) images. I would like to note that png compression is very intensive and requires quite a bit of processing time. Still, I'm quite sure that there will be a noticeable savings in terms of both page loading times and bandwidth usage. Smallman12q (talk) 14:21, 22 February 2009 (UTC)
The image thumbnails for the Main page should also be compressed especially "Picture of the day".Smallman12q (talk) 14:56, 22 February 2009 (UTC)
I have compressed all of the wikipedia barnstars...and it comes out to roughly 50% of their current total size. I don't have the rights to upload them to the commons, and its probably not worth the hassle of posting them here and then having an admin repost them to the commons. But it does show that a number of userpages/talk pages could be loaded a lot faster. ^.^Smallman12q (talk) 15:21, 22 February 2009 (UTC)
If anyone is interested, I have created a bot request at Wikipedia:Bot_requests#Image_Optimization_and_Compression_Bot.Smallman12q (talk) 18:10, 22 February 2009 (UTC)
There is an online optimizer with which you can see how the number of colors affects size. See http://tools.dynamicdrive.com/imageoptimizer/index.php .It seems the current wikipedia logo is 32 colors so it could be optimized a bit more. And the user icon can be compressed even further to about 15% of the current size. I have looked at the wikipedia favicon and it can be compressed. In fact, some of the other mediawiki icons can be losslessly compressed by 70%. Cheers!Smallman12q (talk) 19:38, 22 February 2009 (UTC)

Still need a WP:Developer to update the images.Smallman12q (talk) 00:51, 23 February 2009 (UTC)

I have compressed them a bit further

The savings are several kilobytes. Also, I would appreciate if you gave me credit when you update the pics. Thanks!Smallman12q (talk) 23:48, 23 February 2009 (UTC)

Okay but could you stop flooding the village pump with image galleries? Even though they are compressed they still make this page take way too long to load and even longer to render. Maybe put them on some other page and link to it from here? Thanks. — CharlotteWebb 02:58, 2 March 2009 (UTC)

If the recompression is not lossless, then I would need to review them for loss of quality. The bandwidth savings you're talking about do not appear to be sufficient to justify this amount of time. -- Tim Starling (talk) 09:01, 2 March 2009 (UTC)

I mean lossless. I don't know where I said it wouldn't be lossless....but I do mean lossless. I'm not sure of the bandwidth savings...perhaps someone with the actual data could calculate the savings so I would know whether it is worth pursuing this change.Smallman12q (talk) 16:58, 2 March 2009 (UTC)
See the section above, the comments just above the "Other images" heading. There have been concerns that your compression method may have resulted in some minor quality loss. Equazcion •✗/C • 17:02, 2 Mar 2009 (UTC)
I see. I did the color palette manually so I might not have seen the difference. However, I would like to still say that png compression alone is still indeed lossless.Smallman12q (talk) 20:04, 2 March 2009 (UTC)
I'm back, and seems that a revision is required for bandwidth conservation (although some will think it's redundant). Instead of taking 185 million page views/day as of February 2009, I'll take the average over several months – 180 million. Lets also say the percentage who loaded the logos are halved from my previous estimate, 0.01%.
Estimated b/w saved = 180 million × 0.005% × 5000 bytes = 45 million bytes/day = 42.9 MB/day = 1.26 GB/month = 459 GB/year. Though I must agree that it dwarfs in comparison with this ongoing conversation. So, if an image cannot be compressed further without losing quality, forget about it. But if there's a significant ratio, then go ahead. I believe many logos out there can be crushed. HУтaяtalk2mecontribs 18:34, 3 March 2009 (UTC)
How does 1.26GB/month equal 459GB/year? Are there more months to a year than I've been told or did I miss something... Equazcion •✗/C • 20:47, 3 Mar 2009 (UTC)
OK, my bad. Forgive me 'cos I was tired. It should be around 15.3 GB/year. Anyway this topic will be archived and this is my last response. HУтaяtalk2mecontribs 22:53, 7 March 2009 (UTC)

There is an additional discussion going on at Commons:commons:Administrators'_noticeboard#Thumbnailer_not_thumbnailing_GIFs_-_huge_waste_of_bandwidth.21. Currently, gifs are not compressed at all resulting in a massive waste of bandwidth and increased page load time.Smallman12q (talk) 00:48, 5 March 2009 (UTC)

So no one cares about bandwidth usage? That's disturbing.Smallman12q (talk) 19:32, 10 March 2009 (UTC)

Not in the quantities involved here. A back-of-the-envelope calculation shows that your compressed images will save Wikipedia approximately $0.12 per year. --Carnildo (talk) 04:20, 12 March 2009 (UTC)
Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_57&oldid=1252194577"