Jump to content

Wikipedia:Village pump (technical): Difference between revisions

From Wikipedia, the free encyclopedia
Content deleted Content added
sig and User:Neil's talk page are allergic to each other
Line 711: Line 711:
==[[User talk:Neil]]- the new talk page and my sig are allergic to each other==
==[[User talk:Neil]]- the new talk page and my sig are allergic to each other==


Hi my sig works fine as far as I know on every other page. But when it's put on [[User:Neil]]'s it turns bits of his text there green afterwards. I have cut and pasted the code he gave me, which just meant two square brackets showed after my sig, could you look at the sig and the page concerned, and see what's happening? Because until then I can't post to the lovely Neil's page. :( Anyway, my sig is orange, not green, so I'm completely at a loss and intrigued as to why this would happen. Hope you can help.[[User:Sticky Parkin|<b><font color="#FF8C00">Sticky]]</font></b> [[User talk:Sticky Parkin|<b><font color="#FF8C00">Parkin]]</font></b> 22:08, 18 May 2008 (UTC)
Hi my sig works fine as far as I know on every other page. But when it's put on [[User:Neil]]'s it turns bits of his text there green afterwards. I have cut and pasted the code he gave me, which just meant two square brackets showed after my sig, could you look at the sig and the page concerned, and see what's happening? Because until then I can't post to the lovely Neil's page. :( Anyway, my sig is orange, not green, so I'm completely at a loss and intrigued as to why this would happen. Hope you can help.[[User:Sticky Parkin|<b><font color="#FF8C00">Sticky</font></b>]] [[User talk:Sticky Parkin|<b><font color="#FF8C00">Parkin</font></b>]] 22:08, 18 May 2008 (UTC)
:Your sig does not terminate it's tags properly; html tags started inside a wikilike must be closed inside the wikilink (not outside). I've corrected you sig above (see diff). <span style="font-family: verdana;"> — [[User:Edokter|<span style="color: #008;">'''''E''dokter'''</span>]] • [[User_talk:Edokter|<span style="color: #080;">Talk</span>]] • </span> 22:22, 18 May 2008 (UTC)

Revision as of 22:22, 18 May 2008

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at the BugZilla because there is no guarantee developers will read this page. Problems with user scripts should not be reported here, but rather to their developers (unless the bug needs immediate attention).

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here. Questions about MediaWiki in general should be posted at the MediaWiki support desk.

Non-admin rollbackers

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 5/6 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.delanoygabsadds 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.delanoygabsadds 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.delanoygabsadds 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) OK, it looks like we have quite a bit of support for this. I'm going to move it to WP:VPP and open a straw poll. J.delanoygabsadds 15:18, 15 May 2008 (UTC)[reply]

Discussion moved to Wikipedia:Village pump (proposals)#Non-admin rollbackers

An alternative to IP-range blocking and semi-protection: IP-range protection

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. Happymelon 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. Happymelon 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. Happymelon 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. Happymelon 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.delanoygabsadds 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.delanoygabsadds 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.[1] Also I looked to see how much vandalism is done by Ips just by counting the non-IP reports from Cluebot.[2] 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]

Gadget for quick preview

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. [3]. — 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. [4]). Anomie 11:18, 13 May 2008 (UTC)[reply]
Anomie, yours has an error in it. See this. J.delanoygabsadds 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.delanoygabsadds 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 [5]. 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.delanoygabsadds 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.delanoygabsadds 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):
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.delanoygabsadds 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.delanoygabsadds 16:35, 13 May 2008 (UTC)[reply]
In Safari 3.1.1 (525.17) for Windows running under Wine (1.0-rc1):
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.delanoygabsadds 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):
So, yeah, go figure... What is up with Microsoft, anyway? J.delanoygabsadds 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.delanoygabsadds 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.delanoygabsadds 17:34, 14 May 2008 (UTC)[reply]

Bizarre Category Numbers

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 194
and
Category:Wikipedia articles in need of updating shows well over 200
— Carl (CBM · talk) 18:43, 12 May 2008 (UTC)[reply]
What's more interesting is that the counts appear to be changing. I hardcoded increments into my table, so that when the "All CSD Candidates" category was empty, it would show the PAGESINCAT count of -2 plus the increment of 2 - so the display would be 0. Now, however, it shows -1, so I have to change the increment to match. Nonsense did the same thing. I wonder if it's a growing problem, or if it was an effort to fix it that changed the number? UltraExactZZ Claims ~ Evidence 12:53, 15 May 2008 (UTC)[reply]
That's not interesting, that's completely expected. Whatever glitch threw off the numbers to start with continues to throw them off. I've implemented a workaround in r34870, so at least the counts won't appear negative (but they may be considerably off nonetheless). —Simetrical (talk • contribs) 17:06, 15 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]
I understand. {{user}} is more problematic because it's used frequently and on section creation, when the edit summary cannot be modified. FWIW, {{Anchor}} does break the links; I checked in Article and Talk space. Flatscan (talk) 02:38, 15 May 2008 (UTC)[reply]

resizing SVG images by other units than "px"

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]

Transclusion of Special:Newpages/20 renders page inoperable

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]

Search box problems

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]

Portuguese wikipedia new feature

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. Happymelon 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]

Collapsing boxes by user preference

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?? Happymelon 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]
The show/hide boxes created by {{hat}} and {{hab}} stay always in the 'show' position if you turn off javascript in your browser. This is handy if you are searching for a text string in a collapsed archive, like the one for WP:DRV. EdJohnston (talk) 01:03, 15 May 2008 (UTC)[reply]

Operations on a time value?

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]

Finding Pages in Two or More Specified Categories

Resolved
 – The solution is poorly documented, but exactly what was needed. Proginoskes (talk) 18:26, 15 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]
But only for categories that are present in the text itself, not included through templates. An important caveat. —Simetrical (talk • contribs) 17:08, 15 May 2008 (UTC)[reply]

Image search not working?

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]

That's probably a bug. However, lists like this can display up to 5,000 items at a time by manipulating the URL like this long list of links to Image:Flag_of_Georgia.svg. At the time of writing, there are 2,764 links in that list according to my screen reader JAWS, so that list contains all the links. Graham87 10:23, 15 May 2008 (UTC)[reply]
Thanks. DuncanHill (talk) 14:26, 15 May 2008 (UTC)[reply]
The problem seems to have resolved itself now. Still really weird though :D --TheDJ (talkcontribs) 09:42, 16 May 2008 (UTC)[reply]

User creation log bug

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]

Page creation protection.

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]
thanks-- Agathoclea (talk) 22:38, 14 May 2008 (UTC)[reply]
That did happen for a while; it was a bug. --brion (talk) 23:45, 14 May 2008 (UTC)[reply]
I was thinking what a good feature it was... awwwww. Pegasus «C¦ 03:18, 15 May 2008 (UTC)[reply]
I agree on the feature bit .. but can see the trouble in searching for the right protection could be. Agathoclea (talk) 07:32, 15 May 2008 (UTC)[reply]

Strange "Go" button behavior

Why does entering After the rain in the search box and clicking "Go" take me to After The Rain rather than After the Rain? (The former now redirects to the latter, but it didn't at the time I did that search.) Mike R (talk) 23:58, 14 May 2008 (UTC)[reply]

This is explained at Help:Go button. After failing to find the precise title entered, it tries all lowercase inital letters (which is what you entered here anyway), then all uppercase initials. It's not clever enough to find mixed titles like After the Rain. Algebraist 01:10, 15 May 2008 (UTC)[reply]
Thanks. Mike R (talk) 14:18, 15 May 2008 (UTC)[reply]
It'll find them, but when there are multiple matches it may find another one first. --brion (talk) 15:47, 15 May 2008 (UTC)[reply]

Touring around the villages in Somerset

Wandering through the villages in Somerset (category:Villages in Somerset), I discovered that the article Villages in Somerset is included. That might have been fine except that the article is actually a redirect to the category [6] so I foolishly tried removing the article from the category. I tried this (diff} and found nothing changed even after a few days. So I had a go at a null edit to the article redirect (diff) but there is still the circular tour even after another few days. Any advice (just forget it?)? Thincat (talk) 13:11, 15 May 2008 (UTC)[reply]

I think I have fixed it - I made the article a redirect to [[:Category:Villages in Somerset]]. The : in front of category makes it work like a normal link, without putting it into the category. DuncanHill (talk) 13:17, 15 May 2008 (UTC)[reply]
Oh, well done! And you didn't even have to wait a few days! This is surely a feature rather than a bug in redirects. Thincat (talk) 13:22, 15 May 2008 (UTC)[reply]

Punctuation marks

Can anyone explain why the Punctuation marks info box on at sign doesn't link (the words are underlined in blue, but the cursor stays an arrow rather than becoming a pointing finger - MSIE7). Whilst the same info box on brackets and interrobang and elsewhere work fine? -- SGBailey (talk) 14:11, 15 May 2008 (UTC)[reply]

Fine on my computer (winXP, IE7, FF2). Have you tried the usual bypass cache, restart browser, restart computer rigmarole? Algebraist 16:13, 15 May 2008 (UTC)[reply]
It's working fine here. (Also on Opera, Firefox, and IE6.) —Cryptic 16:13, 15 May 2008 (UTC)[reply]
Still malfunctions today after a ctrl-F5 on top of a power cycle. Hmm. -- SGBailey (talk) 09:40, 16 May 2008 (UTC)[reply]
Stranger and stranger... I've made it work and then not work and then partly work, all in a repeatable fashion. The key appears to be changing the width of the MSIE window. It seems to work full screen or >90% wide or <60% wide. At about 85% wide the pointy finger works for v,d,e and down to comma but not for dash. At 80% there are no pointy fingers. BTW I'm using classic skin which I don't think has an impact here. Anyway, I can "fix" it by changing the window width. Well I never... -- SGBailey (talk) 10:07, 16 May 2008 (UTC)[reply]
I did the same test at another XP / MSIE 7 / Classic skin PC and it did the same thing. Really weird. -- SGBailey (talk) 22:30, 17 May 2008 (UTC)[reply]

The templates at Special:WhatLinksHere&target=Georgia&namespace=10 all link to Georgia, which is a disambiguation page. They should link to Georgia (country). I cannot fix the links myself as the template do not use actual wikilinks, but two letter abbreviations, and I don't know how to do it. Could someone who understands these things fix them please? DuncanHill (talk) 14:48, 15 May 2008 (UTC)[reply]

OK, that link doesn't work, maybe this external one will [7]. DuncanHill (talk) 14:50, 15 May 2008 (UTC)[reply]
Hrm, I tried, but I don't really understand how they do things, the problem eminates from Template:Iso2country. xenocidic ( talk ¿ review ) 14:57, 15 May 2008 (UTC)[reply]
Fixed (I think) {{topic/country|GE|{{{prefix|}}}|{{{suffix| (country)}}}}} -- SGBailey (talk) 15:56, 15 May 2008 (UTC)[reply]
Many thanks! DuncanHill (talk) 16:17, 15 May 2008 (UTC)[reply]

Our search box-- it's suggestion function?

What is that? I want to add something like that to a private wiki I might set up. Lawrence Cohen § t/e 16:08, 15 May 2008 (UTC)[reply]

See mw:Manual:$wgEnableMWSuggest. This is new for MediaWiki 1.13; older versions do include an optional "ajax search" variant, but the UI isn't cleanly integrated, making it a bit distracting.
There's an extension which gives similar behavior, though I haven't tested it myself. --brion (talk) 16:47, 15 May 2008 (UTC)[reply]
Thanks guys. Lawrence Cohen § t/e 17:19, 15 May 2008 (UTC)[reply]

Please see Wikipedia:VPR#Wikipedia logo improvement for a discussion regarding improvement of the Wikipedia logo. I've uploaded a new version of the logo, and since this would be a major change, I'm guessing it would need wide consensus, so I'm posting a notices around. Please direct any comments to the Village pump discussion. Thanks. Equazcion /C 16:09, 15 May 2008 (UTC)[reply]

I spend a fair amount of time repairing links to disambiguation pages. It has struck me that if editors received some kind of warning when introducing such links then they would be more likely to realize their mistake and correct it themselves. Would it be possible for some such to be introduced? DuncanHill (talk) 22:32, 15 May 2008 (UTC)[reply]

Great idea but perhaps a technical hurdle. Even better would be showing them a list of options and automatically piping the link when they select the right one. xenocidic ( talk ¿ review ) 22:37, 15 May 2008 (UTC)[reply]
Yes, that sounds even better! DuncanHill (talk) 22:38, 15 May 2008 (UTC)[reply]
That could be a WP:WIKED enhancement but I don't think the standard Wikipedia editing interface can do that, ever. Pegasus «C¦ 03:33, 16 May 2008 (UTC)[reply]
It could, sure. Wouldn't be too hard to do if it were desirable. —Simetrical (talk • contribs) 17:48, 16 May 2008 (UTC)[reply]
I've made a user script: User:Splarka/dabfinder.js to find disambiguations on a given page. However, it will not work correctly in preview because it utilizes generator=links on a page to find all template links on pages linked to from a given page and see which match the list defined at MediaWiki:Disambiguationspage (in this way, it can check all the links on a page with only two API queries). But it is a bit useful after the fact. --Splarka (rant) 07:14, 16 May 2008 (UTC)[reply]
Nifty. If you don't mind searching out all links in the document and doing ceil(N/50)+1 API queries instead of only 2, you can do something like I do in User:Anomie/linkclassifier.js:
  1. Use getElementsByTagName('A') to find all links
  2. Filter out links with classes 'external', 'extiw', 'new', or 'image'.
  3. List the unique title attributes; this attribute contains the target page name, with a few exceptions (filter out '' and anything beginning 'Edit section:' or 'Special:'). Alternatively, you could decode the page name out of the href.
  4. If you wanted, you could filter out anything with a namespace to be left with just mainspace page links.
  5. Instead of using generator=links, pass up to 50 of the linked pages at a time in the titles parameter.
Interesting approach, I didn't know there was an official list of disambiguation templates. My script looks for categories the page belongs to to do the same thing. Anomie 11:23, 16 May 2008 (UTC)[reply]
That's what the official list does too, more or less. Actually it differs slightly, but probably on Wikipedia they amount to the same thing. —Simetrical (talk • contribs) 17:48, 16 May 2008 (UTC)[reply]

Any special settings were necessary to make Template:Navbox work?

I am attempting to port Template:Navbox and it's variants to another wiki. Initially I ported the Templates source directly to a matching article on the other wiki. Instead of the normal Navbox rendered information, it returned a great deal of HTML and messed with the style of the page putting text behind the wiki logo, pushing the tool/link boxes on the left all the way to the bottom, and it even spilled the /doc page text out of the bottom of the normal article area of the page. In an effort to fix this I began playing around with it, enlisting the aid of User:CapitalR on a separate wiki environment that I used for a while to house information on custom content in an online game. Either way, CapitalR stripped out a lot of the parser functions and other stuff, and simplified it some, and it still seems to be having some difficulty. If you would like to take a look at the output of the full template as it is ported you can look here [http://www.mendo.org/ultima/Template:NavboxTest]. What I really need to know is, where there any special settings that had to be made to allow the template (in its current form or similiar previous ones) to function. Barring that, is there any useful help that anyone might give on it.

Already suggested/tried are the following:

  • Common.css and Common.js sections that are used by this template may not be present - They are
  • HTMLTidy may be interfering - HTMLTidy was not initially enabled so far I could tell. I have added some lines to the LocalSettings.php file to try and enable it just to see if it would fix it. and it did not change at all.
$wgUseTidy = True;
$wgTidyConf = "$IP/includes/tidy.conf";
$wgAlwaysUseTidy=true;
  • Parser Functions are out of date - While they were pretty out of date, they are not up to date with version 1.1.1 displayed (although the files are reported as 1.12...

Any thoughts? Tigey (talk) 01:41, 16 May 2008 (UTC)[reply]

You might be missing an extension that's necessary: I can't off the top of my head think which it might be. What extensions are listed on en.wiki's Special:Version#Installed extensions list that isn't on the equivalent page on your wiki? Happymelon 09:06, 16 May 2008 (UTC)[reply]
OK there are quite a few of them, but most of them I can't see affecting it, then again, you never know...
Category Tree Central Auth Check User
Cite Cross Namespace Links Deleted User Contributions
Expand Templates Link Search MakeBot
MakeSysop OAIRepository Oversight
ParserDiffTest Renameuser SiteMatrix
CharInsert EasyTimeline FixedImage
ImageMap Poem SyntaxHighlight
WikiHiero AntiSpoof AssertEdit
BoardVote CentralNotice ConfirmEdit
DismissableSiteNotice Gadgets MWSearth
Newuserlog SpamBlacklist TitleKey
UsernameBlacklist

All that are on my wiki are:

  • Confirm User Accounts
  • CharInsert
  • Inputbox
  • ParserFunctions 1.1.1

Perhaps tonight I will go through and install some of the likely extensions and see what I can make of that. Tigey (talk) 13:12, 16 May 2008 (UTC)[reply]

Of Note! I installed ExpandTemplates and it outputted the code like so:
<table cellspacing="0" class="navbox nowraplinks"><tr><th style="" colspan=2 class="navbox-title"><span style="font-size:110%;">Title</span></th></tr>
<tr style="height:2px;"><td></td></tr><tr><td class="navbox-abovebelow" style=";" colspan="2">Above</td></tr><tr style="height:2px;"><td></td></tr><tr><td class="navbox-group" style=";;">Group1</td><td style="text-align:left;border-left:2px solid #fdfdfd;width:100%;padding:0px;;;" class="navbox-list navbox-odd">List1</td></tr><tr style="height:2px"><td></td></tr><tr><td class="navbox-group" style=";;">Group2</td><td style="text-align:left;border-left:2px solid #fdfdfd;width:100%;padding:0px;;;" class="navbox-list navbox-even">List2</td></tr><tr style="height:2px;"><td></td></tr><tr><td class="navbox-abovebelow" style=";" colspan="2">Below</td></tr></table>

The output on the NavboxTester page displays the Title cell below this output:

<tr style="height:2px;"><td></td></tr><tr><td class="navbox-abovebelow" style=";" colspan="2">Above</td></tr><tr style="height:2px;"><td></td></tr><tr><td class="navbox-group" style=";;">Group1</td><td style="text-align:left;border-left:2px solid #fdfdfd;width:100%;padding:0px;;;" class="navbox-list navbox-odd">List1</td></tr><tr style="height:2px"><td></td></tr><tr><td class="navbox-group" style=";;">Group2</td><td style="text-align:left;border-left:2px solid #fdfdfd;width:100%;padding:0px;;;" class="navbox-list navbox-even">List2</td></tr><tr style="height:2px;"><td></td></tr><tr><td class="navbox-abovebelow" style=";" colspan="2">Below</td></tr> 

So it processes part of it correctly. Starting with that "Above" cell all the way up to the end table tag. Tigey (talk) 22:02, 16 May 2008 (UTC)[reply]

Aligning a template

Resolved

I should know this by now but how do you align a template to the left? <div align=left style="float: left;">template</div> doesn't work. See:

-- penubag  (talk) 02:13, 16 May 2008 (UTC)[reply]

If a template contains code that aligns itself, you can't just align it another way by placing code outside it. You could subst: it and change the align code, or you can do what I did above, confining it to a table cell so that even though it's still aligned right, it can only go to the right of the cell in which it's contained. Equazcion /C 02:19, 16 May 2008 (UTC)[reply]
Thank you equazicon, it's been bugging me for a while. I was just working on a minor template page so I decided to bring it up. -- penubag  (talk) 02:29, 16 May 2008 (UTC)[reply]
No problem :) Equazcion /C 02:30, 16 May 2008 (UTC)[reply]

Graphic designer needed

I'm looking for a skilled graphic designer.

I need an image for a non-barnstar Wikipedia award with the theme "World Traveler".

I was thinking perhaps the following image, without the barnstar, and with the globe (or another one) superimposed over the Wikipedia globe (or the Wikipedia globe superimposed over it) - I'd like to see the world's countries and the puzzle pieces (with the continents more prominent).

The image also needs a passport laying on the surface beneath the globe stand (where its shadow is, but the shadow should be retained as well). The image's background must be transparent (not white like the background of the image below).

File:Interlingual Barnstar.png

Is this something you can do?

If so, please contact me on my talk page.

I look forward to your reply.

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

You could also try Wikipedia:Graphic Lab. -- John Broughton (♫♫) 01:40, 18 May 2008 (UTC)[reply]

Adding article sizes in histories

Is there any way that the article's character count can be added next to each listing in the article's history? If I look at Recent changes, it shows how many characters have been added or removed with an edit, but this information doesn't show up in the article history, so there's no way to tell which edits did damage to the article. Corvus cornixtalk 18:34, 16 May 2008 (UTC)[reply]

Er... it does for me :D Happymelon 18:41, 16 May 2008 (UTC)[reply]
It wasn't this morning. Maybe I needed lunch.  :) Corvus cornixtalk 20:52, 16 May 2008 (UTC)[reply]

Co-ordinates broken (again)

The co-ordinates at the top of geographical articles appear to be broken again, outputting a long string of text which also overlaps the "An n-class article from Wikipedia" text. e.g. at Tavistock, Devon. DuncanHill (talk) 21:26, 16 May 2008 (UTC)[reply]

I'm not seeing a "class" message. Maybe that's in a non-default theme? But the coordinates are placed in an absolute location on the screen, so tinkering with the header is known to make thinks wander. -- SEWilco (talk) 21:38, 16 May 2008 (UTC)[reply]
It appears to have sorted itself out now. DuncanHill (talk) 21:39, 16 May 2008 (UTC)[reply]
The "class" text is a gadget. DuncanHill (talk) 21:40, 16 May 2008 (UTC)[reply]
It's a dirty hack, we really need an extension that handles the coordinates and their position. You can try adding importScript('User:TheDJ/movecoord.js'); to your monobook.js It makes the coordinates behave a lot nicer, because it positions it correctly in DOM instead of forcing it's position as an offset "close to the header". --TheDJ (talkcontribs) 22:38, 16 May 2008 (UTC)[reply]

Redirects don't appear in watchlist

Has anybody noticed that if one redirects an existing article, the redirect page does not appear in one's watchlist even if reverted? Phlegm Rooster (talk) 21:27, 16 May 2008 (UTC)[reply]

Hm? Can you provide a concrete example of the behavior you've noticed? AmiDaniel (talk) 03:38, 17 May 2008 (UTC)[reply]

Search box suggestion

Dear,

First of all I would like to thank you for the wonderful Wikipedia. I would like to make a suggestion to improve the website.

I have been talking to other people about it aswell, who agreed totally.

Can the text/typing cursor be standing in the "search box" when opening the starting page of wikipedia like it is when you open google? This saves some time not to use the mouse and would be more convenient so you can type your search immediately.

I would like to thank you for your time,

Kind regards,

Bert Ameloot (Belgium) —Preceding unsigned comment added by 62.136.10.199 (talk) 22:05, 16 May 2008 (UTC)[reply]

It's a common request and the reasons not to is that it prevents another logical action - the (page) down arrow key to scroll down. Web design standards also frown upon focus-grabbing. If you have an account, however, you can force this by going to Special:Preferences (my preferences above), Gadgets and tick "Focus the cursor in the search bar on loading the Main Page." x42bn6 Talk Mess 01:03, 17 May 2008 (UTC)[reply]
Most browsers will allow you to quickly navigate your cursor to the search bar using shortcut keys. In Firefox, Alt+Shift+F will do the trick. In IE, it's Alt+F, I believe. AmiDaniel (talk) 03:37, 17 May 2008 (UTC)[reply]
I use Safari on a Mac, and I can just hit "tab" and it takes me to the search box (though that's partly because of a system-wide preference). Personally, I'm opposed to having it auto-focus, as I use the mouse down and up keys when reading, and I don't want an extra click to get out of the box. One of the benefits of registering, though, is that you can easily activate this feature for yourself, though, just like x42bn6 mentioned. :) EVula // talk // // 19:23, 17 May 2008 (UTC)[reply]

Finding templates that conditionally pass parameters that are broken in the new parser

I've ran across some problems with the geobox templates tonight and now pose the following question: Does anyone know of a way to find templates that attempt to conditionally pass parameters using the following syntax?

{{template|{{#if:1|a=1}}}}

Not exactly an easy question to answer, I know :) --- RockMFR 01:09, 17 May 2008 (UTC)[reply]

how did my edit summary get truncated?

why was the edit summary seen here somehow truncated, or altered? —Preceding unsigned comment added by Badmachine (talkcontribs) 01:09, 17 May 2008 (UTC)[reply]

oops i forgot to sign my post and add that the edit summary that i entered said something like 'if you edit someone elses comment then you should remove their signature'. this is what user:sceptre refers to by not vandalism, trust me, I know what section of the policy you're referring to in his own edit summary... so how did he even see what i wrote since its not in my edit summary? did he edit my edit summary? Badmachine (talk) 01:20, 17 May 2008 (UTC)[reply]

Huh? Your reversion of his edit contains the edit summary "Reverted 1 edit by Sceptre identified as vandalism to last revision by Hu12. (TW))" I imagine he simply inferred the reason why you reverted him; I don't see why he'd need psychic powers to figure that out... But, to answer your question, no your edit summary was not in any way edited. You used an automated tool, WP:TWINKLE, to revet the edit, which inserts an automatic edit summary. AmiDaniel (talk) 03:35, 17 May 2008 (UTC)[reply]
yes thats what the edit summary says, but i after the automatically generated edit summary, i entered 'if you edit someone elses comment, you should remove their signature' or similar. sceptres undo has an edit summary that shows 'not vandalism, trust me, I know what section of the policy you're referring to', which looks like a reply to my complete edit summary, which somehow isnt there. can he, as an admin, edit "edit summaries", and did he do so here? Badmachine (talk) 03:47, 17 May 2008 (UTC)[reply]
No, and no. AmiDaniel (talk) 04:06, 17 May 2008 (UTC)[reply]
Okay, thanks amidaniel. Badmachine (talk) 04:14, 17 May 2008 (UTC)[reply]

Unified login question

Apologies if this is answered on a page I didn't guess yet, but: I unified my account (am an admin) shortly after this feature was enabled, with enwiki my home wiki. There were 8 wikis which I had the password to, and approx 16ish that I did not and which, so far as I know/knew were not mine though they had 'my' username. Of those several (not all) I checked, they had zero edits each. This was the status quo until recently. Randomly looking at my prefs tonight, I see that I now own the User:Splash on all Wikimedia wikis, and indeed can login to the arbitrarily selected ru.wikisource, for example. Have the rules changed? Do zero-edit accounts on other wikis get automatically usurped now? Splash - tk 01:59, 17 May 2008 (UTC)[reply]

No, it's probably a bug. Looking into it. -- Tim Starling (talk) 04:52, 17 May 2008 (UTC)[reply]
Fixed now? It looks like there was never any account called "Splash" on ru.wikisource until you created it just now. The real zero-edit accounts (e.g. on ja.wikipedia.org) were not showing up because of a bug. -- Tim Starling (talk) 05:32, 17 May 2008 (UTC)[reply]
So zero-edit accounts are indeed automatically usurped? —Remember the dot (talk) 05:35, 17 May 2008 (UTC)[reply]
No, there has been no zero-edit usurpation since shortly after the start of this trial. The initial implementation was flawed and insecure, and was removed for that reason. -- Tim Starling (talk) 06:18, 17 May 2008 (UTC)[reply]
You are right that I can't login to User:Splash on ja.wikipedia using my global password (nor any other I might expect it to be). However, on my Special:Mergeaccount here, I still do not see the list of same-name, other-wiki accounts which are not yet unified, nor the invitations to enter email or password. I only see the list of the 9 accounts already unified. On the front prefs page, I have a message that my global account status is "All in order!". (This is not causing me any personal difficulty, btw). Splash - tk 12:28, 17 May 2008 (UTC)[reply]

Reference desk template

This is an absurdly minute matter, but it's starting to get on my nerves. On all of the Reference Desk pages, the box containing "Choose a topic:" (as at the top right-hand side of Wikipedia:Reference desk/Language) has become missized. It should clearly be the same width as the "skip to bottom" box above it. The thing is, I can't even locate the relevant template for that part of the page or determine when the change that messed up the template was made. Any help would be appreciated (though if this is the wrong place to bring this up, I'd like to know that, too). Deor (talk) 04:16, 17 May 2008 (UTC)[reply]

I tried this at Wikipedia:Reference desk/header. It sort of fixes the issue (which seems to be an IE-only one), but then screws up the background in IE, so I reverted it back. The root cause of the problem is not apparent to me. --- RockMFR 06:18, 17 May 2008 (UTC)[reply]
OK, thanks. I guess we IE users should expect to live with some little problems. Deor (talk) 13:40, 17 May 2008 (UTC)[reply]
It seem that IE was deciding that the position:relative div needed to be on the same line as the next div, and then oddly shrink that div's box to fit its text. Giving the relative div hasLayout seems to have fixed it. Anomie 13:52, 17 May 2008 (UTC)[reply]
Works for me. Thanks. Deor (talk) 15:23, 17 May 2008 (UTC)[reply]

blockquote

<blockquote></blockquote> does not indent when an image is to the left of the blockquote using <blockquote></blockquote>. Could someone please post this on bugzilla or whatever? Thanks!68.148.164.166 (talk) 08:26, 17 May 2008 (UTC)[reply]

This is how HTML is supposed to behave. The images only push the text aside as much as they need in order to display the image. If the width of the image is larger then the width of the blockquote indent, then this indent might be "non visible". --TheDJ (talkcontribs) 15:44, 17 May 2008 (UTC)[reply]
Yes. If you need to move the text around like that consider using one of the quotation templates such as {{quote box2}}. --— Gadget850 (Ed)talk 15:54, 17 May 2008 (UTC)[reply]
{{quote}} probably mimics <blockquote> better. Gary King (talk) 19:19, 17 May 2008 (UTC)[reply]
True, since it uses <blockquote>, but it give no ability for size, margins or alignment. ----— Gadget850 (Ed) talk - 22:51, 17 May 2008 (UTC)[reply]

Where are the Mediawiki foundation servers located?

Can any one point me to a map or list or something? I am curious because I never get lag or denial of service so I figure I must be close. - Icewedge (talk) 18:29, 17 May 2008 (UTC)[reply]

m:Wikimedia_servers. Equazcion /C 18:37, 17 May 2008 (UTC)[reply]
Not much there on locations actually. They're in the state of Florida, but I don't know anything more specific than that. Equazcion /C 18:39, 17 May 2008 (UTC)[reply]
The primary databases are in Florida. In addition, caches for the purposes of reading pages and delivering images are located in Amsterdam and Seoul. Dragons flight (talk) 18:43, 17 May 2008 (UTC)[reply]
Ok, Thanks. It might be the Seoul server that is me fast access. - Icewedge (talk) 18:49, 17 May 2008 (UTC)[reply]

change the SEARCH field input box, please

Please make the SEARCH field input box *bigger*, *more prominent*, and at the *top center* of the home page.

Searching for articles is what people come to Wikipedia *for*. Making the search box small and sticking it in an obscure corner of the page is odd, awkward, silly, and for some visitors (elderly, vision impaired, or otherwise physically or mentally challenged) troublesome enough to make them give up and look somewhere else for their information. —Preceding unsigned comment added by 192.159.110.7 (talk) 00:12, 18 May 2008 (UTC)[reply]

S/he may have a point there. Perhaps the search box would be more visible to new users if it were directly under the puzzle globe? —Ashanda (talk) 00:21, 18 May 2008 (UTC)[reply]
Directly under the globe is exactly the right place. Someone looking for an article wants to go directly to searching for it, not scan down through two boxes and 11 links. Someone interested in finding out more about Wikipedia can easily skip the search box and browse through the links below it. -- John Broughton (♫♫) 01:34, 18 May 2008 (UTC)[reply]
The Commons' way of doing it isn't bad either. Instead of a list of portals or categories, they just put the search box right at the top of the page. —Remember the dot (talk) 01:53, 18 May 2008 (UTC)[reply]

Untraceable margin

Anybody has an idea why {{Parish church}} gets a big top-margin when used in St Patrick's Church, Hove? Circeus (talk) 01:46, 18 May 2008 (UTC)[reply]

It's to accommodate the size of the image. Try paring the image down to 200px or so. Cheers! —Ashanda (talk) 01:50, 18 May 2008 (UTC)[reply]
Even though I've looked at the template code and know there is patently no way this could be the solution, I tried. Lo and behold, it doesn't work. Circeus (talk) 03:32, 18 May 2008 (UTC)[reply]

Fixed. --- RockMFR 06:17, 18 May 2008 (UTC)[reply]

Adding Applet to my user page

Hi All

I am a registered user but not in the English Wikipedia.

Can I add an applet to me user home page at wiki? and if so I can I do it?

Thank u in advance —Preceding unsigned comment added by 89.139.159.30 (talk) 06:10, 18 May 2008 (UTC)[reply]

If you are asking about another language version Wikipedia, the answer is "no" - Wikipedia is not Facebook. And adding applets raises security issues. -- John Broughton (♫♫) 15:55, 18 May 2008 (UTC)[reply]

Is there a way to count how many articles are in a given category and ALL of its subcategories?

Other than manually :) I would like to know how many Poland-related articles do we have, which should be possible to find out if we could count articles from Category:Poland and its subcategories. Currently my estimate is based on roughly counting stubs, comparing them to project tagged stubs, and using the ratio to estimate all article. Such an estimation, of course, is far from satisfactory (FYI, it gave me a numbers: ~300 tagged stubs, ~9000 stubs total, ~3000 tagged articles, ~100,000 Poland-related articles total). The 100,000 number itself seems more or less correct, but I'd like a more precise estimate - since the error margin here is quite big.--Piotr Konieczny aka Prokonsul Piotrus| talk 13:53, 18 May 2008 (UTC)[reply]

The editor's index reveals that User:Chris G Bot 2 does this. Algebraist 14:10, 18 May 2008 (UTC)[reply]
When I need a quick count I usually fire up AWB and just click "make list", but I expect it would time out with such a massive number of articles to assemble. Plus there's the usual problem of Wikipedia's category tree being sufficiently jumbled that you're not going to get a very accurate count for "poland-related articles" from this analysis anyway: how closely related do you think Scripps National Spelling Bee is to Poland? (That's Category:PolandCategory:History of PolandCategory:Military history of PolandCategory:Military operations involving PolandCategory:Wars involving PolandCategory:World War IICategory:Events cancelled due to World War II, if you want to look it up. Category:World War II is a favourite of mine in pointing out things like this, as it seems to have worked itself into some of the most unlikely parent categories: I found it in a distant subcat of Category:Thailand once!). How accurate do you want to be? Happymelon 14:11, 18 May 2008 (UTC)[reply]
OT:It's at Category:ThailandCategory:History of ThailandCategory:Wars involving ThailandCategory:World War II. That's not very distant. Algebraist 14:48, 18 May 2008 (UTC)[reply]
Gah, I haven't thought of that. Yes, that kills that idea right there :> --Piotr Konieczny aka Prokonsul Piotrus| talk 14:28, 18 May 2008 (UTC)[reply]
Perhaps WikiProject Poland should consider creating something like the List of mathematics articles, though that takes a fair amount of effort to create and maintain. Algebraist 14:20, 18 May 2008 (UTC)[reply]
Some time ago I prodded List of Poland-related topics as it was indeed not maintained. Plus, can you imagine a list with 100,000 entries? There is Category:Poland-related lists and forgotten Wikipedia:WikiProject Lists of basic topics/Draft/List of basic Poland topics. No, as far as those lists go I'll stick to supporting only the assessment-related Category:Poland-related articles by quality, but as I pointed out above - those still cover less than 10% (probably around 3%) of eligible topics.--Piotr Konieczny aka Prokonsul Piotrus| talk 14:28, 18 May 2008 (UTC)[reply]
We at Maths survive OK with a list with 20,000 entries, and I suspect that 100,000 is a substantial overestimate: it seems likely that non-stubs are much more likely to get tagged than stubs, and unlikely that as many as 4% of all en.pedia articles are Poland-related. Algebraist 14:43, 18 May 2008 (UTC)[reply]
That's an interesting hypothesis - I would love to test it (see how large a % of en wiki is related to pl subjects), but I cannot think of any feasible methodology to do it (at least not anything short of many hour effort, which may be sensible if I were to write a paper based on a results, which I am not planning to do - yet... :).--Piotr Konieczny aka Prokonsul Piotrus| talk 18:14, 18 May 2008 (UTC)[reply]
Looking at the index, perhaps User:Erwin85/CatCount is a better place to get a count; as I read it, User:Chris G Bot 2 will produce an actual listing, which doesn't seem to be what is requested here. -- John Broughton (♫♫) 16:37, 18 May 2008 (UTC)[reply]
As far as I can tell from the documentation, CatCount doesn't delve into subcategories. Algebraist 17:02, 18 May 2008 (UTC)[reply]

Wikipedia as a chat client?

I just got this rather odd edit to my user talk page.[8] It occurred to me that while running Huggle I've sometimes seen what look like chat conversations going on as vandalisms to different articles. I wonder, is it possible that someone's using the recent changes feed as some sort of chat client? —Elipongo (Talk contribs) 16:11, 18 May 2008 (UTC)[reply]

Didn't we have a long discussion recently on this? In any case, given how quickly most vandalism is reverted, and how quickly an account can be blocked for repeated vandalism, it seems to me that Wikipedia is spectacularly inefficient as a chat room, and that the Internet has plenty of free alternatives far better suited for this type of thing. -- John Broughton (♫♫) 16:41, 18 May 2008 (UTC)[reply]

Can we produce a time graph / stats of article's activity?

Is it possible to feed an article (talk page, etc.) into some bot or other tool, to get information on how many edits (and editors) contributed to each over time (for example by month)? PS. I am relatively familiar with editor-side counters, but not with article-side counters, which is what I need for this question.--Piotr Konieczny aka Prokonsul Piotrus| talk 18:10, 18 May 2008 (UTC)[reply]

That's what wikidashboard's for. Algebraist 18:42, 18 May 2008 (UTC)[reply]

Pages renamed

How and why are the pages listed as renamed on these pages being renamed? Wikipedia:Version 1.0 Editorial Team/DC Comics articles by quality log and Wikipedia:Version 1.0 Editorial Team/Marvel Comics articles by quality log. Thanks for any help, Hiding T 18:30, 18 May 2008 (UTC)[reply]

They're pages that have been moved between runs of User:WP 1.0 bot - when it doesn't find a page that it found last time, but it finds a 'new' page with similar content, it twigs to the fact that it's been renamed and logs this appropriately. Happymelon 18:56, 18 May 2008 (UTC)[reply]
But there's nothing in the move logs, or deletion logs. Not that I can see, anyway. Hiding T 19:17, 18 May 2008 (UTC)[reply]
For example, ah, they've been moved back. But Sigmar (Marvel Comics) (edit | talk | history | protect | delete | links | watch | logs | views) shows no record of being moved to Sigmar (Marvel comics) or even deleted, even though the bot log states it was renamed from Sigmar (Marvel Comics) to Sigmar (Marvel comics). What's the bot picking up? Hiding T 19:23, 18 May 2008 (UTC)[reply]

Okay I need a bit of help here with some formatting and stuff....

Okay, so I need some help... it's kind of hard to explain what I'm trying to do but... I'm trying to have it so that when you visit a page (my userpage, specifically) it will be different every time, like there will be random options for words.... I'm not sure how to achieve this.... I've seen on other wikia's where they have template:verb or template:noun or something like that, and they have it all formatted with different options of verbs and nouns and such. I would just steal the formatting from those pages but pretty much all other wikias are blocked on this computer :( anyways does anyone know how to make this work? let me know at my talk page please. -Guitarplayer001 —Preceding comment was added at 22:05, 18 May 2008 (UTC)[reply]

User talk:Neil- the new talk page and my sig are allergic to each other

Hi my sig works fine as far as I know on every other page. But when it's put on User:Neil's it turns bits of his text there green afterwards. I have cut and pasted the code he gave me, which just meant two square brackets showed after my sig, could you look at the sig and the page concerned, and see what's happening? Because until then I can't post to the lovely Neil's page. :( Anyway, my sig is orange, not green, so I'm completely at a loss and intrigued as to why this would happen. Hope you can help.Sticky Parkin 22:08, 18 May 2008 (UTC)[reply]

Your sig does not terminate it's tags properly; html tags started inside a wikilike must be closed inside the wikilink (not outside). I've corrected you sig above (see diff). EdokterTalk 22:22, 18 May 2008 (UTC)[reply]