Jump to content

Wikipedia:Village pump (technical)/Archive 59

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

Pantomime, bots and interwikis

I copy from Talk:Pantomime, because it's a generic question:

There is a problem with the interwikis of this page (Pantomime). Every other's language cognate refers to the kind of performance done by mimes, but any attempt to manually correct the interwikis (from here or the other languages' pages) is blindly undone by the bots.

Is there any way to fix this? Some directive that will tell bots not to change the interwikis, or something like that? --Angus (talk) 08:48, 31 March 2009 (UTC)

Use {{bots|deny=...,...,...}} (replace the '...' with the names of the interwiki bots) Also, go to all of the other wiki pantomime pages and remove the english wiki page if it is not the correct one.ManishEarthTalk • Stalk 09:00, 31 March 2009 (UTC)
link the other wikis to Mime artist I'll do it partly.ManishEarthTalk • Stalk 09:04, 31 March 2009 (UTC)
Finished, except cy:Pantomeimeo:Pantomimolt:Pantomimapl:Pantomimafi:Pantomiimisv:Pantomim (cant tell what they are). If there is any progress, please add it to simple:, too, or else the problem will come back.ManishEarthTalk • Stalk 09:39, 31 March 2009 (UTC)

Given: a set of known page names, say A, B, C.

Wanted: a list of redirects to all these pages, sorted by page, in one single API call. Result should contain the information "A is linked to by redirects X and Y; B is linked to by no redirects, C is linked to by redirect Z".

backlinks takes only one single title as a parameter. How can I use it to return the list of redirects to a set of pages? Haven't found any generator that would just pass through a list of given page titles, and just using api.php?action=query&titles=A|B|C&list=backlinks&blfilterredir=redirects doesn't work either. How can this be done? (Note: making three calls to backlinks, one each for A, B, and C, is not an option.) Lupo 11:00, 31 March 2009 (UTC)

I've actually been looking into that, along with looking into two existing bugs in list=backlinks; for the specific case of getting only the redirects it should be possible using the redirect table. If only there were more hours in the day... The problem with allowing more than one input page in general is most likely that the database queries needed become too slow, but I don't know for sure. Anomie⚔ 12:20, 31 March 2009 (UTC)

How about a super-watchlist that highlights changes like talkpage does?

Occasionally, my userpage will be vandalized, and I might not catch it among the hundreds of other items on my watchlist. I'd like the ability to flag a certain subset of pages as notify-me-immediately-if-changed, like the talk page does. Is this practical, and if so, is it reasonable? Thanks.--SarekOfVulcan (talk) 14:59, 30 March 2009 (UTC)

A script could be written... You get the array of elements which belong to the watchlist, parse them and see if they link to that page, and highlight them with DHTML. Its relatively simple. ManishEarthTalk • Stalk 04:45, 31 March 2009 (UTC)
Surely as an admin you could just fully protect your user page. If another user edits your talk page you should get a new message notice. — Blue-Haired Lawyer 10:22, 31 March 2009 (UTC)
Or, as suggested above in response to a different question: you could set up an RSS feed solely for the limited set of pages you want to monitor closely. -- John Broughton (♫♫) 16:40, 31 March 2009 (UTC)
Blue-Haired Lawyer: We usually don't want to protect our admin user pages, since if a vandal is stupid enough to vandalise our user page then the page acts as a honeypot trap. That is, it is better that they vandalise our user pages where we notice it and it does less damage, then that they vandalise articles. But it would still be neat to notice it quickly, so we can stop them before they can vandalise more pages.
--David Göthberg (talk) 15:35, 1 April 2009 (UTC)
Or it would be a good honeypot trap if the user involved actually noticed that his/her user page had been vandalised. Btw I'm not an admin, although I have seen admins (well one anyway) do this, so it was just an idea. — Blue-Haired Lawyer 15:53, 1 April 2009 (UTC)
Ok, this should work but may not be exactly what you want. Putting:
UL.special LI A[title="User:SarekOfVulcan"] { text-decoration: blink; }
(or set to whatever page)
in your monobook.css should make every edit to your user page (but not subpages) flash. The blinking effect is very annoying and doesn't work in IE, so you may prefer setting it to "bold" rather than "blink", although this doesn't stand out so much. — Blue-Haired Lawyer 16:17, 1 April 2009 (UTC)
Blue-Haired Lawyer: Oh, good idea! But I tested and it doesn't work if you have "Enhanced recent changes" activated in your "My preferences" (that setting affects the watchlist too). But here is CSS code that works both with and without that setting:
.page-Special_Watchlist a[title="User:SarekOfVulcan"] {
    font-weight: bold;
}
Blinking made my browser slow, so I changed to bold here. (But I have a very old slow computer.) This method means we can easily add quite a lot of pages to bold or colour or whatever in our personal /monobook.css, since browsers process CSS very efficiently. (Man, I'm going to have fun with that. :)) Seems you found a fairly good solution to SarekOfVulcan's original question.
And a note to those of you who are new to editing your personal /monobook.css: After you have edited it you need to wait a minute, then bypass your browser cache. Otherwise it can take up to 31 days before you see the change.
If any of you non-admin users have trouble with vandalism of your user page, then you can just ask any admin to protect your user page. Well, semi-protect, so you can still edit it yourself. (No need to request it officially, since it is uncontroversial and your page has already been vandalised).
--David Göthberg (talk) 22:13, 1 April 2009 (UTC)
See also Wikipedia:WATCHLIST#CSS. Gwinva (talk) 22:24, 1 April 2009 (UTC)
Along similar lines to the original question - could we get the equivalent of the orange "new messages" band across the top which alerts us to changes on the usertalk page, but maybe in a different color for changes to our user page? Tvoz/talk 22:28, 1 April 2009 (UTC)

Edit summaries

Is there a reson my computer goes agonizingly slow whenever typing an edit summary or headline? It only seems to do it then. I have the latest version of Firefox, Mac OS 10.4.11. It's the only thing it slows down for. Ten Pound Hammer and his otters • (Broken clamshells • Otter chirps • HELP) 17:41, 30 March 2009 (UTC)

Do you have the "allow up to 50 more characters in each of your edit summaries" gadget activated? --Amalthea 18:27, 30 March 2009 (UTC)
No. Ten Pound Hammer and his otters • (Broken clamshells • Otter chirps • HELP) 17:19, 1 April 2009 (UTC)

Redirects

Is there any easy way of determining how many redirects there are in Wikipedia at any time? —  Tivedshambo  (t/c) 11:48, 31 March 2009 (UTC)

From a tool: Wikipedia:Database_reports/Page_count_by_namespace. If you can't wait for daily reports, you could request a database query but that might take longer than 24 hours. --Splarka (rant) 07:46, 1 April 2009 (UTC)
Check the code for Special:Random redirectManishEarthTalk • Stalk 05:23, 2 April 2009 (UTC)
Special:ListRedirects?ManishEarthTalk • Stalk 05:26, 2 April 2009 (UTC)

Subcategories: A show-all option?

You go to a category page. First or second thing you see is the list of Subcategories in it. Sometimes you see all of the subcategories, A-Z; however if there are more than about 30 of them, the list is truncated and you have to click on "Next 200" to see more. In several cases I've noticed that the initially visible list goes up to about "T" in the alphabet, and only three or four subcategories are truncated. In such a case we're hardly saving any space on the page by truncating, and definitely creating a nuisance. I propose that the Template:Commons cat that creates the list have an option added to it allowing supression of the truncation feature in such cases.

Examples: Category:Economics, Category:Government, Category:Communism.

Another point. I assume that the message shown is "Next 200" because there are 200 pages in the subcategories. But the 200 pages are not shown, only the -- typically 30 or so -- subcategories containing them. So the user sees 30 or so names, and this message saying "Next 200." It's incongruous and confusing. Might be nice to tweak that somehow. -- Ong saluri (talk) 19:55, 31 March 2009 (UTC)

This is because subcategories are indexed alphabetically along with regular pages and files. When rendering, a category page starts alphabetically and fetches 200 matches (by sortkey), and then displays them, sorting them by type (image, category, page) after the fact. See bugzilla:1211. --Splarka (rant) 07:34, 1 April 2009 (UTC)

Deletion of protected pages

I would like that when we admins try to delete a protected page, we get some kind of warning notice that the page is protected. I want a warning to show for any kind of protection, no matter if it is only semi-protected or semi-move-protected.

Background: Among other things we have a constant problem that admins delete protected images because they are "duplicates" of images on Commons. But protected images are usually locally uploaded and protected here since they are used in an interface message or in a widely used template, thus those images are high-risk. Of course, deleting any other kind of protected page is usually also irregular and needs a warning.

I tried to add such a warning message in MediaWiki:Confirmdeletetext, by using the {{PROTECTIONLEVEL:edit}} magic word. But that magic word doesn't seem to work there.

I can see several possible solutions to this problem:

1: The best would be if MediaWiki automatically displayed a special message at the top of the deletion dialogue, if the page has any kind of protection. Since I think all Wikimedia projects would have good use of this. I would of course love if that message were fed the edit protection level and the move protection level as parameters $1 and $2.

2: Fixing the {{PROTECTIONLEVEL:edit}} magic word so it works in the deletion dialogue too. But this is much more clumsy, and this might anyway be more work for the devs than creating the message above.

3: I can update MediaWiki:Sysop.js to add such a warning message. But that only helps locally here on the English Wikipedia.

What do the tech experts think that hang out here? Have I missed something?

--David Göthberg (talk) 14:58, 1 April 2009 (UTC)

Global acount managing

Is there any way to remove some wikis from your global account (Basically delete your account on other wikis) I did some interwiki language fixing, and now I have a huge global account. (By the way, does wp really log you in to every wiki in your global account every time you log in?)ManishEarthTalk • Stalk 09:47, 31 March 2009 (UTC)

In what particular way is this a problem for you? (Is there a screen or report or view that lists these other accounts, where you don't want to see them?) -- John Broughton (♫♫) 16:44, 31 March 2009 (UTC)
Yup. Also, I am afraid that ill be logged in to the 36-odd pages in it when I login. (After all, the login page does say logging you in to sister projects.) One more thing. I have been receiving emails from those wikis in foreign languages (I think that they are welcome type emails or maybe account activation), and thay are filling up my inbox.
Have you tried deleting those emails? Lugnuts (talk) 10:54, 2 April 2009 (UTC)

Is there a tool to watch for additions to Categories?

Resolved
 – ukexpat (talk) 20:08, 2 April 2009 (UTC)

I'm looking for a way to watch for additions of pages to a category -- is there anything out there like this?

Thanks, --A. B. (talk • contribs) 13:18, 31 March 2009 (UTC)

I use this script, User:Ais523/catwatch.js In my opinion the absolute best script there is, I can see attack pages, unblock requests whatever as soon as i open my watchlist--Jac16888Talk 13:23, 31 March 2009 (UTC)
Thanks! --A. B. (talk • contribs) 13:52, 31 March 2009 (UTC)

What we really need is something which would straightforwardly allow monitoring of the removal of pages from a category. Currently, the only way to do this is by adding them to a watchlist (which catwatch.js semi-automates), and then trying to find the category removals among al the other edits. --BrownHairedGirl (talk) • (contribs) 01:03, 3 April 2009 (UTC)

Israel is semi-protected and featured. I am on a computer with Firefox and the two words appear together. I don't know whether waiting would have solved the problem, but it looks bad.Vchimpanzee · talk · contributions · 14:34, 1 April 2009 (UTC)

best I can tell, this is just a bad CSS fubar. The 'semi-protected' template sets its icon at 55px from the right of the screen (expecting the 'edit' link to go on its right), while the FA template sets its icon 10px from the right (expecting the 'edit' link to go on the left). the result is that the edit link gets badly mis-positioned. not sure what the best way to approach it is, though. --Ludwigs2 01:21, 3 April 2009 (UTC)
P.s. the best alternative I can think of is to move the Featured Article icon down, so that it lies below (or maybe across) the first heading lower border. that would let the edit link go back to where it wants to be, and shouldn't overlap anything else - that space should usually be empty because of the 'From Wikipedia, the free encyclopedia' trailer. --Ludwigs2 01:41, 3 April 2009 (UTC)

Falklands War spacing

Resolved

Can anyone explain why Falklands War has a lot of extra white space at the top of the article? I can't figure out how to get rid of it. Thanks in advance - Tempshill (talk) 18:50, 2 April 2009 (UTC)

fixed by Melon. --Amalthea 19:18, 2 April 2009 (UTC)
Thanks! Tempshill (talk) 19:58, 2 April 2009 (UTC)

Fixing the Tnavbar-header template

Help would be appreciated.Headbomb {ταλκκοντριβς – WP Physics} 05:39, 3 April 2009 (UTC)

Daylight saving time woes

Resolved
 – Thanks to all for explanations and advice. Tonywalton Talk 09:13, 4 April 2009 (UTC)

I'm in the Europe/London timezone. Last Sunday (29 March) the UK, and the rest of Europe, moved to daylight saving time. Specifically where I am went from GMT (UTC) to BST (UTC+1). Since then I'm seeing a mismatch between the time reported on edit histories and the time generated by ~~~~. The edit history gives the time correctly for my "wall clock" time, however the sig has expanded to UTC time. This edit is an example - the sig that I see on that entry on my talkpage is "22:03, 1 April 2009 (UTC)" whereas the edit history says "23:03" (which is local time. BST). My preferences are set to "Time zone: Europe/London" but I also get the same effect with "Time zone: other" and a 1 hour offset specified (which is filled in correctly by the browser). I'm running Firefox 3.0.8 on Mac OS X 10.4.11 but have seen the same on Safari 3.2.1 on the same OS. This may seem minor, but it's a bit of a bugger when I'm patrolling WP:AIV and comparing "time of last warning on userpage" (which is probably shown as UTC) with "time of last edit" (which might well be UTC+1). Can someone tell me what might be going on, and what can I do to sort it? Tonywalton Talk 22:12, 1 April 2009 (UTC)

Just set "My preferences" - "Date and time" - "Time zone" to "Use server default". And everything you see on Wikipedia will be in UTC.
(That is the same thing as setting "Time zone: Other" to "00:00". The times you see on Wikipedia are produced by the Wikipedia servers, not your own computer.)
The times on an edit history are "produced by the WP servers" as well, but they're shown as local time. I thought whatever expanded ~~~~ did so dynamically as well. Dim of me, when I think about it. Tonywalton Talk 23:29, 1 April 2009 (UTC)
Those of you who want to keep track of UTC time, you might be interested in this little nifty script: User:Davidgothberg/clock. It puts an UTC clock in the upper right corner of all pages. And has links to purge the page and to edit section 0.
--David Göthberg (talk) 22:41, 1 April 2009 (UTC)
Just to clarify: The dates generated by ~~~~ are in UTC for everyone, no matter what timezone they have configured. Anomie⚔ 23:04, 1 April 2009 (UTC)
Thanks for that, Anomie - I should have thought. 4tilde is actually substed into the page, so uses a fixed timezone. I'll stop moaning now - at least I live in a timezone where UTC is my local time 5 months a year! Tonywalton Talk 23:29, 1 April 2009 (UTC)
The timezone added to the page with the tildes needn't appear in UTC for you: see WP:LOCALISE, a gadget to convert all time and date stamps to your timezone. Gwinva (talk) 23:53, 1 April 2009 (UTC)
Tonywalton: Nah, don't feel dim. Time zones and daylight savings time are complex stuff. Human brains are not really equipped to handle such things.
Gwinva: Hehe, that localise script is cool but scary. I have seen the confusion it can cause when some users discuss what happened at what time, and a third user gets all confused, since he uses his local time zone. So I prefer to simply do this way: When I edit Wikipedia, then my time zone is UTC, then I don't refer to my local time at all. Then the clock I look at is in the upper right corner of the Wikipedia pages, not the clock in my Windows system tray or on my desk.
--David Göthberg (talk) 03:02, 2 April 2009 (UTC)
Just tried that gadget - I think I like it, but I'll see how it goes. As for feeling dim, I used to have one of those human brains that did understand such stuff (Olsen zones, POSIX-style TZ strings, all that guff. I even understand why timestamp 0 is 1am, not midnight, on 1/1/1970, on a Unix system in the GB timezone. Which is a deeply sad thing to understand.) Thanks both for your help! Tonywalton Talk 12:58, 2 April 2009 (UTC)

Edit hover-over message

Which MediaWiki page is it that determines the little message you get when you hover over the edit bar? Because it needs a space put in after the full stop. Thanks! It Is Me Here t / c 12:41, 2 April 2009 (UTC)

What edit bar? The edit tab tooltip contains "You can edit this page. Please use the preview button before saving. [alt-shift-e]". But see MediaWiki talk:Tooltip-ca-edit for an older discussion about maybe the same issue. --Amalthea 13:38, 2 April 2009 (UTC)
That looks like the same thing. Safari (3.2.1 on Mac OS 10.4.11) renders the tooltip as "You can edit this page.<LINEBREAK>Please use..." whereas Firefox (3.0.8, same OS) renders it as "You can edit this page.Please use...". Tonywalton Talk 14:30, 2 April 2009 (UTC)
It's rendered without a linebreak but with a space in FF 3.0.8 on WinXP. Algebraist 14:33, 2 April 2009 (UTC)
All the browsers I've tested (Safari, Firefox, and (Windows only) Internet Exploder 7) on both Mac OS X and Windows XP SP3 currently either render the linebreak or fail to a space. What browser are you using? {{Nihiltres|talk|log}} 17:11, 2 April 2009 (UTC)
Firefox 3.0.6 & Opera 9.24 show it with the space, Safari 3.1.2 and IE 7 show it with a linebreak. All on WinXP SP2. --Amalthea 17:27, 2 April 2009 (UTC)
IE8 now displays a linebreak, but does not render the final full stop for some reason. It Is Me Here t / c 09:57, 4 April 2009 (UTC)

Kaliningrad, [edit] "stucks-up"

The Kaliningrad article looks like this on my machine both under Opera 9.62 and Firefox 2.0.0.14. Could anyone tell me, how to solve this problem? - Xbspiro (talk) 08:35, 3 April 2009 (UTC)

WP:BUNCH --TheDJ (talk • contribs) 10:01, 3 April 2009 (UTC)

Are deletions throttled?

I just closed a group MFD which requires the deletion of about 30 pages. In the past, I've just opened them all into Firefox tabs, and done them all at once. Now, when I try to do that, only one works, and all the others put up a page that says

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 "Article::doDeleteArticle". MySQL returned error "1205: Lock wait timeout exceeded; Try restarting transaction (10.0.6.22)".

What is going on here? Can I really only delete one page at a time? Is there a problem with my Firefox? I'll continue deleting these one by one, but it sure is a pain.--Aervanath (talk) 07:32, 4 April 2009 (UTC)

IIRC, that is a database issue, and not a throttle. (I haven't encountered limits like that when deleting, and I seem to recall posting here about a similar message a short time back.) --Ckatzchatspy 08:00, 4 April 2009 (UTC)
I don't think that deletions are throttled per se, but they're complicated database transactions that will be really messy if they go wrong, so everything that has to happen to the database is grouped into one 'database transaction'; MySQL includes a "rollback" function that works almost identically to on-wiki rollback: if something goes horribly wrong during the transaction the whole thing can be 'rolled back' and all previous commits reverted. In the same way as on-wiki, however, that can only happen if no other commits happen during the transaction, so the database has to be locked until the delete transaction is finished and confirmed by the software. My interpretation of the error message is "I've tried to start a database transaction to delete the page, but was told that the database was locked; I've waited as long as I'm allowed but it's still not finished; hopefully by the time you see this and start the transaction again it'll be free". Does that clarify? Happy‑melon 09:40, 4 April 2009 (UTC)
Yeah, I think I understand: there's no formal throttle, but if you go too fast, a deletion might be blocked by the unfinished one before it. Any way around that? Or a way to upgrade the system so it can handle simultaneous deletions of different pages? That seems to imply that if two admins are trying to delete pages simultaneously, one will get a database error, but I've never heard of anything like that.--Aervanath (talk) 10:05, 4 April 2009 (UTC)

Ok, that's even weirder: I just tried it again with a string of redirects from an Rfd, and it went just fine. Could it be because the redirects in general have shorter histories, so there's less stuff for the database to process?--Aervanath (talk) 10:10, 4 April 2009 (UTC)

The relevant MediaWiki code is, for a change, fairly intuitive even if you don't know PHP:
The section from Article.php
		$dbw->begin();

...
		$dbw->insertSelect( 'archive', array( 'page', 'revision' ),
			array(
				'ar_namespace'  => 'page_namespace',
				'ar_title'      => 'page_title',
				'ar_comment'    => 'rev_comment',
				'ar_user'       => 'rev_user',
				'ar_user_text'  => 'rev_user_text',
				'ar_timestamp'  => 'rev_timestamp',
				'ar_minor_edit' => 'rev_minor_edit',
				'ar_rev_id'     => 'rev_id',
				'ar_text_id'    => 'rev_text_id',
				'ar_text'       => '\'\'', // Be explicit to appease
				'ar_flags'      => '\'\'', // MySQL's "strict mode"...
				'ar_len'        => 'rev_len',
				'ar_page_id'    => 'page_id',
				'ar_deleted'    => $bitfield
			), array(
				'page_id' => $id,
				'page_id = rev_page'
			), __METHOD__
		);

		# Delete restrictions for it
		$dbw->delete( 'page_restrictions', array ( 'pr_page' => $id ), __METHOD__ );

		# Now that it's safely backed up, delete it
		$dbw->delete( 'page', array( 'page_id' => $id ), __METHOD__);
		$ok = ( $dbw->affectedRows() > 0 ); // getArticleId() uses slave, could be laggy
		if( !$ok ) {
			$dbw->rollback();
			return false;
		}
		
		# Fix category table counts
		$cats = array();
		$res = $dbw->select( 'categorylinks', 'cl_to', array( 'cl_from' => $id ), __METHOD__ );
		foreach( $res as $row ) {
			$cats []= $row->cl_to;
		}
		$this->updateCategoryCounts( array(), $cats );

		# If using cascading deletes, we can skip some explicit deletes
		if( !$dbw->cascadingDeletes() ) {
			$dbw->delete( 'revision', array( 'rev_page' => $id ), __METHOD__ );

			if($wgUseTrackbacks)
				$dbw->delete( 'trackbacks', array( 'tb_page' => $id ), __METHOD__ );

			# Delete outgoing links
			$dbw->delete( 'pagelinks', array( 'pl_from' => $id ) );
			$dbw->delete( 'imagelinks', array( 'il_from' => $id ) );
			$dbw->delete( 'categorylinks', array( 'cl_from' => $id ) );
			$dbw->delete( 'templatelinks', array( 'tl_from' => $id ) );
			$dbw->delete( 'externallinks', array( 'el_from' => $id ) );
			$dbw->delete( 'langlinks', array( 'll_from' => $id ) );
			$dbw->delete( 'redirect', array( 'rd_from' => $id ) );
		}

		# If using cleanup triggers, we can skip some manual deletes
		if( !$dbw->cleanupTriggers() ) {
			# Clean up recentchanges entries...
			$dbw->delete( 'recentchanges',
				array( 'rc_type != '.RC_LOG, 
					'rc_namespace' => $this->mTitle->getNamespace(),
					'rc_title' => $this->mTitle->getDBKey() ),
				__METHOD__ );
			$dbw->delete( 'recentchanges',
				array( 'rc_type != '.RC_LOG, 'rc_cur_id' => $id ),
				__METHOD__ );
		}

...

		# Log the deletion, if the page was suppressed, log it at Oversight instead
		$logtype = $suppress ? 'suppress' : 'delete';
		$log = new LogPage( $logtype );
		$log->addEntry( 'delete', $this->mTitle, $reason, array() );

		$dbw->commit();
Everything that begins with "$dbw->" is a database commit; you can see the deletion process involves numerous steps. First, it copies the revision table entries to the archive table; then it deletes the protection settings from the page_restrictions table. Then it kills the page's existence by removing it from the page table. There's a hack to update the counts used for PAGESINCATEGORY: numbers, then it goes on a spree to clear the history from the revision table, any trackbacks (not used on enwiki AFAIK, could be wrong), and then all the link table entries from the page. If there's anything in the recentchanges table relating to the page, that's then cleared, and finally the action is actually logged. That's a lot of stuff to do on the database, no wonder it sometimes locks (and no wonder deleting pages with many revisions is a strain on the servers). In the case of redirects, you can see immediately that a lot of these are unlikely to apply; redirect pages are a lot simpler than articles. So it's simply a case of the deletions going through fast enough to not max out the wait timer on the next entry in the database queue. Happy‑melon 11:06, 4 April 2009 (UTC)
<plug>You might try User:Splarka/ajaxbatchdelete.js, this waits for each delete to go through, and waits 1 second before attempting the next.</plug> --Splarka (rant) 10:45, 4 April 2009 (UTC)

Towards an implementation of flagged protection and patrolled revisions

As we're progressing towards an implementation of flagged protection and patrolled revisions, we need to work out the technical details. There is a page centralizing those efforts at Wikipedia:Flagged protection and patrolled revisions/Implementation, comments and suggestions would be appreciated. I also requested a test implementation, so we can make live tests and consider improvements before the implementation, see T20334. Cenarium (talk) 15:24, 4 April 2009 (UTC)

I'm locked out of WP. Help!

Resolved
 – tempodivalse [☎] 01:44, 5 April 2009 (UTC)

Hello. I recently changed my password on Wikinews, because I am a sysop there and decided it would be wise to make it stronger. However, I can't log into Wikipedia now with either my new or old password now without logging into Wikinews first, activating the global account. This isn't really such a bad problem, in an of itself, but it's a nuisance. Can anyone explain what I need to do to get my global passwords straight? Thanks much, tempodivalse [☎] 17:47, 4 April 2009 (UTC)

Special:Mergeaccount, I would assume. It Is Me Here t / c 18:04, 4 April 2009 (UTC)
No, I already have a global account. Actually, I managed to resolve the issue by changing the WP password so it is the same as the Wikinews password. Now I can log into Wikipedia without issues. Unfortunately, it looks as though I'm going to have to manually change the password for all Wikimedia wikis now. Oh well, thanks. tempodivalse [☎] 18:26, 4 April 2009 (UTC)
This shouldn't have occurred; if it's reproducible, it's probably a bug in CentralAuth. Is en.wikinews your home wiki? Happy‑melon 20:02, 4 April 2009 (UTC)
No it's not, which is probably the cause of the problem. Now you've changed the password on enwiki, can you log in to other wikis with that password? That is, has your global account password been updated? Happy‑melon 20:06, 4 April 2009 (UTC)
Yes, my home wiki is en.wikipedia. Now that I changed the password, all the other wikis seem to have updated. I think I can mark the issue as resolved now, thanks. tempodivalse [☎] 01:42, 5 April 2009 (UTC)

Columns in reflist going crazy

At Street newspaper#References, the two columns are all out of whack (on my browser, at least)—column 1 is significantly longer than column 2, and you can't click the links when it's like that (what happens is, you click the link for one of the external sources and that causes the columns to re-align, then you click it again to actually follow the URL...if you refresh the page, though, the columns are back to craziness). The problem seems to be something with the following reference I recently added to the article:

<ref name=readers>{{cite web | last=Green | first=Sara Jean | title=Real Change's transformation includes plan to reach readers | work=[[Seattle Times]] | url=http://community.seattletimes.nwsource.com/archive/?date=20050201&slug=homeless01m | date=1 February 2005 | accessdate=21 March 2009}}</ref>

because if you remove that then things go back to normal. Specifically, the problem is in |title=, because if I replace the title with "Pass" then everything becomes fine. Any idea what in this ref could be causing the problem, and how to fix it? rʨanaɢ talk/contribs 17:51, 4 April 2009 (UTC)

More fun: the problem is spaces in the title. If I replace the title with "Real_Change's_transformation_includes_plan_to_reach_readers" then it works, but any two-word string (like "pass pass") breaks it. Why {{cite web}} would be causing this problem with spaces in titles, and why it would be happening specifically with this ref and not with others (and this ref isn't causing the problem at Real Change, another article where it is used), is completely beyond me. rʨanaɢ talk/contribs 17:55, 4 April 2009 (UTC)
And more info: the problem is not actually in {{cite web}}, because when I take the ref out of cite web and write it by hand

<ref name=readers>Green, Sara Jean (1 February 2005). [http://community.seattletimes.nwsource.com/archive/?date=20050201&slug=homeless01m "Real Change's transformation includes plan to reach readers"]. ''[[Seattle Times]]''. Retrieved on 4 April 2009.</ref>

it still causes the same pattern of problems. I suppose the problem must be in {{reflist}}. rʨanaɢ talk/contribs 18:01, 4 April 2009 (UTC)
(not even specifically in reflist, but in general: in the article, if I replace {{reflist}} with
<div class="references-small" style="-moz-column-count:2; column-count:2;">
<references />
</div>
then I still get the problem. I know the easy solution is to remove the problem reference or change it's title, but I really don't want to screw around with content just because of a stupid technical issue. rʨanaɢ talk/contribs 18:06, 4 April 2009 (UTC)
All recent revisions display without problems for me in Firefox 3, and {{reflist}} hasn't been edited recently. Skomorokh 18:05, 4 April 2009 (UTC)
I'm also in Firefox 3. What's your screen resolution? rʨanaɢ talk/contribs 18:07, 4 April 2009 (UTC)
1280 x 800. Skomorokh 18:12, 4 April 2009 (UTC)
Hm, that's the same as mine. I'm about to head to the library so I'll try looking at it from one of the computers there. Maybe my computer is just jank. rʨanaɢ talk/contribs 18:16, 4 April 2009 (UTC)
It's not just you: see Template talk:Reflist#s something wrong here?. --—— Gadget850 (Ed) talk - 18:41, 4 April 2009 (UTC)
It's an odd Firefox bug, that (among other things) seems to have to do with exactly where the line wraps happen in the content (and thus your screen resolution), maybe the way the page is divided into packets as it is transferred over the network, possibly your CPU speed and other details about your hardware, and the phase of the moon. My best guess is that if everything is just wrong, Firefox lays out the page before the whole of the multi-column content is available and then fails to redo the layout when the rest comes in; when something triggers a re-layout (e.g. the need to draw the selection rectangle around a link) the display gets fixed. Anomie⚔ 19:50, 4 April 2009 (UTC)
So there's nothing that can be done about it other than actually changing the page content? rʨanaɢ talk/contribs 20:31, 4 April 2009 (UTC)
(and yeah, seems like you're right about the line wrapping thing...it turns out if I keep the ref just as it is but move it to some other random spot earlier in the article, everything becomes fine. But I'm not gonna restructure a whole article just to appease Firefox's whims.) rʨanaɢ talk/contribs 20:34, 4 April 2009 (UTC)
you luddite! --Ludwigs2 21:23, 4 April 2009 (UTC)

2009 NCAA Men's Division II Basketball Championship

Could someone fix this bracket? The information is in. ~EDDY (talk/contribs/editor review)~ NOVA NATION 23:49, 4 April 2009 (UTC)

you had the parameter names wrong. parameter names are literal and case sensitive: RD1-team3 (the correct parameter name) is different than Rd1-team3, RD1-team03, rd1-team3, or any other variation. --Ludwigs2 01:05, 5 April 2009 (UTC)

WP:

Is it possible to get to the edit history of the old mainspace WP: shortcuts?

And further, would it be possible for someone to do a history merge of those with the "new" wikipedia-space shortcuts?

It looks like when the WP: = Wikipedia: change was implemented, some history may have been left behind? - jc37 17:13, 3 April 2009 (UTC)

The pages were moved by a maintenance script to accessible titles (those that couldn't be moved from WP:Foo straight to Wikipedia:Foo because there was already a page there, so should still be accessible if you can remember or find the syntax that was used. I doubt that anything particularly important was lost; any instances where the old edits were genuinely important should be dealt with on a case-by-case basis. Happy‑melon 17:39, 3 April 2009 (UTC)
See the reaction to the change back in December 2007; the conflicting pages were moved from WP:Foo to Wikipedia:Foo--DUP (or Wikipedia:Foo--DUP--DUP in some cases when there was eg WP:Foo and Wp:Foo); 934 pages were moved in this fashion - a list is visible here to admins. All the pages have now been deleted. Is there anything in particular you're looking for? Happy‑melon 20:25, 3 April 2009 (UTC)
Understood.
When I went into the page history of WP:UFD, it only listed since 2006, when I know it was used prior to that due to several talk page discussions.
So I'd like to merge the edit histories (if for no other reason than to make the archived discussions make more sense to anyone trying to figure this out in he future).
That aside, how would one actually get to those (now deleted) mainspace ones? The software seems to automatically turn the WP: into Wikipedia: - jc37 18:51, 4 April 2009 (UTC)
If you want the old history, just go to ST47's list, find the appropriate page, and undelete and merge as normal.
It doesn't make sense to ask for the "mainspace ones": those --DUP pages are the mainspace ones. The maintenance script that JeLuF wrote and ran moved all pages named "WP:Foo" in namespace 0 to being "Foo" in namespace 4; exactly like a modern page move with redirect-suppressed, just without the log entries. Happy‑melon 18:02, 5 April 2009 (UTC)

Is there way to set the link color for dates? Could this be added to Special:Gadgets? -- User:Docu 


span.mw-formatted-date a {
color: purple;
}

This should work I think, didn't test it though. Special:Mypage/monobook.css --TheDJ (talk • contribs) 19:02, 5 April 2009 (UTC)


Thanks, it does. For those that don't want to see wikified dates, the following should do: 
span.mw-formatted-date a {color: black;}
-- User:Docu

Title icons and locks and such

I understand Wikipedia is a vast website, but there was a talk on the Simple English Wikipedia about this earlier, and I was wondering if you guys would like to do so also. The proposed plan is to "fix" the icons—that is, the position of the icons. On my browser, the icons appear unorganized and carelessly placed. The idea, thanks to the French Wikipedia, is to put some Javascript code into Common.js, and the browser will automatically place the icons accordingly. This would mean that there would be a huge icon overhaul (of a much larger scale than that on the Simple English Wikipedia). My proposal would be to add some code to MediaWiki:Common.js, create a template, {{icon placeholder}}, and have all templates of an icon nature use that as a parent template (FA icon, protection icons, possibly coordinate icons). Please contact me if you want more details (or are interested in the composition of the Javascript) regarding this proposal. Cheers, obentomusubi 06:06, 5 April 2009 (UTC)

I like the general idea, but there's no real need to have a metatemplate. Just have all topicons use the "topicon" class on their wrapper element (many already do), and have the javascript detect that. Anomie⚔ 16:23, 5 April 2009 (UTC)
We have a meta template (though not fully deployed) {{top icon}}. I have tried numerous times to deploy a JS script to cleanup topicons, but people seem to worry about performance. --TheDJ (talk • contribs) 18:54, 5 April 2009 (UTC)
Relevant discussion can be found in the archives of MediaWiki:Common.js btw. --TheDJ (talk • contribs) 19:03, 5 April 2009 (UTC)

(supplementary) Secondly, I personally like a different FA icon, although I'm sure everybody here is completely fine with it (as am I; I think it was better to change it on the Simple English Wikipedia than here). I might as well have a go, however. The image is , and it was based off of the French Wikipedia icon, . Don't worry, I'll understand if you shoot the icon change down; it's completely understandable. obentomusubi 06:08, 5 April 2009 (UTC)

I prefer the current FA star icon. Anomie⚔ 16:23, 5 April 2009 (UTC)

Deleting previous versions of files

Is there a problem with deleting previous versions of files? I tried to delete a previous version of File:Princess bride.jpg but when I clicked delete on the selected version I only could delete all the versions of the file in question. Garion96 (talk) 16:55, 5 April 2009 (UTC)

Yup...
Here's the archived thread from last week.
As noted there, it's been reported to bugzilla.
It looks like a fix may be in the works, just not here yet.
- J Greb (talk) 17:06, 5 April 2009 (UTC)
You can manually change the URL to get it to work, by changing the "oldimage[]=" parameter to "oldimage=". --Amalthea 17:28, 5 April 2009 (UTC)
Thanks, glad it wasn't me just clicking the wrong link. Hope a fix comes out soon. Any idea what exactly caused it? It always was working good before. Garion96 (talk) 18:06, 5 April 2009 (UTC)

TOC does not appear

Resolved

I had to force the TOC manually to make it appear at Talk:Timeline of United States inventions and discoveries and it's not because of the number of headings. —Admiral Norton (talk) 19:05, 5 April 2009 (UTC)

It was hidden in the comments section of the WP banner. The comments subpages shouldn't usually have any headings since they are transcluded at the top of the talk pages (sometimes more than once). --Amalthea 19:27, 5 April 2009 (UTC)

Current events

Current events page is all messed up. I think possibly there is a broken template, but I can't find it. -ClockworkLunch 22:41, 7 April 2009 (UTC)

If you mean Portal:Current events then [1] must have messed it up but it has been fixed. PrimeHunter (talk) 23:06, 7 April 2009 (UTC)

Multi-sortable tables

I was wondering if there were any interest in multi-sortable tables? What I mean is a type of table where one can sort from among multiple sub-items within each table column. One idea I came up with was to make a table that looks like this: 

{| class="wikitable sortable" style="font-size:85%;width:100%;"
|-
! style="width:6em;" | Year !! Title !! style="width:8em;" | Company !! style="width:8em;" | Data !! Notes
|- style="vertical-align: top;" 
| <b>NA</b>{{-•}}2000{{-}}<b>JP</b>{{-•}}1999 || <b>English</b>{{-•}}''[[Ogre Battle 64: Person of Lordly Caliber]]''{{-}}<b>Japanese</b>{{-•}}Ōga Batoru Rokujūyon Person of Lordly Caliber{{-•}}オウガバトル64 Person of Lordly Caliber || <b>Developer</b>{{-•}}[[Quest Corporation|Quest]]{{-•}}[[Nintendo]]{{-}}<b>Publisher</b>{{-•}}[[Atlus]] || <b>Platform</b>{{-•}}N64{{-}}<b>ESRB/ELSPA</b>{{-•}}Teen{{-}}<b>Players</b>{{-•}}One || <b>Genre</b>{{-•}}Tactical RPG.{{-}}<b>Setting</b>{{-•}}Fantasy.{{-}}<b>Series</b>{{-•}}Sequel to ''[[Ogre Battle: March of the Black Queen]]''.
|}

and then make it so that clicking on the icon in each column brings up a drop-down list of sub-headings to select from (for instance, "English" and "Japanese" in the second column). The script would then sort each table row based on the selected sub-heading. Of course, alternate formatting is also possible.

I think this could be done fairly easily in JavaScript via modifications to Wikibits.js. However, previous submissions I've made to Bugzilla have died due to lack of interest, and if there's no interest then I won't bother. SharkD (talk) 02:31, 8 April 2009 (UTC)

Featured Topic page gone crazy

I am pretty sure that Wikipedia:Featured topics is not supposed to look the way that it does. Something has drastically gone wrong. -MBK004 07:48, 8 April 2009 (UTC)

Cydebot malfunctioned. Should be all OK now (it's a great way to pad your edit count!) MER-C 08:46, 8 April 2009 (UTC)

Icons in WikiProject banners

A recent change to {{WPBannerMeta}} has meant that it now displays little icons next to the quality assessment for all grades (B-Class, Stub-Class, Template-Class, etc); previously they were only shown for FA, FL, A and GA classes. Although we're determined to make this a user preference, with people being able to use personal CSS to see whichever icons they want, there's some discussion still over what the default appearance should be. If anyone here actually gives a damn (:D), we'd love to hear your thoughts on the icons at Template talk:WPBannerMeta#-Class. Happy‑melon 09:43, 8 April 2009 (UTC)

People want user preferences to change the little icons in WikiProject templates? Seriously? --Apoc2400 (talk) 20:45, 8 April 2009 (UTC)
By that I mean it's possible to play with them in personal CSS, not that there's a checkbox in Special:Preferences for them. That would indeed be a little OTT... :D Happy‑melon 20:47, 8 April 2009 (UTC)

Commons top icon

You may notice that for some time, image pages that mirror a file on Commons, display a small Commons icon in the top-right corner. However, the icon overlaps the top edit link generated by MediaWiki:Gadget-edittop.js. This would normally not a problem, if the icon has an id, but the Commons icon does not. Where is that icon generated, and is it possible to add an id="commons-icon" to its declaration, so it can be accounted for in the script? — Edokter • Talk • 13:15, 8 April 2009 (UTC)

MediaWiki:Sharedupload --TheDJ (talk • contribs) 13:28, 8 April 2009 (UTC)
Thank you! — Edokter • Talk • 13:33, 8 April 2009 (UTC)

RSS feed

I want to set up RSS feeds for user talk pages and maybe a few article pages. How do I do that? I went to WP:Syndication, but I couldn't find the icon in the history page that I am supposed to click. Griffinofwales (talk) 17:51, 8 April 2009 (UTC)

It's in the toolbox, down the left hand side on the history page. Tra (Talk) 18:41, 8 April 2009 (UTC)

Special input box for sources when creating a new article

I suggest that when creating a new article, there be a new input box labeled 'Sources'. It would be below the main text box, and the same width but only a few lines high. If anything is entered there, it will be appended to the article under a heading 'Sources'. A bullet point (*) is added at the beginning of each line if not already present.

This would encourage new editors to add sources when creating new articles without having to figure out the <ref></ref> system. Experienced editors probably prefer to enter references in the main text box, so it should be possible to disable the 'Sources' box under preferences. --Apoc2400 (talk) 20:38, 8 April 2009 (UTC)

Not exactly what you describe, but you can enable Special:Preferences → Gadgets → refTools. --Gadget850 (talk) 20:45, 8 April 2009 (UTC)
Thanks, but I was already using refTools. I don't want this for myself, for new editors who may be unsure of where to put sources, and might need a more direct reminder. --Apoc2400 (talk) 22:14, 8 April 2009 (UTC)
This is much better than the suggestion to change "Edit summary" to "Summary and sources". –xeno (talk) 20:45, 8 April 2009 (UTC)
Agreed. If we do that sort of thing, separate input is the way to go. — Gavia immer (talk) 01:29, 9 April 2009 (UTC)
  • It's not a bad idea, but it has issues. How do you encourage inline citations and what do you do when such a header already exists? = Mgm|(talk) 12:56, 9 April 2009 (UTC)
  • It would only be displayed when creating a new article. If someone adds both inline citations and uses this box, then there will be two reference sections until somebody gets around to fixing it. Fixing reference formatting is easy compared to digging up sources for unreferenced articles. --Apoc2400 (talk) 15:26, 9 April 2009 (UTC)
  • It does require a bit of a mind change. However, if this field is used- a bot can pass the information to the controlling Project group who will want to ce the new article. In doing so, this line can be changed to a cite, the section into a bibliography, and harvard notation used to insert inline refs. Ok, there are a lot of assumptions there too! As to the question of how you encourage citation. If there is a new box to fill- we can expect a two line prompt and it is here we leave links to a page about correct referencing. Just a thought. --ClemRutter (talk) 15:39, 9 April 2009 (UTC)


Changes in the Rollback edit summary

Following the discussion on MediaWiki talk:Revertpage (advertised on the proposals village pump) I plan to change the default rollback edit summary to ←Reverted edits by $1 (talk) to last version by $2 (new links to WP:rollback and WP:AES). However, I guess some automated tools might get confused. Any idea who to warn in advance? -- lucasbfr talk 09:33, 9 April 2009 (UTC)

I'd bug User:AzaToth and User:Addshore, they maintain Twinkle and Huggle. MBisanz talk 09:40, 9 April 2009 (UTC)
I already said that Huggle needs a change in the config, I can do that once we've settled on a format. Twinkle doesn't care. But there are other recent changes monitors that I know nothing about, WP:Lupin for example. --Amalthea 09:56, 9 April 2009 (UTC)

Connecting from Thailand

I've seen multiple complaints that users from Thailand can no longer connect to wikipedia. Any idea why this is? Anyone else experiencing this? Any more information? What should I tell the individuals who are experiencing this problem (one has been able to connect only via proxy)?-Andrew c [talk] 14:55, 9 April 2009 (UTC)

Can't they browse the website at all or are they blocked? -- lucasbfr talk 15:19, 9 April 2009 (UTC)
"a page unavailable error"-Andrew c [talk] 17:57, 9 April 2009 (UTC)
Is the problem just Wikipedia? Can they connect to the secure server? Other Wikimedia sites? Other US-based websites? Mr.Z-man 18:05, 9 April 2009 (UTC)

Help please

Something very weird just happenned. After I leftthis comment on an article talkpage, I was unexplainedly unlogged and the edit was attributed, instead of me to Palaboys (talk · contribs). I haven't a clue how or why but could someone fully block Palaboys? With the recent block and disruption regarding Barney Frank I'm concerned about a technical hack. -- Banjeboi 02:30, 9 April 2009 (UTC)

I believe you. It sounds like the details might be different in your case, but if it was anything like mine, this is some kind of rare, bizarre server hiccup, and Palaboys probably hasn't done anything. --Floquenbeam (talk) 02:41, 9 April 2009 (UTC)
If anyone here has a clue how this might have happened, please chime in. Palaboys has been (rather unfairly, IMHO) blocked for this, and I'm pretty sure this is just a technical glitch of some kind. --Floquenbeam (talk) 03:18, 9 April 2009 (UTC)
Palaboys, may be someone's valid account but ... this is a big glitch if it applies edits under a different user name. Just to help a bit here I use a floating IP, shared set of IP's that changes when one launches onto the Internet, and no, I don't use wifi. -- Banjeboi 03:27, 9 April 2009 (UTC)
Normally this shouldn't happen in that case either, since the login is stored in a cookie which is linked to your computer. I see Palaboys was created 1 minute before the edit. Are you sure you didn't create that account on an other browser window? With your permission, I could run a CheckUser. -- lucasbfr talk 09:40, 9 April 2009 (UTC)
Yes, go for a checkuser. this was very strange. Pushing a user off (logging them out) is one thing but putting their edit under a different username is very weird. -- Banjeboi 09:45, 9 April 2009 (UTC)
Ok, that is weird. I confirm that you did the edit, but you appear otherwise unrelated to Palaboys. I'll send the results to the CU mailing list to see if someone can shine some light here. -- lucasbfr talk 09:55, 9 April 2009 (UTC)
I'll help however I can. -- Banjeboi 11:49, 9 April 2009 (UTC)
Any update? -- Banjeboi 22:37, 10 April 2009 (UTC)

Fonts

I cannot read

ᐸᔕᖘᘔ ᐯᖗ᙭ ᐁᑕᒉᕠᖙ: ᙭ᖘᕟ ᘕᕒ ᑕᒉᕠ: ᔕᖘᘔᒉᕠ

(it's showing boxes) Fonts anyone?

Get a proper browser :D Happy‑melon 10:18, 9 April 2009 (UTC)
I've got a proper browser, and it still can't display half those characters. Algebraist 10:20, 9 April 2009 (UTC)
I have Windows Vista and all the symbols display in IE 7.0, Firefox 3.0.8 and Opera 9.64. It's Canadian Aboriginal syllabics and I guess few people ever need them for anything practical. The userbox is apparently a joke involving Mars, maybe supposed to be a claim about being from Mars. I don't know whether the symbols are random or can be translated. PrimeHunter (talk) 10:31, 9 April 2009 (UTC)
Mac OS X 10.5 with Safari also displays al this characters. --TheDJ (talk • contribs) 10:47, 9 April 2009 (UTC)
I guess it depends on what fonts you have on your computer (the characters don't render on my Firefox either) -- lucasbfr talk 11:07, 9 April 2009 (UTC)
If you zoom in, you will find that those boxes have numbers in them representing the numeric value of a unicode character. The first is 1438— Canadian Aboriginal syllabics "pa".[2] You can get that font from http://languagegeek.com/font/fontdownload.html. --Gadget850 (talk) 14:41, 9 April 2009 (UTC)
I love Code2000: it's got everything. --Carnildo (talk) 07:56, 10 April 2009 (UTC)

WikiProjectBanner and WikiProjectBanners Dont Collapse Banners

I have two PCs each running Professional XP and I'm using Firfox 3.0.8 on each. I just noticed today that on one of them the banners do not collapse when the article talk pages have the WikiProjectBanner or WikiProjectBanners templates. Is there something I can do on the PC that does not collapse the project banners? Pknkly (talk) 16:56, 9 April 2009 (UTC)

Try purging the cache and check that JavaScript is enabled on the machine that doesn't collapse. Do other JavaScript functions execute on that machine? Do other collapsible things collapse? Happy‑melon 17:50, 9 April 2009 (UTC)
Right on! There was a Firefox add on (Java Quick Starter) for controlling Java scripts and the block on Wiki pages had not been removed. Thank you for giving me more edit time and less PC troubleshooting time. Pknkly (talk) 06:54, 10 April 2009 (UTC)

Two equals signs do not an edit summary make?

Resolved

Not a huge issue, just a little curious, why two equals signs, i.e. == doesn't work as an edit summary? This peculiarity caused me to commit an edit without an edit summary for the first time in recent memory (the horror). –xeno (talk) 18:28, 9 April 2009 (UTC)

I was very tempted to {{uw-es}} you now. :)
It's probably because the wpSummary field is also used for the section header if you create a new section, which is automatically enclosed in == signs. --Amalthea 09:19, 10 April 2009 (UTC)
And I was tempted to selectively delete the revision... Yes, I'm slightly o-c. =] Thanks for the explanation. –xeno (talk) 18:03, 10 April 2009 (UTC)

JavaScript failure in IE

Does anyone have any bright ideas on this? Since I made this edit to {{WPBannerMeta}}, IE7 chokes and dies on the CollapsibleTables. WTF?!?! Happy‑melon 21:54, 9 April 2009 (UTC)

Chokes and dies how? On IE8, looking at Talk:A Clockwork Orange, it acts incredibly strange: text disappears and reappears depending on which sequence of show/hide links you click, but the actual collapsing still works, and its not screaming at me about script errors. Mr.Z-man 00:46, 10 April 2009 (UTC)
the only thing I see that would sensibly make a difference is that you didn't include the 'border-collapse:collapse' style element in the revision you made. could IE be choking trying to make conventional (separated-cell) tables collapsible? everything else looks like garden variety changes. --Ludwigs2 02:55, 10 April 2009 (UTC)
There more of a conversation about it at MediaWiki_talk:Common.js#IE_bugfix_breaking_IE.3F. -- WOSlinker (talk) 08:26, 10 April 2009 (UTC)
Resolved

I've made some edits to a table on List of Grade I listed buildings in North Somerset (which has been nominated for FL) and seem to have done something which means the External links & Categories no longer show & I can't which bit of syntax I've damaged to produce this - any help appreciated.— Rod talk 11:58, 10 April 2009 (UTC)

You must have fixed it; looks OK now. --Gadget850 (talk) 12:23, 10 April 2009 (UTC)
Thanks agreed looks OK now - I don't know what I did - but resolved.— Rod talk 12:35, 10 April 2009 (UTC)
I've had the same problem with L-form bacteria. The external links and cats were there when I edited the article, but hidden when I viewed it. I tried purging it, which made no difference, but when you click on the TOC link for external links, this section now appears. Tim Vickers (talk) 16:04, 10 April 2009 (UTC)
It's a Firefox bug, sometimes it forgets to render the bottom of the page when the page is loaded. Often, something as simple as tabbing through the links on the page will cause Firefox to re-render it correctly. Anomie⚔ 00:15, 11 April 2009 (UTC)

Please write me a bit of code to hide the "create a book" toolbox.

Resolved

Thanks in advance =) –xeno (talk) 18:04, 10 April 2009 (UTC)

Add to your monobook.css:
#p-coll-create_a_book { display: none; }
I think I'll go add that myself, it's irritating enough :D Happy‑melon 18:09, 10 April 2009 (UTC)
Easy for you, greek for me. Thank yar =) –xeno (talk) 18:10, 10 April 2009 (UTC)
--NE2 19:47, 10 April 2009 (UTC)

Deprecation due to new parsers

The templates in Category:Date-computing templates have been largely deprecated by the {{#time:}} parser. Can we tag them all with {{tdeprecated}}?--Ipatrol (talk) 20:53, 10 April 2009 (UTC)

Wikimania Announcement on sign-in page - be gone

Currently it's for Wikimania, or some disease, but I am not interested in contibuting - I gave at the office - is there a way to get this daily announcement away? I see it each time I log in and it is quite annoying. -- Banjeboi 06:41, 6 April 2009 (UTC)

Where are you seeing this message, and what is its precise text? I can't see any such thing. Algebraist 09:10, 6 April 2009 (UTC)
There's a dismiss button attached to the message. Click it, and the message will go away for a while, unless you have disabled cookies on your browser. Graham87 09:48, 6 April 2009 (UTC)
I just logged out, cleared my cache and logged back in. I didn't see anything. Zain Ebrahim (talk) 09:54, 6 April 2009 (UTC)
My bad, it's on all pages, my pages WP pages and articles as well. It says - "The Call for Participation for Wikimania 2009 has been released. Submit your presentations before April 15." I thought I had added code to rid myself of banner ads like this but there it is again. Do we have a workaround? It's really annoying. -- Banjeboi 19:54, 6 April 2009 (UTC)
Oh, that thing. The 'hide' link ought to work, or you could add 
#siteNotice {display: none;}
to Special:Mypage/monobook.css to remove central notices for good. Algebraist 20:09, 6 April 2009 (UTC)
I have that code but it doesn't seem to effect this one. Is there another code? -- Banjeboi 21:10, 6 April 2009 (UTC)
That CSS ought to work, unless you're not using monobook or your browser doesn't support CSS properly. Algebraist 09:23, 7 April 2009 (UTC)
That's why I was surprised, this has apparently worked fine in the past - could they be doing some workaround? -- Banjeboi 12:07, 7 April 2009 (UTC)
They aren't. It's working as well for me (and Zain, it seems) as ever. Algebraist 12:09, 7 April 2009 (UTC)
I'm using a Firefox browser but it's worked fine before. -- Banjeboi 15:25, 7 April 2009 (UTC)
Benjiboi: I bet you have to log in to Wikipedia each time you have restarted your browser, right? So you have not set your cookie permissions right.
But I see that you indeed have added that CSS code to your personal /monobook.css page. I just tested and that CSS does work. So in your case the cookie setting no longer should matter. So, have you bypassed your browser cache yet? You have to do that to see any changes you have done to your user /monobook.css. Since the CSS and javascript files from Wikipedia are cached for up to 31 days in the web browsers.
--David Göthberg (talk) 15:28, 11 April 2009 (UTC)
I've changed my cookie setting on my browser, let's see if that was the issue. -- Banjeboi 03:45, 12 April 2009 (UTC)

Commons images, local copies, and deletion

I'd like to propose a modification of the behaviour for the bots that delink Commons images that have been deleted. Specifically, what I've noticed is that in some cases, images are moved from EnWiki to Commons - but run afoul of the licensing requirements there and get deleted. The bots then delink those images from EnWiki, even though the original rationales were acceptable here. (A recent example is File:Heroes helix.svg; I've also encountered this with science images, and I'm sure it occurs across the project.) Net effect is that EnWiki loses valid images, complicated by the fact that many editors won't even know they have been removed or how to get them back.

What I'd suggest is that the bots first check to see if an EnWiki version exists or existed, confirm that the licensing was valid, and then restore the local copy. If there is no valid local copy, only then would they go and comment out/remove the image links from articles. That way, we have a "fallback" setup - if an image is valid here, but not on Commons, it gets removed from Commons but stays on this project. Thoughts? --Ckatzchatspy 16:57, 9 April 2009 (UTC)

Bots can't restore local copies without being tagged as sysops. I'd actually be happy if the bots documented what they did; I've seen them delete bad images, but there were alternate (free) images that could have been used to replace, but the bots didn't know, and it's impossible to figure out where exactly they went. Frustrating. EVula // talk // ☯ // 17:07, 9 April 2009 (UTC)
The primary reason for this is of course that an image is transferred and Commons folk find out that the rationale HERE wasn't proper either. In my opinion however, it would be handy if there was a webinterface to the logs of commonsdelinker (cause I know there are logs). Then it would be easy to see where an image was deleted. This could also log to which cats the deleted image belonged (easier to find alternatives), and it could log any links to other wikipedia's that existed on the description page, so you can check what can be restored (and then perhaps used on en.wp with a FUR). Now if that query can be launched from the edit summary, then you have one powerful tool in my opinion. But who is gonna build it :D --TheDJ (talk • contribs) 19:11, 9 April 2009 (UTC)
The problems I've seen have included a recent one where a self-drawn image was properly licensed here, but (for some reason) not on Commons. After being deleted from Commons, the end result was a loss of the image here, even though it was originally fine. In another case, a NASA image was transferred, and then a deletion vote there decided it was acceptable use on EnWiki, but not on Commons. The bot, however, just removed it here and left nothing. These are two cases where someone familiar with the system noticed the removal. How many acceptable images are disappearing from EnWiki because no-one happens to be in the right place at the right time? --Ckatzchatspy 19:01, 10 April 2009 (UTC)
Yeah, this kind of thing is happening all the time. The people who move images to Commons don't seem to know what they are doing. They are constantly moving fair use images, protected high-risk images and even interface images to Commons and delete (or request deletion of) the images here. And they even often move images that already have an identical copy with the same name at Commons, but since they then get a name collision they move it to a new name, thus we get duplicates on Commons.
One thing that could be done is that the Commons people really should check if the image should be moved back to Wikipedia, instead of just deleting it if it is not fit for Commons.
I am watching a handful of high-risk images, and I have to restore some of them every month. It is starting to get ridiculous.
I don't know what we should do about this. It doesn't seem like the people who move images to Commons are learning.
At least the people that change from png images to svg images have now learnt to not delete the png version. (Often the png image is needed for the attribution path, or the svg image simply is ugly, or the svg image is not a correct substitute since the editor who made the svg image had no understanding of the subject.)
--David Göthberg (talk) 13:57, 11 April 2009 (UTC)

Is there an easy way to generate some sort of list from templates?

I'd like a list of articles that have a reporting mark in {{infobox rail}} or use {{reporting mark}}, along with the value of the parameter. (See CSX Transportation for an example of both, with reporting mark CSXT.) Is there any sort of bot or script that will do this? --NE2 17:59, 10 April 2009 (UTC)

The second one is easy: Special:WhatLinksHere/Template:Reporting mark. For the first one, one way would be to modify the template to put such articles in some category. —EncMstr (talk) 18:05, 10 April 2009 (UTC)
That wouldn't output the reporting mark though, which I believe is the end-goal here? –xeno (talk) 18:55, 10 April 2009 (UTC)
Yes, the goal is some sort of table with the article and reporting mark matched up. --NE2 19:46, 10 April 2009 (UTC)
You can at least achieve it partially in a pretty easy way. You can make it so the template categorises the pages into say Category:Wikipedia infobox rail reporting marks, and feeds the reporting mark as category sort order to the category name. For instance Caltrain has the reporting mark "JPBX". So in the article Caltrain the template should categorise like this:
[[Category:Wikipedia infobox rail reporting marks|JPBX, Caltrain]]
This won't show the whole reporting mark in the category, but at least all instances of JPBX will be sorted under "J" and they will be sorted next to each other, not mixed with other marks beginning with J.
We usually make such tracking categories hidden, so they won't bloat the category list at the bottom of the pages and so they won't confuse readers. If you need help with the code for such category handling I can point you to some good code examples. We often use this method when we want a template to report/log when it is used with faulty parameters, or when we want to find out which pages use a certain parameter. It is very useful when we are deprecating or renaming a parameter so we can fix any cases before we remove the parameter from a template. Note that it usually takes about 2 weeks before nearly all cases have arrived in the tracking category.
--David Göthberg (talk) 12:57, 11 April 2009 (UTC)
Unfortunately, that's not quite what I want. I know MediaWiki itself won't do it, but does anyone have a script or something that will? --NE2 17:22, 11 April 2009 (UTC)
If you need more than what the category system can offer, then the place to ask is over at Wikipedia:Bot requests. They are very friendly and helpful over there. It's the kind of place where I would like to tag on five stars in the upper right corner "for excellent service".
--David Göthberg (talk) 18:51, 11 April 2009 (UTC)

Making the "this is only a preview" message look like a proper editnotice

See proposal: essentially with a bit of CSS we can turn the preview bar into a proper editnotice like all the others we have. Comments appreciated over there. Happy‑melon 19:57, 10 April 2009 (UTC)

And get ignored like all the other editnotices? --Apoc2400 (talk) 19:26, 11 April 2009 (UTC)
I think this is a great idea, the current one is hard to see. I think while we are doing this we should add a temporary dismiss button to hide the edit notice once when it is clicked. This is because the edit notice screws with position: absolute; parameters making me save multiple times to align it correctly. Thanks -- penubag  (talk) 20:21, 11 April 2009 (UTC)

History tab external tools problem

Hello there. I seem not to be able to view the "For any version listed below, click on its date to view it. For more help, see Help:Page history and Help:Edit summary. External tools: Revision history statistics · Revision history search · Page view statistics" line in history pages. I think something might be blocking it in my JS or CSS, but can't for the life of me figure out what. Does anyone have any ideas? It Is Me Here t / c 09:50, 12 April 2009 (UTC)

Not sure what a CSS rule is doing on your JS page, but other than that, can't see any reason why it would be hiding it. Happy‑melon 10:12, 12 April 2009 (UTC)
You're right, clearing both pages didn't help - so why can't I see those external tools? It Is Me Here t / c 13:16, 12 April 2009 (UTC)

« ref » tags, templates & parameters.

« It appears that paramaters cannot be used inside the ref tags. ». Are we right ?

Budelberger (   ) 19:13, 12 April 2009 (UTC).

See Wikipedia:Footnotes#Known bugs for issues and workarounds. --Gadget850 (talk) 20:20, 12 April 2009 (UTC)
« Magnifical ! » (© Our Beloved Leader). Sank you véri mûtche, Gadget850 ; but see here : default parameters are not allowed ?… --Budelberger (   ) 21:46, 12 April 2009 (UTC).

Assigning category based on namespace

Guys and gals, I am having a heck of a morning. can anyone remind me how to use the parser functions to check namespace value to assign a category? Basically, IF Namespace = Template Then Category:Nav Templates

Got up too early, went to bed too late. Thanks for the help.

 Tigey   Talk   E-Mail  14:21, 6 April 2009 (UTC)

{{#ifeq:{{NAMESPACE}}|{{ns:Template}}|[[Category:Nav Templates]]}}
Amalthea 14:49, 6 April 2009 (UTC)
Or use one of our easy to use namespace detection templates such as {{template other}}. Or if you need more complex detection use {{namespace detect}}. For instance like this:
{{template other
| [[Category:Nav Templates]]
| <!-- Don't categorise when not in template space. -->
}}
Since the namespace detection templates have the "demospace" feature they can be much better to use than to hardcode the detection, since it makes it possible to test and demonstrate the different behaviours of your template in its own documentation.
--David Göthberg (talk) 15:10, 11 April 2009 (UTC)

Yeah but I think the bare parser function is more comprehensible to almost anyone. — CharlotteWebb 19:11, 13 April 2009 (UTC)

Recursion

Resolved.

The dev's seem to have broken recursion so now {{NextArchive}} doesn't work (a template I hacked together in my spare time; not widely used). See the template's wikitext for details on how it worked. Why doesn't that work anymore? I was thinking of extending it to {{FAC}}, but now I can't. I know it's a horrible hack, but if you don't like how my code looks, don't make me program in the equivalent of a COBOL/Pascal hybrid; give me sanity, or at least turing completeness. This type of check should be trivial, but now I can't see how to do it at all without writing a lot of boring code (like {{FAC}} is right now) and tying yourself to an arbitrary upper bound. --Thinboy00 @933, i.e. 21:23, 6 April 2009 (UTC)

This was deliberate, because these sorts of infinitely recursing templates were taking up ~40% of the CPU time of the entire Wikimedia cluster and also causing fatal OOM errors. If you want to discuss it, contact Domas Mituzas or Tim Starling on IRC.
Wikitext is not supposed to be a programming language, it's supposed to be a markup language. — Werdna • talk 04:04, 8 April 2009 (UTC)
Too late. I think it's Turing-complete these days. --Carnildo (talk) 08:31, 8 April 2009 (UTC)
Thinboy00: I have spent some day thinking about your problem. I think I now have a much more efficient solution for your {{NextArchive}} template and some other archive templates. But it is too complex to explain here. I will contact you when I have coded up those solutions. It might take some time, I am pretty busy, although this is the kind of programming I love to do. :))
--David Göthberg (talk) 14:41, 11 April 2009 (UTC)
Sounds like Fermat's last solution. Gimmetrow 15:50, 12 April 2009 (UTC)
Gimmetrow: Okay, you provoked me to disclose what I am going to do. But don't blame me if you get a headache from reading this:
As far as I know: The only way to find out how many archive pages a page has is to use the #ifexist parser function, since we must check if the archive pages exist or not. But #ifexist is a rather expensive operation since the server that parses the template has to call one of the database servers to check if the page exist or not.
But we don't need to check all the archive pages, we just need to find the last one. So I am going to use a binary search to find the last page. (But with some modifications so it works better in template code, and so we find low values faster.) Thus I can find the last archive page in the range 1-1000 with about 11 #ifexist calls. (WP:ANI already has 529 archive pages...) That is much more efficient than the approaches used now. If we need to check higher numbers I can do that too. I have already coded a binary search for another template that searches the range 0-500, so I know how to do it.
--David Göthberg (talk) 18:11, 12 April 2009 (UTC)
I thought of that, too. It just didn't seem necessary for my application, where the vast majority of searches involve less than 10 items. I figured, if it became necessary to handle more than 10, an increasing binary search tree could be used so that low numbers were found without too much penalty. Gimmetrow 20:41, 12 April 2009 (UTC)
Ah, "increasing binary search tree", good name for it. That is what I use in {{str len}}. Check out the documentation in {{str len/core}} if you are in the mood.
--David Göthberg (talk) 21:07, 12 April 2009 (UTC)
Just curious, but did you do any analysis to come up with the division used at str len/core? On finding archive pages, I thought perhaps this approach: test N, then 2N, then 4N, then 8N, then 16N, etc. to find bounds, then binary search within those bounds. N would depend on the expected distributions. If you did that with string lengths, you might use N=32. Gimmetrow 23:28, 12 April 2009 (UTC)
Since I am just about to create the {{number of archives}} template I have copied this discussion to Template talk:Number of archives and responded there. Please continue this discussion there. And a teaser: My user space prototype for {{number of archives}} already correctly reports that WP:ANI has 529 archive pages!
--David Göthberg (talk) 10:09, 13 April 2009 (UTC)

How to count number of editors that actually set date preferences?

Is there a way to count the number of editors that actually set date preferences?

I am sure that there is already a count of the number of registered editors. But it would be interesting to have a count of the number of editors that actually set a date preference. This would help inform the debate about autoformatting and the vote that is about to end at: Wikipedia:Date formatting and linking poll. We solve other variations such as 'color/colour' without needing markup. It would be useful to know the statistics on usage of this bizarre feature of Wikipedia to see if it is worth all the trouble. Lightmouse (talk) 10:00, 10 April 2009 (UTC)

You need to run a SQL query like
USING enwiki
SELECT COUNT(*) FROM user
WHERE LOCATE( 'date=default' , user_options ) == 0
On a complete copy of the enwiki user database table. Which is not replicated to the toolserver. So you'll need to ask the devs to do it. And there are about 9 million rows in that table. You might need to pester the devs for some time :D Happy‑melon 10:49, 10 April 2009 (UTC)
All date preferences, WMF wide, 20090321
      1 date=hh:mm d.m.yyyy
      1 date=12
      1 date=ISO dt
      1 date=vi longmonth
      1 date=9
      1 date=km
      1 date=hh:mm d mon y
      1 date=hijri
      1 date=vi spelloutmonth
      2 date=ÄŒSN basic td
      2 date=yue ymd
      2 date=hh:mm d. mon y.
      2 date=h:mm d month y
      2 date=ÄŒSN padded dt
      2 date=dmy short
      2 date=ÄŒSN padded td
      2 date=h:mm d mon y
      2 date=fy normal
      3 date=hh:mm dd.mm.yyyy
      3 date=yue dmy
      3 date=h:mm d. mon y.
      4 date=vi shorth
      5 date=ko
      5 date=dmy hr
      5 date=7
      6 date=yue
      6 date=PÄŒP dt
      6 date=tdmy
      6 date=hh:mm d month y
      6 date=h:mm d. month y.
      8 date=thai
      8 date=h:mm dd.mm.yyyy
     10 date=on
     14 date=vi shortcolon
     14 date=alt dmy
     14 date=short dmyt
     14 date=dmy full
     18 date=et numeric
     20 date=ja
     23 date=fi seconds
     28 date=vi normal
     34 date=persian
     37 date=dmyts
     55 date=ÄŒSN basic dt
     58 date=hh:mm d. month y.
     60 date=fi normal
     61 date=fi numeric
     68 date=dmyt
     92 date=zh
   1898 date=4
   2031 date=3
   4702 date=ymd
   5933 date=
  17876 date=ISO 8601
  44032 date=2
  47158 date=1
  72480 date=dmy
  84787 date=mdy
1723038 date=0
7242868 date=default
Lot of crap in there, which is why Werdna is rewriting the preferences system. --Splarka (rant) 07:15, 11 April 2009 (UTC)

Thanks. I am trying to translate that into statistics for the five date preference options. It looks to me like:

  • 7,242,868 have it set to the 'No preference' option
  • 84,787 have it set to the mdy option
  • 72,480 have it set to the dmy option
  • 4,702 have it set to the ymd option
  • 17,876 have it set to the ISO8601 option

Is that correct? Lightmouse (talk) 08:44, 11 April 2009 (UTC)

Well 7 million have left it on the "no preference" option. Other than that, yes, I think that's right. Happy‑melon 09:26, 11 April 2009 (UTC)

The phrase left it implies that they have never changed it. How do we know that users don't change it and then change it back? My phrase was have it set which is more neutral. I see that 'date=0' has 1.7 million users. So my second question relates to these 'date=n' values. Are 'date=0' editors also using 'No preference? Lightmouse (talk) 09:52, 11 April 2009 (UTC)

Oh sorry, I read it as "have set it", which is equally unsupported; your version is indeed the most neutral. I'll have a dig through MediaWiki, see if I can work out what the other values evaluate to. Happy‑melon 11:29, 11 April 2009 (UTC)
Tried and failed. What a mess! Good luck Werdna! Happy‑melon 11:48, 11 April 2009 (UTC)
0 is "default", 1 is "mdy", 2 is "dmy", and 3 is "ymd", at least in English (see $datePreferenceMigrationMap in MessagesEn.php). BTW, it seems that having these numeric codes means the account has not saved any changes to their preferences since 2006, or the preference would have been automatically updated to the more familiar string key. It seems most of the odd values originate from non-English message files; does uselang give you the other language's date options? Anomie⚔ 15:24, 11 April 2009 (UTC)
Thanks. That would make the figures:
  • 8,965,906 have it set to the 'No preference' option
  • 131,945 have it set to the dmy option
  • 116,512 have it set to the dmy option
  • 6,733 have it set to the ymd option
  • 19,774 have it set to the ISO8601 option
Using the 'date=x' figures and assuming that 'date=4' is ISO8601, it shows that 3.0% of editors have something other than 'No-preference' (the previous figure using post-2006 settings was 2.4%). Is that correct? Lightmouse (talk) 19:24, 12 April 2009 (UTC)

If those statistics are correct, it looks like 98% of registered editors have it set to 'No preference'. Lightmouse (talk) 11:56, 11 April 2009 (UTC)

How many of those 98% are indefinitely blocked (vandals, bad usernames, etc), vandals that abandoned the account upon receiving a final warning, abandoned SPAs, or other accounts that probably left all prefs at the default? Anomie⚔ 15:24, 11 April 2009 (UTC)

We don't have 48,312,721 "real" users. Under the current preferences system, all preferences are saved in the database at the default, so one cannot assume that the user specifically set that or even that they were aware that they could change it. Mr.Z-man 16:18, 11 April 2009 (UTC)

If setting a preference affects the likelihood of being inactive, that would be bizarre. But if you can get the statistics on that or any other factor, please post them. The debate has been long on opinion and short on statistical evidence. Lightmouse (talk) 16:51, 11 April 2009 (UTC)
Don't be obtuse. He's only saying that the most accounts have not been used in a meaningful sense, and that the presence of a default preference setting should not be interpreted as a preference not to set any preference. I don't suppose there's any way we could get statistics for "auto-confirmed" users (which by definition have at least ten edits). I think if you set a higher threshold for serious involvement with the project you'll find a lower rate of user-prefs apathy. — CharlotteWebb 17:20, 12 April 2009 (UTC)

I don't know what obtuse means, but it sounds like a bad thing. If you (CharlotteWebb) think I am a bad person, that doesn't matter. What matters to the community is evidence about how often autoformatting is used. It would help the debate if somebody could tell us all what 'date=0' and 'date=1' means. Statistics on autoconfirmed users would be interesting too, as CharlotteWebb suggests. The truth will set us all free. Lightmouse (talk) 17:49, 12 April 2009 (UTC)

Actually Lightmouse the current usage is irrelevant. If people want something we work on giving it to them, we don't assume bad faith and question their motives for wanting it... —Locke Cole • t • c 18:03, 12 April 2009 (UTC)
According to Nielson Online[3], wiki.riteme.site had 56 million unique visitors in April 2008. It appears that around 275 thousand users in the history of Wikipedia have set a date preference. It is unknown how many of these people are still active and log in when reading Wikipedia. (If you are not logged in, date autoformatting doesn't work.} The best case with these numbers is that 1 out of 200 readers benefits from date autoformatting. The Nielson survey shows most of Wikipedia readers arrive here via a search engine. When searching for information about the compulsive detective, Monk, I am sure the reader would remember to log in when they arrive at Wikipedia. -- SWTPC6800 (talk) 02:39, 13 April 2009 (UTC)
Probably they don't, but if they are using a personal computer they probably hit "Remember me" when they log in. --A. di M. (formerly Army1987) — Deeds, not words. 23:07, 13 April 2009 (UTC)

Cannot transfert image from Wikipedia to Commons

Hi!

I would like to use the image File:Bo Obama.jpg on the french Wikipedia but I cannot transfert the image to Commons because of an error message. First, I cannot create a TUSC account to use CommonsHelper, and of course, it's not possible to transfert the image without such account.

Anyone can help please? Could you transfert the image for me please?


Thank you very much,

-- Bestter Talk to me 20:03, 12 April 2009 (UTC)

It's there: Bo "the First Dog". – ukexpat (talk) 14:09, 13 April 2009 (UTC)
thanks! -- Bestter Talk to me 20:21, 13 April 2009 (UTC)

semi-registered IPs

I'm just full of ideas this week. sorry!

this is a comment I made a few months back on Wikipedia_talk:Vandalism#Ease_of_Use_Vinegar. there's a potential advantage in keeping track of the number of sound edits an IP user makes. if IPs that make a certain number of constructive edits (say 50 or so) could be noticed as semi-registered (i.e., regular and beneficial contributors who just haven't bothered to actually register, or regular users doing the wiki-gnome thing), it might help focus anti-vandalism efforts. I think most anti-vandal bots check user contribs already as part of their algorithm, and most good vandal patrollers will check an IP's contribs before reverting something borderline; this would just formalize it by having a defined status of 'trusted ip' (which might in itself be a nice little perk to encourage good-editor IPs) . the only potential risk would be the random event that some trusted IP moved, and the IP was reassigned to someone inclined towards vandalism.

basically, the idea is 'if IP x-x-x-x makes Y many good edits, then we don't have to worry about it, and we can watch other IPs more closely". would that kind of thing be worth the overhead? --Ludwigs2 06:20, 13 April 2009 (UTC)

While we're at it, why don't we also keep different levels of autoconfirmed? After all, it's quite easy to make a few edits to the sandbox or a user subpage and wait a few days and be autoconfirmed. There also should be a sysop tool marking users as confirmed (without auto), which means they have been putting good constructive edits on WP. Maybe one more level for people who have done major edits. ManishEarthTalk • Stalk 11:02, 13 April 2009 (UTC)

Special:Import

I'm just curious why Importing is disabled? For bringing over translated articles, shouldn't we be importing the history for GFDL, the way the Germans do it? (I was quite surprised to see I had done a number of rollbacks on de.wiki, until I realized they import history of our pages [4] [5]). –xeno (talk) 19:01, 13 April 2009 (UTC)

Each wiki we want to import from has to be defined individually in a list... which of the 750 WMF wikis are we likely to import from? It's easier for other languages: we're the biggest, they're usually importing from us. It's harder for us to know which wikis we might want to import from, and the list is too long to simply put them all in; it would make Special:Import unusable. Happy‑melon 19:06, 13 April 2009 (UTC)
Hmmm... Just the most popular ones I guess? Rather than using Category:Interwiki translation templates in the mainspace. –xeno (talk) 19:10, 13 April 2009 (UTC)
The largest is dewiki. The one causing a current ripple apparently is fr-wiki. Is there a a importer user-class? Agathoclea (talk) 20:28, 13 April 2009 (UTC)
Yes, 'transwiki' Currently, however, it can only be granted by stewards. Happy‑melon 20:39, 13 April 2009 (UTC)
Where would we go to get a) some importers and b) get admins/bureaucrats to give those permissions. Agathoclea (talk) 20:48, 13 April 2009 (UTC)
Both are simple site requests to make to the devs. Just establish a local consensus that they're a Good Idea, and post them off to bugzilla. Happy‑melon 21:42, 13 April 2009 (UTC)
On occasion I've seen people wish to import from Meta and other "working" projects. Majorly talk 21:44, 13 April 2009 (UTC)
I could see this being useful if enabled. –Juliancolton | Talk 21:46, 13 April 2009 (UTC)

"View logs for this page" link missing for Main Page

The "View logs for this page" link seems to be missing for the Main Page. Is this a bug or is it intentional? --Ixfd64 (talk) 03:05, 14 April 2009 (UTC)

It's caused by the hiding of #contentSub at MediaWiki:Monobook.css. --- RockMFR 06:01, 14 April 2009 (UTC)
It behaves normally (not hidden) in the Modern skin. Kusma (talk) 06:12, 14 April 2009 (UTC)

Edit summary when edit the lead section

No matter which section is edited, the section name is automatically appeared in the edit summary, except lead section. I suggest that the edit summary should indicate "lead section" as other sections. This little change can help to make it easier to follow the edit history, like find out whether an edit is or is not related a particular section. Some other Wikipedia has already done so. --Quest for Truth (talk) 19:22, 11 April 2009 (UTC)

I agree - that would be useful. Then edits of the whole page would be more easily distinguishable from edits to the lede only.Tvoz/talk 19:52, 11 April 2009 (UTC)
I think that would be a worthy idea. It would certainly make it less difficult to follow the edit history of an article. tempodivalse [☎] 19:58, 11 April 2009 (UTC)
If you don't mind too much about the section name that appears in the edit summary, this can be done easily by adding "summary=/* firstHeading */ " to the section edit link, like this one.
I assume you use the editTop gadget? --Amalthea 20:52, 11 April 2009 (UTC)
Where is it supposed to link to? — Edokter • Talk • 22:51, 11 April 2009 (UTC)
To the <h1 id="firstHeading"> with the page title: #firstHeading. Another option is #top. The problem is, older skins such as "Classic" do not have these IDs in the HTML. —AlexSm 23:30, 11 April 2009 (UTC)
It can simply link to the article without anchor. This will always load the top of the page where the lead section is found. --Quest for Truth (talk) 10:29, 12 April 2009 (UTC)
It can even be text only as well! It is more important that the edit summary indicates only the lead section is edited. Where it links to is a rather not so important issue. --Quest for Truth (talk) 00:11, 14 April 2009 (UTC)

I really don't see the point in this. Those who take edit summaries seriously might consider the possibility that pre-filled comments like "/* In popular culture */" actively discourage attempts to "briefly describe the changes [they've] made" (assuming it is possible to actually do so). I think this also tends to confuse new users. Many times I've seen silliness like

(→added 2 paragraphs about homestar runner)

in recentchanges or on my watchlist because somebody has gotten the false impression that the edit summary is supposed to go between the slashes and asterisks. But hey as long as we're mucking around with this feature we should darken the light-gray color to make it more readable against a white background. — CharlotteWebb 17:56, 14 April 2009 (UTC)

Categories reporting wrong number of members

Category:Redirect-Class AFC articles reports itself having 1536 members, although looking through the entries there are only 1320. That is the same number that one finds after compiling a list of category members using AWB. Anyone know why the page would report the wrong number of member pages? Someguy1221 (talk) 06:45, 13 April 2009 (UTC)

1320 does seem to be the correct number, as there are 6 full pages of 200 plus another 120. Just an idea, I don't suppose it would be double-counting pages which have been added to the category twice, or something weird like that? — Martin (MSGJ · talk) 07:19, 13 April 2009 (UTC)
I'll just note that 1536 is also (naturally) the number returned by the PAGESINCAT magic word. Someguy1221 (talk) 07:46, 13 April 2009 (UTC)
There was until recently a software bug where pages that were deleted were not subtracted from the category counts. That bug has now been fixed, but the numbers remain incorrect by the same amount they were when the fix was scapped. There is a maintenance script that needs to be run, but with enwiki having several million categories even running a maintenance script is a matter requiring some planning and thought. Happy‑melon 09:42, 13 April 2009 (UTC)
Would depopulating and repopulating the category help at all? If not, is there anything that we can do? — Martin (MSGJ · talk) 10:40, 14 April 2009 (UTC)
The only way is to undelete and redelete the pages that were in the category... assuming you can find them. Happy‑melon 11:39, 14 April 2009 (UTC)
I would have no idea how to find them! But I would be quite interested to find out what had happened to all of them. — Martin (MSGJ · talk) 11:49, 14 April 2009 (UTC)

dumb question: editing notifications?

Resolved
 – ukexpat (talk) 14:56, 14 April 2009 (UTC)

Some pages have a banner that appears when users try to edit them. For example, User:Jimbo Wales has a banner that says "You may edit this page!" above the edit box. Does anyone know how to edit such messages? Special:AllMessages doesn't seem to give any information. --Ixfd64 (talk) 04:02, 14 April 2009 (UTC)

WP:EDITNOTICE. – ukexpat (talk) 04:08, 14 April 2009 (UTC)
Thanks! --Ixfd64 (talk) 05:19, 14 April 2009 (UTC)

interwiki template usage

is there any way to transclude a template across wikis? For example, if I have made a template on meta or enwiki, and I want to use it on the other wikis like wikt:, s:, v:, etc (and maybe even other language wikis), do i have to make the template again on every wiki or or is there a way to use it directly? ManishEarthTalk • Stalk 05:55, 14 April 2009 (UTC)

No. Among other issues, the various wikis use different implementations of CSS and JS; many templates depend on these. --Gadget850 (talk) 09:24, 14 April 2009 (UTC)
Is mw:Manual:$wgEnableScaryTranscluding disabled on all Wikimedia wikis? PrimeHunter (talk) 10:01, 14 April 2009 (UTC)
Yes. Happy‑melon 11:39, 14 April 2009 (UTC)

Notes page?

you know, I'm going to throw this idea out there, because it's something I keep finding myself missing. would it be possible to make a special page (like the watchlist) dedicated to making notes to yourself? I'm thinking a tab or link (like the 'watch' tab) that you can click on to add a given page to your notes page, and then on the notes page itself, have a link to each page with some space to leave notes (maybe have the links constructed as section headers, or something like that). of course, I could build something like that on a user subpage, but that's got two drawbacks that have kept me from doing it so far: (a) it's a pain to set up and maintain, and (b) it would be public, and I'm not sure I want the dumb things I'm mulling over available for everyone to read. thoughts? --Ludwigs2 00:06, 12 April 2009 (UTC)

bugzilla:541#c2 --Splarka (rant) 07:33, 12 April 2009 (UTC)
B: Having a secret subpage like that could be abused in many ways. (Note: Don't confuse this with what we usually mean by "secret user subpage" = subpages in user space that are not linked from anywhere.) And I see in the bugzilla request that Splarka linked too that Brion said "NO". I think an acceptable solution perhaps could be if such a subpage were only visible for all logged in users. Thus it at least would not be visible for the search engines and the Wikipedia readers.
A: The "one click bookmarking" functionality can be coded in javascript as a user script. So I went looking, and there already exist two such readymade scripts! See User:Twinzor/Wikimark and user:js/popupBookmarks. I have not tested any of them, so I don't know how well they work, but they look promising.
Personally I use a text file on my hard disk for my Wikipedia notes and to-do list. And more "permanent" bookmarks I manually add to my user page. But I only edit Wikipedia from home. But I know many Wikipedia editors are more nomadic so I can see the need for an easy to use bookmarks+notes page.
--David Göthberg (talk) 12:52, 12 April 2009 (UTC)
lol - I see that issue produces some strong feelings. I hadn't actually thought about the javascript solution, but those look interesting. I'll check them out. and your 'logged in user' idea might work, though I'm still not sure I'd want my off-the-cuff thoughts enshrined forever in a public edit history. but if I could just make a decent bookmark list, that would be a good start. thanks. --Ludwigs2 16:22, 12 April 2009 (UTC)

This matter is also being discussed on the proposals page under 'favourites section' JRGregory (talk) 23:23, 15 April 2009 (UTC)

History pages taking forever to load with javascript enabled

Resolved.

I know this isn't the Firefox help desk, but has anyone else experienced any issues with history pages taking forever to load in FF3.0.8 (Win) ? With javascript disabled, it works fine, but when enabled it takes anywhere from 30 seconds to a minute to load the history page. –xeno (talk) 03:49, 12 April 2009 (UTC)

Does this happen on other WM projects, other MediaWiki installs, or when logged out? Lets narrow it down. --Splarka (rant) 07:35, 12 April 2009 (UTC)
Unfortunately this doesn't narrow it down at all, but I have a possibly related problem with history pages for exactly the same configuration (+ many installed extensions). History pages generally load OK, but twice during the last 24 hours a history page froze my browser so that I had to restart it. And it seems I am not the only one, see WP:ANI#Technical Problem? and WP:Help desk#Firefox freezing on page histories. --Hans Adler (talk) 13:37, 12 April 2009 (UTC), extended 16:12, 12 April 2009 (UTC).
Seems to only occur on Wikipedia, doesn't matter logged in or out, but it seems to be when looking for 250 or more revisions of history. Chrome and IE are fine... Pulling my hair out! I've emptied my monobooks and turned off all gadgets and still no joy. –xeno (talk) 14:37, 12 April 2009 (UTC)
After a night of rest, it seems that history pages are now loading (quite quickly in fact) for me. Looks like whatever problem was going on, has been fixed. - NeutralHomer • Talk • April 12, 2009 @ 17:20
Still no luck for me. If and when the pages load fast, they kind of hang for about 30-45 seconds before allowing me to scroll or click on anything. Limiting myself to 50 or 100 revisions is my temporary workaround but I wish I knew what was causing this. –xeno (talk) 17:24, 12 April 2009 (UTC)
I too have had the same problem today, and it happened on both Firefox and IE7 (ah the joys of two browsers...); the page history was about 1000 edits though, so not sure if that had anything to do with it. It temporarily froze my browser, but when I came back after about 15 minutes, the page history had loaded and I was able to use it. Risker (talk) 20:40, 12 April 2009 (UTC)

There was a similar issue with JS on page history a few months ago on the Polish Wikipedia, bug 17240. Mr.Z-man 20:56, 12 April 2009 (UTC)

It's still happening for me as of right now, Firefox. Who then was a gentleman? (talk) 22:28, 12 April 2009 (UTC)

  • Seems I spoke too soon above, it is back at it again. Same as everyone else, Firefox. *sigh* - NeutralHomer • Talk • April 12, 2009 @ 22:35
I tried IE8 and it's happening there, too. Who then was a gentleman? (talk) 23:15, 12 April 2009 (UTC)

The bug report has a workaround: Adding the line

removeHandler(window, 'load', histrowinit);

to your monobook.js. It breaks the extension that provides an "Only new" button in my watchlist. Since there is no sure way to reproduce the bug, I cannot absolutely confirm that the workaround works. --Hans Adler (talk) 23:24, 12 April 2009 (UTC) As I just found out, the workaround also disables the script that asks for rollback comments. --Hans Adler (talk) 23:30, 12 April 2009 (UTC)

Many thanks for the workaround! ... I can wiki again without wanting to shoot my computer. Unfortunately, I did all kinds of local troubleshooting before I came here, including deleting all my saved passwords and forms, but c'est la vie. –xeno (talk) 03:03, 13 April 2009 (UTC)
A better workaround is probably to set your Wikipedia "My preferences" - "Recent changes" - "Number of edits to show ..." to something lower than 250. Who needs to see 250 revisions at the same time anyway?
It "hangs" for me too on history pages when clicking to view 250 revisions. That is, it takes some minutes. I am not entirely sure I could handle such long history lists before, but I think I have used it occasionally. I still have my preference set to the default 50 revisions, since I don't need more and I have such a slow computer. I use Firefox 2.0 on WinME on a very old computer.
--David Göthberg (talk) 16:25, 13 April 2009 (UTC)
500 revisions makes it far easier to search within the history without having to click "older","older","older" all the time. Until recently I had no problem at all loading that many revisions. –xeno (talk) 16:36, 13 April 2009 (UTC)
I agree entirely. I often look at 500 at a time. Saying that, I don't seem to have the problem right now at least. But I usualy use Chrome (which breaks some Unicode so I have to be careful). Dougweller (talk) 18:03, 13 April 2009 (UTC)

Doing a hard refresh should fix the problem. Caused by a change at MediaWiki:Common.css. --- RockMFR 19:20, 13 April 2009 (UTC)

Yes, I disabled the workaround and it's working fine without it now. Thanks. Now I must find a rather large trout... –xeno (talk) 19:26, 13 April 2009 (UTC)
RockMFR found the problem and fixed it. The technical details are discussed here.
Important: Many of you will need to bypass your browser cache to get the fix. (Since the fix is in a CSS page and the Wikipedia CSS pages are cached in the browsers for up to 31 days.)
--David Göthberg (talk) 13:27, 15 April 2009 (UTC)

Subpage feature

The MediaWiki subpage feature is enabled for most talkspaces. But it is disabled in the "Category talk" and "Help talk" namespaces. I think that is an omission that needs to be fixed. Among other things this makes it hard to do talk page archiving for category talk and help talk pages. I also think that subpages should be enabled for the "Help" namespace.

Background and details:

I found an old report from a user that some of the talk page archiving templates don't work on category talk pages. I investigated and discovered that the reason is that the MediaWiki subpage feature is disabled on category talk pages. This means that magic words like {{BASEPAGENAME}} and {{SUBPAGENAME}} don't work as you expect, and relative paths like [[../Archive 1]] doesn't work at all on those pages. It also means that there is no small backlink to the basepage in the upper left corner of the subpage.

I can work around this problem with some fancy template programming, but I rather have the problem itself fixed. I see no reason why the subpage feature should be disabled in those talk spaces, and I don't think it will break anything if we enable subpages there.

I have checked some other language versions of Wikipedia, and they do have subpages enabled for all talk spaces. Also, they have subpages enabled for the "Help" namespace, which we don't have.

I know this is a simple setting in MediaWiki. My guess is that our sysadmins simply forgot to enable it for those talk spaces and for the Help namespace.

For reference, here is the full list of the talk spaces:

Subpages disabled: Help talk, Category talk

Subpages enabled: Talk, User talk, Wikipedia talk, File talk, MediaWiki talk, Template talk, Portal talk

And the subject spaces:

Subpages disabled: main/article, File, MediaWiki, Help, Category

Subpages enabled: User, Wikipedia, Template, Portal

--David Göthberg (talk) 12:06, 12 April 2009 (UTC)

From the Wikimedia configuration files, subpages should be enabled in all namespaces except 0, 6, 8, 12 and 14; that is, all except article/main, File, MediaWiki, Help and Category. Subpages not appearing in the Help talk and Category talk namespaces is a bug, as they are explicitly enabled in config. I agree that they should be enabled in the Help namespace, as has been done on numerous other wikis. Happy‑melon 12:36, 12 April 2009 (UTC)
Well, in that settings file you linked to: Right below the default subpage settings there are some arrays which seems to be overrides for some projects. In the override array for enwiki the namespaces 12-15 are not listed, which I guess defaults to "false" = "no subpages". Thus Help, Help talk, Category and Category talk don't get subpages, no matter what the defaults say. So it seems we have located the exact place where this mistake was done.
Those arrays need to be fixed. And the code that uses those arrays should ideally be fixed so it falls back to the defaults for items that are not in the array, although that might be too tricky to be worth the trouble.
I see that the arrays for some of the other projects probably also need to be fixed.
So I guess this should be reported to Bugzilla? Can any of you guys who are used to Bugzilla file a bug report on this?
--David Göthberg (talk) 13:25, 12 April 2009 (UTC)
I just did (T20437); well spotted on the source. I'll update the bug with the exact problem and its fix. Happy‑melon 15:12, 12 April 2009 (UTC)
Updated. Happy‑melon 15:26, 12 April 2009 (UTC)
I see that Andrew Garrett (which I guess is User:Werdna) closed the bug as "invalid". He said:
"If you want subpages in these namespaces, you're going to have to check that nobody minds, and then post a site request."
And then he said:
"I don't think anybody expects a full-blown vote on such a trivial matter, just a general note somewhere prominent that the behaviour will be changing, and a check to see if anybody objects, as with most configuration changes."
He doesn't seem to understand that the MediaWiki default is to have subpages in the Help talk and Category talk namespaces. And that the way those override arrays were added is buggy. Anyway, I guess we can do some announcing and then post a "site request". (Does anyone know what a "site request" is and how it is done?) Since we want to enable subpages in the "Help:" namespace too, I will try to get a watchlist notice or so pointing to here. See the next two sections.
--David Göthberg (talk) 17:26, 12 April 2009 (UTC)
Yes, it's just a particular category of bug reports. What 'bugs' me about his close is that he could just as easily turned the bug into a site request, rather than just shooting it and moving on. Happy‑melon 18:50, 12 April 2009 (UTC)
I did a search in Bugzilla and found this old but related T3467. It seems to be about when they extended the default that Help talk, Category talk have subpages. But as mentioned before, the default is overridden for some projects, like enwiki.
--David Göthberg (talk) 22:36, 12 April 2009 (UTC)
Would pages in the namespaces in question that currently have a slash in the title then automagically become subpages? Example: Help talk:Table/Archive 1. --Gadget850 (talk) 13:11, 13 April 2009 (UTC)
Yes. There isn't a "subpage flag" for individual pages, the namespace flag just changes how slashes in a title are interpreted. I've created a list of the pages that would be affected here. Anomie⚔ 13:33, 13 April 2009 (UTC)
This will of course result in the slight oddity that Category talk:AC/DC in its upper left corner automatically will get a small link to Category talk:AC. (Oops, that's a red link, not sure if the link will be shown then.) But that is the same oddity that we already have in other places, such as that Talk:AC/DC in its upper left corner has a link to Talk:AC.
But in most case we want that link, since for instance Category talk:Articles to be merged/Archive 1 should link back to Category talk:Articles to be merged. And we need the magic word {{SUBPAGENAME}} to return "Archive 1" for that subpage. Currently that magic word instead returns the entire page name "Articles to be merged/Archive 1".
--David Göthberg (talk) 14:22, 13 April 2009 (UTC)
You would have had me at "yes", but as a tech support engineer, I'm always happy with a full explanation. --Gadget850 (talk) 14:30, 13 April 2009 (UTC)

Is there any particular reason why subpages of categories are not a good idea? I know that I came across some unexpected behaviour when we were setting up categories for WPAFC (for example Category:AfC submissions by date/14 April 2009), but I recall getting around the problem somehow (maybe by using the titleparts parser function). — Martin (MSGJ · talk) 10:47, 14 April 2009 (UTC)

I suspect there might be trouble; the category pages are constructed from two different tables: the editable page content comes from the page table like any other page, but the category memberlists come from the categorylinks table. If the code for one recognises subpages but the other doesn't, it could get messy. It might work, it's worth asking. Happy‑melon 10:52, 14 April 2009 (UTC)

I'm going to repost these as site requests now. Happy‑melon 10:52, 14 April 2009 (UTC)

T20459 Happy‑melon 10:57, 14 April 2009 (UTC)

So what do we do with the old T20437 ? I had already reopened that bug. I guess we should link from that bug to the new bug in some way, right? And what do we do then, vote for the bugs so they get attention or who do we poke?
--David Göthberg (talk) 17:13, 15 April 2009 (UTC)

Subpages in Help talk and Category talk

Per discussion in the section Subpage feature above, we want to enable the subpage feature in the "Help talk" and "Category talk" namespaces. We think it is just a bug that needs fixing, since all talk spaces are supposed to allow subpages. Among other things we need subpages for archiving of talk pages.

If anyone has any comments to this, please add them here.

--David Göthberg (talk) 17:26, 12 April 2009 (UTC)

Subpages in Help

Per discussion in the section Subpage feature above, we want to enable the subpage feature in the "Help:" namespace. The reason being that subpages are often useful, and we only have disabled subpages in the namespaces where it causes problems. If anyone knows any problems this might cause, please tell us.

If anyone has any comments to this, please add them here.

--David Göthberg (talk) 17:26, 12 April 2009 (UTC)

Hanging in firefox

Has anyone else noticed firefox hanging on Wikipedia pages? I'm trying to work out if it is something to do with wikipedia or with the no script extension for firefox. Anyone got any clues as to whether the java for Wikipedia has altered recently? If that hasn't I guess it's something introduced in the last couple of no script updates. Hiding T 15:00, 13 April 2009 (UTC)

Hmmm. It's not noscript, but it is definitely something to do with the java on wikipedia or wikimedia or somewhere, and how firefox is dealing with it, as far as I can make out. I disabled no script and still got the hanging. I enabled no script and removed all wikipedia and wikimedia whitelistings, and got no hanging. Any thoughts? Firefox seems to hang and chew cpu for a good couple of minutes before loading a page. Hiding T 15:05, 13 April 2009 (UTC)
Everything works fine for me.See comment below. I am using Firefox 2.0, on WinME on a very old computer, and I have javascript enabled and I run a number of user scripts too. What Firefox version are you running? On what OS?
--David Göthberg (talk) 15:41, 13 April 2009 (UTC)
I'm getting the exact same symptoms - started maybe 4 or 5 days ago? firefox 3.0.8 on windows Vista. Nancy talk 15:43, 13 April 2009 (UTC)
Is it only on (long) history pages? See above at #History pages taking forever to load with javascript enabled, there is a workaround:
removeHandler(window, 'load', histrowinit);
(added to your skin page) as for the actual problem itself, I don't think anyone has filed a bugzilla for en.wiki yet; not sure if it can just be tacked on to the existing bugzilla:17240. –xeno (talk) 15:47, 13 April 2009 (UTC)
For me, the issue isn't limited to such pages. —David Levy 15:52, 13 April 2009 (UTC)
Yes, for me as far as I can recall it is history pages, I'll give your fix a whirl, thanks! Nancy talk 15:55, 13 April 2009 (UTC)
Wow, I'm experiencing the same issue (which I assumed was due to a problem on my end). Last night, I had a page hang for several minutes (right before I was to save my edits), and I didn't even have many tabs open.
I'm running Firefox 3.0.8 in Windows 7 (beta). —David Levy 15:52, 13 April 2009 (UTC)
"Hangs" for me too on history pages when clicking to view 250 revisions. That is, it takes some minutes. But I am not sure I could handle such long history lists before, since I have my preference set to view 50 revisions a time since I don't need more and I have such a slow computer.
--David Göthberg (talk) 16:09, 13 April 2009 (UTC)
  • Wow, I'm glad I posted. Not sure how to thread this though. I'm running 3.08 on Vista, and yes, it's been the last four or five days. I'll try that workaround, but I think it's any page as opposed to history pages. I'll keep an eye on it. At the minute I've revoked javascript permissions as the only work around. I'll try this workaround, enable javascript permissions, reduce history pages to 50 contribs and let you know. Hiding T 16:46, 13 April 2009 (UTC)
    Using the removeHandler workaround, there is no need to limit yourself to 50 revisions. –xeno (talk) 16:49, 13 April 2009 (UTC)
    I think I've added the code correctly, see [6], but I'm still seeing firefox hang when java is enabled and contribs are at 500. I'm going to cut history pages back to 50 contribs again. What's the next step? Hiding T 10:43, 14 April 2009 (UTC)
    Did you forget to use Shift-Reload? Anyway, after this change (and another Shift-Reload!) the problem should really be fixed now. --Hans Adler (talk) 10:52, 14 April 2009 (UTC)
    I usually just close and restart the browser. But I've removed the code from my js and it seems ok fingers crossed. Ta. Hiding T 22:56, 14 April 2009 (UTC)

In case this helps, I've had no problems. I use FF 3.0.8 on Win XP SP3. My add-ons are AVG Safe Search 8.0, AVG Security Toolbar (disabled), Greasemonkey 0.8.2nnnnnn and Java Quickstarter 1.0. I've had a dozen tabs open for the last couple of weeks (using the "restore last session" option). --Philcha (talk) 17:25, 13 April 2009 (UTC)

Do you view 500 revisions worth of history at a time? –xeno (talk) 17:26, 13 April 2009 (UTC)
Quite often, especially if I see a lot of reverted vandalism, so 2/3 of the history is not real changes. Also on categories & "what links here", when I use them. --Philcha (talk) 12:15, 14 April 2009 (UTC)
  • Update: Still hanging, it's not just history pages it's pages in general, Firefox is having trouble responding quickly. I'm baffled by this, any ideas? Hiding T 10:20, 15 April 2009 (UTC)
    That sounds like the unrelated problem that I have most of the time. Often clicking the same link several times seems to help a bit. I am in the UK, and it was particularly bad during the Virgin Killer censorship. Then it was OK for a while, with some problematic periods. The problem has been consistently present (although not as bad as before) since around the time when IP data retention started. Therefore I guess it's related to such censorship/privacy intrusion mechanisms. --Hans Adler (talk) 10:48, 15 April 2009 (UTC)
    That's a possibility. I've revoked java permissions for the toolserver and wikimedia, and that seems to have helped though. Hiding T 12:39, 15 April 2009 (UTC)
RockMFR found the problem and fixed it. At least he fixed the problem that caused Firefox to hang for some minutes when trying to load a history list that is 500 long. It also hanged for a shorter time for history lists of 100 items. The technical details are discussed here.
Important: Many of you will need to bypass your browser cache to get the fix. (Since the fix is in a CSS page and the Wikipedia CSS pages are cached in the browsers for up to 31 days.)
--David Göthberg (talk) 13:38, 15 April 2009 (UTC)

I'm looking for a way to have links to disambig pages in an article get a different font. That way as I'm reading through an article I can spot links that need updating while I'm familiar with the context and correct it. Is this possible? Vicarious (talk) 00:23, 15 April 2009 (UTC)

I'd be surprised if there is a way to do that, but check out WP:POPUPS: you can hover over a suspected link to see what the beginning of the linked article looks like. —EncMstr (talk) 00:41, 15 April 2009 (UTC)
User:Splarka/dabfinder.js adds a link to the toolbox to find disambiguation links on the page. Mr.Z-man 04:24, 15 April 2009 (UTC)
As for fixing link to disambigs, there are also some tools listed on WP:WikiProject_Disambiguation/fixer, and there is a tool at tools:~jason/disambigs_in_an_article.php. —AlexSm 04:35, 15 April 2009 (UTC)
I appreciate the prompt response and advice from all of you. EncMstr, I've fiddled with POPUPS before but having to hover over every link is more than I'd like to do. AlexSm, I checked out the tool and it certainly has it's uses, however in my natural reading of articles (a common event) it wouldn't help, and I'd find it cumbersome to go to the tool for each article I read. Mr.Z-man, your suggestion seems to be closest to what I'm looking for, although I find the documentation somewhat lacking. I tried adding it to my monobook (and clearing my cache) but didn't notice a change. Although, perhaps I'm at fault for a lack of comprehension, and perhaps I should be asking elsewhere for it. Vicarious (talk) 05:29, 15 April 2009 (UTC)
Well, first of all, you should blank User:Vicarious/monobook.css, none of that is css. Then you should undo this and simply use importScript('User:Splarka/dabfinder.js');. Then you should go to an article page (like via Special:Random), purge your browser cache of the site (ctrl-shift-reload or whatever) and click the "Find disambiguations" link showing in the toolbox. There isn't much documentation because there are only two things to do, click that or click the similar redirect hilighter (and it is a somewhat advanced tool). --Splarka (rant) 07:18, 15 April 2009 (UTC)

User:Anomie/linkclassifier.js looks to be what you want. The stylesheet I use with it underlines redirects and makes dab pages the colour of 'stub links' (which I have disabled). Subtle and unobtrusive, but effective. Happy‑melon 10:00, 15 April 2009 (UTC)

Inadvertent garbage

Both my edits today have added garbage at the end of the section I have been editing: [7] and [8]. Text seems to align in some way with qLauncher toolbar items. Restarting Firefox 3.0.8 and deleting qLauncher made no difference but disabling Smarter Fox 1.2.2 has (I hope) removed the problem. Thincat (talk) 14:59, 15 April 2009 (UTC)

Is today April Fools somewhere?

Resolved
Everything is backwards. It is hard to edit.

I was just trying to add commentary to the Reference Desk, and in the edit-text window everything is backwards at the bottom of the window. (This appeared when there was an edit conflict and the whole page was in the edit-text field; and I also saw it after clicking "edit page" for the whole page. Didn't appear when editing a section.) Tempshill (talk) 16:41, 15 April 2009 (UTC)

Should be fixed now. --- RockMFR 16:53, 15 April 2009 (UTC)
Reminds me of my attempts to usurp xeno on the Hebrew Wikiquote. –xeno (talk) 16:57, 15 April 2009 (UTC)
I hate doing any interwiki work on the Arabic, Persian, or Hebrew wikis for that very reason. RTL screws with my head every time. EVula // talk // ☯ // 17:04, 15 April 2009 (UTC)

Display at image from Commons.

Greetings. File:Homopholis fasciata1.JPG here on en.wiki is not the same image as Commons:File:Homopholis fasciata1.JPG on Commons. (The one here is a cropped version.) I'd like to be able to display the Commons version of the image. Is there a way to do this? [[Commons:File:Homopholis fasciata1.JPG]] creates a link, just as if I'd said [[:Commons:File:Homopholis fasciata1.JPG]].

(My reasoning is, I want to use a bot to create a list of these images, showing them side by side, so I can visually see if they look the same. But I can't seem to do this with Wikisyntax, unless there a method I don't know about.) – Quadell (talk) 19:09, 15 April 2009 (UTC)

Since both the full and the cropped version have been properly transferred to commons I just deleted (WP:CSD#F8) the local version (and changed the one link to it so that it points to commons:File:Homopholis fasciata1 cropped.JPG). To my knowledge there is no way to show a commons image that is obscured by a local image. --Amalthea 19:52, 15 April 2009 (UTC)
ETA: I thought I had changed the link, but RockMFR beat me to it. :) --Amalthea 20:01, 15 April 2009 (UTC)

automatic deletion summaries - again

A few weeks ago, I was asking about the disappearance of automatic deletion summaries. I think I now know the cause. It seems when this edit to MediaWiki:Sysop.js was made to introduce some new code, it also removed the old code that generated automatic deletion summaries in the process. Is there a way to bring this "feature" back? Unfortunately, I am unable to do this myself since I suck at JavaScript/CSS coding, and there's probably a 99.99% chance I would mess something up if I tried anything. --Ixfd64 (talk) 02:03, 12 April 2009 (UTC)

"content was ..."/"only contributor was ..." default deletion summaries have been disabled, as it's never an appropriate rationale for deletion and was highly problematic for attack pages, etc. The discussion for removal is here, disabling this caused some side effects, but since then, it's been resolved. Cenarium (talk) 02:25, 12 April 2009 (UTC)
Ah, I guess that explains everything. Thanks for the information! --Ixfd64 (talk) 03:29, 12 April 2009 (UTC)

If you or anybody else really wants this and plans to use it I think I know how to make a javascript gadget to mimic the old behavior. — CharlotteWebb 17:05, 12 April 2009 (UTC)

Sure, that would be great. Maybe someone could make a user script or something. :) --Ixfd64 (talk) 21:00, 12 April 2009 (UTC)

Ew, a script to undo a script. — Werdna • talk 05:05, 13 April 2009 (UTC)

Well, since the first statement in the section was incorrect (the change was done by blanking system messages, not by the Sysop.js), the new would-be script would try to reproduce MediaWiki functionality. Or it could be even better, e.g. adding the number of deleted revisions. —AlexSm 17:56, 13 April 2009 (UTC)
It would be much better to put the number of revisions deleted or undeleted in a separate field of the logging table rather than making it part of the edit summary. — CharlotteWebb 13:28, 16 April 2009 (UTC)
beware of code 
s1 = "content was: '$1'"; s2 = "content before blanking was: '$1'";
s3 = " (and the only contributor was \"[[Special:Contributions/$2|$2]]\")";
function bytes(s){ return encodeURIComponent(s).replace(/\%[0-9A-F]{2}/gi, '_').length; }
function contentwas(){
  if(wgAction!="delete" || !(field = document.getElementById("wpReason"))) return;
  x = new XMLHttpRequest();
  x.open("GET", wgServer + "/w/api.php?action=query&format=xml&prop=revisions&rvprop=user|content&rvlimit=25&titles=" + wgPageName, true);
  x.onreadystatechange = function() {
    if(x.readyState != 4) return; z = new DOMParser().parseFromString(x.responseText,"text/xml");
    rev = z.getElementsByTagName("rev"); content = "";
    if(rev[0].childNodes.length) { content = rev[0].childNodes[0].nodeValue; s = s1; }
    else { s = s2; for(i = 1; i < rev.length && !content.length; i++)
      if(rev[i].childNodes.length) content = rev[i].childNodes[0].nodeValue; }
    if(!content.length) { field.value = "page was blank"; return; }
    content = content.replace(/\s+/, " ");
    only = rev[0].getAttribute("user");
    for(i = 1; i < rev.length; i++) if(rev[i].getAttribute("user") != only) { only = null; break; }
    if(only && bytes(only) > 64) only = null;
    if(only) s += s3.replace("$2", only, "g");
    limit = 257-bytes(s); // SIC!
    if(bytes(content) > limit){ content = content.substring(0, limit);
      while(bytes(content) > limit - 3) content = content.substring(0, content.length-1);
      content += "..."; }
    field.value = s.replace("$1", content);
    }
  x.send("");
  }
addOnloadHook(function(){ setTimeout("contentwas()", 1000); });

I tested this for a few hours in my own dark corner of the internet and it seems to work. If anyone wants to add better error-checking and a more graceful way to aim for 255 but avoid splitting multi-byte characters, go for it. — CharlotteWebb 19:06, 13 April 2009 (UTC)

I'd just like to note that anyone who uses this code and ends up putting "content was 'John Smith eats babies'" in a deletion summary will be fed to the lions... :D Happy‑melon 13:16, 14 April 2009 (UTC)

Expand templates intro

I suggest that this text be added to MediaWiki:Expand templates intro:

To expand an entire article, one may type {{:articlename}} in the box Input text instead of pasting the article's source.

I saw it on the Swedish wiki. Iceblock (talk) 14:50, 12 April 2009 (UTC)

I tried it, and you are right it works. But I don't see the point? Why would you want to expand a whole article?
--David Göthberg (talk) 18:13, 16 April 2009 (UTC)
I suppose if you wanted to copy and paste an entire article to another wiki but you didn't want to copy over the templates. Tra (Talk) 19:33, 16 April 2009 (UTC)

Collapse templates

I was trying to find templates that "collapse" a section of the text so that clicking on them can hide/show. I found {{Collapse}}, {{Collapse top}}, {{Collapse bottom}} and {{show}}, and another way seems to be to use 

<div style="clear:both;width:95%;" class="NavFrame">

Are there others? Is it ok to create a "Category: Collapse templates" containing all of them? Regards, Shreevatsa (talk) 00:06, 13 April 2009 (UTC)

There is also {{hat}} and {{hab}}. tempodivalse [☎] 00:14, 13 April 2009 (UTC)
And {{hst}}, {{hidden}}, {{hidden begin}}, {{hidden end}} & {{HiddenMultiLine}} -- WOSlinker (talk) 16:28, 13 April 2009 (UTC)
No one said it's a stupid idea, so I decided to go ahead and add these to a new Category:Collapse templates, but after adding {{collapse}}, {{collapse top}}, {{collapse bottom}}, {{show}}, {{hst}}, and {{HiddenMultiLine}}, it seems {{hat}}, {{hab}}, {{hidden}}, {{hidden begin}}, and {{hidden end}} are edit-protected. Could someone with the right powers add these? (Or undo my changes if they're a bad idea.) Shreevatsa (talk) 21:41, 16 April 2009 (UTC)
That category seems to be a good idea. You can add the category to most of those protected templates yourself, since the /doc pages are not protected. In fact, that is the very reason we started using such /doc subpages, so anyone can edit the categories, interwikies and the doc text, even when the template itself is protected.
I created the /doc page and added your category for the two protected templates that didn't have a /doc page.
--David Göthberg (talk) 00:06, 17 April 2009 (UTC)
 Done Oh, looks like I was being unobservant. Thanks, I've added all the pages to the category now. Regards, Shreevatsa (talk) 00:41, 17 April 2009 (UTC)

Template:Infobox comics character problem in Opera 9.0

Resolved.

The template Template:Infobox comics character used to render just fine in Opera 9.0. Some time in the last few days or weeks, however, some change (I don't know if it's a change in this template and or in some nested template that this template uses) broke this template in Opera: now this template expands to fill the entire width of the page, pushing the intro text entirely down below the template box rather than having it flow to the left of the infobox. For example, see the Superman or Spider-Man page in Opera (note, on the other hand, that some pages that use the template, like Magog (comics), render just fine). Could someone please fix this? This affects literally thousands of pages in Wikipedia. Thanks. —Lowellian (reply) 17:22, 15 April 2009 (UTC)

I see it too. That infobox blows up to full page width on for instance Spider-Man when I view that page with my Opera 9.02. While it looks normal in my Firefox 2.0 and my very old IE 5.5. I have no idea why that happens.
--David Göthberg (talk) 13:42, 16 April 2009 (UTC)
Probably related to this edit. But I can't find anything wrong with it. The infobox in Superman still has a valid width of 24em. — Edokter • Talk • 13:56, 16 April 2009 (UTC)
Fixed - Yeah, I too thought the use of {{comics infobox sec}} had something to do with it, so I already checked that code before. But now that you Edokter pointed to it I took a second look. Some code prettifying helped. That is, I indented the code to make it more readable and then I discovered that the first if-case in {{comics infobox sec}} was lacking the necessary colon ":" in the first "{{#if:||}}".
--David Göthberg (talk) 15:19, 16 April 2009 (UTC)
I should have spotted that... I usually do... — Edokter • Talk • 16:15, 16 April 2009 (UTC)
Yes, it's fixed now and rendering correctly! User:Davidgothberg, thank you so much for fixing[9] this problem. :) —Lowellian (reply) 06:01, 17 April 2009 (UTC)

Strange sorting behavior

There is a table at 2007–08 Pittsburgh Penguins season#Skaters exhibiting strange sorting behavior. The first six columns sort correctly, but the last five (Playoff) columns have a mind of their own. I have no idea what's going on. Any help would be appreciated! Thank you. — Twas Now ( talk • contribs • e-mail ) 09:54, 16 April 2009 (UTC)

style="width: 0.1em;" rowspan="39" class="unsortable". colspan and rowspan confuse the sortable tables code. You will have to add separate empty fields for all the rows. --TheDJ (talk • contribs) 12:24, 16 April 2009 (UTC)
Thanks for the help. That solved it. — Twas Now ( talk • contribs • e-mail ) 12:37, 16 April 2009 (UTC)
There is still something weird going on with the sorting of zeros in the playoff section (so it only affects G, A, and Pts). Does the sorting recognize a 0 as equal to an empty cell? — Twas Now ( talk • contribs • e-mail ) 16:05, 16 April 2009 (UTC)

"The database did not find the text of a page..."

Both Talk:1978 Washington summit and Talk:1977 London summit give the MediaWiki:Missing-article error. The history is empty for both pages. Anomie⚔ 11:40, 16 April 2009 (UTC)

Hmm, strange. I thought I'd have a go at deleting and restoring Talk:1977 London summit, but as there seems to be no history, there is nothing to restore! Do you know if there was definitely a page there once? — Martin (MSGJ · talk) 12:21, 16 April 2009 (UTC)
I'm getting rather wierd results from the toolserver database (that is, nothing!); not sure why it's even a bluelink. Please don't anyone touch the Washington one; play around all you will with the London one (unless you can find any more, Anomie?). Happy‑melon 12:29, 16 April 2009 (UTC)
No idea if there are any more or if they ever really existed, my bot found those two by throwing errors on them. Anomie⚔ 12:34, 16 April 2009 (UTC)
Ah, that's explains things. I'm looking at a list of the pages with page_ids surrounding the Washington one, and they've all been edited by your bot. I was going to complain that you'd probably destroyed other examples, but if the bot errors out on them then that's not the case.
The toolserver database confirms what appears to be the case: there is an entry in the page table for the Washington talk page, and it has a page_id (22431511). However, there are no entries in the revision table associated with that page_id. Curious. Happy‑melon 12:49, 16 April 2009 (UTC)
Same with Talk:1978 Washington summit; no history to restore. Could this be a botched move? — Edokter • Talk • 12:55, 16 April 2009 (UTC)

I'm running a really nasty query that (assuming River doesn't kill it and eat me!) should flag up any more of these. Happy‑melon 13:38, 16 April 2009 (UTC)

Query failed, too nasty... FTR it was something like this: 

SELECT page.page_id, page.page_title
    FROM page LEFT JOIN revision ON page.page_id = revision.rev_page
    WHERE revision.rev_page IS NULL;

That is, "create a table containing every row from the page table (11 million entries) mapped to every row of the revision table (250 million entries) wherever the page_id and rev_page values are the same (creating a null row if there is no such row in the revision table), then return only the rows where such a null row had to be created". Happy‑melon 14:58, 16 April 2009 (UTC)

Is this:
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 "Revision::insertOn". MySQL returned error "1205: Lock wait timeout exceeded; Try restarting transaction (10.0.6.22)".
related? –xeno (talk) 16:58, 16 April 2009 (UTC)
Don't think so, I got that too a few hours ago. I think the servers are being put through the mill at the moment, probably a random period of high load (plus the connection between the Squid servers in Amsterdam and the Apaches in Florida went down this afternoon, so they were thinking about disabling that entire cluster until it got fixed). All manner of things seem to be shaking loose. Happy‑melon 17:33, 16 April 2009 (UTC)
yea, i managed to get it sorted. –xeno (talk) 17:49, 16 April 2009 (UTC)

Ah whats going on with the change in red links? A black link with red question mark? Red links are ugly I agree but that was exactly why -they strongly point to missing articles. I think this change will have a negative effect on people creating articles from the missing links. Dr. Blofeld White cat 12:08, 16 April 2009 (UTC)

Go to "my preferences", then "misc", and check the top box (format broken links) - that should restore redlinks. DuncanHill (talk) 12:12, 16 April 2009 (UTC)

Thanks. I'm thinking though about new comers who may want to contribute and not know this and bypass these links. Dr. Blofeld White cat 13:03, 16 April 2009 (UTC)

The default behaviour is the same as it ever was. Either you changed your preferences accidentally or the software changed them of its own accord (as it has been known to do from time to time). Algebraist 13:07, 16 April 2009 (UTC)

Yes my browser seems to have slightly "changed" when I logged this morning. I have no idea how!! Dr. Blofeld White cat 15:32, 16 April 2009 (UTC)

My contributions bizarritude

My contributions just lost all the links to articles etc, and just shewed stuff like this " () () m ‎ (Reverted 4 edits by identified as to last revision by . ()) (top) []" when I clicked on "earlier 50". DuncanHill (talk) 14:58, 16 April 2009 (UTC)

I just had the same problem with Preston Village, Brighton. A purge worked there. Algebraist 15:00, 16 April 2009 (UTC)
And just now with my watchlist. Reloading worked there. Algebraist 15:02, 16 April 2009 (UTC)
 Works for me. Perhaps somebody was messing with a MediaWiki page? –Juliancolton | Talk 15:02, 16 April 2009 (UTC)
Seems to be OK again. Very odd. DuncanHill (talk) 15:03, 16 April 2009 (UTC)
Has happenned a couple more times, and also happened on "my preferences" where it displayed my username etc as (). DuncanHill (talk) 15:17, 16 April 2009 (UTC)

I saw it too, on my contributions and a couple of templates and pages I was viewing at the same time. Purging or refreshing seemed to clear it tho. - Trevor MacInnis (Contribs) 15:32, 16 April 2009 (UTC)

I saw it on an article a few minutes ago, disappeared on null edit. I suspect one or more servers are serving borked pages, hence the intermittence. Happy‑melon 16:09, 16 April 2009 (UTC)
I was just referred here from the Help Desk, where I had posted about this in Waltheof, Earl of Northumbria. --ColinFine (talk) 20:25, 16 April 2009 (UTC) - But it seems to have fixed itself now --ColinFine (talk) 20:31, 16 April 2009 (UTC)
If it is of any help, when I was over at Wikinews earlier today I had something similar happen: the main page didn't display any links at all. Tried a refresh, nothing happened. When I came back a few minutes later everything was fine. Looks like this is a cross-wiki occurrence? tempodivalse [☎] 20:33, 16 April 2009 (UTC)

Everything's gone weird

Now pages display in a strange font, with the editing tabs in a list near the bottom og the page and the my talk/my preferences stuff in another list below that. DuncanHill (talk) 16:06, 16 April 2009 (UTC)

That's where those links are if not moved elsewhere by CSS, so this might be caused by your browser failing to load the stylesheets properly. Algebraist 19:05, 16 April 2009 (UTC)

Can't undelete Talk:Recession

Oops... I deleted Talk:Recession to remove personal information included in some vandalism, but every time I try to restore it, I get this Database 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 "Article::insertOn". MySQL returned error "1205: Lock wait timeout exceeded; Try restarting transaction (10.0.6.22)".

Help! – Toon(talk) 19:23, 16 April 2009 (UTC)

Oh wait... it's back... :s – Toon(talk) 19:24, 16 April 2009 (UTC)
(edit conflict) This was happening to me earlier. Took me about 30-45 minutes to get it restored. (Just kept trying). –xeno (talk) 19:25, 16 April 2009 (UTC)

Persondata

Is there something going on with Persondata today ? Normally, I can see Persondata on every article that has it but today I can't. Is there anything going on ?

Thanks,

Tovojolo (talk) 21:42, 16 April 2009 (UTC)

See MediaWiki talk:Common.css#InChI and persondata. The CSS has been moved to {{Persondata}}, which may cause them to be invisible again. If you use your monobook.css to show persondata, try adding !important to the declarations. In fact I did it for you. Does that restore it? — Edokter • Talk • 22:51, 16 April 2009 (UTC)
Tovojolo confirmed that it fixes the problem. — Edokter • Talk • 23:30, 16 April 2009 (UTC)

Disappearing links?

For some reason, when I log out and view the page Armalite and ballot box strategy, all the links are missing - the blue text simply doesn't appear. When I log in again, they reappear. I haven't noticed this problem on any other articles. Does anyone have any idea what might be causing it? Robofish (talk) 23:23, 16 April 2009 (UTC)

See above. Algebraist 23:25, 16 April 2009 (UTC)
Thanks, I tried saving a null edit and that seemed to do the trick. Strange... wonder what's causing the problem? Robofish (talk) 23:32, 16 April 2009 (UTC)

Category & job queue sanity check

How long does it usually take for a new category to populate itself? I made a few modifications to {{val}}, so that when a particular parameter is present in an instance of {{val}}, it adds that page to a category. That was about 17 hours ago, and there's virtually nothing in the category (one article-space entry). It's entirely possible that only one article uses these parameters, but that would come as a bit of a surprise (especially to the template maintainers, I'd imagine). I'm therefore wondering if there have been any job queue delays or other issues lately, that might cause recent changes to the template from being reflected on cached pages. (Incidentally, purging and refreshing had no effect. The job queue is currently at 5872, and was at 0 yesterday.) TheFeds 14:32, 14 April 2009 (UTC)

See Special:Statistics. The current job queue is at 7K, which is relatively small. Try a dummy edit on the page; if it does not appear in the category, then something else is wrong. --Gadget850 (talk) 17:39, 14 April 2009 (UTC)
When you change the categorisation in a template it takes about two days before most cases have arrived in the category. And about two weeks until nearly all cases have arrived.
And here's the long explanation:
This is because the pages that use the template are only re-rendered when they are visited, and the categorisation of the page is only updated when it is re-rendered. And it takes some days before most of the pages have been visited. If some page never gets a visit, then it will never turn up in the category. (And I have tested it, I had a secret page that didn't get categorised for months.) If it is a very widely used template or it is used on exotic pages deep in the "Wikipedia:" namespace or similar, then you might see stragglers arrive for a long time. Thankfully at least our articles get visited regularly, if not by humans so by the search engine crawlers, such as Google's crawler. So I think the search engines actually help us keep our categories updated!
So most of this delay is not caused by the jobqueue. The jobqueue does many things, but in this case: When you change a template, all pages that use that template gets put on the jobqueue, and when the process that processes items on the jobqueue takes the next page from the jobqueue it sends a message to all servers to drop that page from the cache. Note that it doesn't re-render the page. But since the pages get dropped from the cache they will be re-rendered the next time they get visited.
And that is why we need a jobqueue, since one change might affect thousands of pages, and for each of those pages a message has to be sent to each cache server to drop that page. Thus the jobqueue means that that heavy work can be done in the background when the servers have time for it.
Actually, even after the page has been visited and re-rendered, it still takes some time before the page turns up in the category. My guess is that the order to insert the page in the category is put on the jobqueue (or some other such queue system), and thus it takes some time before the category shows the page. Usually this only takes some minutes after you visited the page, but when the servers are really busy it can sometimes take a day.
There's much more to this, I guess we should write a guide about this sometime...
And a disclaimer: I am not a developer and I have not studied the MediaWiki code and Wikipedia server settings. Instead what I stated is based on what I have read and then verified by years of Wikipedia editing and template coding.
--David Göthberg (talk) 21:46, 14 April 2009 (UTC)
I didn't think this day would come, but I think I'll have to partially disagree with you David ;) At least my experience doesn't match some of what you've said. After making a change to a template, simply visiting a page (and re-rendering as you've called it) does not update the category. It will show the new category on the page, but it won't update the category contents. Even purging the page doesn't do it: the only way to force the updating of the category is by making a null edit. On the other hand, I believe the job queue does update the categories, even though it can take several weeks. Your secret page did get recategorised eventually, didn't it? I've recategorised thousands of pages by changing a template, and I know for sure that not every page was revisited by someone. — Martin (MSGJ · talk) 21:57, 14 April 2009 (UTC)
I believe the job queue should be updating the links tables (categorylinks, pagelinks, etc.) when you edit a template. If its not, that sounds like a bug. I'll have to ask Tim Starling, or someone else more familiar with the job queue than me about it. Mr.Z-man 23:09, 14 April 2009 (UTC)
Mr.Z-man: We can't have the servers re-render all dependant pages every time a template is edited. It would cost way too much server resources. You know, some templates are used on millions of pages. And sometimes the same template is edited many times in one hour. So unfortunately the servers have to be lazy and only update things if/when a page is visited.
MSGJ: First of all, even when you have visited the page or even purged it, then it takes some time before the page gets visible in the category. This takes anywhere from some minutes to a day depending on how busy the servers are. Did you wait for 24 hours to see if the page turned up?
But yeah, sometimes it seems that even though the page shows the new category, it "never" turns up in the category, and then not even purging seems to help. I haven't figured out under what circumstances this happens. Then one has to do an actual edit that changes something on the page (adding a space is enough) to cause the page to re-categorise. I don't know if a null edit is enough.
I know another circumstance when a category gets shown on a page but sometimes "never" shows up in the category: If a template or code on the page adds a category automatically, without any edit to the page or template. For instance if the date or a category count or other such measurement is used to trigger the adding of a category. Then that category is shown on the page on the next page re-render (pages are cached for a week if not edited), but it seems then the page sometimes doesn't show up in the category. But it also seems that the category often do show up. (But I haven't done enough testing of this, so I don't know for sure.)
My secret page got categorised only because I accidentally visited it myself. (I felt kind of stupid, ruining my own test run.) The page turned up in the category some minute after I had visited the page.
How can you know no one visited your pages? There are search engine crawlers and other automatic bots that visit pages. Some of them don't heed noindex and nofollow tags and similar.
--David Göthberg (talk) 23:38, 14 April 2009 (UTC)
According to mw:Manual:Job queue, template edits do (or are supposed to) update the links tables, which should include categories. Duplicate entries are removed when a job is run [10], so multiple edits to a template will only cause one reparse, unless the edits are far enough apart that the reparse is done before the 2nd edit. Mr.Z-man 23:54, 14 April 2009 (UTC)
DG, my knowledge of the MW code base also disagrees with you. IIRC your secret page test was testing dynamic inclusion: {{#ifexpr: {{CURRENTDATE}} > Some date | [[Category:...]] }}, which is indeed a 'black hole' where pages are only added to the category when someone edits the page. Also don't forget that Tim purged the job queue a while back and a lot of jobs were lost: if your page recaching was still outstanding at that time it would have been abandoned.
Yikes, huge post
Normally when a pageview request comes in it is processed by one of the squid servers. If the squid has a cached copy of the page that the requestor wants to see (a complete copy, including all the bells-and-whistles around the edge, so logged-in users rarely hit the cache) then the page is served directly by the squid, and never gets any deeper. If the squid doesn't have the necessary page (or if it does have a copy but its cache has expired (either because it's too old or it has been forcibly expired), it forwards the request to an Apache web server, which checks the client browser's own cached version and tells it to use that if it's still valid. Otherwise it reconstructs the page from the database. The Apaches draw their page data from five slave database servers, which are continually syncing themselves with the master database server. Asking an Apache to render a page is a read-only operation: material is drawn from the slave databases and compiled into a new page, which is returned to the squid, cached, and then returned to the user. The only writes made to the database are to update hitcounters if enabled, and to wipe the new messages notification if it's a user viewing their own talkpage. There is nowhere immediately apparent where database updates are invoked from the Article::view() call stack. Either the update was triggered upstream, in the squid caching code that I don't fully understand, I'm missing something, or your experience with the secret page was a fluke (I doubt the latter given the timespans involved). A page edit immediately drops all downstream pages from the squid caches, so that readers can do some of the job queue's work in rerendering pages.
Requesting a page purge automatically falls through the squids to the Apache layer: once it's confirmed that the user is allowed to purge, all it does is send a message to all squids invalidating any cached copies of the page: when the browser is then redirected back to the page, the request triggers a fresh copy to be created by an Apache. If the purge is of a MediaWiki page, purging also invalidates the Apache's cache of the system messages (the main difference between the MediaWiki namespace and other namespaces is that MW page content is cached by the Apaches (which is why per-page editnotices were disabled: they were making the MW namespace too big, because the Apaches don't have very much memory)).
Editing a page is, of course, completely different: making any edit to a page (including a null edit) falls through to an Apache, which makes a load of write actions on one of the slave databases. Any tables relating directly to the page are updated immediately, and if the page has a small number of transclusions all 'downstream' updates are done immediately. Otherwise they are pushed onto the job queue. Since all this is done to a slave database, the changes have to be propagated to the master database, and then back out to the other four slaves. In a period of high load, this may take long enough that, if you then quickly request a page, that goes to a squid that passes it to an Apache that loads the data from a different slave, you may get the old data for a short time, as you describe, DG.
In summary, therefore: page views and page purges do not AFAIK update categorylinks, although this could be incorrect. Direct edits to templates definitely do put complete rebuilds of all downstream pages onto the job queue; all downstream pages definitely are eventually rebuilt as a result of upstream edits. Committed edits are made to slave databases, so it is possible to get old versions of pages if the request is served by a different slave that has not yet been synced. Happy‑melon 11:45, 15 April 2009 (UTC)
Wow, long post indeed. We should definitely have a guide somewhere, where all these words of wisdom can be kept. My experience backs up the above anyway, even if I didn't understand all the long words ;) I have often thought that it would be helpful to have a bot to perform null edits on a category to force the updating after a change to a template. (I'm impatient and sometimes don't want to wait two months.) I think I'll put a request in. — Martin (MSGJ · talk) 12:19, 15 April 2009 (UTC)
Happy-melon: I have done more secret page + category tests than the test you are referring to. But you don't know about those tests since I used secret pages. :)) But this is tricky stuff and I haven't done enough tests to be sure, and there's always the occasional server hiccups, so my conclusions might be wrong.
Anyway, one thing I am sure of is that when we change the categorisation in a template it usually takes some days before most pages that use that template arrive in (or are removed from) the category. And that is the answer to the original question above. So TheFeds, just be patient and wait some days.
Yes, I intend to start out such a guide page and copy this discussion to the talk page of that guide page. I think the guide page should be be about most of the different kinds of delays that we experience here on Wikipedia. I suggest we name that page Wikipedia:Update delays. The guide page itself might be fairly empty in the beginning, but we could discuss and report conclusions and test results on its talk page. And it would be nice to be able to point people to that talk page.
--David Göthberg (talk) 14:08, 15 April 2009 (UTC)
It should probably be a Help page. --Gadget850 (talk) 14:23, 15 April 2009 (UTC)
Happy-Melon is mostly correct, though there is another layer of caching using memcached, which stores the parser output – the rendered text minus the skin, as well as a few miscellaneous things – and all write actions are done on the master database. Slaves should always be read-only, otherwise lag could cause auto-increment indices to become out of sync. Most reads are done from the slaves, except in cases where lag would be more than an inconvenience. Mr.Z-man 16:32, 15 April 2009 (UTC)
  • Oh yes, of course, that could be messy :S But it's still possible to get the old version if you then read from a slave that hasn't been fully synced.
    Is the memcache layer what's marked as "Try file cache" in Article::view()? Line 751... Happy‑melon 10:15, 16 April 2009 (UTC)
  • Z-man, so who's assembling the skin and the personalized frame with the memcacheded parser output? It has to go through another Apache somewhere, right, to check login status, and render the "new messages" banner and the user (talk) page links? --Amalthea 13:16, 16 April 2009 (UTC)
  • The file cache seems to be something different, where it stores the full rendered HTML to disk, like Squid, but built into MediaWiki and not as fast. The memcached layer is the parser cache. Any request by a logged-in user goes to apache, the content stored in memcached is set and accessed by MediaWiki. Mr.Z-man 18:20, 17 April 2009 (UTC)
In addition (and it pretty much follows from what Melon said): If a category is transcluded from a template and changes due to some parser function then it needs a (null) edit to actually put it in the category. Good examples for this can always be found in Special:WhatLinksHere/Template:Db-t3, which categorizes a page in CAT:CSD if it has been tagged for seven days. E.g., {{New York Yankees seasons}}, {{Infobox HAR}} and {{Dodgers retired numbers}} have all been tagged on March 24, all claim to be in CAT:CSD (since they have been rerendered in the last two weeks), but no amount of purging will make them actually show up in the category. A null edit would. --Amalthea 14:29, 15 April 2009 (UTC)

At WP:CFD, about a month ago, we tested this with emptying of categories after it was removed from a template. Our results would appear to confirm what DG has said, in that edits were necessary. It took so long waiting for the job queue to take care of it that I went ahead and made null edits to clear the category out. --Kbdank71 14:35, 15 April 2009 (UTC)

I can't remember exactly when Tim killed the job queue, but it might have been around that time. The whole process needs a fairly radical overhaul, I think it's on the medium-term todo list for one or other of the devs. Happy‑melon 10:17, 16 April 2009 (UTC)
I did some testing with my own wiki, and haven't been able to replicate any of the issues described here. When editing a template, the job queue was properly populated and the script used by Wikimedia to run the jobs as well as the jobs themselves seemed to be working correctly. The only 2 possible issues I can see are:
  1. The backlink cache is never forcibly cleared. However, it has an expiry time of an hour, so this should only affect pages where the template is added within an hour of an edit to the template, so it shouldn't affect the majority of pages, and should be fixed if the template is edited again after the cache expires.
  2. If the category is dependant on some parser function that doesn't return true when the job is run, it won't be updated.
-- Mr.Z-man 18:20, 17 April 2009 (UTC)

Science RefDesk Problem

I'd fix it, but have NO idea how to do it.

Every time i go to the science refdesk, the sidebar that links to the other refdesks empties out and is completely blank. Not to be rude, but someone should fix it; it's kinda annoying.  Buffered Input Output 13:04, 16 April 2009 (UTC)

Looks fine to me...Browser/version/OS? –xeno (talk) 13:08, 16 April 2009 (UTC)
And to me. Have you tried bypassing your cache? Does the problem occur on any of the other refdesks? How about on Wikipedia:Reference desk/header/nav? Algebraist 13:10, 16 April 2009 (UTC)

Bypassing the cache does nothing; the links still don't appear. And they are all fine on Wikipedia:Reference desk/header/nav. Browser is Internet Explorer 7, OS is XP Professional SP3.  Buffered Input Output 12:42, 17 April 2009 (UTC)

Looks fine to me as well. Do you have any special scripts or gadgets installed which could be causing this? — Martin (MSGJ · talk) 12:54, 17 April 2009 (UTC)
I'd say it was the school's server/blocking scripts, but the problem occurs at my house as well (IE6+XP Home SP3). The only difference is that bypassing the cache fixes it at my house.  Buffered Input Output 16:37, 17 April 2009 (UTC)

Deactivating autopatrol

I make a lot of edits to page using AWB, many of which are new and unpatrolled. Unfortunately, it seems that because I'm an admin my AWB edits that take well under half a minute each mark the pages as patrolled... but I haven't looked at the full article. Is there some way to deactivate the autopatrol feature for my account without it interfering with other sysop abilities? Thanks. –Drilnoth (T • C • L) 02:07, 17 April 2009 (UTC)

I don't think so, but you could create an alternate account for such purposes. Stifle (talk) 08:45, 17 April 2009 (UTC)
Correct me if I'm wrong, but shouldn't autopatrolling only affect pages that you create here on en-wiki? It won't mark a page as patrolled just because you edit it. Have a look at your patrol log, only pages you (recently) created are marked as "patrolled (automatic)". Amalthea 10:16, 17 April 2009 (UTC)
Yes I believe Amalthea is right. — Martin (MSGJ · talk) 12:51, 17 April 2009 (UTC)
Oh... okay. Maybe the person who let me know about this was mistaken. Anyway, thanks! –Drilnoth (T • C • L) 13:56, 17 April 2009 (UTC)

MediaWiki request

Not sure where to post this, so I'll try here. If you're on a category page, you see a message saying "this list may not reflect recent changes (learn more)", and "learn more" links to a very technical (and probably not particularly accurate) section of a help page intended for editors. However, since categories are intended to be navigated by readers, and they are liable to be intrigued by this message, it would be far more appropriate to link this to information that they might be able to understand. I've tried to write such information at WP:FAQ/Categories#Why might a category list not be up to date?. Please can someone who knows the magic change the link under "learn more" to point to that FAQ section rather than the help page section? Or even better, get rid of it (it's not really a common problem, espcially in reader-facing categories) and add a more general link, something like "To learn more about using categories, see the FAQ." (That FAQ is a starting point for readers, but it also contains a clear onward link to the other FAQ: WP:FAQ/Categorization, which is meant for editors.)--Kotniski (talk) 10:09, 17 April 2009 (UTC)

Should all three of MediaWiki:Category-article-count, MediaWiki:Category-article-count-limited and MediaWiki:Category-empty be updated to point there? Amalthea 10:21, 17 April 2009 (UTC)
Yes, that would seem to be it!--Kotniski (talk) 10:46, 17 April 2009 (UTC)
Done Amalthea 10:57, 17 April 2009 (UTC)
Thanks! Kotniski (talk) 14:55, 17 April 2009 (UTC)

On MediaWiki:Category-article-count, we could add "approx." to the total. -- User:Docu

Is that necessary? Is it inexact for any other reason than the thing about templates? --Kotniski (talk) 14:55, 17 April 2009 (UTC)
I'm not sure about the full effects of the template thing. It might be just a delay in updates, but sometimes the count remains off by several. -- User:Docu
Kotniski: Category updates are delayed for a whole bunch of reasons. Even when not using templates and you manually add or remove a category from a page it can take anywhere from some minutes to several hours before the page is added or removed from the category. Removing a page usually takes longer time, and adding and removing subcategories also take longer time. So removing a subcategory is the operation that takes the longest time. (I guess that is a priority setting in the system, and I agree with that priority order.) Also some categories show the wrong category count. See discussions Categories reporting wrong number of members and Category & job queue sanity check above.
And it is a common problem. We added the text that says "This list may not reflect recent changes" and the (learn more) link since we constantly have problems with editors worrying why their page doesn't turn up in or are removed from the category. So they start doing extra edits to the page and testing all kinds of weird things, and they go ask on our user talk pages and/or here on the Village pumps. And they even ask for or suggest that bots should "touch" (do dummy edits) to all pages in their category. When all they need to do is to wait long enough for the category to update. See the discussions above for examples. (Well, there are some odd circumstances when you perhaps need to "touch" the pages.)
Already a 10 minute delay is enough for an editor to start panicking and try extra edits and come asking us what is going on etc., and delays of 10 minutes or more are common even when templates are not involved. Things have been much more quiet after we added that text and the learn more link.
I think that the (learn more) link should be linked to a page specifically written to be its target. Since then that page can be written in a way that is helpful for both readers and editors. It was linked to a good text, but that text has since been changed.
--David Göthberg (talk) 17:05, 17 April 2009 (UTC)
OK, if that's the case, then we probably need more explanation than is present at either the previous or the new link target. Do you know where we can find the "good text" in the history (or would you be able to recreate something similar)? As a temporary measure, I've added some extra text at the current link target - the second paragraph of WP:FAQ/Categories#Why might a category list not be up to date? - please improve if you can (but let's try to keep that page simple - if it starts getting technical, then perhaps better to link to a separate page like you suggest, or do something at the editors' FAQ).--Kotniski (talk) 17:18, 17 April 2009 (UTC)
There are really to issues: (1) the category doesn't necessarily display all articles that list the category on their list. (2) the count on the page doesn't match the number of articles displayed below. For point (1), I think it can take several weeks. -- User:Docu

Requested interface change

I have posted a request that requires consensus first at MediaWiki_talk:Common.js#Requested_change_to_Monobook_skin. -- IRP ☎ 22:21, 17 April 2009 (UTC)

Enforce wikibreak at work?

I'd like to put something in place that keeps me from editing from my work computer, without actually blocking access to the site. Maybe a perl-based proxy script that blocks WP pages with "edit" in the URL? Has anybody done this in a way that they found to be convenient?--SarekOfVulcan (talk) 14:46, 17 April 2009 (UTC)

Something like this? Papa November (talk) 17:02, 17 April 2009 (UTC)
That would prevent the user logging in altogether, I believe he's looking for a way to simply prevent him editing whilst at work... Self-restraint sometimes fails us... =] –xeno talk 17:05, 17 April 2009 (UTC)
Bingo. :-)--SarekOfVulcan (talk) 17:32, 17 April 2009 (UTC)
Actually, I could probably modify that script to block me between 8 and 6 every day, instead of watching for an end date...--SarekOfVulcan (talk) 17:34, 17 April 2009 (UTC)
If you look in my monobook.js you will see a routine called 'wikibreak'. You can give it a date to reactivate, but I am sure you could modify it to work with a time range. It works by finding and removing your edit token. Chillum 17:34, 17 April 2009 (UTC)
That would appear to work, unless I just broke my ability to edit at all. :-)
if (today.getHours() >= 8 
      && today.getHours() <= 18 
    && today.getDay() >= 1 
      && today.getDay() <= 5)
  {
  addOnloadHook(wikibreak);
  }
are you sure you won't now just end up editing as an IP? =] I suppose you could block yourself it that became an issue... –xeno talk 18:20, 17 April 2009 (UTC)
Heh. I probably will at some point (did once yesterday, actually), but for the most part, I like my edit history as it is.--SarekOfVulcan (talk) 19:09, 18 April 2009 (UTC)

I've got a couple of scripts that will prevent you from ever editing as an IP. Let me know if anyone wants them. Note that they require Greasemonkey because they have to work all the time, and User:YOURNAME/monobook.js will not. — CharlotteWebb 18:30, 17 April 2009 (UTC)

Sure, send them along! –xeno talk 18:32, 17 April 2009 (UTC) (For the record I just want it to prevent me editing as an IP, nothing to do with wikibreaking...)

Well here's one really simple way:

if(e = document.getElementById("editform"))
	e.innerHTML += '<input name="assert" value="user" type="hidden" />';

Then if you try to edit without logging in you'll get an error message that says "The specified assertion (user) failed". Changing the url to "&action=edit&assert=user" will have the same effect. Bots should use "&assert=bot", etc. — CharlotteWebb 10:33, 18 April 2009 (UTC)

That would be cool if I hadn't converted mostly to Chrome over the past few months. :-)
  • Why not just ask your boss to help? DuncanHill (talk) 18:37, 17 April 2009 (UTC)
    • Because, as I commented to him, if I put measures in place, that's good for morale -- if he has to enforce them, that's bad for morale. Besides, I don't want to lock myself off the internet, or even completely out of WP -- I just don't want to burn time looking up references for AfDs, or creating a new article.--SarekOfVulcan (talk) 19:08, 18 April 2009 (UTC)

I've found an extension for Firefox that works well; it allows you to select any website, and then create specific access rules for that site. In your case, you could set it up to block all access to Wikipedia between certain hours, or to only allow a certain amount of time per time period. (For example, you could allow yourself 10 minutes of access every two hours, which I've found is enough for quick information searches, but not enough time to get into editing.) I'll try to look up the script name and post it later today as it is on a different computer. --Ckatzchatspy 18:55, 17 April 2009 (UTC)

CSS screen media type in Opera's fullscreen

Wikipedia is one of the few major sites on the internet that specifies most of its CSS specifically for the "screen" media type. This, in a way, excludes Opera users browsing in full-screen, as Opera triggers the fullcreen "presentation" media type. While I'm aware that the two media types represent different purposes, as Wikipedia is not explicitly setting any separate styles for fullscreen presentations, and as no other WikiMedia project that I know of does this (so it's evidently not a MediaWiki peculiarity), I see no reason for it. ɹəəpıɔnı 00:12, 18 April 2009 (UTC)

It is because we have "alternative" skins for handheld and printing. Note how I say alternative, and not additional. The solution is to use: media="screen, projection, tv, tty, aural etc..." You can see the obvious problem here CSS forgot it might be handy to define "all but" :D --TheDJ (talk • contribs) 01:23, 18 April 2009 (UTC)
There are only so many CSS media types. It seems perfectly reasonable to make our "screen" style rules apply to "projection" also. —Remember the dot (talk) 01:48, 18 April 2009 (UTC)
As a matter of fact, it seems that we used to do that. This must be a recent regression. --TheDJ (talk • contribs) 02:02, 18 April 2009 (UTC)
Commit located [11] --TheDJ (talk • contribs) 02:06, 18 April 2009 (UTC)
Ticket created. --TheDJ (talk • contribs) 02:14, 18 April 2009 (UTC)
Curious... I've never heard of anything actually supporting the projection type. :) Per spec it's not compatible with the screen type, as it's a paged medium (no scrolling allowed). It seems unlikely this is correct behavior for Opera. --brion (talk) 21:45, 19 April 2009 (UTC)
8 or 9 years ago Opera tried to make the browser double as a presentation tool, with presentations crafted purely in HTML+CSS. It didn't have transitions like Powerpoint, but was a nifty tool and Håkon Wium Lie used to do all his presentations using Opera. Opera 7 introduced a few bugs which took a long time to be fixed, but the still have documentation for it. Presentation is optionally a page medium. dramatic (talk) 22:47, 19 April 2009 (UTC)

Multiple mountain infoboxes: is this technical or is this policy

I asked on the Policy Village Pump as well because it may be a policy question.

Eaglenest Mountain is a confusing article. North Eaglenest Mountain is actually the taller of two adjacent peaks (by a few feet) and the more famous one. And the hotel for which the two peaks were named was actually on North Eaglenest Mountain. But only one could be a stand-alone article unless there was a lot of duplicate content. The problem is that I can't put two infoboxes in one article. The coordinates for the first appear at the top of the page and in both infoboxes. If this can't be fixed (technical), I suppose two articles are justified (policy).Vchimpanzee · talk · contributions · 20:57, 16 April 2009 (UTC)

I went ahead and separated the two articles, so now it's a policy problem.Vchimpanzee · talk · contributions · 22:33, 16 April 2009 (UTC)

I probably would have used a single infobox with less specific coordinates that could cover both mountain peaks, but I don't work on geo-articles, so do with my recommendation what you will. =) --Dinoguy1000 (talk · contribs) as 66.116.12.126 (talk) 05:49, 21 April 2009 (UTC)
You should add disambig templates at the top of both articles to avoid confusion. Mentioning them in the article prose is good, but may not be enough. SharkD (talk) 06:40, 21 April 2009 (UTC)

Page cache and date autoformatting

Just a question of interest. How does date autoformatting work with page caching. Does it cache a separate version of each page for each date preference? Does it store a single copy that is post processed? In either case, will there likely be a performance gain when autoformatting is turned off? Thanks. -- Tcncv (talk) 20:52, 18 April 2009 (UTC)

If I recall correctly, every time a logged-in user loads a page, the parser makes an HTML version of the page based on your preferences (i.e. skin, whether to number headings, date format, etc). I'm not sure if these versions are cached. Anonymous users can't set user preferences, so many of their requests go through Squid caches. Graham87 11:01, 19 April 2009 (UTC)
The Wikimedia servers use several layers of caching and replication to reduce load on the database master. As noted, the squid servers handle an awful lot of requests: whenever a page is requested, the request is routed through a squid, which checks if it has an exact copy of the page requested already rendered. Since all anonymous users see the same version of pages, this means that ~80% of anon pageviews are served directly by the squids. This is why, for instance, there are no userpage/talk/contribs links at the top of the screen for anon users, only the login/create account link. Since the hit rate for logged-in users would be very low I don't think pages rendered for specific users are cached; all their requests, along with any anon requests that 'miss' the squid caches, fall through to the layer of Apache web servers, which recreate the page from the raw text. The Apaches maintain their own caches, of parsed page text - that is, the output of a page after all templates and such have been expanded, but before wikitext is converted into HTML - from which they can quickly generate the content HTML and then wrap it in the necessary shell as dictated by the user's skin, preferences, stylesheets and group permissions (so for instance, admins get a "delete" tab while other users don't). If the Apache memcache can't provide the necessary wikitext, or the cache is out of date, the text is extracted from the actual database tables: to reduce load on the database master (that's used for all write operations eg edits) the master is synced to five slaves which the Apaches actually read from. Only in the worst case where all the caches are missed and the slave lag is over a certain threshold will a page request actually result in data being read from the database master.
So in terms of date autoformatting, it has very little impact on performance. The squids do not have to cache separate forms of the page because anon users always see the date in the form it was entered (this is why the geolocation idea was not popular with the devs, because it would either dramatically increase cache misses or require the squids to save five copies of each page), and the Apaches cache the parsed wikitext before HTML conversion and preference implementation. Hope this clarifies. Happy‑melon 13:10, 19 April 2009 (UTC)
Yes, it does. That was a very good explanation. I hadn't considered all the other logged-in user specific aspects. Thank you. -- Tcncv (talk) 14:19, 19 April 2009 (UTC).
For logged in users, yes, the parser cache does cache a different version depending on date preference and a couple other options. If you look at the page source, you can see some of the options in the cache key. For me right now, the key for this page is enwiki:pcache:idhash:3252662-0!0!0!ISO_8601!!en!2 - which translates to: English Wikipedia, parser cache, pageid:3252662, not using action=render, math preference, stub threshold, date preference, heading numbering, language, thumbnail option, able to edit the page, not printable version. (note that some are represented by an empty string). So there's a lot of different options that affect cachhing for logged in users. Mr.Z-man 18:07, 19 April 2009 (UTC)
That's interesting, Z-man, but somewhat confusing. If I were to set all my preferences to be the same as yours and reload this page, I could in principle use that cache key because the appearance would be exactly the same... except for the 'pt' links at the top (talk, contribs, watchlist, etc). Are those not part of the parser cache? Is only the content of #bodyContent cached? If that's the case, what's the point of all the optimisations for logged-out users (setting wgUserName = null, etc)? What about a user who was not an admin... they would again be getting otherwise exactly the same page, but without the "delete"/"protect" tabs. Where does the caching stop and the parsing take over? And, given that the squids are simple eat-and-regurgitate data storage, who's doing the parsing? Happy‑melon 18:24, 19 April 2009 (UTC)
The parser cache only stores the content that you see in action=render, that is, the page content, minus anything specific to the skin. The skin elements are all done separately from parsing the content. I made a flowchart — File:MediaWiki-render-flowchart.svg Mr.Z-man 02:20, 20 April 2009 (UTC)
  • Doh! I know where I was going wrong... "parser cache" == memcache != squid cache. All is revealed. Happy‑melon 09:40, 20 April 2009 (UTC)
  • Thanks, Z-man. Out of curiosity, where in that process does a request of a not-logged-in user check whether the user has any messages, to display the new-messages banner? It has to leave the squids somewhere for that? Amalthea 09:52, 20 April 2009 (UTC)

succession box

Resolved

succession box on this page is not working pl help.[12].User:Yousaf465 (talk)

Icons in sidebars

Moved to: Wikipedia:Village pump (policy)#Icons in sidebars.

Update to popups

I invite users to test User:TheDJ/slimpopups.js. An update that I'm planning for WP:POPUPS.

  • removes all fallback methods for elements that can already use api.php. Presents an alert if api is not enabled on your mediawiki installation
  • fixes an issue with autoedits not autosaving/previewing.
  • now supports images from Commons again
  • now supports descriptions from Commons again
  • "hacks" to support both the Image and File namespace
  • switches from custom to firebug/safari error/debug logging
  • fixes an issue with timezone corrections that had been broken for a while now.
  • adds support for several new interwiki prefixes
  • fixes an issue with listing image usages.
  • contributions tree removed due to brokenness.
  • Now always show template code when looking at a template link, or an image link.
  • Switched to soxred editcounter
  • Preview user's info. blocked/groups/editcount. Thx to Splarka

Usage: 

importStylesheet('MediaWiki:Gadget-navpop.css');
importScript('User:TheDJ/slimpopups.js');

Unless serious regressions are reported, this code will likely go into effect somewhere next week. --TheDJ (talk • contribs) 21:01, 15 April 2009 (UTC)

I think it works good. Powergate92Talk 22:13, 15 April 2009 (UTC)
For the sites without api.php, I think it's unacceptable to have two alert boxes pop up on every page load about how the api is not enabled. It's very disruptive to the user experience and most users won't know what it means at all. I think better options would be to either:
  • Keep popups working with minimal functionality.
  • Have the notification appear when they hover over a link but in the form of the yellow popup boxes that the user is expecting to see. The text could then be something along the lines of "Due to recent updates, navigation popups is no longer compatible with this site. Click here for instructions on how to use an older version." That could then link to a page explaining how to copy and paste in an older version of popups.
  • Fail silently, so that the page renders as if popups was not installed. Tra (Talk) 22:36, 15 April 2009 (UTC)
Mmm, good points. The idea is that I want people to realize that we are switching to a requirement of API. We can't go supporting "old technologies" on a tool that is "little" maintained. As a matter of fact, the plan is to switch more and more of popups to API and writeAPI, so that the JS code can be cut down significantly, reducing maintenance work. I guess your second option might be worth considering.... --TheDJ (talk • contribs) 00:24, 16 April 2009 (UTC)
Done. --TheDJ (talk • contribs) 09:58, 16 April 2009 (UTC)

I also figured it's about time I switched the edit counter link. My personal preference would be Soxred93/X!. If you think that is a bad idea, please let me know. --TheDJ (talk • contribs) 09:58, 16 April 2009 (UTC)

TheDJ: I suggest you add that "importStylesheet('MediaWiki:Gadget-navpop.css');" line to your User:TheDJ/slimpopups.js. Thus people only have to load the javascript and that in turn will load the CSS. I stumbled on that and wondered "WTF? Why do I only get transparent popups?". Took me a while to figure out what had happened.
If you are going to overwrite the old User:Lupin/popups.js then you have to load the CSS from your code, or you will break it for those of us that load User:Lupin/popups.js from our personal /monobook.js instead of using the gadget.
The preliminary results from my testing is that your popups seems to be working both in my Firefox 2.0 and my Opera 9.02.
--David Göthberg (talk) 14:57, 16 April 2009 (UTC)
The official version is now the gadget version. The User:Lupin/popups.js is only a loader for the gadget and it's stylesheet, primarily kept in order to facility any 3rd party websites that use it. My version will replace the "Gadget' code, and thus need not include the stylesheet. --TheDJ (talk • contribs) 15:15, 16 April 2009 (UTC)
Ah, I didn't notice that. So all good then. And thanks for taking care of the popups script. It is a lovely script that makes life much easier for us editors, and it does need some updates.
--David Göthberg (talk) 18:19, 16 April 2009 (UTC)
Yeah I like it myself, that's why I work on it :D. I don't foresee myself doing a full rewrite of it any time soon, but some things just needed to get fixed and I guess I'm doing it. --TheDJ (talk • contribs) 21:06, 16 April 2009 (UTC)

The changes have been deployed now. If you hear of any problems, drop me a line on my talkpage. I'm busy with other stuff, but i'll check that the talk regularly, in case there is any blowback. --TheDJ (talk • contribs) 17:22, 19 April 2009 (UTC)

Woohoo!!! Thanks! Saintrain (talk) 22:26, 21 April 2009 (UTC)
  • Currently the allowed formats for wikilinks are:
Wiki format Link to page Display
[[xxxx]] xxxx xxxx
[[xxxx]]wwww xxxx xxxxwwww
[[xxxx|yyyy]] xxxx yyyy
[[xxxx|yyyy]]wwww xxxx yyyywwww

But it would be useful if this was also allowed:

Wiki format Link to page Display
[[xxxx||yyyy]] xxxxyyyy xxxx

and this would be useful if the whole of the article name is not the first part of all derived forms, e.g. to link from a word "emancipated" to page emancipation, [[emancipat||ion]]ed is shorter, and perhaps easier to read in text, than [[emancipation|emancipated]]. Anthony Appleyard (talk) 09:48, 17 April 2009 (UTC)

That makes the wikilink syntax unnecessarely complicated IMO. We now have [[link|display]], and we shouldn't complicate it further by combining these; it results in an ambigous link construction. — Edokter • Talk • 13:49, 17 April 2009 (UTC)
Agreed. While personally, I like the suggested syntax, we should be keeping this as user-friendly as possible. — Martin (MSGJ · talk) 13:56, 17 April 2009 (UTC)

I don't think this is necessary; at best it saves a few characters for those prepared to learn an esoteric syntax. I do not agree that the proposed structure is "easier to read in text" than the current system, which seems to be completely adequate. This does not enable any constructions that cannot already be made with the existing syntax, and completely obstructs our ability to develop the link syntax in other ways. Happy‑melon 16:29, 17 April 2009 (UTC)

I think it's a nice idea, but doesn't the pipe trick already cover most applications? --Hans Adler (talk) 10:50, 18 April 2009 (UTC)

Why not link directly to emancipated? --NE2 12:07, 18 April 2009 (UTC)

Neat idea. Not sure the suggested syntax is the best though. SharkD (talk) 03:51, 22 April 2009 (UTC)

Proposed moves

When a page move fails (because there is already something other than a redirect back to the page one is trying to move from), one is presented with an error message and a link to the Proposed moves page, which has instructions about how to proceed. Would it be possible for the error message actually to generate automatically the templates etc, and insert them on the talk page of the article whichit is proposed be moved and onto the Proposed Moves page for the editor? This would be much more user-friendly in my opinion. DuncanHill (talk) 15:39, 21 April 2009 (UTC)

Short answer, "no". The message is just that, a message (MediaWiki:Articleexists, I believe); it cannot take spooky actions like editing pages. The message could probably be improved to give more details on what edits need to be made, however, but that must be weighed against the risk of triggering the "I'll just copy and paste" reflex in newbies if they see instructions that are too complicated. Happy‑melon 15:48, 21 April 2009 (UTC)
This would be a nice feature for TW or something though. Could it be easily coded in javascript? Algebraist 15:53, 21 April 2009 (UTC)
I'm not a newbie and I find the instructions for requesting a pagemaove too complicated! I think I used a requested move today when a db-move would have done. DuncanHill (talk) 19:21, 21 April 2009 (UTC)

The problem is that you can only move a page "over" the redirect if (a) it has only one revision and (b) the redirect points to the page you are moving. This is too restrictive; while one can move [[Foobar]] → [[Foobar (disambiguation)]] or [[Foobar (Beavis and Butt-head character)]] one cannot follow-up by moving [[Foobar (river in Europe)]] → [[Foobar]], etc. without layers of bureaucracy. A better restriction would be "contains no revision that isn't a redirect". That way the software would check for potentially useful content (a misplaced or merged-and-long-forgotten-about stub for example), and it would do a damnbetter job of it than the average admin. Basically if there's something buried in a pile of various redirects, it ought to be moved to an appropriate title (though we may want it to remain a post-merge redirect) or explicitly deleted, but not automatically as a result of a page-move.

But yeah, it would be easy enough to add the features described above. — CharlotteWebb 19:03, 21 April 2009 (UTC)

Switching between two monobook.js files

Looking quickly, I didn't see a tool for flipping between two monobook.js setups quickly; I'd prefer to have different tabs for different CSD chores. Anyone know of one? - Dan Dank55 (push to talk) 20:00, 21 April 2009 (UTC)

Why not just have two different subpages containing the different sets of code, and have your monobook.js just contain importScript(whichever you're using right now)? Algebraist 20:03, 21 April 2009 (UTC)
I'm still looking for a single button that would switch between the two versions with a click, rather than having to retrieve, edit and save. - Dan Dank55 (push to talk) 23:46, 21 April 2009 (UTC)
Hmmm... You could probably hack this together by modifying User:Xenocidic/statusChanger2.js –xeno talk 23:50, 21 April 2009 (UTC)
One rather silly way of doing this would be to abuse the skin system. Put one lot of script in monobook.js, and the other lot in myskin.js along with importStylesheet(Mediawiki:Monobook.css). Algebraist 23:56, 21 April 2009 (UTC)
A smarter way would be to switch in your monobook based on something in your cookie, and write yourself a bookmarklet that will change the cookie accordingly, to switch from one setup to another and reload the page (or do more sophisticated work getting rid of the old tabs and executing the scripts from the new setup). Amalthea 00:02, 22 April 2009 (UTC)

You could make a routine that has a table of the specific revision numbers for the different versions you want, then it could revert your monobook page to that revision when clicked. Of course the list of revision numbers would need to be on a sub page so they would not change when the monobook page is reverted. Chillum 00:05, 22 April 2009 (UTC)

Interwiki link in user talk page

How comes the link [[it:Discussioni utente:A. di M.]] in my user talk page is shown inline, rather than in the sidebar like other interwiki links? --A. di M. (formerly Army1987) — Deeds, not words. 00:05, 22 April 2009 (UTC)

I think because talk pages are not supposed to have interwiki links. –xeno talk 00:09, 22 April 2009 (UTC)
Yes. As stated in meta:Help:Interwiki linking, this feature does not work on talk pages. Algebraist 00:12, 22 April 2009 (UTC)

Global preferences?

Resolved
 – ukexpat (talk) 14:23, 22 April 2009 (UTC)

I was poking around on the meta wiki but couldn't really find a good place to ask this: has there been any attempt to implement global preferences using SUL? It's a bit of a pain to have to set my language, signature, time offset, etc., every time I stumble onto a new sister project. –xeno talk 18:17, 17 April 2009 (UTC)

It might actually be coming to a wikipedia near you ! bugzilla:14950 --TheDJ (talk • contribs) 02:16, 18 April 2009 (UTC)
Excellent =) I would've been surprised if I had been the first to propose this. –xeno talk 16:11, 18 April 2009 (UTC)
I feel your pain, xeno. :) EVula // talk // ☯ // 16:19, 18 April 2009 (UTC)

Scanning a database dump

Resolved
 – ukexpat (talk) 14:22, 22 April 2009 (UTC)

Moved to help desk. 12:50, 20 April 2009 (UTC)

Page layout

Discussion moved from Help Desk

Often I happen across articles where the unfortunate placing of images results in great chunks of vertical whitespace. I find it hard to understand how so many people could make these edits and fail to notice that they had messed up the page layout, and I'm curious to know whether this is just a peculiarity of my browser or the way it's set up (I'm using IE 7). If anyone here has other browsers I wonder if they might be kind enough to check this specimen page: http://wiki.riteme.site/w/index.php?title=Crab&oldid=284196945. Does everyone else see a huge gap in the section "Evolution and classification"? 86.161.42.104 (talk) 04:25, 17 April 2009 (UTC).

  • I see the gap in IE7 and not in Firefox 3 or Chrome. A peculiarity of IE7 indeed, I guess, but maybe someone can explain why? Perhaps we can just take the "get a better browser" responses as read :) Gonzonoir (talk) 11:13, 17 April 2009 (UTC)
Thanks, that's interesting. I usually fix these layout problems when I see them; now I'm wondering if I ought to be doing that. I suppose it's still a reasonable thing to do since so many people use IE? I think you're right: a Wikipedia techie should look at this and figure out if Wikipedia is generating valid HTML that IE is failing to render it correctly (in which case is there a way of working round the IE bug?), or if Wikipedia is generating faulty HTML and it just so happens that some other browsers cope gracefully and IE doesn't (in which case the faulty HTML should be fixed). What's the procedure for making that happen? 86.146.47.94 (talk) 11:42, 17 April 2009 (UTC).
I'd suggest the village pump technical noticeboard. I'd bet on this issue having been discussed before, though, so maybe leave this question live for another day or so in case a knowledgeable reader can resolve it here first.
I agree that we need to fix IE-specific issues, certainly; however much I personally think the browser's pants I can hardly pretend the majority of our readers won't be using it :) Gonzonoir (talk) 12:05, 17 April 2009 (UTC) —Preceding unsigned comment added by 86.150.100.38 (talk)
While it's true the gap doesn't exist in Firefox, Firefox does incorrectly (or unattractively) render the horizontal rules behind the images/templates. Notice also how the image of the hermit crab gets shoved into the wrong section of the article in Firefox, whereas in IE7 the positioning is lexicographically correct. Not sure which browser's behavior is proper from a coding perspective, or (more importantly) desired. SharkD (talk) 06:46, 21 April 2009 (UTC)
This appears to be an IE bug. The image is placed in a div with class="thumb tright", and the tright CSS style includes both "float: right;" and "clear: right;". The float property removes the div from the normal flow and the clear property causes it to be positioned after (below) other right aligned boxes (the infobox in this case). The relevant section of the CSS Specification contains the statement, "Since a float is not in the flow, non-positioned block boxes created before and after the float box flow vertically as if the float didn't exist." This calls for the main text to flow without interruption, as is correctly rendered by Firefox and Chrome. IE has it wrong. If the clear property were contained in a block element with out a float (such as <br style="clear:right" />, IE, Firefox, and others will correctly apply the clear to the main flow and will position that and subsequent blocks below the right side floats. -- Tcncv (talk) 00:43, 22 April 2009 (UTC)
Just wanted to add that the page looks as expected in IE 8. However, I see the large whitespace reappear if I run IE 8 in IE 7 "compatibility view". So, the problem appears to be fixed in the latest version of IE. Radiant chains (talk) 01:03, 22 April 2009 (UTC)
Thanks guys. Since I presume large numbers of people are still running IE 7, do you agree that it is reasonable to adjust the layout to fix these whitespace problems where it can be done without damaging the readability or aesthetics of the article? 86.161.41.18 (talk) 04:48, 22 April 2009 (UTC).
In the more extreme cases such as the Crab article, yes go ahead. For less severe cases, use good judgment. I don't think we want to produce suboptimal layouts to accommodate one browser if the savings is only a few lines of white space. If you do make such changes, be sure to note the IE7 display issue in the edit comment, or the next Opera, Chrome, or Firefox user may revert the change. -- Tcncv (talk) 23:01, 22 April 2009 (UTC)

Hatnote with article name ending in period

The template for sending people to an article with a similar name ends up putting two periods in a row if the article name ends in a period. Look at Alex Lee.Vchimpanzee · talk · contributions · 22:39, 21 April 2009 (UTC)

Pro-tip: create a redirect which doesn't have a period at the end, and link to it instead. — CharlotteWebb 02:24, 22 April 2009 (UTC)
I thought of that, but where redirects can be avoided (disambiguation pages being the exception) it probably should be done. Also, the article being linked to is tagged and might be merged. Naturally, I wouldn't want to create a redirect to something which might itself be redirected.Vchimpanzee · talk · contributions · 15:03, 22 April 2009 (UTC)
Just use {{dablink}} instead of {{for}}, and you can format it however you want to. --Floquenbeam (talk) 16:07, 22 April 2009 (UTC)

Melicope sororia

Resolved
 – ukexpat (talk) 14:21, 22 April 2009 (UTC)

What the heck is with Melicope sororia? Links to it are blue; it has a history; some old versions and diffs can be viewed; it has a "what links here"; it hasn't been deleted; but the article itself can be neither seen nor edited. Hesperian 02:40, 22 April 2009 (UTC)

Try it now; it was acting freaky for me too, but I purged the cache and it seems OK now. --Floquenbeam (talk) 03:04, 22 April 2009 (UTC)
Yep, it's fine now; thanks. I purged the cache myself (using &action=purge) and it didn't fix it. You seem to have purged the cache with a dummy edit, which I couldn't do because I was unable to edit the page. Weird. Hesperian 03:06, 22 April 2009 (UTC)
Cache purging didn't work the first 2 times I tried it, but worked on the third. You just have to want it more than the server does. :) --Floquenbeam (talk) 03:10, 22 April 2009 (UTC)
Oh, very good! I'll remember that. :-D Hesperian 03:13, 22 April 2009 (UTC)

Brackets in page names

Would allowing brackets in page names be a major undertaking? I assume that the answer is yes, but the ability to use brackets in page names would allow some chemistry articles to be put at their correct title, eg Benzopyrene. shoy (reactions) 16:49, 22 April 2009 (UTC)

Oh, you mean square brackets? — Martin (MSGJ · talk) 16:56, 22 April 2009 (UTC)
It would break the page URL; see Wikipedia:Naming conventions (technical restrictions). ---— Gadget850 (Ed) talk 17:07, 22 April 2009 (UTC)
I'm aware of that, I was asking if it was possible to modify MediaWiki to accommodate square brackets. shoy (reactions) 19:39, 22 April 2009 (UTC)
The problem with that is if you wrote [[one]] and [[two]], it wouldn't be clear if that meant one and two or one]] and [[two. Tra (Talk) 19:58, 22 April 2009 (UTC)
Could it work if you were allowed to percent-encode it like [[Benzo%5ba%5dpyrene]] ? --83.253.240.46 (talk) 20:24, 22 April 2009 (UTC)
I moved it to Benzo〚a〛pyrene, but I'm not sure if that's actually better. Move it back if you don't like it. --NE2 17:35, 22 April 2009 (UTC)
Those Unicode brackets are displayed as question marks on my old computer. And the URL looks messy ...
"Benzo(a)pyrene" with parentheses seems fairly commonly used according to Google.
(See also WT:Chem#Benzopyrene) --83.253.240.46 (talk) 18:12, 22 April 2009 (UTC)

Grey bar in IE6 when not logged in

If I'm not logged in, I get a grey bar at the top of every page (immediately below the links to discussion, edit this page etc.). It doesn't appear if I'm logged in. Also, it doesn't appear in IE7 (whether logged in or not).--A bit iffy (talk) 16:05, 23 April 2009 (UTC)

I see it too, when using my very old Internet Explorer 5.5 and not logged in. And I don't think I have seen it before.
--David Göthberg (talk) 21:46, 23 April 2009 (UTC)
I'm suspecting something with centralnotice/sitenotice. Is it somewhere around that position ? Can you try disabling JS, because that should kill any sitenotice loading ? --TheDJ (talk • contribs) 22:12, 23 April 2009 (UTC)
Right, when logged out the thick grey bar is exactly where the centralnotice is shown when logged in. And yeah, I suspect that is the culprit too. I disabled javascript in my IE 5.5 and yes, the grey line disappeared. (And as a well known side effect the Wikipedia logo lost its transparency. Ugly! :))
--David Göthberg (talk) 22:26, 23 April 2009 (UTC)

Template:Infobox WikiProject/sandbox

Need help at Template:Infobox WikiProject/sandbox, how do you make 25em the default for the width and 300px the default for the image size parameters and also allow for optional values in those two fields? Thanks --Funandtrvl (talk) 18:41, 23 April 2009 (UTC)

You appear to have done that properly. For those who want to know: {{{parameter|default}}} will do the trick. x42bn6 Talk Mess 19:00, 23 April 2009 (UTC)

Weird space at top of article

I can't figure out what's going on in this article: Mark Sanchez. The infobox template was changed, and now its creating a massive space for reason that I can't figure out --it seems to work on other articles using the template. Any ideas? --Bobak (talk) 00:46, 24 April 2009 (UTC)

That appears to be explained (if not addressed) at the template talk page: Template talk:Infobox NFLactive#Whitespace. Maralia (talk) 00:56, 24 April 2009 (UTC)

Missing tab

Wikipedia:Administrators' noticeboard/Geopolitical ethnic and religious conflicts doesn't have a "New section" or whatever tab. How is that fixed? ▫ JohnnyMrNinja 02:38, 24 April 2009 (UTC)

To get a "new section" link on non-talk pages, add the magic word __NEWSECTIONLINK__ anywhere on the page. I went ahead and did this for the page you linked. — Gavia immer (talk) 03:01, 24 April 2009 (UTC)
Thanks! ▫ JohnnyMrNinja 03:27, 24 April 2009 (UTC)
You're welcome. — Gavia immer (talk) 03:44, 24 April 2009 (UTC)

Heading fonts

  • The types of headings can be viewed here.

The above is the hierarchy of headings in which H2 is the only heading which is not bold. Does anyone know why and how this came about? Also, why there is a line stretching across the page associated with H2? Rotational (talk) 12:21, 14 April 2009 (UTC)

I've replaced the list of headings with a link to the sandbox so that this discussion doesn't affect the archiving system. Tra (Talk) 12:37, 14 April 2009 (UTC)
Actually, the h1 heading is also not bold, it's just in a large enough font size that it appears quite thick. h1 and h2 headings have a bottom margin, that's the "line" you see. Is there some reason why this shouldn't be the case? Happy‑melon 13:12, 14 April 2009 (UTC)

Well, the H1 line makes some sort of sense being the title heading, but using the H2 repeatedly in an article cuts the page into unaesthetic watertight compartments, which H3 and H4 don't. Is it possible to use an H2 heading and have the option of a bottom margin or not? If one could skip from H1 to H3 without using H2 there would be no problem, but some editors have hysterics at that and quote MoS:Headings in support Rotational (talk) 13:57, 14 April 2009 (UTC)

And they are right. As much as headings are about esthetics (which is a very personal preference), they are even more so about how we order article content. --TheDJ (talk • contribs) 14:12, 14 April 2009 (UTC)

This is about why it is necessary to have a bottom margin associated with the H2 heading when the line itself quite clearly doesn't help to order the article content. Rotational (talk) 22:19, 14 April 2009 (UTC)

If you are asking why the headers show as they do, then it is because they are defined in http://wiki.riteme.site//skins-1.5/monobook/main.css. You add personal CSS to change them as you desire. --Gadget850 (talk) 18:09, 14 April 2009 (UTC)

Well we wouldn't want the same type of heading to appear differently in different articles. Changing the CSS to removing all the horizontal section lines might not be a bad idea actually. I think the current divided appearance just subtly reinforces the page-within-a-page misnomer among users who don't understand how they actually work. You probably don't know how often we get questions like "why is there no edit history for just this section?" or "why can't I add just one section to my watchlist?" or "why don't these '→' links work anymore?", occasionally from admins "why I can't I protect just this one section?", etc. — CharlotteWebb 18:11, 14 April 2009 (UTC)

Another long-time WP editor has pointed out that Wikipedia's line-associated H2 heading is "a somewhat unusual layout convention, and one that is not followed by most publications, including our nearest rivals citizendium, encyclopedia.com, britannica.com, etc." Rotational (talk) 22:19, 14 April 2009 (UTC)
Your britannica.com link has horizontal lines beneath the H2 headings. --Amalthea 22:30, 14 April 2009 (UTC)
The lines are almost invisible and do not extend across the page.....Rotational (talk) 06:10, 15 April 2009 (UTC)
The difference is light gray versus darker gray, they're both 1 px solid lines and they both stretch all the way across the body content, technically neither go all the way across the page, britannica just has the TOC on the right, so the content area isn't as wide. Also, encyclopedia.com doesn't use heading tags for section headings, they use an h2 where we use an h1 (for the article title), they use strong tags for the section headings, which semantically, I'm not sure is entirely correct. Mr.Z-man 00:12, 16 April 2009 (UTC)
Well, if one has to have a line going with the H2 heading, the light grey version is a vast improvement. Can't someone just tweak the CSS and see what the reaction is? Rotational (talk) 09:15, 17 April 2009 (UTC)

Back to the original post: The appearance of bold also seems to be dependent on the browser zoom. At 100%, all of the headings H1 through H4 appear bold on my computer, but if I zoom out a step (ctrl+-, or ctrl + mouse scroll wheel), the H2 level appears noticeably lighter than the H1, H3, and H4. It's possible this may also be dependent on the display's DPI setting, which may explain why some users see the headings differently. -- Tcncv (talk) 23:12, 15 April 2009 (UTC)

"the hierarchy of headings in which H2 is the only heading which is not bold. Does anyone know why and how this came about?"

My guess: To make it look different than the other heading levels, in particular the h3 heading. Instead of having a sequence of heading levels where the only difference is small changes in size, it (and the horizontal line) makes h2 stand out from the subordinate levels.

"Also, why there is a line stretching across the page associated with H2?"

To make it clear that the non-bold h2 is superordinate to the bold h3. And to provide visual navigation aid for the eyes – on a long talk page such as this it makes it easy to find the next topic when scrolling the page quickly. The line clearly separates the talk topics from each other. In articles it makes it easier to find the beginning of the major sections.

"using the H2 repeatedly in an article cuts the page into unaesthetic watertight compartments"

"watertight"? – does the line in some way hinder you from reading past it?
Re "unaesthetic" – it's been some time since I used a WP user-account, but can't skins create different looks for headings? Or your personal CSS?

"the line itself quite clearly doesn't help to order the article content."

It helps me see the order.

"with the H2 heading, the light grey version is a vast improvement."

That's a personal preference.
--83.253.240.46 (talk) 09:30, 21 April 2009 (UTC)

I think the H2 line is essential to keep long articles and Talkpages readable. They give a clear and useful indication where the next section or message starts, and I'd hate to see the line go. Yintaɳ  21:32, 24 April 2009 (UTC)

A possible way to find hoaxes

It is worrying how hoaxes which miss NPP can lurk for months or years and only get detected by luck or accident. It is not easy to know where to look for them, but I have an idea: would it be possible to generate a list of "surviving articles whose author edited only on a single day" (or, better but more complex, "only edited within one period of three days") and maybe, "over n months ago"? Hit-and-run is a trademark of most hoax authors, who I guess don't want to risk their main account in case they are found out. Such a list would contain many perfectly genuine articles, but it would be a good place to check for possible hoaxes. JohnCD (talk) 17:21, 19 April 2009 (UTC)

If the WP Statistical machine - who do such a great job could do a dump of articles - could possibly do all edits by those who edit less than a 100 edits and who appear to have less than 10 articles and all in less then 10 days - might be a bigger scope - but might come with some real doosies - they also tend to be orphan articles or close SatuSuro 00:04, 20 April 2009 (UTC)

We've got a category of articles edited by only one user, that might help. Really such a query would take up masses of time and server cycles; I don't think it'd be worth it. Ironholds (talk) 07:21, 20 April 2009 (UTC)
Fair enough! good point SatuSuro 07:25, 20 April 2009 (UTC)
Agreed, if it would be laborious it's not worth it. I'll look at "articles edited by only one user" but I don't think it's what I'm looking for: long-standing hoax articles have usually been edited by others who tidy them up and correct the spelling and tag them "unreferenced", but don't actually read them and think, hey, this sounds unlikely. JohnCD (talk) 09:05, 20 April 2009 (UTC)
The number of server cycles used is irrelevant, per WP:DWAP. Users are free to choose how much time they contribute. Thus, if anyone is willing to do this, they should! Whatever404 (talk) 12:06, 20 April 2009 (UTC)
Server usage is only (usually) irrelevant for normal editing. If this were run as a bot using the API, it would need to meet the bot policy's "does not consume resources unnecessarily" requirement and if it were run on the Toolserver would need to ensure it didn't use an unnecessary amount of resources there, as it is a shared server. This could theoretically be done using a database dump, but the last successful full history metadata dump was 6 months ago, so the data might not be too useful. Mr.Z-man 17:51, 21 April 2009 (UTC)
Ouch. I hadn't noticed that it had been that long since stub-meta-history was completed for enwiki. Dragons flight (talk) 10:40, 24 April 2009 (UTC)
  • The only real way to avoid hoaxes is to thouroughly check every article as it comes in. User:AlexNewArtBot already helps by sorting new articles and delivering lists to subscribed WikiProjects. Perhaps you can ask them to somehow set up a list of articles that don't fit into a specific category. That's the most likely place for hoaxes to hide. - Mgm|(talk) 10:31, 24 April 2009 (UTC)

Daily break

Can anyone modify this script so that it logs me out at a particular time each day (e.g. between 2:00 and 11:00 and between 14:30 and 19:30 local time every day)? Thanks in advance, A. di M. (formerly Army1987) — Deeds, not words. 23:38, 23 April 2009 (UTC)

See above @ #Enforce wikibreak at work?. –xeno talk 00:41, 24 April 2009 (UTC)
No, I want to be logged out altogheter, not just prevented from editing: I would still waste my time reloading my watchlist over and over again! :-) --A. di M. (formerly Army1987) — Deeds, not words. 01:01, 24 April 2009 (UTC)
I've attempted this, but it is just cargo cult programming as I don't know any JavaScript. (I just took the existing script, looked up how to extract day/month/year from a date, assumed the syntax was the same as in C++, and hoped for the best.) It doesn't appear to work; can anyone take a look at it? --A. di M. (formerly Army1987) — Deeds, not words. 12:43, 24 April 2009 (UTC)
Now it worked. (But I was sure I had refreshed the cache, hadn't I?) --80.104.236.167 (talk) (A. di M.) 15:12, 24 April 2009 (UTC)

Search Results - Article Creation Wizard

The discussion at WP:VPR#Search Results - Article Creation Wizard has kind of petered out, but I'd still like to know whether the Search Result special page can be edited, or whether it can be made editable, or whether we can change the redlinks there to point to a new intermediate Article Creation page. Anyone? Rd232 talk 12:49, 24 April 2009 (UTC)

Weird characters

Can anyone tell me what the unusual, several-lines-high, characters in the old side of this diff? Nyttend (talk) 04:07, 24 April 2009 (UTC)

That looks like what happens when you copy/paste from some text document that's using a different or proprietary text encoding. basically, the odd symbols would look like normal text in the original app, but the web browser doesn't understand them, and so interprets them as best it can as unicode characters. The vandal was probably inserting some oh-so-poignant phrase s/he'd copied from somewhere, and was probably as mystified as you were that it came out that way. --Ludwigs2 06:13, 24 April 2009 (UTC)
It's called "mojibake". —Remember the dot (talk) 06:16, 24 April 2009 (UTC)
Ugh, I hate that word. sounds like something you find on the menu at some B-class ethnic restaurant, which inevitably turns out to be pickled toad eggs wrapped in cabbage leaves, or something like that. --Ludwigs2 17:30, 24 April 2009 (UTC)

bot to hard code convert template results

Resolved
 – BRFA withdrawn. Happy‑melon 17:55, 24 April 2009 (UTC)

Hiya, been gone for like 5 years and now I'm back. So I've written (or maybe am writing) a bot to take instances where the Convert template is used and get the results of the conversion and hard code those results into the page. This will keep the server from having to do those conversions whenever the page is parsed.

Common Questions

  • Yes, I know the conversion is not horribly expensive. I'm just proposing making them just oh so slightly less expensive. If it becomes a little bit more efficient then that's better than not a little bit more efficient. Any arguments against efficiency are well... absurd (IMO).
  • I am not deprecating the convert template (I hope it grows and expands and is used more and more and more), it will still be used by lots and lots and lots of human editors, I'll just eventually come around and rip it out.
  • Yes, it is a pretty big job, but not a hard one, and certainly not a big very deal. I was flabbergasted when the people who've responded thus far weren't either for it or totally ambivalent.

Well, feel free to drop your $.02 at Wikipedia:Bots/Requests for approval/KevinBot

Thanks and have a great day. Kevin Rector (talk) 05:14, 24 April 2009 (UTC)

See WP:PERFORMANCE. It's far better to keep the wikitext straightforward and easy to edit than worry about how long it takes to execute a few templates. {{convert}} has been optimized so that it no longer causes problems like it did at one point about 1.5 years ago. —EncMstr (talk) 05:17, 24 April 2009 (UTC)
I'm afraid I don't like this idea. When I see a convert template, I know the conversion is accurate and hasn't been vandalized. This sort of vandalism is difficult to spot, in the article and in diffs: if lots of people were conversant in both systems, we wouldn't need the conversions, and it's often difficult to distinguish between an anon correcting a conversion and a vandal changing the number. Checking the conversions is more than trivial for units one is not familiar with (for example, metric horsepower, which does not signify anything to me). For this reason, I tend to replace "hard-coded" conversions with {{convert}}. jhf (talk) 17:40, 24 April 2009 (UTC)

The BRFA has been withdrawn. Happy‑melon 17:55, 24 April 2009 (UTC)

Template redirect to redirect doesn't work

Just now I was looking at the Recently Featured Articles on the home page, and I clicked on "SkyTrain" to see which one it was. It took me to SkyTrain (Vancouver), where I was startled to see one section that rendered as:

Expansion
  1. REDIRECT Template:Future public transportation

It took me a little while to see what was going on here. It turned out that the actual wikitext was 

 ===Expansion===
 {{future canadian public transportation}}

and that the wikitext for Template:future canadian public transportation (with a small C) was: 

 #REDIRECT [[Template:Future Canadian public transportation]]

and the wikitext for Template:Future Canadian public transportation (with a capital C) was: 

 #REDIRECT [[Template:Future public transportation]]

Evidently the double redirection threw the template-expansion process off. I fixed this one by changing Template:future canadian public transportation to redirect directly to Template:Future public transportation, but this obviously goes against the intent of whoever created the Canada-specific template: they must have meant that at some point it would contain Canadian-specified wording and would no longer redirect to the generic one. (Which seems silly to me, but this is not the forum for that.)

I figure there are two ways to go. (1) Something could be done to prevent people from setting up template redirects that won't expand properly, and some sort of automated search could be done to apply the type of fix that I did in this case. Or (2) these things should be made to expand properly.

I don't care personally which way you resolve this, so please don't bother responding to me (I rarely use this IP address anyway). But I'm sure there are people who do care, and I'm posting here to call the matter to their attention. --70.48.228.103 (talk) 06:20, 24 April 2009 (UTC)

Double redirects are generally fixed by bot; this one just hadn't been fixed yet after this redirection. --NE2 06:26, 24 April 2009 (UTC)
You might like to read Wikipedia:Village_pump (proposals)/Archive 44#Double redirects for more background on redirect chains. — Martin (MSGJ · talk) 17:49, 24 April 2009 (UTC)

Where to find list of Wikipedia Icons?

I am attempting to locate a list of standard wikipedia icons and images that are used for adminsitrative purposes and are not relevant to the content (like the wikipedia globe is a standard wikipedia icon and may appear on many pages but it has nothing to do with the page). I have come up with some like these : 

		// <img alt="" src="http://upload.wikimedia.org/wikipedia/en/d/d6/Ambox_style.png" width="40" height="40" border="0" />
		wikiImgs.add("Ambox_style.png");
		// <img src="/skins-1.5/common/images/magnify-clip.png" width="15" height="11" alt="" />
		wikiImgs.add("magnify-clip.png");// tiny small window and large window in the bottom right of caption
		// <img alt="Sister project" src="http://upload.wikimedia.org/wikipedia/en/thumb/4/4a/Commons-logo.svg/40px-Commons-logo.svg.png" width="40" height="54" border="0" />
		wikiImgs.add("40px-Commons-logo.svg.png");// 
		//<img src="/skins-1.5/common/images/poweredby_mediawiki_88x31.png" alt="Powered by MediaWiki" />
		wikiImgs.add("poweredby_mediawiki_88x31.png"); 
		//<img src="/images/wikimedia-button.png" border="0" alt="Wikimedia Foundation"/>
		wikiImgs.add("wikimedia-button.png"); 
		//http://upload.wikimedia.org/wikipedia/commons/thumb/f/f8/Wiktionary-logo-en.svg/50px-Wiktionary-logo-en.svg.png
		wikiImgs.add("wikimedia-button.png");
		// http://upload.wikimedia.org/wikipedia/commons/thumb/5/5f/Disambig_gray.svg/30px-Disambig_gray.svg.png'

I would like a more complete list please. Is there a place where I could find this more complete list ?

Thanks! —Preceding unsigned comment added by 209.2.51.125 (talk) 13:38, 24 April 2009 (UTC)

In general all these elements are contained in HTML blocks that have the classes, metadata or noprint. As far as I'm aware, there is no definitive list of the images that are used in this kind of way, and it will also vary heavily between the different language versions of wikipedia. --TheDJ (talk • contribs) 13:58, 24 April 2009 (UTC)
Browsing through the directories at http://svn.wikimedia.org/viewvc/mediawiki/trunk/phase3/skins/ will show up what is distributed in the default Mediawiki install. Of course Wikipedia has other widely used images as well, but this should be a start. Dragons flight (talk) 15:30, 24 April 2009 (UTC)

Everything running smoothly?

During the past few days I've been getting a lot of lagging servers, "sorry we've encountered a problem", crashing page-reversals, etcetera. From here (Europe) it looks as if the WP servers can't keep up with the global demand. Is there anything known about this? And is there a place where I can get the latest info about the servers and their workload? Yintaɳ  22:08, 24 April 2009 (UTC)

See the links on this page, especially Mark's Request Stats which has what I think you're asking for. —EncMstr (talk) 22:17, 24 April 2009 (UTC)
Great stats, thanks! Yintaɳ  22:37, 24 April 2009 (UTC)

TOC colors?

Is there any way to change the colors in the TOC (for everyone) without changing the rest of the page? Is there anything in Category:TOC templates that would do this? Would this be possible with the software? ▫ JohnnyMrNinja 17:26, 24 April 2009 (UTC)

You could make a 'fake' TOC where you place the text __NOTOC__ followed by the code for the table below (you can see it on the edit screen). Replace #99ffff with the colour you want and replace each of the lines beginning with <li class="toclevel-1"> with links to each section in the page. Bear in mind that you would need to update the TOC every time you add/remove/rename a section and the show/hide links won't work. Also, this is very non-standard so I'd advise against using it outside of userspace. Tra (Talk) 18:14, 24 April 2009 (UTC)

Contents
Yikes, don't do that anywhere outside your userspace, as Tra says; people will eat you alive if you try and make ToCs hardcoded anywhere else. That said, nice idea Tra. Happy‑melon 18:58, 24 April 2009 (UTC)
That is a nice idea, but it wouldn't work for a Wikiproject talk page... — Preceding unsigned comment added by JohnnyMrNinja (talk • contribs)
There are some templates, like {{TOCright}} or {{TOCleft}}, that mess with the format a little bit, but that's about it, and neither have to do with colors. hmwithτ 09:52, 25 April 2009 (UTC)

A question

I came across some markup I haven't seen before, and I was wondering if it was a new technical ability for admins. The most recent edit by this user was deleted, but without actually deleting/restoring the page to which it was made. How was this done? (i.e., so I can do it in the future) Thanks. Parsecboy (talk) 03:33, 25 April 2009 (UTC)

Maybe it's [RevisionDelete], the new version of Oversight?--Aervanath (talk) 04:00, 25 April 2009 (UTC)
That's what I was wondering, I just hadn't seen it before. Thanks, Aervanath. Parsecboy (talk) 10:29, 25 April 2009 (UTC)

Very screwy attributions

OK, something weird just happened. I had someone come to me because of this edit attributed in the page history to me. I had not even looked at that page today, much less reverted anyone's changes to it. (Nor have I been on any recent changes patrol.) If you look at my contributions, they do not show that edit in there. What is going on??? LadyofShalott 05:37, 25 April 2009 (UTC)

  • I see it in your contributions. Do you have the page on your watchlist? I once rolled back an edit with a stray click while looking at my own. Someguy1221 (talk) 05:47, 25 April 2009 (UTC)
    • OK, now this is getting even stranger. Yes, you're right, it is showing in my contributions now. It wasn't there before. (I used a ctrl-f search to look for the word geology to make sure I wasn't just overlooking it when I checked before.) I do have it in my watchlist, and if I had not seen that it was not listed in my contributions before, I'd think your explanation made sense. Now I'm just confused. I do know Benjiboi posted here not long ago about an edit he made, that showed up in the article history with someone else's username attributed, a very similar situation. LadyofShalott 05:55, 25 April 2009 (UTC)
    • Here is the link to the similar thread of what happened to Bebjiboi. [13] I am wondering just how often these glitches are occurring. LadyofShalott 06:05, 25 April 2009 (UTC)
      • considering the number of edits that wikipedia gets in a day (a number I don't know, but am assuming is huge), as well as the synchronization that needs to be done between databases and slaves, I'd be shocked if there wasn't a noticeable number of errors of this sort. It's a statistical phenomenon: every data transfer has a tiny percent chance of transfer errors, and every transfer error has a tiny percent chance of being undetectable by the system; multiply by 15 bazillion edits per month and you end up with a near certainty of something odd happening, somewhere. probably someone made that edit and a computer glitch happened that credited it to you; possibly you made some other revert and the computer randomly reverted this page. it's even possible that someone did something unrelated somewhere unrelated, which ended up being interpreted as you doing this. craziness. you should feel blessed, in that same way that those who get struck by falling meteorites feel blessed that the universe has singled them out for ultra-special treatment (in that last moment before the meteorite turns them into something resembling grape jello). --Ludwigs2 06:51, 25 April 2009 (UTC)
        • I was suspicious of this edit comment when I saw it, but given the above, maybe the IP wasn't just messing around? [14]. Dougweller (talk) 07:08, 25 April 2009 (UTC)
          • well, don't get the statistics wrong. errors are exceedingly rare - they make 'one in a million' look friendly - but when you have 50 million trials, one in a million will happen (more or less) 50 times. and it will happen to somebody who will (generally) not see it as hitting the lotto number. IPs are a little tougher, too. if it's a dynamic IP, then the address gets reset with each connection, so it's entirely possible for someone else to make an edit with your IP. I suspect the same thing happens if someone piggybacks your wireless connection (I doubt wikipedia distinguishes between you on your router and someone else on your router unless you're using named accounts).--Ludwigs2 07:21, 25 April 2009 (UTC)
  • LoS, if it makes you feel any better, not very long ago my watchlist showed me being rollbacked - except it was actually my version being rollbacked to. Cosmic rays ionize microchip components, Ethernet connectors get loose, and servers get flaky. I've predicted imminent failures before and the WMFtechs fix it before I'm proved right. Possibly they plan this on coffee-break (or hang on my every word). :) (And I think it's around 300K edits/day) Franamax (talk) 13:11, 25 April 2009 (UTC)
  • Comment. Not to hit the ooow-spooky or lock the gates alarms but perhaps an "unexplained misattributed edits" bin should be started and maintained in the possibility this is something more problematic or an actual odd hack? Luckily both myself and LadyofShalott raised the issue and also brought it here. Likely these are the tip and most of these go unnoticed and unreported. Or should we place in the denial - what we don't think about helps us sleep - pile? -- Banjeboi 14:49, 25 April 2009 (UTC)
    • Let's just sleep happily. :) Every few months I see something weird happen. As long as it doesn't happen again, 'tis all fine. Experience with this desk does show that every so often, a server dies and the consequences reverberate. For instance, a few months ago a server lost a load of images, leaving only the thumbnails behind. Except for major failures though, this kind of stuff can really not be tracked down in a high-volume environment, since there's no way to recreate the exact conditions where the failure occurred. Certainly, PEBCAK is the most likely explanation, but not always. I looked at the mis-rollback I mention above every way I could, it was absolutely a glitch in the sytem - but I'm not going to go back through 100's of edits to figure out where it was, and no dev is going to look at it anyway. Shit happens. Now if it happens twice in a row, I'll be all over it! Franamax (talk) 01:09, 26 April 2009 (UTC)
  • I also had a odd edit phenomenon. I was adding a message to User talk:Shappy [15] by editing the "Welcome Back" section, and when I saved my edit, the entire rest of the page (except for the section I was editing) disappeared. I had to revert myself and the 2nd time the edit worked. First time that happened to me. Strange. — Becksguy (talk) 15:19, 25 April 2009 (UTC)

mw-missing-article message on image page

I was going through images at Special:UncategorizedFiles, and came across an error when I tried to view the image page of File:North American Fresh Water Run-Off1.png. The "File history" section shows that there was indeed information on the page when the image was first uploaded. However, the page history for the image description is completely empty. The only content now shown on the page is:

The database did not find the text of a page or revision that it should have found, named "File:North American Fresh Water Run-Off1.png" .

This is usually caused by following an outdated diff or history link to a page that has been deleted. Other possible causes are an incorrect URL, or deleted revisions in an existing page.

If this is not the case, you may have found a bug in the software. Please report this, making note of the URL and how you reached that URL.

Radiant chains (talk) 08:26, 25 April 2009 (UTC)

I'd classify that as "definitely weird" and as such opened a thread at AN to ask an admin to check for anything grunts can't see. Franamax (talk) 10:38, 25 April 2009 (UTC)
The file came from http://ca.geocities.com/grandcanal2005/. It appears to be copyright and there is no evidence permission was received. Therefore, I have deleted the image. If somebody wants to contact the owner and get permission, they can upload it again. Jehochman Talk 10:43, 25 April 2009 (UTC)

How easy would it be to set up a template or similar to speed up the disambiguation of links? So that rather than manually changing [[link1]] to [[link1 (reason a)|link1]] you could, for instance do [[ (reason a)|link1]] ? Spaces aren't allowed at the start of page names, right? —Preceding unsigned comment added by 78.151.177.80 (talk) 10:40, 25 April 2009 (UTC)

Have a look at the WP:Pipe trick. --Amalthea 11:14, 25 April 2009 (UTC)
Doctor, heal thyself! ([[WP:pipe trick|]]: pipe trick) --NE2 11:55, 25 April 2009 (UTC)

Function parser depth limit changes ?

Have there been any changes to the function parser in the last 24 hours ?

A template I am working on with deeply nested functions has been working for the last two weeks automagically stopped working a few hours ago, and it seems to be related to the nested depth of #if: statements.

Peet Ern (talk) 14:18, 25 April 2009 (UTC)

I don't think so. What's the template? Happy‑melon 23:46, 25 April 2009 (UTC)

Clipped Thumbnail

Can someone explain why in Figure 2 of the article Buck converter the left part of the text has been clipped off? (I see this in Google Chrome and Internet Explorer. Comparing the thumbnail with the intermediate-sized file File:Buck_operating.svg, I notice that the text in the thumbnail has been shifted to the left, relative to the drawing. Is this something that can be fixed in the SVG code of the original image? Thanks! Peter Chastain (talk) 15:37, 25 April 2009 (UTC)

Short answer: we convert SVGs into PNGs for display on actual article pages, as you may already know. Unfortunately, the conversion software is pretty buggy, and will sometimes misplace text like that. The actual raw SVG file seems to be fine (Firefox renders it correctly), but the version in the article tripped over whatever bug in the renderer causes such problems. Unfortunately, I don't know of any way to fix this. — Gavia immer (talk) 23:09, 25 April 2009 (UTC)

Text-related problems in SVGs are often the result of using unsupported fonts. In this case, though, I'd guess rsvg doesn't support embedded fonts. Solutions include changing the image to use supported fonts, or converting the text into paths (so it's no longer text at all). Anomie⚔ 23:24, 25 April 2009 (UTC)

I have made a request at Wikipedia:Village pump (proposals)#Jumbled up mess of link types. It does not require a developer to fulfill. -- IRP ☎ 04:49, 26 April 2009 (UTC)

Section editing brings up wrong section

Hi,

At the Computing reference desk, I've tried clicking "edit" on the last few sections to edit just that answer, and it causes me to start editing the previous section.

Thanks - Tempshill (talk) 14:47, 26 April 2009 (UTC)

I found that it appeared to be inserting the wrong section number in the URL. Manually changing the number in the URL was the workaround. Tempshill (talk) 15:28, 26 April 2009 (UTC)

template won't categorize?

Resolved

I went to use this template - {{str_trim}} - and had some difficulty finding it (I'd forgotten the exact name). I looked in Category:String manipulation templates, where it doesn't appear, but when I finally found the template I saw that it had a valid tag for that category, and had had one since 4-March. so why didn't it get added? I'd try a purge, but the page is protected. can someone fix or explain this? —Preceding unsigned comment added by Ludwigs2 (talk • contribs) 15:23, 26 April 2009 (UTC)

I null edited the page, and it works now. That's the old problem, see Help:Category#Categories and templates. Amalthea 15:32, 26 April 2009 (UTC)
(edit conflict)The category is on the /doc page, which does have a purge link. ---— Gadget850 (Ed) talk 15:34, 26 April 2009 (UTC)
yeah, I knew about that problem, but I didn't think it would take a month. does the categorization stall until someone edits the categorized page? and does purging the /doc page work? I'd have thought you'd need to purge the page itself. --Ludwigs2 15:59, 26 April 2009 (UTC)
Purging isn't enough. The template needs to be (null) edited to add it to the category. The job queue supposedly takes care of it eventually, but the last time we talked about this here, at Wikipedia:Village_pump_(technical)/Archive_59#Category & job queue sanity check, nobody could say with certainity. --Amalthea 16:26, 26 April 2009 (UTC)
Retrieved from "https://wiki.riteme.site/w/index.php?title=Wikipedia:Village_pump_(technical)/Archive_59&oldid=1088278328"