The technical section of the village pump is used to discuss technical issues. Bugs and feature requests should be made at BugZilla since there is no guarantee developers will read this page.
FAQ: Intermittent database lags can make new articles take some minutes to appear, and cause the watchlist, contributions, and page history/old views sometimes not show the very latest changes. This is an ongoing issue we are working on.
Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here.
Please sign and date your post (by typing ~~~~ or clicking the signature icon in the edit toolbar).
Discussions older than 7 days (date of last made comment) are moved here. These discussions will be kept archived for 7 more days. During this
period the discussion can be moved to a relevant talk page if appropriate. After 7 days the
discussion will be permanently removed.
Texvc patches
I don't know if this is an appropriate place to do so, but I'd like to draw attention to four texvc bugs that I wrote patches for a few weeks ago. Please could a developer review them and perhaps commit them? I'd especially like to see the colour patch in Wikipedia. Here are the bugs: #1663 (colour support), #2026, #3052, #4000. Lupin|talk|popups 01:42, 7 January 2006 (UTC)[reply]
You should have had four emails corresponding to four commits I made. Rob Church (talk) 15:24, 13 January 2006 (UTC)[reply]
For some reason I only got one, but I noticed that you'd commited the changes. Thanks! Do you know when these will take effect in wikipedia? Lupin|talk|popups 18:16, 20 January 2006 (UTC)[reply]
Whenever someone compiles/updates/synchronises. Rob Church (talk) 23:36, 25 January 2006 (UTC)[reply]
What is Wikimedia's energy source?
What energy source powers the Florida data HQ and by which power company? The lorax 20:09, 17 January 2006 (UTC)[reply]
Do they provide their service in exchange for that giant advert about Wikipedia? Martin 00:22, 18 January 2006 (UTC)[reply]
The energy source for Wikipedia article content, on the other hand, is traditionally caffeine. (SEWilco 05:34, 18 January 2006 (UTC))[reply]
I disagree. I say chocolate. [[Sam Korn]] 12:16, 18 January 2006 (UTC)[reply]
Chocolate contains a small amount of caffiene! --Aussie Evil 21:52, 18 January 2006 (UTC)[reply]
Meanwhile, the developers are dosed up to the nines on whatever Jimbo's auntie's cousin's younger nephew's dog's half-brother's owner's sister's ex's parents can get hold of. Rob Church (talk) 08:05, 25 January 2006 (UTC)[reply]
Ultimately, Wikimedia's energy source is Sol. --Aaron 23:16, 28 January 2006 (UTC)[reply]
Questions re server load from images in userspace
A policy is being prepared that may advise editors to remove templates with images from their userpages to lessen server load. Realizing that its hard enough to tune a system and near-impossible to explain it to civilians, still, I'm trying to understand this more. If anybody reads this who is familiar with the technical side of these issues and wants to reply that would be great, thanks. Herostratus 22:49, 20 January 2006 (UTC)[reply]
To clarify -- I'm given to understand that the size of the image does not matter much, in other words a 45x45 image uses basically as much as a 450x450 image. Is this correct?
Replies:
A large image uses more disk space, takes more bandwidth when transferred at full size, and requires more resources when being resized. It takes no more resources to refer to an already existing image of large size other than the network transfer.
Generally, you should not worry much about little things like templates and "server load" at a policy level. If they're expensive, we'll either fix it or restrict it at a technical level; that's our responsibility. --Brion 01:01, 21 January 2006 (UTC)[reply]
Does color depth make much difference? What about file format (jpg vs png)?
Replies:
At the moment, very large PNG images are more expensive than JPEGs to resize due to the memory usage of the converted program. This is a technical issue and can be improved; we already have technical measures in place to restrict very large such images. --Brion 01:01, 21 January 2006 (UTC)[reply]
Is it advisable to delete all images from userpages? Recognizing that this is an intersection of policy and system capacity, would an advisory such as "no more than five images is recommended on a userpage, including those in templates" help reduce server load?
Replies:
Generally, if an image isn't usable in the encyclopedia you probably shouldn't upload it to Wikipedia. Remember that everything here must be freely licensed, and can and will be redistributed to and by third parties.
If you don't want the picture of you, your cat, or your girlfriend to be copied, modified, reused, and redistributed by commercial and noncommercial publishers, don't put it on Wikipedia. --Brion 01:01, 21 January 2006 (UTC)[reply]
Recognizing that this is policy issue, would system capacity issues possibly be addressed by advising editors to go easy on image use in articles? (For instance, in a few articles I placed images more for page-design purposes than to illustrate a point. Should editors not do that? Only worry about it for likely-to-be-popular articles? Or not worry about it all?
Replies:
As a design and usability matter, you should avoid unnecessary images which don't contribute something to the article.
As a technical matter, it's our responsibility to keep the system running well enough for what the sites require. In other words: it's not a policy issue. If and when we need to restrict certain things, we'll do so with technical measures. --Brion 01:01, 21 January 2006 (UTC)[reply]
What about images in community space (for example, the one at the top of this page). There aren't many but they are served often. Would it help to cut back on those? What about Images in signatures? (I know sigs are discussed somewhere but are the servers straining enough to make a crackdown advisable, I wonder.)
Replies:
Community space is a small fraction of total hits, and stock images that don't change much are not terribly expensive to serve. Definitely not an issue.
Signatures are a different matter because of the way they multiply; a bad sig can pollute thousands of pages and is hard to clean up. This isn't really specific to images, but generally we have been cracking down on too much fancy stuff in sigs due to their tendency to break when "clever markup tricks" rely on software bugs which get fixed. --Brion 01:01, 21 January 2006 (UTC)[reply]
I suppose this is unanswerable, but is there any way to quantify image load vis-a-vis our server capacity in a way that a civlian could understand enough to contribute in an informed way to a policy discussion?
Replies:
"Policy" shouldn't really concern itself with server load except in the most extreme of cases; keeping things tuned to provide what the user base needs is our job. --Brion 01:01, 21 January 2006 (UTC)[reply]
I'm curious about something sort of related: have you seen WP:AUM? Is this not a case where a technical solution should be provided before we go off killing/changing tons of templates (in ways that increase bandwidth usage, or render poorly on certain browsers)? —Locke Cole • t • c 01:32, 21 January 2006 (UTC)[reply]
You should avoid metatemplates if they're ugly, hard to use, or fragile. That's just common sense; don't worry about "server load" for them.
For some very complex templates, people should probably be thinking about replacements for them such as proper data tables that will be easy for people to use and maintain, rather than hacking up ugly templates.
If someone's advising against "metatemplates" because they're ugly, fragile, and likely to break, listen to them. If someone's advising against them because they "increase server load", ask them for their benchmarks. I'd love to see them. --Brion 01:52, 21 January 2006 (UTC)[reply]
Jamesday has been widely interpreted (or perhaps overinterpreted) as suggesting meta-templates should be eliminated and his comments are responsible almost entirely for making WP:AUM into policy. Though I don't know for sure, the above questions may have been provoked by other recent comments Jamesday made about limiting image use in templates. It seems like Jamesday plus a number of non-devs have been pushing for editting policies (such as WP:AUM) based on minimizing server load, but your comments above seem to indicate we should not be worrying about server issues. So which is it? Dragons flight 02:05, 21 January 2006 (UTC)[reply]
I have to date refused requests to advocate the AUM "policy" based on server load because nobody's yet produced any evidence for this server load claim. While in a basic sense, calling two templates will involve twice as many template data loads as calling one, I've not seen any indication that this is significantly burdensome at realistic levels. If you can get James to produce a solid test for it, we'll talk about it. --Brion 02:12, 21 January 2006 (UTC)[reply]
Jamesday's concern in this area was more about invalidating page caches due to sub-sub-sub-templates being modified, and that change invalidating many pages. This, together with the level of complexity, fragility, and maintenance nightmare, are together why the WP:AUM is policy. -- Netoholic@ 02:26, 21 January 2006 (UTC)[reply]
Since our software doesn't actually do that at this time, and to do it we'd first want to set up a background process for invalidations which will make it easy and inexpensive, I don't see that as a strong argument from the load perspective. --Brion 02:32, 21 January 2006 (UTC)[reply]
First of all, this is not policy. No consensus of Wikipedians agreed upon it, and clearly not even a consensus of developers agree upon it. Second of all, the sub-sub-sub templates you speak of (such as {{qif}} should never (or only rarely) be modified). If the issue is only with sub-sub-sub templates, then it's a non-issue as far as I'm concerned. And in any event, server/technical issues should not influence editorial decisions except in the most extreme of cases (which it appears this is not). —Locke Cole • t • c 02:33, 21 January 2006 (UTC)[reply]
Just let me ask, what developer proposed this idea? How many developers have said it's a good idea? How can ordinary Wikipedians who nothing about the software deign to talk about making drastic changes to solve performance problems? You haven't made any measurements to evaluate the impact of this change and have no means of doing so, and so this is all just an elaborate theory that is more likely than not premature optimization in the wrong place. Deco 02:23, 21 January 2006 (UTC)[reply]
As far as I know, just Jamesday. If he's done any measurements he hasn't shown them to me. --Brion 02:32, 21 January 2006 (UTC)[reply]
Brion: can you go tell that to the people on the talk page there and remove the policy tag then since its a policy pushed against any attempt at votes etc.
Netoholic took a vauge set of statements from jamesday that weren't phrased at all as a demand and that he seemed to have little interest in substatiating with more details and used it to push that "policy" and it seems managed to get sufficiant support from gullible members of the admin team to push it into getting the policy tag against the wishes of much of the wider community. Plugwash 02:27, 21 January 2006 (UTC)[reply]
I've said that numerous times in the past. --Brion 02:32, 21 January 2006 (UTC)[reply]
BTW i think you really need to consider some promotions, the reason we get stuck with hacks like the if templates (and now the arguably worse hiddenstructure css) and css and javascript hacks everywhere is because we have a lot of sysops and very few developers. The result is that its much faster to get things done in a way a sysop can do through hacks involving css and javascript than it is to actually get them done properly (moderately important patches can take weeks to get committed even if a patch is written, nice to have stuff takes even longer. Plugwash 03:23, 21 January 2006 (UTC)[reply]
We've had a couple new devs come on recently; Rob Church has been applying fixup patches and such. --Brion 19:01, 21 January 2006 (UTC)[reply]
Avriette poked me after reading about the image load issues, and suggested I ping you guys about about [PhotoN]. Is there any interest in looking at pulling in something like this?
--adam at phase-n dot com 15:51, 25 January 2006 (AEST)
I suspect the plea is in response to the huge number of links generated by anonymous users actually remembering to sign their contributions when they haven't created a user page. Would it be possible to add the now-familiar namespace-dropdown to this list? —Phil | Talk 15:46, 23 January 2006 (UTC)[reply]
At some point in the not-too-distant future, I'll look into adding a namespace selector to some query pages. Rob Church (talk) 14:49, 27 January 2006 (UTC)[reply]
Audio links with loudspeaker
Can I get some comments on this proposed addition to the css? I want to add an .audiolink class to put clickable loudspeakers next to audio files (only where desired, of course).
Clicking the loudspeaker goes to the loudspeaker image page instead of the audio file. (Try it. See the big warning?) With the addition of this audiolink class, the loudspeaker would be added as part of the link through css, and would be clickable as expected.
I don't think it could possibly hurt anything, but "Any changes to Monobook.css or Common.css should be first proposed to Wikipedia:Village Pump." — Omegatron 20:15, 21 January 2006 (UTC)[reply]
I think {{click}} does what you're asking for. æle✆ 22:15, 21 January 2006 (UTC)[reply]
It doesn't work.
A css class is superior to a kludgy complex template. — Omegatron 05:46, 22 January 2006 (UTC)[reply]
Look at bugzilla:539 if you haven't already; there's work on allowing images to link somewhere other than the description page. æle✆ 21:18, 22 January 2006 (UTC)[reply]
Support. Sounds good to me. (And yes, it should be a system image. Go ask a dev about it, I'm sure they wouldn't mind.) —Ilmari Karonen (talk) 07:13, 23 January 2006 (UTC)[reply]
Some people wanted to change it, though; saying a blue loudspeaker would be better, etc. So maybe we should leave it editable for now? — Omegatron 03:30, 24 January 2006 (UTC)[reply]
Is there a standardized loudspeaker symbol somewhere in Unicode? If so, could we use that? --DavidCary 06:17, 26 January 2006 (UTC)[reply]
I don't think that's a very good idea for accessibility by many browsers. They were using the music note symbol before, but people didn't like it.
I tried adding the code above to both the monobook.css and common.css. It didn't have any effect, so I assume it's being overridden by something else, despite the !important tags. Can someone help? — Omegatron 19:37, 29 January 2006 (UTC)[reply]
The protection message is wrong
Until yesterday, when editing a semi-protected page, there was, quite correctly, no warning message at all. Now, it says that it has been locked so only admins can edit it, which is really very very wrong indeed. Has someone been entertaining themselves in MediaWiki: space again, or has something changed in MediaWiki itself? Either way, could the relevant person/people try to fix it? I've alredy seen a couple of confused talk page messages regarding this, and the problem is something like 24hrs old. -Splashtalk 02:11, 22 January 2006 (UTC)[reply]
Yes. But when/why was this changed. Like I said, until yesterday, there was no warning at all. And no warning at all is the right move, since why do people care if it is semi'd and they can edit it? If they can't they get a "view source" button and a message anyway, and there's no need to tell people already editing it that they are allowed to do so! -Splashtalk 02:21, 22 January 2006 (UTC)[reply]
I don't think it's inappropriate to remind people the article is semi-protected. I'm sorry we disagree on that. But at least we seem to agree that using MediaWiki:Protectedpagewarning is the wrong idea.. —Locke Cole • t • c 02:33, 22 January 2006 (UTC)[reply]
We have a tag warning about the protection, and I don't see why anyone who can edit the article cares, really, since they are still encouraged to edit it, unlike admins in the case of a full-protected page. What should we do about the message anyway: clearly, it can't stay in the broken state it is. -Splashtalk 02:49, 22 January 2006 (UTC)[reply]
I think we should compromise: add a new message for semi-protection warnings but have it default to blank. If/when it comes up, we can add the message later (but it should probably be in MediaWiki regardless so other MW users can customize it to their liking). —Locke Cole • t • c 05:00, 22 January 2006 (UTC)[reply]
You realise the software has no concept of "semi protection", right? It's just our name for a specific configuration set that allows us to add a protection level that requires an account to be autoconfirmed. I have a feeling this problem has arisen in response to a bug fix I committed last week, so I'll get onto providing some sort of solution. Rob Church (talk) 07:52, 25 January 2006 (UTC)[reply]
All right, here's what we have. It is my fault, but I'm not sure exactly how best to fix it, so I want some user input. The problem is this; there are an indefinite number of levels of protection given site configuration. So what is it you want to see? Separate notices would be a mess, and be quite unfeasible. Would you prefer to see no warning, or perhaps just details on who can do what - i.e. print out the current protection level, with a link to the protected page guidelines. I'm in your hands, metaphorically, so let's hear it? Rob Church (talk) 11:59, 25 January 2006 (UTC)[reply]
Previously there was no message when the page was semi'd and the usual message when it was full'd. I thought that was working ok, it having stood without comment for a month or so. If we feel we absolutely can't go back to that (and we should, imo, because "no message" is what autoconfirmed users get when they execute a move) then a human-friendly message giving the current level(s) would be better. Since there is no software concept of semi, though, human-friendly might be impossible, in which case nothing at all is probably better. At present, we have a both-ways message, which I suppose is kind-of alright too. That's not terribly helpful is it? -Splashtalk 12:08, 25 January 2006 (UTC)[reply]
The technical explanation for the change is that I fixed the function which checks for protection of any nature so that it works with the new protection system. As a side-effect, the message now shows up for all. I'm tending towards a brief reminder of the page's current editing restrictions unless there are objections. Rob Church (talk) 10:24, 26 January 2006 (UTC)[reply]
Ideally, I think the warning message would list the restrictions:
The following protections have been applied to this page:
That seems ok to me (i.e. what Robchurch proposes with the kind of info that Demi suggests). It would be nice if we can avoid "autoconfirmed" turning up and confusing newbies. -Splashtalk 15:09, 27 January 2006 (UTC)[reply]
How do you make the buttons lay next to the search box, not under (ex.)? MartinHagberg 12:39, 22 January 2006 (UTC)[reply]
There seems to be no option for this using inputbox (see m:Help:Inputbox), and since this is an extension in the MediaWiki source (and you can't include forms in raw HTML) to get it changed you'd have to file an enhancement request using wikipedia:MediaZilla. -- Rick Block (talk) 16:19, 22 January 2006 (UTC)[reply]
Looking at the page, I see the issue has been addressed. —Ilmari Karonen (talk) 07:06, 23 January 2006 (UTC)[reply]
With a recently added "break=no" parameter to inputbox. -- Rick Block (talk) 14:58, 23 January 2006 (UTC)[reply]
Which I've implemented above as an example. Rob Church (talk) 10:25, 26 January 2006 (UTC)[reply]
CVS Problem
Is there a problem with the CVS? Last night I tried to download MediaWiki 1.6, and today I tried to download the extensions, and both times I got the following error:
cvs.exe [checkout aborted]: Error reading from server
cvs.sourceforge.net: 0: No such file or directory
If this is just a problem for me, could somebody help me fix it? Thanks, Shardsofmetal[ Talk | Contribs ] 16:28, 22 January 2006 (UTC)[reply]
Sometimes sf.net anon CVS buggers out temporarily for some reason. — Ilyanep(Talk) 17:59, 22 January 2006 (UTC)[reply]
SourceForge's anonymous CVS servers have a reputation of being intermittent. Give it another go. Rob Church (talk) 07:53, 25 January 2006 (UTC)[reply]
Possible Signature Vulnerability
Forgive me if this has been mentioned before, but it appears to me that there is a severe security problem in letting users choose their own signatures. This is because people in Wikipedia use the links in the signature. However, using javascript and AJAX, I believe that an attacker could take the user to the desired location as well as load a webpage in the background. For instance, a vandal could change his/her signature to load Special:Makesysop with the proper parameters in the background to make a vandalbot username an admin while loading the desired page in the foreground. If that user then left an incendiary comment on the homepage of a bureaucrat, prompting the bureaucrat to click a link in the signature, then there could be quit a bit of damage done to Wikipedia. Where(talk) 20:33, 22 January 2006 (UTC)[reply]
Sigs are wikitext, not HTML, and thus cannot do anything disallowed in wikitext. --Brion 20:35, 22 January 2006 (UTC)[reply]
Even if possible, Special:Makesysop requires that a HTTP POST request is sent to the server to process form output. So the exploit as described would not produce a result. Rob Church (talk) 07:55, 25 January 2006 (UTC)[reply]
It's largely academic here, but it's worth pointing out that you can submit POST requests with AJAX. Lupin|talk|popups 05:15, 27 January 2006 (UTC)[reply]
AJAX-schmajax. You can submit POST requests with classic DHTML. --Brion 04:48, 31 January 2006 (UTC)[reply]
The style definition in MediaWiki:Common.css doesn't seem to strictly adhere to the CSS2 specification. The germane part of the style sheet is as follows:
The fact that some browsers allow applying the vertical-align style element to the <tr> tag does not mean that browsers are required to support this variation from the standard, and some browsers in fact do not do so. This leads to variation in appearance of the infobox text from that which was desired.
It appears that a standards-compliant style sheet should include the following styling in place of what's there today:
.infobox td,
.infobox th {
vertical-align: top;
}
This change would seem to produce the desired consistent alignment behavior in a browser-independent way. I therefore propose it for discussion. — JonRoma 03:39, 23 January 2006 (UTC)[reply]
Totally agree with this change, and more. We also need to add some padding to the cells, since that is done manually in almost ever infobox anyway. Please see simple:MediaWiki:Common.css and copy all of the Infobox template style section over to ours. -- Netoholic@ 14:49, 23 January 2006 (UTC)[reply]
JonRoma's request done. Adding padding to the infobox would mean that we'd have to go and change all the infobox templates on this end. Is someone prepared to go and do that? howcheng {chat} 00:29, 25 January 2006 (UTC)[reply]
Yes, where needed. The change is very subtle. -- Netoholic@ 05:44, 25 January 2006 (UTC)[reply]
Is there anywhere in Wikipedia where there is a complete description of how <noinclude></noinclude> are supposed to work? Also, the other special Wikipedia HTML codes (such as <nowiki></nowiki>)? Thanks.
⇒normxxx|talk⇒email 18:17, 24 January 2006 (UTC)[reply]
I don't know of any complete list of extensions. The purpose of noinclude tags is to include markup in a template which is shown on the template page itself but not on the pages into which it is transcluded. It is often used to add descriptive text on how the template is used, or to add it to a category for certain types of templates. Similarly, text marked <includeonly> is shown on pages the template is transcluded into, but not on the template page itself, and is useful for categories (since you usually don't want the template itself in the category). Deco 19:29, 24 January 2006 (UTC)[reply]
Include and noinclude are described in the "Noinclude and includeonly" section of m:help:template. nowiki is part of the wikimarkup syntax, described at Help:Editing. Extensions in general are described at m:MediaWiki extensions, although not all extensions are installed at all mediawiki sites. I'm not sure where the list of extensions installed at, say, en.wikipedia.org is. Perhaps someone else who watches this page might be able to help out. -- Rick Block (talk) 02:22, 25 January 2006 (UTC)[reply]
There's Special:Version which, I think at least, speaks only about enwiki. -Splashtalk 05:48, 25 January 2006 (UTC)[reply]
<noinclude>, <includeonly> and <nowiki> are not extensions, they are part of the core parser. There's also <onlyinclude>, <center>, <gallery>. <math> and <html> are optional, the former is enabled on this wiki but the latter isn't. Wikipedia runs on the bleeding-edge development version of MediaWiki, so documentation may occasionally lag behind features. We rely on users to watch wikitech-l and bugzilla and keep it up to date. -- Tim Starling 02:18, 28 January 2006 (UTC)[reply]
12 hours watchlist
I have experienced a switch from default 3 days to default 12 hours watchlist at no: and nn:, but not at en:. If I select 3 days explicitly and then hit "hide my edits", I'm back to 12 hours. This happened to me and others at no: on 19 January and has not improved yet, and then at nn: on 24 January. I've not had any problems at en: so far. Have there been any software updates recently or any other changes that could explain this? --Eddi (Talk) 04:06, 25 January 2006 (UTC)[reply]
Here's a chunk of CVS Mediawiki code that seems to explain it:
So if you would otherwise have over 1000 items displayed, it seems that it restricts you to 12 hours by default. Lupin|talk|popups 04:08, 25 January 2006 (UTC)[reply]
I have more than 1000 pages on my watchlists at no: and nn:, and I may incidentally have passed the limit on 19 and 24 January, respectively. But the number of items displayed for 3 days is far from 1000, even counting talk pages, so the 1000 limit is probably on the number of watched pages, not displayed items – or it may be an even bigger bug. --Eddi (Talk) 04:21, 25 January 2006 (UTC)[reply]
You're right. It looks like $nitems is the number of pages in your watchlist excluding talk pages. I'm guessing that things are done this way for performance reasons. Lupin|talk|popups 12:40, 25 January 2006 (UTC)[reply]
Had the same problem when my watchlist got up there. Simplest solution: set your watchlist the way you want it, with the proper "&" variables in the URL (http://en.wikipedia.org/w/index.php?title=Special:Watchlist&days=3&hideOwn=1, for example), then bookmark/fave it -- putting it on the "Bookmarks" toolbar in Firefox or the "Links" toolbar in IE gives you one-click access to your favorite watchlist view (and makes it that much easier to compulsively check for bad edits during your day....). Or you can set that URL as one of your browser's start page (Firefox allows multiple start pages) -- this will also get you extra points on the official Wikipediholic test.... — Catherine\talk 04:25, 27 January 2006 (UTC)[reply]
Is it possible to utilize the userspace Javascript/CSS files to create a custom version of the character insertion tools? I'd like to make it so that I don't see some of the foreign-language characters that I never use, and also add some macros for commonly used functions like *{{subst:test1}} ~~~~. I've managed to add a couple of options via hacks, but I'm not very satisfied with the results. I'd like to be able to replace the whole thing. Crotalus horridus (TALK • CONTRIBS) 00:32, 26 January 2006 (UTC)[reply]
My suggestion is to use the code #editpage-specialchars { display: none; } to hide the main one then copy the code from the main one over to your own css file and butcher it mercilessly as you see fit (making sure to remove or change the div id) and that should in theory at least give you your own custom special-chars box. JtkieferT | C | @ ---- 01:44, 26 January 2006 (UTC)[reply]
What about a setting in 'preferences', to allow users to choose a layout. I much the prefer the now reverted dropdown box, and since it works on my system, I'd like to be able to use it. -- Ec5618 10:09, 27 January 2006 (UTC)[reply]
search bug?
Please confirm this bug, then post it to the appropriate place (Bugzilla?).
When I type
magnetotactic
into the little search bar on the left and punch the "Search" button (or the "Go" button),
I get a page that includes
----
Results 1-4 of 4
* Lodestone
...cteria (Italian Wikipedia) had learned the trick. Magnetotactic bacteria build miniature magnets inside themselve...
Relevancy: 11.8% - 1.3 kB (185 words) - 21:29, 12 January 2006
* Sense
Relevancy: 3.6% - 12.6 kB (1894 words) - 17:42, 14 January 2006
----
I expected it to *either* say "Results 1-2 of 2", then list 2 results,
or else say "Results 1-4 of 4", and then list 4 results.
But it seems to claim there are 4 results, and then only give 2 of them.
Another bug is that neither "2" nor "4" are correct. At least 5 articles (perhaps more) use the word "magnetotactic":
Search indexes are a little out of date, and will be rebuilt/updated/improved/etc. soon. Rob Church (talk) 16:21, 26 January 2006 (UTC)[reply]
Deprecating images that are used on templates
I've created a SVG version of the peace symbol, Image:Peace Sign.svg. I'm attempting to replace all instances of the old Image:Peace-symbol.png with this (since, as a vector image, the SVG version scales much better to different resolutions). But I'm running into some trouble. The "What links here" page doesn't seem to be getting updated properly. Many of the uses are on templates, but even when I both replace the image on the template and then do a dummy save on the pages that transclude it, the list is still not updated. What do I need to do to get an accurate idea of where the image is used, and have it updated as I change it? Crotalus horridus (TALK • CONTRIBS) 06:45, 26 January 2006 (UTC)[reply]
I think making null edits on the pages that use the template updates the what liks here list. Not that that sounds like a very acceptable way out for you. --Martyman-(talk) 07:48, 26 January 2006 (UTC)[reply]
I'd suggest just going through all the links in the what links here list, skipping the ones that already have the SVG version. A tabbed browser like Firefox makes this very easy. Or you could just add a note to the image talk page and leve it at that, letting people migrate to the SVG version gradually. —Ilmari Karonen (talk) 12:17, 26 January 2006 (UTC)[reply]
Spam protection filter
I was unable to close the VfD discussion for Mofunzone, which gave me a new, unfamiliar message on both the discussion page and the article itself :
The page you wanted to save was blocked by the spam filter. This was caused by a link to an external site.
See the spam blacklist on Meta for a full list of blocked sites. If you believe that the spam filter is mistakenly blocking the edit, then please request that it be fixed on the spam blacklist talk page. The following is the section of the page that triggered the filter:
The following text is what triggered our spam filter: (EN Wikipedia's address)
Anyone have any idea what is actually going on here?
It's broken, don't know why. Disabled for the moment. --Brion 09:30, 26 January 2006 (UTC)[reply]
Thanks! It works fine for me now. I suppose the filter script needs more off-site testing? :) - Cheers, Mailer Diablo 09:34, 26 January 2006 (UTC)[reply]
The problem was not enough on-site testing. It had already been tested on my computer and on Wikicities with no problems, a few minutes of careful observation after deployment on Wikimedia would have picked up the problem. -- Tim Starling 04:36, 28 January 2006 (UTC)[reply]
Nested tables and wikitable
If you have a wikitable and have another table inside the wikitable, that table will inherit all attributes from the wikitable, and that's is seldom what you want (if you want the nested table to be a wikitable, you specify that one as a wikitable).
Ther is a simple fix for the problem, just change the css for wikitable to:
Take a look at the newly featured article Krazy Kat. Specifically, this edit here and this one here. Notice how there are problems with the footnoted reference to Kramer in either version. In both cases the numbering of the footnotes is wrong; in the former there is only one link next to "Kramer" in the Notes section despite the two references to him, whereas in the latter there are two links as there should be, but the name "Kramer" is completely missing from the Notes section! How do I resolve this issue? Andrew Levine 02:44, 27 January 2006 (UTC)[reply]
Hmmm...I tried playing around with it, but was unsuccessful. I'd be interested to find out what's wrong. — Knowledge Seekerদ 03:23, 27 January 2006 (UTC)[reply]
This seems to be a new problem with all pages currently using cite.php I think it is a bug in the code. Hopefully a developer will fix it soon. --Martyman-(talk) 04:30, 27 January 2006 (UTC)[reply]
Cite.php bug
What hapened? It was working fine until yesterday, Now there is an obvious bug, see List of charismatic leaders. How do we alret the developer? ≈ jossi ≈t • @ 04:54, 27 January 2006 (UTC)[reply]
I've reverted the buggy version of the extension. Use ?action=purge or edit to fix affected pages you may find. --Brion 10:17, 27 January 2006 (UTC)[reply]
Cheers. What happened? —Phil | Talk 10:37, 27 January 2006 (UTC)[reply]
Please ignore the "Did you know" and "In the news" headings, as that is just a bug on this page only. It's On this day and Wikipedia Community that need to be fixed. Good luck.
Every page on Wikipedia is a collaborative effort. But there are some special places reserved for specific types of discussion and assistance. Find what you're looking for here:
The Community Portal — The center of community involvement. Learn about projects and activities you can join to help improve Wikipedia.
The Help Desk — Come here if you need help editing. You can ask a question about using Wikipedia. Alternatively, you can find what you need at Help:Contents.
The Reference Desk — For questions about any subject you're researching or curious about (not about Wikipedia itself), just like at a library's reference desk.
The Signpost — Wikipedia's newspaper, where you can read and post news about what's happening on this website.
Donations — Wikipedia is funded entirely by its users. We appreciate all donations. Thank you!
I've spent hours trying to find why the headings in the right-hand column don't line up. Are you an expert at markup? Can you fix this? --Go for it! 04:37, 27 January 2006 (UTC)[reply]
I've no idea what the root cause is, but I have to say that the DOM tree for that table is a mess. It looks like someone applied a sort of a shotgun approach to DIV placement to it. One difference I can immediately see is that the "In the news" section is wrapped in a DIV with style="float: right; margin-left: 0.5em;", while the other two sections in the right hand column are not. That could well be the cause, but I'm somewhat scared of actually taking a look at the Wiki source to test this hypothesis... —Ilmari Karonen (talk) 17:07, 27 January 2006 (UTC)[reply]
Please have a look into my sandox at this revision. I have replaced all div tags with span (diff). Don't ask my why, but I have had several very strange effects with div in the past, without being able to say what goes on. --Adrian Buehlmann 18:13, 27 January 2006 (UTC)[reply]
Brackets in links
Often I notice brackets () inside wikilinks represented by %28 and %29 e.g. Tom Jones (singer) [[Tom Jones (singer)]] and Tom Jones (singer) [[Tom Jones %28singer%29]], these are obviously the same. Is there any reason for this and is it ok to replace the code with the actual symbols? I assume it is but I don't understand why people do this in the first place. Martin 13:35, 27 January 2006 (UTC)[reply]
Such links have been copied-and-pasted fgrom URLs. It is fine to change them back. - IMSoP 14:15, 27 January 2006 (UTC)[reply]
ok thanks Martin 21:42, 27 January 2006 (UTC)[reply]
Is there anyway to get a random page generated from a single category? I am thinking about for use in Portals.--Birgitte§β ʈ Talk 16:46, 27 January 2006 (UTC)[reply]
It's been requested, but I can't remember which bug number at the moment. Rob Church (talk) 02:06, 30 January 2006 (UTC)[reply]
Infobox CSS change
Somebody just changed the CSS for .infobox and it looks horrible. Can we change it back? --Gareth Hughes 17:25, 27 January 2006 (UTC)[reply]
I've corrected the CSS so that the display isn't changed. Changing the CSS for infobox classes changes a whole lot of different infoboxes. Shouldn't this have been discussed beforehand? --Gareth Hughes 17:55, 27 January 2006 (UTC)[reply]
Please undo this edit, as it was not in the original infobox definition. TH cells are centered in most browsers by default, but some infoboxs are designed to left-align them as a design choice. Your edit overrides that at a cell level, and so is changing those appearances. For example, the Template:Infobox example template should show all cells left-aligned, but is not as a result of your edit. -- Netoholic@ 20:42, 27 January 2006 (UTC)[reply]
"Difference between revisions" page not working correctly
Normally when you compare two versions of a page (to see what changes were made or to revert vandalism etc) it shows all the text from both revisions in 2 colums with differences highlighted in red text. At the moment, when I tell it to compare 2 versions, its just showing the current version as is, with pictures and formatting etc, like the normal article. Any ideas?
--Naha|(talk) 20:38, 27 January 2006 (UTC)[reply]
Err, ok this HAD been happening for a good ten minutes or so at least, but it appears to be working fine now. Not sure what changed hehe. --Naha|(talk) 20:42, 27 January 2006 (UTC)[reply]
If you see it again, please provide some specific links. --Brion 21:18, 27 January 2006 (UTC)[reply]
Is there any way to get raw output from a Category that includes the articles linked there?
I'm trying to find out if I can use some of this functionality on my monobook.js for an image tagging tool. Thanks! ~MDD4696 23:49, 27 January 2006 (UTC)[reply]
As far as I know, the actions are "history", "edit", "submit", and "raw". Raw just outputs your js as js rather than an HTML page. I don't think you can get raw output from a category. Superm401 - Talk 03:10, 28 January 2006 (UTC)[reply]
That doesn't appear to do anything, looking at the code; it may just be something to do with "tricking" the cache in some way. - IMSoP 19:43, 29 January 2006 (UTC)[reply]
Request for recompilation of texvc
Rob Church kindly committed some patches to texvc, but it hasn't been recompiled for wikipedia so they have no effect here. Please could texvc be recompiled and wikimedia wikis updated? Lupin|talk|popups 04:51, 28 January 2006 (UTC)[reply]
I think Brion's looking into recompiling and updating now. Rob Church (talk) 02:07, 30 January 2006 (UTC)[reply]
And has now finished it. Rob Church (talk) 03:51, 30 January 2006 (UTC)[reply]
PHP errors on meta
I'm getting intermittent PHP errors on Meta, when I hit "edit". For example, "Fatal error: Undefined class name 'parseroptions' in /usr/local/apache/common-local/php-1.5/includes/MessageCache.php on line 45". Dmharvey 06:40, 28 January 2006 (UTC)[reply]
I saw one of those here as well (may have been a different script but same class name). I almost forgot to add it to my extensive collection of them. :) Superm401 - Talk 07:42, 28 January 2006 (UTC)[reply]
Almost without doubt, a one-off. Happens sometimes. Managing an Alexa top-20 website with ~100 servers and a lot of hits per second; developers who, with one exception, aren't paid and do it out of the goodness of their hearts...mistakes are going to occur, and should be excusable. Rob Church (talk) 02:09, 30 January 2006 (UTC)[reply]
From what I can see, these are artifacts of the way we push updated code to the servers. Sometimes you just at just the wrong microsecond and the file's halfway through being copied. The code cache then sometimes gets confused with the bogus file in its memory, so occasionally they stick around on one server until it gets restarted. We're poking around at ways to do this more cleanly. --Brion 03:53, 30 January 2006 (UTC)[reply]
Images at "Wikipedia:Copyright problems"
The instructions at WP:CP currently state that {{article-cv}} should be used to list images on that page. However, if one follows this, the entire image is displayed because it isn't prefixed with a colon ( : ). Is there another template that should be used for images? There is no {{image-cv}}. -- Gyrofrog (talk) 16:09, 28 January 2006 (UTC)[reply]
Yeah, that'd be nice. When I created article-cv I didn't create image-cv to avoid cries of "instruction creep" (and also I'm willing to bet large sums of wikimoney that it will be overlooked 60% of the time anyway — who ever reads the instructions?). But taht doesn't mean we couldn't try — I wonder if a Template God is able to use those wacky things that templates can do to 'sense' if the 'article' name begins with "Image" and automate the process within a single template (then creating a redirect from image-cv to article-cv for simplicity's sake)? -Splashtalk 17:44, 28 January 2006 (UTC)[reply]
Well, it wasn't always like this, but I'm not sure how to put things back the way they were. I went to add an image and noticed that soneone had added the images directly into the listing. I figured this was a mistake and prefixed them with colons. But after I added my listing I noticed the same thing had happened. I (briefly) checked the histories of both WP:CP and {{article-cv}} but couldn't tell when something relevant might have changed. -- Gyrofrog (talk) 17:51, 28 January 2006 (UTC)[reply]
{{article-cv|:Image:Phase Modulation.png}} works fine for me. The colon has always been necessary. -Splashtalk 18:08, 28 January 2006 (UTC)[reply]
I guess I forgot (as did the person before me). When adding {{imagevio}} to the image itself, it generates the text for that particular image and does include the colon. But the instructions at WP:CP omit the colon (I have gone back and added a colon). -- Gyrofrog (talk) 19:17, 28 January 2006 (UTC)[reply]
Thanks. In my defence, when I created those instructions, I did include the colon (e.g. [1]), but someone helpfully removed it later... -Splashtalk 19:34, 28 January 2006 (UTC)[reply]
Wikifetcher
Devs might already know about this, but is there anything we can do to block remote loads from this new "Wikifetcher" gadget? (http://www.wikifetcher.com/wf/index.php) It's basically a "steal content for your adsense site" mechanism. The site says "IMPORTANT NOTE: Wikifetcher uses a method called "Remote loading", which means that the mirror loads a page from the Wikimedia servers directly every time someone requests a page from them. This method is forbidden by Wikipedia, so you may not use wikifetcher on Wikipedia." I don't think this is going to stop your average SEO/Adsense site builder unless there's some technical measure, though. Just stumbled across this and thought an FYI was in order, anyway. — Catherine\talk 23:07, 28 January 2006 (UTC)[reply]
It might be possible to block by user-agent, if it uses a distinct one. If it doesn't, it would be a good thing to ask them to use a distinct one. Even then, it's easy to change, since the source is available. --cesarb 23:39, 28 January 2006 (UTC)[reply]
Sounds like classic Bandwidth theft to me. What's the legality of using this thing in the US? Raul654 06:41, 29 January 2006 (UTC)[reply]
Just to point out this Wikifetcher is nothing to do with the Wikifetch project I am spearheading (which hasn't kicked off much). :-) Rob Church (talk) 23:28, 29 January 2006 (UTC)[reply]
As to the actual issue, sites which don't want their content remote loaded can block the IP addresses of servers doing so using their preferred method; at the proxy level (e.g. for sites using Squid, which is what we do when we catch the buggers) or directly in Apache using a swift DENY FROM. Rob Church (talk) 23:29, 29 January 2006 (UTC)[reply]
The problem I see is that this person is selling this PHP gadget, which means that he's making it easy for his many different customers, using many different servers, to leech off our bandwidth. I was just curious if there's any way (via user-agent or something else) to block the fetcher itself, and not the particular IP, or if somebody has to watch for these and block them one by one. I am just guessing that if this became popular it could have a relatively significant impact on our servers (or Wikicities', or Wookiepedia, or any of the other popular Mediawiki installations). — Catherine\talk 23:54, 30 January 2006 (UTC)[reply]
Anyone who pays money for that is a moron: it takes about 30 seconds to write one, like hundreds (perhaps thousands) of others already do. --Brion 04:46, 31 January 2006 (UTC)[reply]
Bug report: search box
It appear that the nowiki-tag produces quite undesireable results when used in conjunction with this search box:{{search wikipedia}}
For example, see four tildes: ~~~~. Oddly, when transcluding the template, the problem seems to go away, though. The Reference Desk currently uses the code in the standard header, which means transclusion wouldn't be practical there. Any thoughts? -- Ec5618 23:36, 28 January 2006 (UTC)[reply]
It's definitely a bug; you should report it on bugzilla. --cesarb 23:42, 28 January 2006 (UTC)[reply]
I've commented-out the template call in your example here, because it's affecting the whole page; to see what's happening, uncomment and do a preview. --cesarb 23:46, 28 January 2006 (UTC)[reply]
Right, thanks. I'm not quite comfortable submitting bugs, to be honest. I can tell you that it seems to affect math-tags as well: . -- Ec5618 23:47, 28 January 2006 (UTC)[reply]
Well, I'm comfortable submitting bug reports, and I will submit this one. --cesarb 00:02, 29 January 2006 (UTC)[reply]
I noticed that a while ago you changed the format of the monobook skin so that there was no indentation between the edge of the page and the article tab. However, you changed this back to the previous format. I was wondering what the reason for this is, because I liked the other one better. Also, if I update my mediawiki installation, and don't update the css files (to keep the different tab formatting), are there any other css changes that I need that I would be missing? Thank You, Shardsofmetal[ Talk | Contribs ] 04:34, 29 January 2006 (UTC)[reply]
That was a patch I applied (authored by a third party, Chris Ware); a couple of devs made light protest, and there were a few user complaints, so I reverted. Rob Church (talk) 23:30, 29 January 2006 (UTC)[reply]
AOL IP ranges
One of the AOL IP ranges has been given as 202.67.64.0/18. It was first listed as such all the way back on October 12 2004 by User:Jamesday. However, a whois check shows it's managed by APNIC and they report it as allocated to Primus Telecom Australia, which is not a subsidiary of AOL.
Can we clarify this? Did it get reallocated? Or is this a typo and the real AOL range is something else? And if it's Primus Telecom does it need any special handling at all or should we just drop it from the list? -- Curps 06:29, 29 January 2006 (UTC)[reply]
AOL's own webmaster info page lists this range (or a subset of it), but ARIN says it's managed by APNIC and APNIC says it's allocated to Primus Telecom. Hmmm... -- Curps 06:44, 29 January 2006 (UTC)[reply]
I wanted to direct some attention toward this seemingly forgotten page.
A lot of people have been reporting what they percieved were bugs, though it seems few people actually watch the page at all. The page was a terrible mess, so I can imagine that it thus didn't have a high priority. I have recently removed a lot of fluff, and have tried to improve the layout. Perhaps some knowledgeable people could have a fresh look at the listed Bugs. -- Ec5618 15:47, 29 January 2006 (UTC)[reply]
Can understand why people doesn't use that page, WP:BUG contains: # Providing technical details with our customized bug-reporting tool, MediaZilla., Wikipedia:MediaZilla contains first: Report it at Wikipedia:bug report - this is the easiest way. So it's a circular procedure to report a bug that way. If someone tries to post a bug there wheel stuck in a while-loop. →AzaToth 15:52, 29 January 2006 (UTC)[reply]
Still, surely this page should be monitored closely. The comments at Wikipedia:Bug report shouldn't be ignored. -- Ec5618 20:35, 29 January 2006 (UTC)[reply]
There's too many of these scattered pages. In general I recommend these old pages be closed; it's misleading to imply that developers will read and respond to bug reports on some page we obsoleted with a bug tracker in 2002... --Brion 23:15, 29 January 2006 (UTC)[reply]
Mark the buggers with {{oldbugpage}} at the top. This adds a blunt but not too intimidating box pointing all bug and feature requests to BugZilla. Rob Church (talk) 08:04, 1 February 2006 (UTC)[reply]
What links here not accurate
Sometime in the last week or so, the What links here page for the Persondata template stopped accurately listing all the articles that included the template. Whereas previously it was reporting around 300 inclusions, it suddenly dropped to about 150, and I know of several examples of articles that include the template which are no longer being listed on the page, for example Ross Winn. Am I missing something or is there some kind of bug here? Kaldari 20:05, 29 January 2006 (UTC)[reply]
Nevermind, it looks like it is a bug: [2]. Kaldari 20:08, 29 January 2006 (UTC)[reply]
I'll slap a bot onto it. Rob Church (talk) 23:31, 29 January 2006 (UTC)[reply]
Bah, some bugger's already done it. Rob Church (talk) 23:48, 29 January 2006 (UTC)[reply]
I wonder if you could reveal how one bots this problem, and who one asks for their bot's help? The WLH bug is jamming up TfD something chronic. I wonder if the devs might nobble the bug soon, or press their big "Update all template inclusions" button (they have one, right?). -Splashtalk 02:19, 30 January 2006 (UTC)[reply]
On a related note, for the purposes of manual orphaning, someone suggested searching for {{name}}, but this turns up every article containing the string between the {'s so is a pain to trawl. It does at least highlight the actual occurences of the full string, so is usable. How complete is this search likely to be? -Splashtalk
It turns out Tim's been running the refreshLinks maintenance script on all wikis, and as far as I know, this one's now been done. That should have sorted most, if not all, template links out. My method used the pagelinks table to pick up pages still pointing to the templates and then null-edits them to update the templatelinks table. I must also point out that this was not a bug - it was the result of an update to the software. Rob Church (talk) 03:54, 30 January 2006 (UTC)[reply]
That's encouraging, but it certainly hasn't come close to fixing the issue. A case in point is Special:Whatlinkshere/Template:MonthN which claims to be included in only 3 articles, but is included in at least all those (ten) in Category:Timeline of Afghan history, 2004 and probably more. Has Tim stopped his script, or does it really take literally weeks to run? -Splashtalk 18:14, 30 January 2006 (UTC)[reply]
I'll answer the last bit first. At last estimate from Domas Mituzas, we had some 50 million rows in the link table for this Wikipedia alone. You do the math. As to the former bit, I'll see about running a manual check on that template and throwing a bot at the results to see what happens. Rob Church (talk) 17:31, 31 January 2006 (UTC)[reply]
Deviation from MediaWiki?
How much does the Wikipedia software deviate from MediaWiki? Are there many changes, or is it essentially the same? Several of my recent questions might have been answerable just by looking at the MediaWiki source code, so I was hoping that there wouldn't be much difference between the two... ~MDD4696 20:31, 29 January 2006 (UTC)[reply]
It deviates almost nothing. The only deviations come from the fact that often code is first tried "live" on the site before being added to CVS, the configuration, and perhaps a few tweaks. Notice, however, that you have to look at the CVS HEAD, since it's the version closest to what's used on the site. --cesarb 20:46, 29 January 2006 (UTC)[reply]
Not quite. Code is committed, then it's reviewed and tested on http://test.wikipedia.org to check for fatal errors before being synchronised to all our servers in one go. Wikimedia's wiki farm runs a more or less up-to-date version of CVS HEAD. Rob Church (talk) 23:32, 29 January 2006 (UTC)[reply]
I don't support this. Normal notability guidelines should apply. If the reference plays an important role, it deserves an article. If it's only valuable to Wikipedia editors, it can be in Wikipedia space, like Wikipedia:Using the Wayback Machine. Creating a separate namespace will only muddy the waters. Superm401 - Talk 07:02, 30 January 2006 (UTC)[reply]
Discussions areas need layout revision
Hi Folks
I've noted that in discussion areas, where people are having various edit wars, conversations, etc., it's not easy to see who's making what comment, who's quoting someone, when one person stops talking and when another begins, and so on. After a few edits and replies, it becomes an indecipherable hodge podge. This isn't really adequate for constructive resolution of questions and conflicts.
The comment title and author should automatically be be placed at the beginning of every post and automatically separated from any comment content by a complete line space. Each person's discussion comment should then be automatically followed by two line spaces to cue the reader that this author's commentary is finished and the next author's entry begins.
TGD
The problem is that talk pages are treated almost exactly like articles, so such formatting would be difficult. There's an idea to replace talk pages with threaded forum–type systems at m:LiquidThreads for MediaWiki 2.0. æle✆ 22:17, 29 January 2006 (UTC)[reply]
Yes please. Kaldari 22:26, 29 January 2006 (UTC)[reply]
Have you seen how the French Wikipedia lays out their discussion pages? See Le Bistro, their equivalent of the Village Pump. I think it's all done with CSS; perhaps we could adapt something similar here. — Catherine\talk 00:20, 31 January 2006 (UTC)[reply]
It's a rather simple hack. only need css. :) →AzaToth 00:36, 31 January 2006 (UTC)[reply]
Newbies and images
In certain areas of the website, we are being overwhelmed with newbies uploading copyrighted images (copyvios) and images with uncertain copyright status (not usable). Naturally, newbies are generally unaware of our image usage policy, which has been thoughened considerably, incidentally. But the thing is, this is multiplying considerably the work of everybody else, in order to keep Wikipedia in compliance with both the law and our policy. Perhaps we should consider making the ability to upload images available only to accounts that are, say, a couple of months old? I don't know if that's even possible from the technical point of view, so I'm not even proposing this elsewhere before I find that out. Regars, Redux 23:33, 29 January 2006 (UTC)[reply]
I'd guess it would be easy to do using the "autoconfirmed" which is used for page moves. --cesarb 01:47, 30 January 2006 (UTC)[reply]
Possible, and not a bad idea. Autoconfirmed is an automatic permission users receive when their account has been registered for a specific period of time; the default for which is four days, and this is what we've got set on Wikimedia wikis. File a request on BugZilla and see what happens. Rob Church (talk) 03:55, 30 January 2006 (UTC)[reply]
Thanks for the feedback. But BugZilla? Isn't it supposed to be for reporting bugs? I believe this is more about a change in the MediaWiki, which might have to be supported by a policy change. Then again, I'm not really experienced in reconfiguring the software... Redux 15:50, 30 January 2006 (UTC)[reply]
We use BugZilla to keep hold of bugs, feature, and site configuration requests. The correct product and severity for a feature request are MediaWiki and enhancement, respectively. Rob Church (talk) 17:29, 31 January 2006 (UTC)[reply]
I think it's a good idea, first thing to do will be to see if the community in general agrees, then if so file it on bugzilla (as far as I understand bugzilla is for all changes/improvements as well as actual bugs). Martin 15:57, 30 January 2006 (UTC)[reply]
I'm not sure that a couple months is the right length of time. When I notice new users uploading problematic images, I will engage them in a discussion about the policies, what's okay to upload, and inform them about Commons. I've found that the new users catch on pretty quick and have become good contributors to Wikipedia. Granted that many of the images at [3] are probably copyvios, though many others are self-authored photos.
I think that Special:Upload has improved greatly at explaining what's okay and not, but could be made more clear and explicit. Many users that I engage in discussion are quite confused by Wikipedia:Image copyright tags and don't understand that well, which license to select. Maybe we could improve that page, and link it boldly to the line "Specify the licence of the file by selecting it from the drop-down list below." on Special:Upload? -Kmf164 (talk | contribs) 17:50, 31 January 2006 (UTC)[reply]
Just to point out an alternative here. We can also create permission groups which are explicitly denied the ability to do things, e.g. we could create a noupload group which denies upload rights to users. This could then be added by a local bureaucrat using a modified version of the current interface for granting rights, which I'm going to improve sooner or later. Rob Church (talk) 08:03, 1 February 2006 (UTC)[reply]
I believe that this idea is complementary, rather than an alternative. I like the idea, as a form of removing upload rights from whichever user (regardless of how old the account is) who shows a disposition for ignoring policy and uploading problematic images. Although I could suggest, if it's even possible from a technical standpoint, what if that could be done in a somewhat similar way to blocking a user? I mean, Administrators might be given the ability to suspend temporarily a user's ability to upload images. On the original suggestion, of course, two months was an original suggestion, it could be a little less, but I do believe that, given our policy, and our concern with keeping Wikipedia in compliance with the law, it has become somewhat difficult for the ability to upload images to remain as an automatic privilege of every new account. It's severely multiplying the work load of other users. Not to mention that some newbies don't respond immediately — nothing too strange, as new users aren't all that active in the beginning as a rule. Also, some newbies don't really know what's going on when we contact them about the images not being usable, and it takes them a while to catch on. As an alternative, I might suggest that, instead of making the ability to upload images available to new users after a predetermined period, we could make it available upon request. I don't mean any kind of "support/oppose" vote, the user would just have to answer a few standard questions, and if (s)he answers right, the ability to upload would be granted — and in order to answer right, that person will have to read up on Wikipedia policy. As a complement to that, future abuse could result in temporary suspension of the ability to upload images. Redux 13:38, 1 February 2006 (UTC)[reply]
Common.css ammendment proposal
I would like to add the following two rules to MediaWiki:Common.css
#toc::before { content: "The following section incorrectly uses id=\"toc\" instead of class=\"toccolours\". Please amend this by editing the relevant template or page. "; }
#toc[summary="Contents"]::before { content: ""; content: none; content: inhibit; }
No user agent that supports double‐colon notation for pseudo‐elements does not support attribute selectors, according to the Wikipedia CSS support page, so it should work fine.
Should one be inclined to raise objections, speak now, lest for ever hold thy peace! — Nicholas 01:10, 30 January 2006 (UTC)[reply]
I'm sure you know what you're talking about. -- Ec5618 01:19, 30 January 2006 (UTC)[reply]
well, yes. Which bit would you like explaining? – Nicholas 02:10, 30 January 2006 (UTC)[reply]
But why do you have to beat the browser over its head with different forms of content until it reacts? --cesarb 01:46, 30 January 2006 (UTC)[reply]
Well 'inhibit' would probably be the most correct, and if that isn't supported, it falls back to none, and then back to an empty string. No particular reason other than that. – Nicholas 02:10, 30 January 2006 (UTC)[reply]
"toccolours" is not the only replacement for "toc"; and "toc" is often appropriate, like on Template:CategoryTOC. Among other uses, toc is used often where the infobox, messagebox, and wikitable CSS classes should probably be used. I'd really prefer someone with a database dump to run a query to find which pages use id="toc" so that they can be edited without this sort of message appearing. I don't support the change. -- Netoholic@ 08:54, 30 January 2006 (UTC)[reply]
Any replacement contents boxes should have a summary attribute too, so they would not show the message (see my user page for just such an example). As to whether 'toccolours' is the right class, well that's context dependant, and I wanted to keep the message short. Of course it would be better to make all these changes via a database dump, but that option is not available to me, and this will help coerce and educate page maintainers into fixing pages they watch over. The desired goal is valid XHTML. Perhaps, Netaholic, you would be happier with this alternative from my own monobook.css:
It makes the ToC an aesthetically appeasing green colour and also makes incorrect usages of id="toc" stand out like a sore thumb, whilst avoiding any messages (but not educating people either). — Nicholas 13:19, 30 January 2006 (UTC)[reply]
Wierd errors
I am seeing some wierd errors on wikipedia at the moment. My sandbox at User:Martyman/Sandbox2 is showing two copies of the latest version of my page at User:Martyman/Sandbox3, but is not showing any edits since 17th december. Does anyone know what is possibly going on? --Martyman-(talk) 01:15, 30 January 2006 (UTC)[reply]
OK, don't mind me, I had include the other page as a test earlier. Strange the content I thought was there has gone though.. Oh well.. --Martyman-(talk) 01:19, 30 January 2006 (UTC)[reply]
Edits going missing is not something we can ignore. Is this still a problem? Rob Church (talk) 08:01, 1 February 2006 (UTC)[reply]
Another small step towards MathML support in MediaWiki
Will this allow us to enter equations directly in MathML, or do we still have to work with the LateX code?
HTH HAND —Phil | Talk 10:03, 30 January 2006 (UTC)[reply]
Focus
When creating a new article the focus automatically switches into the edit box, whereas it doesn't when editing an existing article. This auto focus switch is new and somewhat irritating, as it also brings that browser window to focus if you're looking at another window. I'm not sure when this change was made, or indeed which bit of code was changed. Any chance of it being removed or do people like it?
Also, if you make your edit before the page loads and are typing in the summary box when it does finish loading, you get switched to the main edit box and end up typing your summary in there. I think this feature should be left to individual users to install and deleted from the site-wide monobook.js. The best solution would be to have a shortcut key which focuses the edit box in my opinion. Lupin|talk|popups 13:03, 30 January 2006 (UTC)[reply]
Very irritating and inconsistent. I already know how to operate my computer, please don't try to do it for me. I'm going to hunt this down and kill it, slowly. —MichaelZ. 2006-01-30 17:57 Z
That field already has an accesskey assigned: control-comma works in my browser. —MichaelZ. 2006-01-30 18:00 Z
I removed it. Purge your cache (shift-reload), or load the style sheet in your browser window and refresh. —MichaelZ. 2006-01-30 18:03 Z
I'm pointing readers to wikipedia articles from my webpage, and the wikipedia page won't let the browser go back to my page... how do I fix this? (I'm using MS Word to write the page.)
Please email me if possible to fix. Thanks.
Removed email. Reposting this to the Help Desk. -- Ec5618 16:18, 30 January 2006 (UTC)[reply]
History Page Problem
I keep finding a problem that something that was not changed is marked as changed, when comparing different user edits, for an example see the Zero Hour history page. --The1exile 17:18, 30 January 2006 (UTC)[reply]
Are you sure it was not changed? Looking, for instance, at the link you provided, we can see that the first revision has a non-breaking space (800 MHz, 1.8 GHz) and the second one doesn't (800 MHz, 1.8 GHz). It's very hard to see, since it's the actual non-breaking space character that was used, instead of its character entity. In that case, some browsers change them to spaces when the article is edited (it's a known bug), which explains the change. --cesarb 18:15, 30 January 2006 (UTC)[reply]
Strange email message
The Wikipedia Help Desk mailing list (at helpdesk-l@wikimedia.org) received this very strange message:
"Dear user helpdesk-l@wikimedia.org, administration of wikimedia.org would like to inform you
Your account has been used to send a large amount of unsolicited
commercial e-mail during the recent week. Most likely your computer was infected and now contains a hidden proxy
server.
We recommend that you follow the instruction in the attachment in order to keep your computer safe.
Virtually yours,
The wikimedia.org team."
It also contained a zipped attachment, which I did not even attempt to open.
In a word. Yes. Anything to get you to run the presumably virus laden attachment. Dragons flight 22:28, 30 January 2006 (UTC)[reply]
Yup. This is a classic and rather transparent trick to get you to open the attachment. It works a lot better for ISP e-mail addresses, where the last part reads for example "The aol.com team". I get these at a domain I own, and I'm very entertained to discover that my domain's "team" (which doesn't exist) is sending me security bulletins. Deco 00:47, 31 January 2006 (UTC)[reply]
Thanks. I thought it was suspicious, we get lots of emails contianing viruses on the list, though this is the first one that looks likes it was specifically targeted TO the list. User:Zoe|(talk) 19:13, 1 February 2006 (UTC)[reply]
Tracking Anonymous Users
I find it very annoying that there is no easy way to communicate with anonymous users of shared IP addresses. I was thinking about a method involving with session cookies. This would make it possible to make sure that comments and warnings go out to the correct user of a shared IP address and possibly even make it possible to selectively ban users of shared ip addresses (not perfectly as they could always remove the identification cookies). Has this been suggested before, and would there be any major technical issues with it's implementation? --Martyman-(talk) 22:32, 30 January 2006 (UTC)[reply]
I was just shown a very strange thing on the Dingbat page. If you view the page as a logged-in user, everything looks fine and dandy. However, if you are logged out, the top of the page has a big yellow box that says:
"This image is not an orphan—see Autofellatio
This image is needed as it is either linked from a text link or is otherwise useful, even though it appears to have nothing linking to it.
Please do not delete this image without verifying that it is really not needed."
Followed by:
"We want it noted that the image is provided by Hornyboy.com and copyrighted by RudeBox Media, Inc., but it can be used freely with this mention."
...and a copyright notice, etc. This only appears if you are logged-out when you view the page. We were able to view it from multiple browsers, networks, and OSes. So. What is happening here? I don't see it in the history, but I didn't look too deeply there. -- ManekiNeko | Talk 23:28, 30 January 2006 (UTC)[reply]
I don't see such a notice. You say another editor is experiencing the same thing, on a different computer and account? Or does the issue occur on a single computer only? -- Ec5618 23:40, 30 January 2006 (UTC)[reply]
Four different computers, three different people. The other two don't have accounts (or weren't logged in, at any case), and were asking me why this appeared on the page; I didn't see the box until I logged out myself. When I logged back in, it went away again. The systems this showed up on were: two different Mac OS X computers on separate networks (running both Safari and Firefox), and two different Linux boxes on separate networks running Firefox. We were all communicating via chat and our computers aren't connected in any way to each other's. You don't see this when you log out? Very odd. --ManekiNeko | Talk 00:09, 31 January 2006 (UTC)[reply]
Follow-up: just retried it in Mac OS X Firefox and it seems to be gone -- an edit by User:Sean_Black (9 minutes before your post) seems to have fixed it, though for the life of me, I can't figure out why. :) -- ManekiNeko | Talk 00:18, 31 January 2006 (UTC)[reply]
About two weeks ago, when I viewed Main Page while logged out, it was displaying a version of the main page from 2002. Purging the page cache fixed the problem. JYolkowski // talk 03:19, 31 January 2006 (UTC)[reply]
Do you mean the browser cache? Because we all did that and it didn't work. (Also, I had never visited the Dingbat page before, logged in or not, so it couldn't have been in my cache.) Anyway, this particular one is fixed, but I'm sure curious to know what happened. -- ManekiNeko | Talk 03:41, 31 January 2006 (UTC)[reply]
No, it's the page cache, the one you purge by using action=purge (get the edit link for the page and change action=edit into action=purge). --cesarb 03:53, 31 January 2006 (UTC)[reply]
Ah, I did not know about that. :) Under which circumstances do you normally need to do that? -- ManekiNeko | Talk 05:54, 31 January 2006 (UTC)[reply]
When the software gets confused. It's done automatically when needed (for instance, when the page is edited); however, if it fails, you get stale data on the cache, with sometimes strange results. This means you never normally need to do that; when you need to use it, it's because of a bug or other problem with the Wikipedia system. --cesarb 15:04, 31 January 2006 (UTC)[reply]
Wow, ok. Thanks for the info. :) -- ManekiNeko | Talk 06:22, 1 February 2006 (UTC)[reply]
Password security
I've disabled the ability to use blank passwords. Accounts which had blank passwords will have to reset them by e-mail on the login form. [4] --Brion 23:54, 30 January 2006 (UTC)[reply]
Search glitch?
I'm not sure if this is the right category, but it seems it is some kind of technical problem, so here goes...
I am trying to figure out the size of an article I spend a lot of time editing. I want to keep an eye on the size so I can know in advance when the article might be getting too long and need to be divided up. When i search for it, though, it does not show up in the search results no matter what combination of kewords I use, or even if I use the exact title. However, if I type the title and click "go", it does go to the article just fine! The article name is Dextro-Transposition of the great arteries (actual capitalization: dextro-Transposition of the great arteries), I have searched using "transposition", "dextro", "Dextro-Transposition", "arteries transposition", "d-TGA", and many more. Yet nothing yeilds the proper article in the results! I even tried copying and pasting the article contents to a subpage of my user page and searching for that, but it still doesn't work. I'd like to find out if this is an issue on my end, and if so, how I can fix it; or if it may be an issue with the search function, and hopefully it can be looked at. In the meantime, it would be great if someone could find out the size of the article for me...thanks in advance. bcatt 03:12, 31 January 2006 (UTC)[reply]
The search index is a couple months out of date for the moment. --Brion 03:36, 31 January 2006 (UTC)[reply]
Image Licensing Drop-Down Change Request
Hi all. Currently the Image Upload Licensing drop-down has a "Movie or TV screenshot" selection that tags an image with {{film-screenshot}}. This needs to be split up into two different selections: "Movie screenshot" which corresponds to {{film-screenshot}}, and "TV screenshot" which corresponds to {{tv-screenshot}}. Thanks! ~MDD4696 03:37, 31 January 2006 (UTC)[reply]
How do I make the h1-level heading on my user pages disappear (as someone did on a Main Page draft)? - ElAmericano | talk 04:30, 31 January 2006 (UTC)[reply]
You don't. --Brion 04:43, 31 January 2006 (UTC)[reply]
@!#?@!
I'm having a problem creating a page with the title @!#?@!. (This would be a redirect to Q*bert.) Whenever I try, it truncates to @!. Any idea why this is happening? Crotalus horridus (TALK • CONTRIBS) 05:40, 31 January 2006 (UTC)[reply]
Ah, that makes sense. So it's the presence of the HTML anchor that makes it impossible. Too bad. Crotalus horridus (TALK • CONTRIBS) 06:10, 31 January 2006 (UTC)[reply]
Icons on the Help page need help
I've been working on the help page and I've run into a slight problem that I don't know how to fix...
In Internet Explorer, the icons on the help page show up with white backgrounds. In Firefox, the background for the icons is transparent, and so matches the surrounding background (light purple) - like they're supposed to.
Does anyone know how to fix this so that the icons appear correctly in Internet Explorer?
Has there ever been discussion on fixing the Internet Explorer alpha transparency problem? This 18 line javascript fixes the problem and is very widely used across the internet. (See google results for: AlphaImageLoader Filter). You can very easily put it into your monobook.js as well, to test it use Internet Explorer and login w/:
There has been. It triggers ActiveX warnings on various versions of IE depending on security settings, and sometimes crashes. (Note that IE7 renders alpha-transparent PNGs just fine. If MS ever gets around to releasing it to the public... ;) --Brion 06:16, 31 January 2006 (UTC)[reply]
Where are they? I'm trying to see what has been done, maybe I can help hammer out some of the problems. Even *when* MS releases IE7, we still have ~80% of our readership using IE5.5/IE6 User:Αchille
In the wiki and mailing list archives from a couple years ago. --Brion 06:33, 31 January 2006 (UTC)[reply]
Hmm. Our software converts SVGs into PNG format before rendering. And PNGs don't work on IE (except the unreleased beta) if they use alpha transparency, but do work if they have binary transparency. Is it possible to alter the SVG renderer on the server side so that it uses binary transparency to render empty (100% transparent) areas of SVGs when they are converted to PNG format? I think this would fix most of the problems and without requiring any client side hacks. Crotalus horridus (TALK • CONTRIBS) 06:26, 31 January 2006 (UTC)[reply]
Alpha-transparent PNGs work on IE. They just have a solid white background, which 99% of the time is fine. --Brion 06:33, 31 January 2006 (UTC)[reply]
On mine, they had a light bluish color replacing the transparent regions, which made them stick out like a sore thumb on almost any background. I wonder why the discrepancy? Crotalus horridus (TALK • CONTRIBS) 06:35, 31 January 2006 (UTC)[reply]
File:IE-transparency.png...have a solid white background...Not true it depends - Here is a sample screenshot of an article rendered by the Trident IV engine. On TridentV/Gecko the LexisNexis logo looks fine. User:Αchille
IE7 fixes alpha transparency of PNGs. IE7 is included with Vista. All new computers come with the latest Windows, and average PC turnover time is 2 years. Hence, this problem will go away. Deco 07:33, 31 January 2006 (UTC)[reply]
Unfortunately, it won't. Microsoft has claimed that they will only make IE7 available for Windows XP SP2 and above. There are still tons of users running Win98 and WinME, and furthermore, many of them cannot upgrade to XP because their antiquated boxen simply couldn't handle its bloat. Trust me on this - I've worked phone tech support. Unless MS relents on this front, we will, unfortunately, be stuck with broken implementations of PNG for the better part of a decade to come :( Crotalus horridus (TALK • CONTRIBS) 07:36, 31 January 2006 (UTC)[reply]
I find the highly dismissive responses very troubling. What do you mean by "in 2 years, hence problem will go away"? In two years there will be more technogies emerging that the TridentV engine will not handle. This can be fixed now with minimal repercussions. User:Αchille
You're misinterpreting me. I didn't say the problem will go away in 2 years. I meant that because computers turn over quickly, the problem will go away within say 5 years for a large percentage (maybe 70-80%) of our users. In the meantime, I don't think we should be using nasty exploits that aren't guaranteed to work with new versions of software. It'd be nice to fix this, but it's not our problem to fix and the images are still usable, if sometimes ugly. Deco 18:06, 31 January 2006 (UTC)[reply]
nasty exploits that aren't guaranteed to work with new versions of software. Can you vouch for the truthfulness and the accuracy of that statement? User:Αchille
Nope. I'm just taking the word of Brion above, who probably knows more about web dev than me as a Mediawiki developer. Deco 18:53, 31 January 2006 (UTC)[reply]
To summarize again: we tried it a year or two ago, there were many complaints, we turned it off. --Brion 20:06, 31 January 2006 (UTC)[reply]
How to import census data into the Wikipedia
Hi there. I am trying to massage some census data (ooh, baby) so that we can import it via robot into the Esperanto wikipedia. A resource page at the gazeteer has a database of cities & towns with a county FIPS number. And there's a separate database with counties having a county FIPS number, but the two numbers do not seem to match up. I was hoping for the classic one-to-many relationship (one county has many cities/towns), but it doesn't seem to work.
Maybe this sort of census information can be found somewhere else. Would anyone know how I can match up a city to its county? -- Yekrats 18:13, 31 January 2006 (UTC)[reply]
Talk to User:Ram-Man. He wrote the User:Rambot which imported all of the US census data into the English Wikipedia, and linked cities to counties with it. User:Zoe|(talk) 19:17, 1 February 2006 (UTC)[reply]
And if we had a user with equals signs and spaces in their name, you'd have to write something like {{vandal|1=-= =DARK= =-|2=-=_=DARK=_=-}}. Eww. Are there any legitimate users with equals signs in their name, anyway? Should they just be disallowed? Doesn't seem like a common character to use in "real" names. —Ilmari Karonen (talk) 16:52, 1 February 2006 (UTC)[reply]
Another solution is to use the nowiki tag for the argument only: {{vandal|<nowiki>-=-=DARK=-=-</nowiki>}} produces [nil -=-=DARK=-=-]([[User talk:-=-=DARK=-=-|talk]] · [[Special:Contribs/-=-=DARK=-=-|contribs]] · [[Special:DeletedContributions/-=-=DARK=-=-|deleted contribs]] · [[Special:Nuke/-=-=DARK=-=-|nuke contribs]] · [[Special:Log/-=-=DARK=-=-|logs]] ·filter log· [[Special:Block/-=-=DARK=-=-|block user]] ·block log). - Liberatore(T) 19:55, 1 February 2006 (UTC)[reply]
Searching for articles
I have read Wikipedia:Searching and as far as I can see, there is no way to search article names rather than body text. Am I right? I would like to be able to search for (say) article titles +January +2005 -sports and to not get a list of several thousand pages which link to or reference the words. Is it possible? -- SGBailey 16:39, 1 February 2006 (UTC)[reply]
You could use google (or your search engine of choice) searching for "site:wikipedia.org" or "site:en.wikipedia.org" and your search terms. Your example comes out like this, for example.--Cherryblossomtree 17:58, 1 February 2006 (UTC)[reply]
I don't think this answers the question. The person wants to search only titles, not bodies. This is possible with a database query, but besides that I don't think so. Deco 19:47, 1 February 2006 (UTC)[reply]
Argh, sorry. I misread. I thought the request was specifically to search bodies. Oops.--Cherryblossomtree 19:49, 1 February 2006 (UTC)[reply]
Actually you can, though it may not be totally reliable: [5] I'm afraid your search won't likely work, though, as the indexer seems to discard numbers. --Brion 20:23, 1 February 2006 (UTC)[reply]
Internet Explorer 7 / Wikipedia Logo
I just recently installed IE7 and the Wikipedia/Wikinews/Wiki* logo does not appear. I have not yet tested it on other machines. Can someone else verify on this? User:Αchille
This is correct. In fact, this occurs on all sites using the latest Mediawiki software. I have reported this to the IE team for investigation. Deco 19:45, 1 February 2006 (UTC)[reply]
I'll check it out. Haven't had any luck getting the last Vista beta up and running, so XP it is... :P --Brion 20:15, 1 February 2006 (UTC)[reply]
Ok, got public beta installed on XP. Confirmed that the classic alpha hack no longer works (it did on beta 1); I've changed the conditional includes so that it skips the IE workarounds JavaScript for IE 7 and later; the logo now displays properly, though I haven't checked out every feature to confirm proper functioning. --Brion 21:29, 1 February 2006 (UTC)[reply]
I also had this problem and without changing anything, the logo has now started appearing again. hmm --Colonel Cow 21:42, 1 February 2006 (UTC)[reply]
You don't have to change anything, I changed the software. :) --Brion 21:44, 1 February 2006 (UTC)[reply]
ah, ok, that explains it :) --Colonel Cow 21:48, 1 February 2006 (UTC)[reply]
For anyone interested here's a diff of the change. Thanks Brion, that was quick! User:Αchille
Tiny little problem: Is there a better way to do this? My goal is to have a non-breaking space in the link Leopold I (looks a bit strange if it wraps the line before the "I"). I have seen this occurs quite often (another example is World War I). --Adrian Buehlmann 22:15, 1 February 2006 (UTC)[reply]
There's a different one: {{nobr|[[Leopold I]]}}. Whether it's better or not is another question. --cesarb 22:21, 1 February 2006 (UTC)[reply]
.jpg)
