Is it possible to search through all the edit summaries at once, or search through all previous versions of a page? This would be helpful if I'm trying to find when a specific edit was made to an article.--Aervanath's signature is boring 05:10, 8 May 2008 (UTC)[reply]

One would need a database dump or access to the toolserver. If you are looking for something specific and you don't mind describing it, I'm sure somebody reading this will be able to quickly find it for you. — CharlotteWebb 15:04, 8 May 2008 (UTC)[reply]

Oh. No, I was just asking in general. It's not a big deal, just a tool that would come in handy.--Aervanath's signature is boring 15:28, 8 May 2008 (UTC)[reply]

You can use your browser's Find feature, though you'd still have to do it page by page (but if you view 500 edits at a time, that cuts down on it). EVula // talk // ☯ // 20:24, 8 May 2008 (UTC)[reply]

That would only work for exact strings as I'm not aware of any browser with a built-in regex search (though it might be possible to create a javascript tool for that... shrug). Also if I understand correctly, the user also wants to search the text of old revisions, which obviously wouldn't be feasible in a web browser. — CharlotteWebb 13:26, 9 May 2008 (UTC)[reply]

Ah, but yes, it is possible to search through old versions of a page - see WP:EIW#History. -- John Broughton (♫♫) 18:05, 10 May 2008 (UTC)[reply]

The talk page Template_talk:Non-free_fair_use_in is being very difficult to edit, save and see diffs, giving lots of time outs followed by a Wikipedia server generated error message. This happens for me only at that page, and my belief is that this is being caused by one of the comments present there, which has some kind of code in it that gets replaced by a lot of error messages in red. I tried to edit that comment out, but the time out of death didn't allow me. An administrator should look into it ASAP, and someone more knowledgeable than me should most probably report a further bug to WikiMedia, as this thing is most surely going to be exploited by vandals as soon as they discover how to reproduce it. -- alexgieg (talk) 16:56, 9 May 2008 (UTC)[reply]

The talk page does not load at all for me. Looking at the edit box here, I noticed that it contains three transclusions of User:Superm401/Sandbox2, which is one gigantic clusterfuck. I suspect it is the source of the problem (because I can only get the "show preview" button to work if the sandbox template is removed). — CharlotteWebb 17:08, 9 May 2008 (UTC)[reply]

Update: ParkingLotTherapy has been applied [1]. — CharlotteWebb 17:10, 9 May 2008 (UTC)[reply]

Fixed it by going directly to the edit URL and archiving all the old stuff. I'm not sure which code caused the problem but now both the archive and main talk page load fine. Equazcion •✗/C • 17:12, 9 May 2008 (UTC)[reply]

Guess not. Equazcion •✗/C • 17:13, 9 May 2008 (UTC)[reply]

Indeed. We don't want to DOS the servers... I can't figure out what the template does, but it looks like a masterpiece of sorts. User:Gracenotes/Maximage is mere peanuts comparatively... Gracenotes^T § 17:55, 9 May 2008 (UTC)[reply]

This seems to be a VERY exploitable trick right there. That template was doing a massive exponentiation calculus. No wonder the server that was attempting to fulfill the request was giving up. This is clearly an exploitable DOS avenue, and MediaWiki would do well to add some kind of limitation so that such expressions would be stopped before causing damages. -- alexgieg (talk) 18:01, 9 May 2008 (UTC)[reply]

Should probably be taken to bugzilla. Equazcion •✗/C • 18:09, 9 May 2008 (UTC)[reply]

Someone please do it then. I'm not used to bugzilla and learning, registering etc. just for that, ouch... In the meantime, I've requested an editprotected change to the exploitable template. -- alexgieg (talk) 18:17, 9 May 2008 (UTC)[reply]

If I read the archive correctly, the creator of this improvised arithmetic device (IAD) requested that it be added to the {{Non-free_fair_use_in}} template. — CharlotteWebb 18:29, 9 May 2008 (UTC)[reply]

I think that he was just making an honest contribution: the complicated code wasn't added to the sandbox until months later. Unfortunately the page history is fragmented and I can't find exactly what it looked like at the time. But yes, this is exactly why we protect high-risk templates. If someone actually managed to get code like that into a high-use template, the servers are going down... Happy‑melon 18:51, 9 May 2008 (UTC)[reply]

Beans, beans, the magical fruit... just saying. Equazcion •✗/C • 18:57, 9 May 2008 (UTC)[reply]

I did think that when I posted it (actually just after, but it was too late :D). I guess it's fairly obvious to even the most luddite of 'professional' vandals, but there are many worse ways to damage the site, some of them permanent (and no way am I going to spill the beans on those on-wiki :D). Happy‑melon 19:00, 9 May 2008 (UTC)[reply]

We're pokin' at it. :) --brion (talk) 19:23, 9 May 2008 (UTC)[reply]

Exponentiation and the pow template

alexgieg left a note at Template talk:pow. If there is a DOS issue here, I hope that one of the system admins will resolve it. Since anyone can create a new copy of the template anywhere, I don't see a benefit of changing that template just to avoid the potential of abuse. — Carl (CBM · talk) 18:48, 9 May 2008 (UTC)[reply]

It does seem reasonable to ask if exponentiation can be added to the expr parser function directly. — Carl (CBM · talk) 18:51, 9 May 2008 (UTC)[reply]

I submitted a bugzilla enhancement request for this: Template:Bug. --CapitalR (talk) 03:28, 10 May 2008 (UTC)[reply]

Isn't this possible already with {{#expr:2^8}} = 256? —Remember the dot ^(talk) 04:28, 10 May 2008 (UTC)[reply]

OK, I went ahead and changed Template:Pow to just use the built-in MediaWiki operation, which should be much faster. Please let me know if I've inadvertently introduced any problems. —Remember the dot ^(talk) 04:31, 10 May 2008 (UTC)[reply]

The ^ operator became available about a week ago, see Wikipedia:Wikipedia Signpost/2008-05-02/Technology report#New features. —Remember the dot ^(talk) 04:37, 10 May 2008 (UTC)[reply]

Template:Floor and Template:Ceil are two more that can probably be changed over. Still reviewing them... --- RockMFR 04:46, 10 May 2008 (UTC)[reply]

Great, I wasn't aware of the new features. Thanks for letting me know. --CapitalR (talk) 04:50, 10 May 2008 (UTC)[reply]

I updated Template:Floor and Template:Ceil just now, and they seem to be working fine too. —Remember the dot ^(talk) 20:30, 10 May 2008 (UTC)[reply]

Resolved

I made an edit to List of baryons changing a <references /> tag to {{Reflist}}, and the page started coming up with "Node-count limit exceeded|link=yes|" errors. I reverted, and this didn't fix the problem. I guess this is related to Wikipedia:Template limits, but I can't figure out why this has suddenly become a problem. Can anyone figure this out? Thanks. Mike Peel (talk) 19:47, 9 May 2008 (UTC)[reply]

Yes, it has suddenly become a problem, because someone has decided, in their infinite wisdom, to reduce the preprocessor node count limit from one million to fifty thousand (a factor 20 reduction). This has screwed up several pages, including the entire peer review process, but that someone obviously didn't mind about that. This reminds me a lot of the time when "WP:" and "WT:" were converted into namespace shortcuts: nice idea, but zero points for communication skills. Please up the limit to a least 200000, and please don't mess with limits without consulting editors of affected pages. Thank you. Geometry guy 20:22, 9 May 2008 (UTC)[reply]

Where is this limit set? Mike Peel (talk) 20:28, 9 May 2008 (UTC)[reply]

It's set on the server side, externally. I will inquire on IRC. I'm sure that this is just something the devs overlooked, and we will find some sort of solution in short order. — Carl (CBM · talk) 20:52, 9 May 2008 (UTC)[reply]

Re Geometry guy, I would bet the reason for this is the section above about a broken talk page. Some people were using recursive template invocations in a pretty silly way, which did/does need to be fixed. — Carl (CBM · talk) 20:54, 9 May 2008 (UTC)[reply]

I hope it will be fixed. Please forgive my grumpiness, but I think it is important to express it: attempts to fix issues like this have ramifications, which can interfere with our main goal, improving the encyclopedia, in unexpected ways. Geometry guy 21:10, 9 May 2008 (UTC)[reply]

I see someone already brought up the issue. I hope this is being looked into by those who can do something about it. I've been working on that page for over a month and I just logged in to nominate it for featured list. Imagine my horror when I saw it all mangled up. Does anyone have a time frame for when this would be fixed?[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 21:25, 9 May 2008 (UTC)

Would someone like to enlighten me as to what the hell the preprocessor node count actually counts?? I understand all the other data in the HTML summary, but I have no idea what this statistic actually means. Happy‑melon 21:54, 9 May 2008 (UTC)[reply]

It counts nodes in the parse tree that the parser ("preprocessor") generates from the wiki text of the page. The more complicated the page wikitext is, the higher the node count will be. To really be precise about what it counts, you would need to read the parser source code and see when it creates new nodes. — Carl (CBM · talk) 22:05, 9 May 2008 (UTC)[reply]

If/when we find a nice way to not have the above and similar templates kill the parser dead, you'll get your node count back. --brion (talk) 23:06, 9 May 2008 (UTC)[reply]

Bah, I'm leaving it at the old defaults until Tim gets a chance to tweak it. There's still some awful worst cases, though, we may need a different point for some of the limits. --brion (talk) 23:17, 9 May 2008 (UTC)[reply]

It's appreciated. I'm going to work on making peer review lighter on the system. Is there a template guru around who wants to figure out what's making list of baryons so heavy? — Carl (CBM · talk) 23:21, 9 May 2008 (UTC)[reply]

Thanks for the quick response.[[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 23:25, 9 May 2008 (UTC)

BTW, the List of Baryons is heavy in template use because there is a lot of unconventional things that needs to be written, and since it's in a table with limited horizontal space, not using template can lead to major ungliness. It uses

{{PhysicsParticle}} 5 times, to display uncertainties (retarded I know, but I haven't figure out a better way yet),
{{SubatomicParticle}} 470 times to display particles,
{{su}} 19 times and to display various values and particles,
{{frac}} 122 times,
{{nowrap}} 59 times to make sure that things stay unwrapped in the table,
{{cite journal}} 31 times,
{{cite web}} 1 time,
{{reflist}} 1 time,
{{particles}} 1 time,

for a total of 708 uses of templates.

It will eventually use {{val}} about 200 times when Skylined fixes the val templates bugs. The result is a very pretty list, at the cost of heavy template use. [[::User:Headbomb|Headbomb]] ([[::User talk:Headbomb|ταλκ]] · [[::Special:Contributions/Headbomb|κοντριβς]]) 23:39, 9 May 2008 (UTC)

The underyling problem is that SubatomicParticle generates a huge number of preprocessor nodes during each use. {{SubatomicParticle|electron}} =
e⁻
uses 106 nodes, and it isn't the worst. Presumably we need a more parser friendly implementation of its component templates. Dragons flight (talk) 00:05, 10 May 2008 (UTC)[reply]

I think one of the reasons for lowering the limit is that it was fairly ineffective. Large and transclusion-heavy pages tended to exceed the memory or load-time limits and would fail to load completely well before they hit the template limits. Mr.Z-man 23:55, 9 May 2008 (UTC)[reply]

This appears to have been fixed. Thank you to whoever did that. Geometry guy 15:50, 10 May 2008 (UTC)[reply]

Do someone here have an answer for my question at the Wikia forum thread How do I add a meta tag to the pages in a wiki? Will (Talk - contribs) 03:13, 10 May 2008 (UTC)[reply]

Your link is invalid. — xaosflux ^Talk 03:28, 10 May 2008 (UTC)[reply]

Correct link: How do I add a meta tag to the pages in a wiki?. -- ShinmaWa^(talk) 16:52, 10 May 2008 (UTC)[reply]

Assuming you run this wiki yourself, you can add a little extension, such as mw:Extension:MetaDescriptionTag or mw:Extension:MetaKeywordsTag etc. --brion (talk) 23:01, 10 May 2008 (UTC)[reply]

I don't have access to the server. How do I check what is installed? Will (Talk - contribs) 02:02, 11 May 2008 (UTC)[reply]

It's at Special:Version. Algebraist 08:49, 11 May 2008 (UTC)[reply]

Resolved

It is just me, or something is wrong with the references here? Tried to fix it myself, but I couldn't :( --Racso (talk) 04:00, 10 May 2008 (UTC)[reply]

A vandal had edited out a closing ref tag. Does it look right now? —Ashanda (talk) 04:05, 10 May 2008 (UTC)[reply]

Perfect! --190.13.12.115 (talk) 21:57, 10 May 2008 (UTC)[reply]

Is there any addition that will auto-sign my talk page comments? Is this being considered for developer action? I know there's a bot to do it, but I'd really like it if it was automatic. --Dan Beale-Cocks 15:09, 10 May 2008 (UTC)[reply]

There's no way to do that currently. The idea has been suggested and rejected many times in the past, so no, there's nothing in the works (at least, that I'm aware of). An automatic system couldn't determine reliably to which edits to add signatures and which to ignore. Equazcion •✗/C • 15:12, 10 May 2008 (UTC)[reply]

This would be fixed with mw:Extension:LiquidThreads, along with many other things. But that's dead in the water as far as I can tell. —Simetrical (talk • contribs) 15:37, 11 May 2008 (UTC)[reply]

We are currently having problems with several things displayed at the top of pages and their positions. This needs to be handled. Below are subsections for some of the issues.

--David Göthberg (talk) 12:06, 11 May 2008 (UTC)[reply]

For non-logged-in users, every page has headers that run into each other

This came from the help desk. I've confirmed this behavior. -- ShinmaWa^(talk) 16:47, 10 May 2008 (UTC)[reply]

If you're not logged in, then two messages are displayed: the one about early registration for Wikimania, and also a link to tips on how to use Wikipedia (such as "Find out more about navigating Wikipedia and finding information").

Unfortunately these two messages are very close together and the resulting effect is ugly. Does anyone know how to improve things? I can't see where the messages come from.

NB: maybe this is because of the small size of the device I'm using (an Asus Eee PC) so perhaps it doesn't happen for everyone.

Thanks,--86.157.11.211 (talk) 15:59, 10 May 2008 (UTC)[reply]

For some reason the smaller "Ten things you may not know about Wikipedia" or the redundant "Interested in contributing to Wikipedia?" does not appear in Opera. 199.125.109.104 (talk) 18:08, 10 May 2008 (UTC)[reply]

Oops, it wasn't there on May 6, but it is there now (the smaller notice along with the centered one). 199.125.109.104 (talk) 18:12, 10 May 2008 (UTC)[reply]

Yeah with the Eee PC you are going to have problems, its native being 800X600 right, it works fine if your resolution is 1280x1024, which is what mine is set at.--Kerotan^{Leave Me a Message} Have a nice day :) 19:37, 10 May 2008 (UTC)[reply]

Actually, it's worse than that, being 800*480! So size matters then, does it? Well, quite a few people aren't blessed with 1280*1024, and there's a growing demand for smaller-sized machines. A great thing about the Wikipedia site compared to others is how well it renders on resolutions such 800*480. So as one major trend is for smaller-sized screens, it would be a big pity if Wikipedia weren't able to handle some aspects smoothly.--86.157.11.211 (talk) 20:29, 10 May 2008 (UTC)[reply]

I have to agree that simply saying "if you can't increase your resolution, oh well!" isn't really an adequate answer. With the global reach of Wikipedia and the wide number of machines using them, including low-end laptops/desktops, OLPC machines, internet-enabled appliances, TV set-tops, smart phones, etc etc, we really have to concentrate on usability on all machines. -- ShinmaWa^(talk) 02:34, 11 May 2008 (UTC)[reply]

Yes, the sitenotice needs to have more top margin. I think I know where to fix this MediaWiki:Monobook.css but I have instead reported this to the guy who seems to tinker the most with this MZMcBride, since he probably knows more about this.

I see that he now instead turned off the "anonnotices" for not logged in users. That's a temporary fix, but the problem will be back the moment we need to have a message for not logged in users again.

--David Göthberg (talk) 11:57, 11 May 2008 (UTC)[reply]

We previously had three messages showing to anonymous users – the sitenotice (Wikimania), the donation banner, and the anon tips (Ten things..., etc.). One of them has been disabled (the sitenotice). The anon tips should be merged with the donation banner, however, we should wait a few weeks to do so (see further info here). If the anon tips are causing serious layout issues for a lot of users (after the sitenotice was removed), we can disable the anon tips for a month or so (and perhaps write some new tips in the meantime). --MZMcBride (talk) 14:33, 11 May 2008 (UTC)[reply]

I think the anon tips are what moved the title down, they appear to be new as of the end of March? 199.125.109.105 (talk) 16:04, 11 May 2008 (UTC)[reply]

What's up (or rather down) with the header?

I know that things can be placed above the header and underneath the tabs at the top of the page. For some reason some kind of unnecessary line break appears to exist there which is screwing up some of the templates as the big grey horizontal line is cutting straight through them. At first I noticed it on user page templates, but take a look at this article template (for co-ordinates). Doesn't look good at all. Can someone fix this or are we stuck with it now? .:Alex:. 21:12, 10 May 2008 (UTC)[reply]

Yes, the page title with its underscore some weeks ago became lower. I have been looking around the CSS codes and other places to try to figure out why but have not found anything yet.

If anyone knows anything: We need to know if this is permanent or not so we know if we should modify all templates that place things in the upper right corner. That's a truckload of templates and includes things like the featured article star, protected pages padlocks and coordinates. I would prefer to move the page title back to its old position higher up, if we could figure out how.

--David Göthberg (talk) 12:03, 11 May 2008 (UTC)[reply]

My "solution" as regards co-ordinates running into the grey line is to simply duplicate the co-ordinates as per my edit here. I do this from time to time when I come across the ugliness of the co-ordinates running into the line, but obviously it would be much better if it were fixed. I think this particular problem has been around for maybe a year.--217.44.174.185 (talk) 13:20, 11 May 2008 (UTC)[reply]

Fascinating, the code {{coord|51|23|3.3|N|0|33|38.71|E|type:landmark|display=title}} locates the coordinates 4 pixels lower in the title than the code {{coord|51|23|3.3|N|0|33|38.71|E|type:landmark|display=inline,title}} I don't recommend going around editing the bazillion articles that use coordinates, but the template could probably be fixed so that it does the same thing all the time - both use the same {{coord}} template. 199.125.109.105 (talk) 14:22, 11 May 2008 (UTC)[reply]

The coords break when sitenotices / anonnotices are used. The small icon / coord placement is a complete absolute positioning hack, so it is entirely unsurprising that it breaks with the slightest change. We need a better solution altogether, however, I personally wouldn't go around trying to "fix" the current CSS and positioning, as more than likely than not, you'll break more than you fix. With the anonnotice gone and the sitenotice being dismissable, the coords shouldn't be hitting the grey <h1> line anymore. --MZMcBride (talk) 14:36, 11 May 2008 (UTC)[reply]

This change was probably due to r32382, just from your description. If so, it will probably last for some time, but it's not necessarily permanent. A more complete fix is desirable (see Template:Bug). —Simetrical (talk • contribs) 15:42, 11 May 2008 (UTC)[reply]

That's about the right time frame, March 24. Is the sitenotice the rotating notices at the top right that includes "Ten things you may not know", or is that called the anon-notice? I did notice that the centered "Early Registration for Wikimania" notice is gone, and the title has moved up 25 pixels from where it has been since the end of March. It is now 39 pixels high (64 or 40 for logged in users depending on if they hide "Early registration"), with about 11 or 12 of that for the rotating notice at the top right. I spoke to soon, I see that the centered "Early registration" is now gone. But now it's back again. Anyway, the coordinates appear 7 pixels above the line with the Early registration notice and 1 pixel of the globe is above the line and the coordinates just below the line if coord display=title is used instead of coord display=inline,title, so if the coordinates were consistently located about 3 pixels lower than where they are using display=title, they would be above the line with the Early registration notice (and in conflict only with very long article names and small browser windows), and below the line without the Early registration notice, and also below the line for anon users, 1 pixel farther, but no one is going to complain about a 1 pixel difference, I would think. 199.125.109.105 (talk) 16:11, 11 May 2008 (UTC)[reply]

(unindent) about this issue with the coordinates. I personally use importScript('User:TheDJ/movecoord.js'); to correct the position of the coordinates at the DOM level (where it should be fixed). --TheDJ (talk • contribs) 19:15, 12 May 2008 (UTC)[reply]

Watchlist-notice

Until today the template {{watchlist-notice}} was displayed on top of both the user watchlist and the recent changes list. This was so that we admins could add watchlist notices to that template and they got displayed in both places at once, thus efficiently reaching us that edit the Wikipedia. Today MZMcBride changed it so that the message is only displayed in the user watchlist.

I think it was good that the notices were displayed in both places, since I know that some editors hardly ever use their own watchlist but only work with the recent changes list.

Before I go on, an explanation:

• MediaWiki:Anonnotice – Visible on top of all pages for not logged in users. If this message is empty then the system instead shows the sitenotice to those users. A trick is to set the anonnotice to for instance <p></p> so it doesn't display anything but still prevents the not logged in users from seeing the sitenotice.
• MediaWiki:Sitenotice – Visible on top of all pages for all users. Not logged in users see this one too if the anonnotice is empty.

I can only guess: Perhaps MZMcBride thinks we should use the sitenotice instead to reach editors and then use the "empty trick" he applied to the anonnotice today so only logged in users see the sitenotice? Then I disagree, since judging from myself: Since the sitenotice is too intruding, I click it away immediately, while the watchlist notice I often leave so I can take a look again later. Besides, I think that the "empty trick" is a bit too much of a hack, since it means that when we add sitenotices we must check if the anonnotice has the trick applied or not.

--David Göthberg (talk) 12:34, 11 May 2008 (UTC)[reply]

The actual place to put watchlist messages is MediaWiki:Watchlist-details. When the rollback drama was going on, the dismissable part of the message was put into a template to allow one dismiss button to work in multiple places. Because the message was about rollback, we decided to put it at the top of RecentChanges because those who do RC patrolling would benefit more than most with a change in rollback. However, RecentChanges has very little to do with any of the other messages put into the watchlist notice, such as Board elections, and so I finally removed it. At no time did anyone intend for the message to stay there permanently, it was only done because of the relationship between rollback and RC patrolling. However, it, of course, can be re-added if there's consensus, though, to me, it seems like an awfully strange place to put a message.

As for the anonnotice / sitenotice thing, I spoke with the person who added the messages. The Wikimania notice really only needed to be shown to logged-in users, but because Cbrown added it to both messages, I figured we could show it to anons for a week, and then remove it. The Anonnotice hack (or a variation) has been used for years. Logged in users who immediately dismiss the sitenotice without reading it will not see that message ever again unless they log out. If you'd like, you can think of the anonnotice hack as a security feature. Very rarely do messages need to be broadcast to everybody. Checking one extra page is no big deal. --MZMcBride (talk) 14:29, 11 May 2008 (UTC)[reply]

I don't know if this has been/is being discussed somewhere else, or even if this is the correct place to post this, but I think that non-admin rollbackers should be allowed to make more than 5 rollbacks in a minute before being throttled. I think that they (OK, we) should be able to make at least 10 rollbacks (15 would be better) before being throttled.

Considering that rollback rights are not automatically assigned (as autoconfirmed rights are), I do not see any reason that we should be restricted so much. I use Huggle rather vigorously, and I would be able to be much more effective in my vandal-fighting (especially during high-volume times) if I was not slowed down by having to force Huggle to mimic the rollback feature for ⁵/₆ of the time after I use up my 5 rollbacks in 10 seconds. (which I do fairly frequently when vandalism is at its peak)

Also, I sometimes encounter someone who adds external links (pointing to pages in the same website) to many articles (think 15-25) before I realize what he/she is doing. I review their contribs in Huggle to ensure that they are all spam, and if they have not been warned previously, I usually give them either a level 2 or a level 3 warning, open their contribs, and click on the rollback links. It is incredibly annoying to only be able to do 5 rollbacks, and then having to click "undo" for the rest. J.delanoy^gabs_adds 02:04, 11 May 2008 (UTC)[reply]

I have to agree. I had the same problem when reverting someone who had spammed about 120 articles today. Even though I took a second or two to double check every single diff using popups, I still bumped on the limit several times. Rather frustrating and time consuming. —Ashanda (talk) 02:36, 11 May 2008 (UTC)[reply]

I haven't personally hit the limit but I agree that since there's approval to receive rollback it could probably be increased a bit. xenocidic (talk) 02:38, 11 May 2008 (UTC)[reply]

The throttle is set in the site configuration, but it is easy to change. You just need to point the developers the presence of the mythical beast of consensus. Titoxd^{(?!? - cool stuff)} 03:19, 11 May 2008 (UTC)[reply]

That's what I am hoping to get here... J.delanoy^gabs_adds 13:29, 11 May 2008 (UTC)[reply]

Doesn't seem like it should be much of a risk to increase the limit to, say, 25 or even 50 rollbacks per minute. Actually, I'm not sure it even really needs a limit at all; after all, the worst you could do with unlimited rollback would be to run a bot to rollback every page and every new edit as soon as it's made — and that would just get you blocked quickly and the rollbacks reverted. Yes, that would be a nuisance, but hardly a serious one. Probably about equal in overall annoyance level to a 5-minute database lock or thereabouts. —Ilmari Karonen (talk) 14:05, 11 May 2008 (UTC)[reply]

It sounds like double or tripling the limit would help editors, while posing minimal risk. Unless a case is made for a higher limit, I don't think we should go there; there is a clear downside, and - absent a demonstrated need - why go there? (So count this as a vote for doubling or tripling the current limit.) -- John Broughton (♫♫) 01:52, 13 May 2008 (UTC)[reply]

So, would 15 rollbacks per minute enjoy consensus? —Ilmari Karonen (talk) 19:15, 13 May 2008 (UTC)[reply]

I'd say so; the benefit is real, and the opposition is not. :) EVula // talk // ☯ // 20:02, 13 May 2008 (UTC)[reply]

Why on Earth do we even need a limit? We can just revoke it from someone who abuses it. _{1 != 2} 20:10, 13 May 2008 (UTC)[reply]

I agree that we don't need a limit on the number of reverts a minute: I don't see why it was necessary to include a limit in the first place. Rollback is very easy to remove if it's abused, and changing non-admin rollback from five reverts a minute to unlimited will be a major positive, in my opinion. Acalamari 20:32, 13 May 2008 (UTC)[reply]

I think the limit was placed when non-admin rollback was first introduced, as part of a compromise to those that were opposed to it. I'd be fine with the restriction's removal, now that we've established that granting rollback isn't the encyclopedia-destroying concept some may have been concerned it would be. As has been pointed out, abuse can easily be dealt with by any admin. EVula // talk // ☯ // 20:55, 13 May 2008 (UTC)[reply]

←OK, it looks like several people think it's a good idea, so, how do we move forward from here? Should I create a poll somewhere to try to get more community input? If so where should I create it? As a subpage of WP:ROLLBACK? J.delanoy^gabs_adds 21:11, 13 May 2008 (UTC)[reply]

The feature request is bug 12760. I support this measure and would prefer no restriction, the current limit makes rollback useless at nuking spam. MER-C 06:50, 14 May 2008 (UTC)[reply]

I put a limit on it because I thought we were going to be sensible and give rollback to all users, and I had the limit set accordingly. I'm not attached to it, and it was pretty much plucked from thin air, so there's no big deal in upping it two or three-fold. FWIW, I've hit this limit too, and it's a bit of a pain. — Werdna talk 09:16, 14 May 2008 (UTC)[reply]

As the person who filed bug 12760 back when rollback was first made available, this obviously has my full support. I can confirm that the limit is easily reached during busy periods when only a handful of people are patrolling recent changes. While I have addressed this to some extent in Huggle by falling back to normal reversion rather than just displaying an "Action throttled" error message, the difference in speed can be significant Gurchzilla (talk) 12:10, 14 May 2008 (UTC)[reply]

• Why do the links for the contents page not work?
• Why do the bullet points look wierd? (they're black squares)
• Why is there major lag when I'm typing? (what I've typed appears after I've stopped typing)

The Vandal Warrior (talk) 12:41, 11 May 2008 (UTC)[reply]

After finding even more errors and serious lag I decided to "emulate to Internet Explorer 7" only to find out that it doesn't work, so I had to uninstall Internet Exlporer 8 and restart my computer. The Vandal Warrior (talk) 13:17, 11 May 2008 (UTC)[reply]

IE8 is a beta. That means it doesn't necessarily work right. There's a fairly large list of known issues, I'm sure, although I don't know if it's public. If you find any errors, it would be best to report them to Microsoft, not us. —Simetrical (talk • contribs) 15:44, 11 May 2008 (UTC)[reply]

Indeed, this first IE8 beta is a *verrrrry* preliminary developer beta, and a lot of stuff is very buggy in it. You shouldn't use it for your daily browsing. --brion (talk) 17:46, 11 May 2008 (UTC)[reply]

I gave up on IE7 altogether when using it on Wikipedia due to the extreme lag time in loading pages. It happened in more than one location, on multiple computers, so it can't be blamed on some site configuration on my end. I've been forced to use Firefox. Corvus cornix_talk 18:58, 12 May 2008 (UTC)[reply]

Hmm, Internet Explorer (actually, MSN Explorer Premium) is slightly faster for me than Firefox. —Preceding unsigned comment added by 71.107.170.231 (talk) 02:46, 13 May 2008 (UTC)[reply]

Speed is kinda the same for me, but IE tends to piss its pants and die less when I'm loading a page. However, FF doesn't do it too often (~once/day)... -Jéské ^{(v^_^v E pluribus unum)} 03:26, 13 May 2008 (UTC)[reply]

I wonder if it could be a problem of a combination of Classic Skin and IE7? Corvus cornix_talk 04:11, 13 May 2008 (UTC)[reply]

I am a user in telugu wikipedia. I am trying to learn bot programming using python. I downloaded the python wikipedia framework. When I tried to login, I am getting the error as follows. I am accessing internet through a proxy server (might be having a firewall, dont know exactly). Does this error has any thing has to do with that?. Is there any alternative to running the bot? The edits i am trying to experiment with the proposed bot are only minor edits like adding the categories to one or two pages. It will not be dangerous. once i confirmed that it is going to work correctly, I will request permission to run it.

E:\python\pywikipedia>python login.py
Checked for running processes. 1 processes currently running, including the curr
ent process.
Password for user Ravibot on wiktionary:te:
Logging in to wiktionary:te as Ravibot
Traceback (most recent call last):
 File "login.py", line 277, in <module>
   main()
 File "login.py", line 273, in main
   loginMan.login()
 File "login.py", line 225, in login
   cookiedata = self.getCookie()
 File "login.py", line 144, in getCookie
   response, data = self.site.postForm(address, predata, useCookie=False)
 File "E:\python\pywikipedia\wikipedia.py", line 3137, in postForm
   return self.postData(address, data, sysop = sysop, useCookie=useCookie)
 File "E:\python\pywikipedia\wikipedia.py", line 3160, in postData
   conn.endheaders()
 File "C:\Python25\lib\httplib.py", line 860, in endheaders
   self._send_output()
 File "C:\Python25\lib\httplib.py", line 732, in _send_output
   self.send(msg)
 File "C:\Python25\lib\httplib.py", line 699, in send
   self.connect()
 File "C:\Python25\lib\httplib.py", line 667, in connect
   socket.SOCK_STREAM):
 socket.gaierror: (11001, 'getaddrinfo failed')

--Ravichandrae (talk) 13:06, 11 May 2008 (UTC)[reply]

From my moderate knowledge of pywikipedia, I suspect that the problem is with some combination of your computer, internet connection, and the pywiki framework, rather than your bot code. Are you behind a proxy server? Pywiki doesn't like proxies very much IIRC. Happy‑melon 17:15, 11 May 2008 (UTC)[reply]

Would it be possible to tweak my watchlist so it has a live RSS feed? RC-0722 ^247.5/1 15:48, 11 May 2008 (UTC)[reply]

http://en.wikipedia.org/w/api.php?action=feedwatchlist See the API documentation for more information. Mr.Z-man 17:40, 11 May 2008 (UTC)[reply]

Thanks. RC-0722 ^247.5/1 04:01, 12 May 2008 (UTC)[reply]

There are a number of options listed at WP:EIW#Watch. -- John Broughton (♫♫) 01:55, 13 May 2008 (UTC)[reply]

Our current tools for blocking and protecting pages don't match our real needs. A lot of our vandalism comes from dynamic IPs that have a fairly narrow range of interests. Take the unstoppable User:Josh Gotti, for example. You can't block his IP range forever, because it's basically "all dial-up users in Cincinatti". You can't semi-protect the articles he vandalizes, either, because it's a huge swath of music articles. User:Soccermeko is similar: dial-ups out of Atlanta, with a fixation on Nicole Wray and related artists. Final example is User:Editor652, a Cox Cable IP user that is obsessed with fiddling with number of blacks living in Honduras, and interest that ripples across a wide number of articles on Latin America.

All three of these cases have similar characteristics: an unblockably wide IP range, too many articles being vandalized to leave on infinite semi-protection, and a demonstrated willingness to enlist their sock drawer in furthering their goals.

What I would like to get feedback on is an IP-range protection feature. Admins would be able to specify a list of CIDR ranges to protect an article from. If an anonymous or registered editor matches the CIDR range, he would be blocked from editing the article. A flag would need to be available that would exempt a registered account from the check, with the default being to subject the account to checks. That way, if someone else in Cincinnati takes up an interest in pop music, there would be a method to allow him to edit by appealing to an admin. Kww (talk) 16:24, 11 May 2008 (UTC)[reply]

I would suggest that you may be too obsessed with eliminating unproductive edits. For every vandal there are four non-vandals, so I do not see Wikipedia in any danger of collapsing. Cute image, by the way. The school/cd versions of Wikipedia are stable. 199.125.109.105 (talk) 17:13, 11 May 2008 (UTC)[reply]

Yep, and those four non-vandals don't cost me any time or worry at all. I'd like to let more of them edit more often, and the more articles that wind up semi-protected or full-protected, the less they can accomplish.Kww (talk) 17:36, 11 May 2008 (UTC)[reply]

For a lot of people, fixing vandalism is the easiest way to be productive. It takes a couple of minutes to figure out and deal with vandalism (for some a few seconds), while it can take an hour to look up references and make a single contribution to an article. A lot of time I would prefer to just sit around fixing vandalism than trying to add material. It's more like if there were no vandals I wouldn't have anything to contribute than if there were no vandals I would be able to contribute something. Far too many articles are semi-protected for far too long. 199.125.109.105 (talk) 19:08, 11 May 2008 (UTC)[reply]

Restricting editing based on IPs in this fashion has privacy issues: I suspect that if it were implemented, particularly if it became widely used, a clever analysis could narrow down the possible IP address of a logged-in user dramatically; the more widely the system was implemented, the more accurately an IP address could be determined. Apart from that, I think the system would produce a phenomenal amount of administration and require more man-hours to maintain than we have available in people who really understand CIDR and the blocking system well enough to do this without accidentally preventing 'all of China' or 'the entire world minus Cincinnati' from editing an article. What I woudl prefer to see would be a method of blocking a user or IP only from certain namespaces, such that we could be a bit more liberal about blocking larger groups from the mainspace only if we knew they can still contribute on-wiki (or even ask to be IP-block-exempt on-wiki); conversely, we could block myspace-ers and stalkers from everything but the mainspace, to see if they can actually contribute productively. Happy‑melon 17:25, 11 May 2008 (UTC)[reply]

The privacy issues would be manageable by logging. If everytime someone clicked the "edit" button on an article they were blocked from it generated a publicly accessible log entry, you are right. If that log either didn't exist or was only available to people with checkuser rights, the privacy impacts would be minimal.Kww (talk) 17:36, 11 May 2008 (UTC)[reply]

Even if it was only possible to view what's currently available (a list of a user's contributions) useful information can still be gleaned. Every time an editor successfully edits an article which is subject to a range-protection, you know that that user is not in that range. If the protection system becomes widespread, a user who edits a wide range of controversial articles (and there are editors like that, and they are usually top targets for abuse or harassment), their location could be tied down; even if it's only marginally reduced, that is still a violation of the privacy policy. The more widely the system is deployed, and the wider the blocks that are implemented, the narrower the range could become. I'm not saying that it's the equivalent of granting all editors checkuser status, but it is potentially the release of private data which is prohibited by foundation policy. Happy‑melon 19:14, 11 May 2008 (UTC)[reply]

It would have to be ridiculously widespread and you would still have to do quite a bit of studying for that to be true. IPv4 has millions of potential addresses. Assuming such a system would be built like the current ipblock system, only 65000 addresses could be blocked at once. This doesn't even come close to releasing private data even if we start blocking most of the world from editing specific articles. Mr.Z-man 20:14, 11 May 2008 (UTC)[reply]

It's in the billions actually :D. As I said, it's not by any means foolproof and it would need a lot of effort on someone's part to track them down. But of course they're not just going on possible IP addresses... how many of those 4 billion IPs are in the USA? As soon as I see someone editing from 2300-0400 UTC and using "color" I know they're from America... and a lot of editors carefully narrow themselves down a hell of a lot more. I fully agree that it would be difficult, inconclusive and have no guarrantee of success... but we just lost an arbitrator to off-wiki harrassment, and I won't support anything that makes events like that, whoever the target, more likely in the future. Happy‑melon 21:44, 11 May 2008 (UTC)[reply]

You really are serious. By your logic, we should only allow checkusers to block individual IPs and especially ranges using a private log because someone might be able to pin down the general location of new accounts based on the IP addresses that are blocked from account creation. Except in your scenario, someone would have to look at all the articles someone edits, look at all the ranges blocked on those articles (which assumes a massive change to the protection/blocking policy where we start blocking large parts of the world from editing specific articles en masse) then narrow down the ranges they could possibly use to maybe a few thousand (we can only block 1/65536 of all the IPv4 space at a time, so unless they edit 60000 separate articles and we conveniently block a different /16 range on each one, the number of possible large ranges will be at least in the thousands). Eliminate reserved address space and they might be able to narrow them down to a few different ranges, that depending on the ISP may resolve to a specific area, also assuming that the person isn't an admin or has ipblock-exempt. Its an incredibly unlikely scenario requiring hours of work, massive numbers of coincidences, significant changes to protection/blocking policy that would allow huge rangeblocks (hardblocks too, mind you) to be used on specific articles on a grand scale. Mr.Z-man 22:57, 11 May 2008 (UTC)[reply]

Yes thanks for reminding me that that information would also be available to an interested party. The two needn't work in isolation: the list of hardblocked IPs and ranges would provide further information. For the third time, I am not claiming it is foolproof, easy or effective, but it is possible. Combined with the significant increase in administration that would be required, I think it's a solution looking for a serious enough problem. Happy‑melon 08:56, 12 May 2008 (UTC)[reply]

Once again I think you are creating a solution in search of a problem. I do not see vandalism as that big an issue. 199.125.109.105 (talk) 18:48, 11 May 2008 (UTC)[reply]

Note to the bot's though, I would set up two, one that only looks at the odd revision number edits, one that only looks at the even revision numbers, both of which only look at the most obvious types of vandalism, swear words and large unexplained deletions. That way the load is shared between them. 199.125.109.105 (talk) 18:56, 11 May 2008 (UTC)[reply]

I think that Happy-melon's idea is very good. If we restricted someone from, say, everything but talk pages, we could indef-block an IP, and legitimate editors from that IP could easily request account creation and discuss their block, while at the same time, any vandalism coming from that IP would not be prominent, and could be dealt with at leisure. J.delanoy^gabs_adds 19:15, 11 May 2008 (UTC)[reply]

I think what you are really saying is you want a way to block a registered user, or an IP or a range of IPs, from editing a specific article or set of articles. On the surface this would be great for enforcing an ArbCom ruling along the lines of "Kww is banned from editing [Forbidden fruit] for a period of one year", but I worry sometimes about software creep like this. Now I realize in the real world everybody's grandfather will say things like prevention is better than treatment, better than a complete cure even. But to remove more and more elements of free will is also to make evaluation of personal judgment needlessly difficult (due to lack of meaningful examples).

As for the case you gave above, I don't see anything that wouldn't be better addressed by stable versions, liberal issue of ip-block-exemptions, and aggressive encouragement of good editors to create an account. — CharlotteWebb 19:23, 11 May 2008 (UTC)[reply]

• Not really. What I want is a way to prevent socks from attacking an article. As it stands today, Soccermeko creates an account, diddles around for a while until he becomes confirmed, and then goes and screws up the Nicole Wray articles. Once I notice, I have to file a sock-puppet report, revert all his changes, and monitor the situation until someone notices my sock-puppet report and acts on it. Whoever notices the SSP has to go through the effort of confirming it, blocking the new user, and then making sure that I was complete when I reverted all of the sock's edits. If we could simply protect that group of articles against 4.154.*.* and 74.242.*.*, the problem would pretty much go away.Kww (talk) 20:47, 11 May 2008 (UTC)[reply]

I just noticed another discrepancy ... I'm not asking for a way to block an individual registered user from an article (although others may want that). I'm saying that if we blocked an article from being edited by 4.154.*.*, and a registered editor attempted to edit the article from 4.154.2.2, he would be blocked as well, unless the bit was set to exempt him from IP checks. That way, socks are essentially autoblocked.Kww (talk) 23:52, 11 May 2008 (UTC)[reply]

Hey, I resemble that remark. Ip editors are just as important to keep as anyone else. 199.125.109.105 (talk) 19:44, 11 May 2008 (UTC)[reply]

I am assuming you meant to say "I resent that remark". I do not think we should disallow IP edits, but it is a tempting prospect. Your comments above, stating that you do not see vandalism as a big issue, clearly show that you do not understand how vandalism works here. For example, I have made a total of nearly 40000 contributions to Wikipedia. At least 32000 of those are reverting vandalism, warning vandals, filing reports to AIV, RPP, and UAA, etc. I say that to prove that I am qualified to make this next statement: At least 75% of vandalism is made by either IP editors. At least. It is probably closer to 80 or 85%. Nearly all of the rest is made by non-autoconfirmed users (users who cannot edit semi-protected pages). Less than 2% of the vandalism I revert is on pages that are semi-protected. This totally random comment could not have been brought to you without the generous support of our sponsers... :P J.delanoy^gabs_adds 19:58, 11 May 2008 (UTC)[reply]

I take it that you aren't a fan of Are You Being Served?, Mr. Delanoy. I wholeheartedly agree that the view that vandalism isn't much of a problem is fairly unrealistic. My total counts aren't as high as yours, but the percentages are even worse.Kww (talk) 20:47, 11 May 2008 (UTC)[reply]

I did mean resemble. It's a very old malapropism, possibly from Amos and Andy but definitely used by the three stooges. 199.125.109.105 (talk) 15:33, 12 May 2008 (UTC)[reply]

Actually, I like this idea. Though I would extend it to be just another option of protection. Allowing the ability to temporarily (or, if necessary, indefinitely) "page ban" individual editors. Imagine if we could protect the page from 2 revert warring users, leaving the page unprotected for everyone else. (Socking could then cause full or semi-protection, as appropriate.)

It could cut down on blocks. ("I don't need to indef block this user, as they're a postive contributor everywhere else. But when it comes to [Forbidden fruit], they need a content ban.")

It would help with arbcomm enforcement.

This could be done by username, by IP, by IP range (using the same system as blocking).

Sounds great to me. - jc37 20:46, 11 May 2008 (UTC)[reply]

I'm a big fan of this idea; I proposed something similar in October (although Kww's is more robust), it didn't gain traction, and I lost track and didn't pursue it. This plan would improve the editing environment of honest IP editors. Vandalism is a bigger problem than 199.125.109.105 suggests, and the way we deal with it right now treats legitimate IP editors poorly. Right now, if someone on a big dynamic IP pool starts harassing the article John Doe, we have three choices:

1. Revert, revert, revert. This just doesn't work with a persistent vandal.
2. Semi-protect the page. This prevents every IP editor on the planet from editing the article.
3. Range block the IP. This prevents every legitimate IP editor in that range from editing any article at all.

I assume the more bells and whistles range-protection has, the harder it would be to implement. So, I think the most basic of all (prevent IP editors or non-autoconfirmed editors from a certain range from editing an article) would be useful enough to implement if it's technically possible. The more options, the better. I'm glad to see more participation here, and hope we could get enough interest that we could file a Bugzilla request, and be able to point to lots of activity on this thread to demonstrate that it isn't one or two people who think it would be cool. This would help, a lot, and improve the situation for both vandal fighting and legitimate IP editors. --barneca (talk) 21:22, 11 May 2008 (UTC)[reply]

I'm slogging through some comparisons of how much Ip editing is vandalism.[2] Also I looked to see how much vandalism is done by Ips just by counting the non-IP reports from Cluebot.[3] The numbers are not far off from what has been reported. The first group I checked had 38/500 non-Ip reverts, leaving 92% for the IPs. So far I'm only a little ways into the IP edits, but so far 72% are non-vandalism. And the bad thing is that along the way, I was the one to revert 20% of that vandalism, hours later. Can you imagine if 20% of vandalism was really going undetected? Wouldn't it be better to just let them all edit a few rotating vandal-magnets like sex or myspace or heaven forbid even Wikipedia (which in my opinion should never ever be protected other than on very rare occasions)? At least you know the vandals will get blocked and the vandalism fixed. 199.125.109.105 (talk) 08:02, 12 May 2008 (UTC)[reply]

My coffee isn't working this morning, and it's Monday, so I'm sorry if we're agreeing and I just didn't catch on, or if I'm not addressing your point. But to be clear, I am not saying a large percentage of IP edits are vandalism. I'm saying that a large percentage of annoying multiple source vandalism on articles comes from dynamic IP's (it has to; static IP's and named accounts are easy to block). The problem is, our only tools to fight this are too blunt; total range blocking, and article semi-protection. If range blocking on individual articles was available, we could avoid blocking as many legit IP edits. It isn't perfect; a different, legit IP editor actually interested in that particular article would still be out of luck. But at least they would be able to edit other articles (unlike a range block), and at least all other IP editors not on that ISP would be able to edit that particular article. It's not a solution in search of a problem, it's a solution to a very real, persistent problem that is currently making IP editing more difficult than it needs to be. --barneca (talk) 13:28, 12 May 2008 (UTC)[reply]

Ok, I'll try to break it down closer to see. I'm not sure that it matters, because I'm going to assume that 75-85% of edits from dynamic IPs are also productive, same percentage as all IPs. 199.125.109.105 (talk) 15:26, 12 May 2008 (UTC)[reply]

Not sure that's necessary; my point would still be the same, whether it was 25% or 75% or 95%. --barneca (talk) 16:15, 12 May 2008 (UTC)[reply]

This is bug 870 IIRC. I might look at it. — Werdna talk 01:10, 13 May 2008 (UTC)[reply]

674 maybe? :-) As for the concerns about "administration" - we allow rangeblocks, and we allow page protection. Neither of those are overwhelming us in bureaucracy... Mr.Z-man 02:11, 13 May 2008 (UTC)[reply]

Cool, Z-man. Bug 674 is close; part of the usefulness, however, would be the added ability to rangeblock the article. Choosing to block a particular editor or IP is not as disruptive to innocent editors as rangeblocking or page protection. Don't know enough about how blocking works to know if range blocking would be incorporated into a solution to Bug 674 or not; depending on the answer to that, it might be worth an additional comment at that bug, or a separate bug request.

Also of interest, that bug (which I hadn't seen before) points to an interesting old discussion: Wikipedia:Per-article blocking. Very old (before there was such a thing as semi-protection!), so evidently either this is too hard to implement, or the developers haven't given it a high priority. --barneca (talk) 02:31, 13 May 2008 (UTC)[reply]

I've thought about how this would be implemented as well. It would probably be easiest to design it like the current blocking system, allowing blocking IPs, ranges, and users (possibly autoblocks as well). As Werdna noted in the bug, other options that might be possible are blocking titles based on regexeps (which would allow effective namespace bans) and categories. Mr.Z-man 02:44, 13 May 2008 (UTC)[reply]

For vandalism by IP editors, I recommend looking at Dragons flight/Log analysis. Yes, the vast majority of vandalism is from IP editors. But most IP edits aren't vandalism.

Also, a relevant proposal is Wikipedia:Autoconfirmed Proposal/Poll - that will make it more difficult for trolls to attack semi-protected pages, and it will be more obvious that an account has been set up only to do so. -- John Broughton (♫♫) 02:22, 13 May 2008 (UTC)[reply]

It's not difficult to implement, but it's difficult to do well. The blocking system is very firm about the assumption that a user can only have one block applying to them — and it's quite annoying to do this properly. — Werdna talk 09:11, 14 May 2008 (UTC)[reply]

Resolved

I asked a question over at Wikipedia:Help and was sent here. I was editing the Meridian, Mississippi article to include a paragraph about Naval Air Station Meridian when I came across a problem. The link to John S. McCain, Sr. would display in neither Firefox 2.0.0.14, IE7, nor the IE Tab extension for Firefox. I've had this problem before with E. F. Young, Jr., and it was never resolved. After doing a bit of playing around, I found out that I can't open an article whose name ends in a period unless I type in "...w/index.php?title=TITLE". A URL including "...wiki/TITLE" won't display anything in Firefox (displays Done message in status bar with no page title and blank page) and an HTTP 500 Internal Server Error in IE7. Other users in this thread are able to view the pages, so I don't know what the problem is. Any ideas? --Dudemanfellabra (talk) 19:17, 11 May 2008 (UTC)[reply]

Hmm.. apparently the problem has fixed itself. I can now view all the pages. --Dudemanfellabra (talk) 01:05, 12 May 2008 (UTC)[reply]

I've posted here regarding the current Edittools situation. Thoughts and / or volunteers would be much appreciated. --MZMcBride (talk) 04:34, 12 May 2008 (UTC)[reply]

At Special:ListGroupRights, it says that sysops can move a page without creating a redirect from the old page. I'm probably missing something obvious, but how do I do this? It would save some time when userfying nn-bio articles. Stifle (talk) 11:41, 12 May 2008 (UTC)[reply]

I vaguely recall that there's no interface option for it. I'm not sure offhand how it's accessible, or if it is at all. —Simetrical (talk • contribs) 14:38, 12 May 2008 (UTC)[reply]

Not an option I have ever encountered; I simply delete the redirect afterward. — Edokter • Talk • 15:11, 12 May 2008 (UTC)[reply]

I've never seen the option at all, either, and I have a history with page-move vandals. -Jéské ^{(v^_^v E pluribus unum)} 04:25, 13 May 2008 (UTC)[reply]

According to #wikimedia-tech, this feature is only available through the mw:API and it is not in use on this project. Nakon 04:30, 13 May 2008 (UTC)[reply]

For a while, I have been using a script by User:Sander Säde that uses AJAX to give a very fast preview of a page while editing (without having to reload the entire page). I finally got around to touching it up today, at User:CBM/quickpreview.js. Are other people be interested in this? I can probably turn it into a gadget if people would be likely to use it. — Carl (CBM · talk) 13:04, 12 May 2008 (UTC)[reply]

How do I use it? I'd like to try it out. I imported the script but nothing seems to have happened. I guess I might need to install this ajax you're talking about. xenocidic (talk) 15:29, 12 May 2008 (UTC)[reply]

No, all you have to do it add importScript('User:CBM/quickpreview.js'); in your monobook.js, refresh your cache on that page (shift-reload), and then edit some other page. You will see a 'quick preview' button has appeared beside the usual preview button. — Carl (CBM · talk) 15:31, 12 May 2008 (UTC)[reply]

Yea, I thought so, but it isn't showing me a new quick preview button. I even tried restarting the browser altogether after doing the hard refresh. xenocidic (talk) 15:37, 12 May 2008 (UTC)[reply]

You have a lowercase 's' in importScript. [4]. — Carl (CBM · talk) 15:39, 12 May 2008 (UTC)[reply]

Cheers mate. I definately think this will prove useful. and now that I've read up on what a Gadget is, I'd say, go for it. xenocidic (talk) 15:56, 12 May 2008 (UTC)[reply]

Odd, that the script by SS wasn't listed at WP:EIW#Preview, while others were. I assume significant overlap. -- John Broughton (♫♫) 02:38, 13 May 2008 (UTC)[reply]

There is already a speedy preview button in wikEd, and it's terribly useful. If this new script would be accessible to all users (wikEd only works in Mozilla), then I believe we are talking about a significant improvement to editing experience. Waltham, The Duke of 05:18, 13 May 2008 (UTC)[reply]

Re John Broughton: I didn't know about that page, somehow. Alex Smotrov's code is very similar to Sander's code; I made mine scroll back to the top when the preview is hit, but other than that they should behave the same. Do you have a preference between them ? Alex's code has fewer dependencies, so it may be better for use as a gadget. — Carl (CBM · talk) 11:10, 13 May 2008 (UTC)[reply]

Neat, but I like mine better for what it does when editing sections with refs (e.g. [5]). Anomie⚔ 11:18, 13 May 2008 (UTC)[reply]

Anomie, yours has an error in it. See this. J.delanoy^gabs_adds 14:09, 13 May 2008 (UTC)[reply]

Fixed, thanks for the bug report. Anomie⚔ 14:22, 13 May 2008 (UTC)[reply]

Carl (not to put off Anomie...), I really like your idea. Your preview thingy parsed the preview fully twice as fast as the normal Wiki one did (I literally timed them :P ). If you can get it to work in IE, you should definately try to get it put in as a gadget. One question, can you space the buttons evenly? As this picture shows, the quick preview button is not quite the same distance apart from the other buttons. I know this is trivial, but I also know this will drive me nuts for the rest of eternity... J.delanoy^gabs_adds 14:09, 13 May 2008 (UTC)[reply]

Re Anomie: I like the reference preview; I added that to my javascript code. — Carl (CBM · talk) 17:22, 13 May 2008 (UTC)[reply]

You have a bug in your reference preview. Try it on a section that has a <ref name="..."/> where the contents are specified in a separate section, for example the third reference in [6]. Anomie⚔ 21:30, 13 May 2008 (UTC)[reply]

Yes, I know. I tried out your code for that, but I didn't succeed in making it work. Also, I don't like the idea of making an extra query for what is supposed to be a quick preview. I think people can live with broken reference previews when editing just one section of an article, in the name of having the preview appear Right Now when they click the button. — Carl (CBM · talk) 22:20, 13 May 2008 (UTC)[reply]

What exactly are you talking about? I can give you an opinion if you'll tell me what you are talking about. J.delanoy^gabs_adds 00:26, 14 May 2008 (UTC)[reply]

One trick some people do is to type <references/> at the bottom before previewing, so they can see their footnotes. Anomie's code, and mine, now do that automatically. This breaks if you edit one section that has "named references" defined in a different section. In that case, the wiki text literally doesn't have the information for that reference. In my code, you will see a red error message when this happens. Anomie's code responds by downloading the entire source of the page before displaying the preview - which is too slow for my taste. Really, if people want to preview references, they need to preview the entire page. — Carl (CBM · talk) 14:15, 14 May 2008 (UTC)[reply]

I'll have to disagree with you there, especially with the "they need to preview the entire page" part, and thus keep using my own code. In fact, I originally wrote my script not as a "quick preview" script but specifically as a "preview a section with references" script. Anomie⚔ 15:06, 14 May 2008 (UTC)[reply]

Oh, I see. Yes, that would be a very different goal. My goal is just to have a very fast preview. — Carl (CBM · talk) 15:29, 14 May 2008 (UTC)[reply]

Maybe this could be provided as a separate "plugin"? E.g. the preview gadget would check runMeBeforeAjaxPreview variable, and execute it if it's defined (by the user importing this plugin). —AlexSm 16:56, 14 May 2008 (UTC)[reply]

Re J.delanoy: The issue with the space is that there is a text element between the other pairs of buttons, which I need to duplicate to put between the quick preview button and the following button. But I think this is an area where there are browser compatibility problems, so I need to think about it more carefully. Maybe someone else who has more javascript experience can help. — Carl (CBM · talk) 17:22, 13 May 2008 (UTC)[reply]

Actually, it keeps changing on me, so it's probably not as a result of your code. I guess it is a result of the AWESOME Firefox software grappling with (and varyingly losing and winning to) the crappy Microsoft software that I am cursed with using as my OS... J.delanoy^gabs_adds 17:25, 13 May 2008 (UTC)[reply]

Is there a reason that popups don't work on the quick preview? I.e. to preview the links. xenocidic ( talk ¿ review ) 14:19, 14 May 2008 (UTC)[reply]

quick preview: need testing in other browsers

Could a few people who use non-Firefox browsers test this and report whether it works? The code for your monobook.js is importScript('User:CBM/quickpreview.js'); or importScript('User:Alex Smotrov/qpreview.js');. Only turn on one at a time. — Carl (CBM · talk) 11:10, 13 May 2008 (UTC)[reply]

In IE7 (7.0.6000.16643):

• User:CBM/quickpreview.js - javascript error, line 15 char 3: "Could not get the type property. This command is not supported".
• User:Alex Smotrov/qpreview.js - works.
• User:Anomie/ajaxpreview.js - works.

Anomie⚔ 11:25, 13 May 2008 (UTC)[reply]

In Safari 3.1.1 for Windows. (just downloaded to see how it would work...)

• User:CBM/quickpreview.js - works, but is very slow, slower than the default Wikipedia preview.
• User:Alex Smotrov/qpreview.js - I don't know if this is supposed to show a new button or just make the existing one faster? In any case, the preview seemed faster, but no new buttons showed up.
• User:Anomie/ajaxpreview.js - Doesn't come up with an error i.e. shows button next to the "save page" button, but when I click the button, it shows this "working" symbolism made up of /\| and -, and I waited nearly 2.5 minutes, and it still hadn't come up with a preview.

J.delanoy^gabs_adds 14:39, 13 May 2008 (UTC)[reply]

Of course, I'm using Windows Vista, so who knows what MS added to make Apple stuff not work. J.delanoy^gabs_adds 16:35, 13 May 2008 (UTC)[reply]

In Safari 3.1.1 (525.17) for Windows running under Wine (1.0-rc1):

• User:CBM/quickpreview.js - works, not slow at all for me.
• User:Alex Smotrov/qpreview.js - works.
• User:Anomie/ajaxpreview.js - works.

Anomie⚔ 15:36, 13 May 2008 (UTC)[reply]

Based on these, it looks to me like Alex's version is better. for the gadget version, I think it's better to have the button appear beside the regular preview button instead of the edit toolbar (not everyone has the edit toolbar turned on in the first place, and it's odd to require it for this.) I'll copy Alex's code to my page and tweak it a little. It looks like we could still use an IE 6 tester. — Carl (CBM · talk) 16:28, 13 May 2008 (UTC)[reply]

I have an old comp that may have IE6 still on it. I'll fire it up and check. J.delanoy^gabs_adds 16:35, 13 May 2008 (UTC)[reply]

Thanks. I have finished updating User:CBM/quickpreview.js, so that is the version to test. — Carl (CBM · talk) 16:38, 13 May 2008 (UTC)[reply]

Using Microsoft Internet Explorer 6 (version 6.0.2800.1106) on a computer running Microsoft Windows Millenium Edition (version 4.90.3000):

• User:CBM/quickpreview.js - works, no errors. (!)
• User:Alex Smotrov/qpreview.js - works.
• User:Anomie/ajaxpreview.js - works.

So, yeah, go figure... What is up with Microsoft, anyway? J.delanoy^gabs_adds 17:05, 13 May 2008 (UTC)[reply]

Ok, if I actually read your post, Carl, it would all make sense to me.... (of course, I was using an 800x600 screen, so cut me some slack.) J.delanoy^gabs_adds 17:11, 13 May 2008 (UTC)[reply]

quick preview: features

The script is not that complex, and I don't think it really matters whose version is made a gadget; several names could be added as maintainers. Also, browser compatibility can always be fixed. I think we have to focus on how the script has to look and what additional features it might have:

• button location and name
• how the "waiting mode" is displayed
• additional message on top e.g. "this is Ajax preview: interwiki and categories are not updated"
• second button for ajax diff; unfortunately, this wouldn't save any traffic, as the script would still have reload the entire page (in the background); however, this would still has the advantage of "continuos editing" (cursor stays in the same place in the edit window)
• re-executing some scripts after previewing, e.g. to make the tables sortable and blocks collapsing
• fixing "name" references from another section (as in Anomie's script)
• also update interwiki on the left and categories at bottom (as in fr:MediaWiki:Gadget-QPreview.js

Personally, I think that the last two options are a bit too complex for a simple ajax preview script. —AlexSm 16:56, 14 May 2008 (UTC)[reply]

I personally liked the name "Quick Preview" better than "Ajax preview", and I also liked the button changing to "Please Wait". A custom message on top would be nice. J.delanoy^gabs_adds 17:34, 14 May 2008 (UTC)[reply]

I've put together a table of various CSD categories for easy tracking, and included the number of pages in each category using the PAGESINCAT magic word, which should - in theory - return the number of pages in each category. When I load the page, however, I get several categories that - when empty - give negative results. The table is here. Even after purging, the number of attack pages for speedy deletion will read as -1 when the cat is empty; Nonsense pages will read as -2 pages in the category, even when empty. Am I doing something wrong, or is there an error with the category or PAGESINCAT? Thanks, UltraExactZZ ^Claims ~ Evidence 15:21, 12 May 2008 (UTC)[reply]

It's a known bug; see bugzilla:13683. — Carl (CBM · talk) 15:29, 12 May 2008 (UTC)[reply]

Aha, missed that one. Knowing that, I'll see if I can increment those counts in the template to bring everything to zero. Thanks! UltraExactZZ ^Claims ~ Evidence 15:43, 12 May 2008 (UTC)[reply]

Ended up using {{sum}} to fix the problem, though - as the bugzilla report notes - the larger issue is why the counts are wrong to begin with. Interesting. UltraExactZZ ^Claims ~ Evidence 18:31, 12 May 2008 (UTC)[reply]

Yeah, they're way off. At the moment,

{{PAGESINCATEGORY:Wikipedia articles in need of updating}}: says 193

and

Category:Wikipedia articles in need of updating shows well over 200

— Carl (CBM · talk) 18:43, 12 May 2008 (UTC)[reply]

Do you know how to do this? (I found this and then posted it to the Wikipedia namespace, but I have no idea how it was created).

Please rebuild it.

(Or explain to the rest of us how, so one of us can do it).

The Transhumanist    17:33, 12 May 2008 (UTC)[reply]

What is supposed to be on that page? I can probably recreate it, but I don't know what the 0s are supposed to mean. — Carl (CBM · talk) 18:05, 12 May 2008 (UTC)[reply]

http://en.wikipedia.org/w/index.php?title=Special%3AAllPages&namespace=4 is a low-tech solution. Putting .allpagesredirect { display:none; } in your css will hide the redirects, though you'll have to skip past the subpages yourself. —Cryptic 18:13, 12 May 2008 (UTC)[reply]

Does anyone know what percentage of accounts on the English Wikipedia are unused? By unused, I mean an account that has no edits to any page and no logged actions other than its creation. It would be great if I could get some exact numbers on this from the database or something. Pyrospirit (talk · contribs) 21:54, 12 May 2008 (UTC)[reply]

To first approximation, all of them. To take a look at the year ago account creation log you'll see that well over half have a red "contribs" entry signifying that they have no undeleted contributions. I don't know why people register accounts that are never used, but it is exceedingly common. Dragons flight (talk) 22:00, 12 May 2008 (UTC)[reply]

For the watchlist? To prevent someone impersonating "their" identity on other websites? Also, account with only deleted contribs also show up as red, I think, so some portion of them (%=???) created a joke article that got deleted, and never did anything else. --barneca (talk) 22:10, 12 May 2008 (UTC)[reply]

I registered my account on December 14, 2005, but didn't make my first edit until February 2 the following year. I did it primarily to secure my name, which I use pretty much everywhere I go on the internet. While that isn't likely to be the reason for everyone, I'd imagine that at least a few have done so for that reason. EVula // talk // ☯ // 22:23, 12 May 2008 (UTC)[reply]

Someone did a few toolserver queries about this not that long ago. Who did them and where the results are, I don't remember... Mr.Z-man 22:29, 12 May 2008 (UTC)[reply]

It was User:SQL who did the query. Don't know where he hid the data. MBisanz ^talk 22:39, 12 May 2008 (UTC)[reply]

One clue is that by my rough calculation, there are about 1500 people per second searching for something on Wikipedia, and only 3 people editing something. If each editor does 50 edits a month, you have a ratio of one person editing for every 25,000 who use the stuff they create. Makes you feel kind of powerful, doesn't it? That's a ratio of 99.996% of people who are thinking of editing but don't, assuming that everyone wonders why there is an edit link. On some of the articles. 199.125.109.105 (talk) 23:25, 12 May 2008 (UTC)[reply]

I did a blog posting about this (and some other statistics) a while ago. (For those who don't want to read the whole thing, the answer is that about roughly 2/3rds of all registered editors have never made an edit, per this mailing list posting.) -- John Broughton (♫♫) 02:45, 13 May 2008 (UTC)[reply]

My unsystematic investigation of a few points in Special:ListUsers suggests that a significant fraction of unused accounts are socks, waiting to be activated, e.g. tell-tale groups with very similar names.

While we are on this topic, what do people thing of asking the developers to add an "Active user" number to special:statistics, where "active" is up for debate but minimally might be at least one edit in the last 6 months (still would be dramatically less than total number of users). Ideally would exclude edits to the user's own user page. PaddyLeahy (talk) 03:44, 13 May 2008 (UTC)[reply]

That would really be interesting to see. As for myself, I've got two of the unused accounts - I think I've made a few edits with them, but I've got the account I used to use and one similar reserved to prevent impersonation. --Philosopher ^{Let us reason together.} 14:02, 13 May 2008 (UTC)[reply]

Using the {{User|}} link in a topic title, for lack of a better term, 'busts' the 'go to topic' arrow when the topic is created. Is there any way to set things up so that {{User|}} links can't be used in topic titles, or would that be a 'more trouble than it's worth' situation?

Granted, it's a minor thing, but when a page it busy, it helps to be able to use the go to arrow. HalfShadow 02:10, 13 May 2008 (UTC)[reply]

Non-technical solution: When I notice it, I just change it to User:John Doe, and put the {{user}} template right below the title, and explain why in an edit summary. No one has complained yet. It does get annoying, tho, and it's surprising that so many people don't notice it breaks the little section title arrow. --barneca (talk) 03:51, 13 May 2008 (UTC)[reply]

The documentation for {{Anchor}} specifically recommends inserting the template directly into the header. I would fix my edit summaries manually, but I can see how it's annoying. Flatscan (talk) 03:39, 14 May 2008 (UTC)[reply]

I haven't checked, but it's possible {{Anchor}} doesn't break things. Even if it does, it isn't that common. In any case, what HalfShadow is talking about is the common use of {{user}} in AN and ANI headers, which does break things. --barneca (talk) 14:25, 14 May 2008 (UTC)[reply]

See bug 10207, which is unresolved for a long time. Who decides when to upgrade software like librsvg2?

See also Wikipedia:SVG_Help#Image:Dielectric_responses.svg

Archimerged (talk) 08:16, 13 May 2008 (UTC)[reply]

According to Mark in #wikimedia-tech, it seems rsvg is just whatever version is packaged by the relevant distributions. It's planned to upgrade the application servers to Hardy soon, which seems to mean librsvg 2.22.2-2. But apparently the image-rendering servers are still running Fedora, so the upgrade might not happen there until they're switched to Ubuntu. Be patient, I guess. The current version seems to be 2.14, or so it's claimed, which is kind of ancient. —Simetrical (talk • contribs) 15:02, 13 May 2008 (UTC)[reply]

Hi, I wanted to ask someone about a problem with another wiki project. This is the project. The problem is that whenever you try to resize an image, it gives an "Error creating thumbnail:" message.[7] The odd thing is that the error only appears for newly uploaded images, the old ones working perfectly.[8] Do you have any idea as to what might cause the problem?

Check that ImageMagick on the server works properly. MaxSem^{(Han shot first!)} 09:37, 12 May 2008 (UTC)[reply]

Sorry for dumb question, but I really have no idea how to do that. diego_pmc (talk) 18:03, 12 May 2008 (UTC)[reply]

Is it possible to resize used SVG images in any other unit than just px's, It would nice to specify the width of an image using "em"'s or "cm"'s that way pictures would appear the same no matter the resolution. Currently the [[image]] does not support this (I think). (TimothyRias (talk) 15:32, 13 May 2008 (UTC))[reply]

Using em for image size will cause it to be the same size independent of the resolution, yes, but the image would blow up dependent on the user's font size. (I'm speaking in general terms; I don't think it's possible to do so with the MediaWiki software) EVula // talk // ☯ // 17:36, 13 May 2008 (UTC)[reply]

Note also that currently all SVG images are rasterized to PNG server-side for inline display. --brion (talk) 22:35, 13 May 2008 (UTC)[reply]

Resizing with font is part of the wanted behavior. Some people need large fonts because they are visually impaired. It would be nice if they were able to read text in SVG to. This behavior would help accessibility. With the regard to the server side rasterization of SVG to PNG. I don't see this being a problem. The only thing you need is the pixel size of em on the client computer when asking the server for the pic. (TimothyRias (talk) 06:29, 14 May 2008 (UTC))[reply]

Which is not available, except by using JavaScript, and then it's unreliable. The size of an em will vary across the page, and may change without notice to the server if the user resizes the text. It also means that a slightly different size will potentially be served to every user, so that caches will work much less effectively: most views will probably require a thumbnail to be generated for just that view and then never used again.

There is a preference controlling default thumbnail size. If there were a syntax for specifying multiples of that thumbnail size instead of exact pixel sizes, and editors used that, users with visual impairments or other reasons to use non-default sizes would be able to see properly-sized images. This avoids all the problems of your suggestion.

Of course, when we start serving actual SVG, the sizes can be specified in em's, because client-side scaling should hypothetically be simple in that case. Similarly, if we're willing to serve somewhat larger images than most users need, then once client-side scaling improves we might be able to use em-based sizes there too, allowing the client to resize. But as long as the server is doing the resizing, trying to get the font size from the client is impractical. —Simetrical (talk • contribs) 14:05, 14 May 2008 (UTC)[reply]

Resolved

Image:Vitaminwater.gif - That image keeps getting tagged as unused, because it says it is not used in any articles. However, in Glacéau, it is used, yet the image file doesn't recognize it. Both pages have been purged multiple times, and the image has been there for a while. What's going on? Soxred93 (u t) 21:06, 13 May 2008 (UTC)[reply]

I null-edited Glacéau and it now appears correctly. Just a caching issue. Happy‑melon 21:09, 13 May 2008 (UTC)[reply]

Resolved

This article was accidentally deleted during an attempt to revert page move vandalism (despite having more than 5,000 revisions). I don't seem to be able to restore all the revisions and settled for just undeleting the last few. Can another admin take a look? Is a developer needed to fix this? WjBscribe 01:03, 14 May 2008 (UTC)[reply]

Restored. Aaron Schulz 01:12, 14 May 2008 (UTC)[reply]

Resolved

Within a few minutes of each other, the help desk has gotten two messages regarding User pages that transcluded {{Special:Newpages/20}} and {{Special:Newpages/10}} respectively. The result of this is that the Wiki renderer utterly fails, resulting in no HTML code being delivered to the browser and a blank screen. I'll be the first to admit that I didn't know one could transclude this page at all, but since it appears multiple users are doing it, to have it utterly fail like this is something that should be fixed. This seems, to me, to be a serious problem. All anyone needs to do is transclude this onto any article page to make it completely unusable to anyone who doesn't know to manually fix it via typing URLs in the address bar. Is this a known issue or something new to report? -- ShinmaWa^(talk) 04:42, 14 May 2008 (UTC)[reply]

Bug 14113. Fixed in revision 34780. -- KTC (talk) 05:25, 14 May 2008 (UTC)[reply]

It may still be a few hours before someone updates Wikimedia's copy of the file though. Mr.Z-man 05:31, 14 May 2008 (UTC)[reply]

River synced it about 25 minutes ago. —Simetrical (talk • contribs) 14:06, 14 May 2008 (UTC)[reply]

Resolved

Any idea as to what is wrong with the search box? Ever since the introduction of the new search box feature I've noticed that when using it you may have to click search 2-3 times before you get any results at all. It's a bit odd when typing in Newcastle gets no results on the first try but 13,000+ on the second. CambridgeBayWeather Have a gorilla 04:44, 14 May 2008 (UTC)[reply]

One of our search backend servers went down a few days ago due to a bad hard drive. It wasn't properly depooled from the load balancer, so some requests were still being sent to it (thus, obviously, failing!) I've manually depooled it, which seems to have niced things up. --brion (talk) 16:59, 14 May 2008 (UTC)[reply]

...and Mark's restarted the process which checks for down servers, which seems to have gotten stock itself. :) --brion (talk) 17:04, 14 May 2008 (UTC)[reply]

Thanks for the explanation. CambridgeBayWeather Have a gorilla 19:43, 14 May 2008 (UTC)[reply]

Hi. Can you help me, please? The portuguese wikipedia community is debating if we should implement a wizard similar to Wizard introduction. The only difference would be that, after the unresgistered user completes the wizard, the new article would be immediately created rather than being sent to revision. Could you please let me know if this new feature can be implemented in portuguese wikipedia? Thanks and regards, --Rodrigofera (talk) 10:05, 14 May 2008 (UTC)[reply]

Technically, the different endpoint requires only a trivial change to the page wikicode, or possibly the addition of a little javascript. We can't help you come to a conclusion over the merits of the system, however - that needs to come from the editors of the Portugese wikipedia. Happy‑melon 10:23, 14 May 2008 (UTC)[reply]

That would be great, if it is technically possible, we can proceed with the discussion over there. Thanks! GoEThe (talk) 11:12, 14 May 2008 (UTC)[reply]

Is it possible for me to add something to my monobook.js (and {{FAQ}} if necessary), to automatically collapse the FAQ on this page only, for me only? More generally, how easy is it to use personal javascript to affect the expand/collapsed states of collapsible tables A) generally, B) per template, C) per instance?? Happy‑melon 10:27, 14 May 2008 (UTC)[reply]

Since this page's FAQ is nicely wrapped in a div, this code should work:

function HideVPFAQ(){
    var t=document.getElementById('villagepumpfaq');
    if(!t) return;
    t=t.getElementsByTagName('TABLE');
    if(!t || t.length==0 || t[0].id.substr(0,16)!='collapsibleTable') return;
    collapseTable(t[0].id.substr(16));
}
if(doneOnloadHook) HideVPFAQ(); //if imported dynamically
else addOnloadHook(HideVPFAQ);

BTW, if for some reason someone ever made this FAQ collapse by default then this script would expand it. For the more general question, if you can get a handle on the table somehow (e.g. by getElementById) you could use the same method to change it. Anomie⚔ 11:13, 14 May 2008 (UTC)[reply]

Is it possible to write an expression to operate on a value such as

  2008-05-14 13:06 (UTC)

specifically to return "true" if it is currently 2 hours past this time, false otherwise? Thanks, xenocidic ( talk ¿ review ) 13:10, 14 May 2008 (UTC)[reply]

Yes, you can convert the timestamps to pure seconds using this code:

{{#time:U| 2008-05-14 13:06 (UTC)}}

and then manipulate them with #ifexpr. — Carl (CBM · talk) 14:18, 14 May 2008 (UTC)[reply]

Cheers, I'll work on that. Thanks! xenocidic ( talk ¿ review ) 14:22, 14 May 2008 (UTC)[reply]

Is there a tool which allows one to search for pages which belong to two or more categories supplied to the tool? Treating categories as sets, I want a set of results R (existing as either a list of search results or a generated and discarded category page) such that

where is one of the n categories supplied to the tool. If such a tool does not exist, how difficult would it be to make one?

Proginoskes (talk) 18:34, 14 May 2008 (UTC)[reply]

WP:CATSCAN can intersect two categories. Algebraist 21:04, 14 May 2008 (UTC)[reply]

And there's a (rather old) proposal WP:Category intersection. Algebraist 21:05, 14 May 2008 (UTC)[reply]

This now can be done in the standard search box: see Wikipedia:Categorization#Searching for articles in categories. -- John Broughton (♫♫) 21:18, 14 May 2008 (UTC)[reply]

Resolved

It appears that image search is not working. Here is an example search: images containing 'simpsons'. This should come up with some images but it does not. Gary King (talk) 19:31, 14 May 2008 (UTC)[reply]

Our dedicated non-mainspace search daemon (on maurus) have died, Brion restarted it. --rainman (talk) 21:16, 14 May 2008 (UTC)[reply]

Will hopefully be more reliable in future if we get a chance to give it a backup. --brion (talk) 21:26, 14 May 2008 (UTC)[reply]

testing dum de dum

On Special:WhatLinksHere/Image:Flag_of_Georgia.svg, when I click on "next 50", I get the same list - I also get a "previous 50" option, but again it just gives me the same list. That is to say, I can only see the first 50. (If anyone is interested, I'm trying to find where the wrong Georgian flag is being used). DuncanHill (talk) 21:47, 14 May 2008 (UTC)[reply]

Resolved

What's going on in the user creation log? It's showing doubles of every account created. Is anyone else seeing this? Acalamari 22:14, 14 May 2008 (UTC)[reply]

It's been reported to the devs on IRC and they're looking into it. Nakon 22:15, 14 May 2008 (UTC)[reply]

Okay, thanks: I don't use IRC so I'm not aware of any discussions there, so I reported it here. Thank you. Acalamari 22:19, 14 May 2008 (UTC)[reply]

Fixed. --brion (talk) 22:21, 14 May 2008 (UTC)[reply]

Excellent. Thanks. Acalamari 22:25, 14 May 2008 (UTC)[reply]

Some time ago I found out that protection for pagecreation was case insensitive. Did this stop? I protected here but was able to create here. Could this have anything to do with the fact, that I protected two alternative spellings? Agathoclea (talk) 22:28, 14 May 2008 (UTC)[reply]

With the exception of the leading capitalization, everything is case sensitive (ie: jim Carrey is the same as Jim Carrey, but Jim carrey is not). EVula // talk // ☯ // 22:30, 14 May 2008 (UTC)[reply]