The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at BugZilla since there is no guarantee developers will read this page.
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.
The search index is often out of date, sometimes taking weeks before it's updated. Because of that, recent changes are not immediately reflected on the search.
If all the links in the articles suddenly become underlined (or the opposite), or red links instead end with a red question mark (or the opposite), or paragraphs are fully justified instead of left justified (or the opposite), it's probably because your browser failed to load one of the stylesheets (or the server sent you a wrong one). Do a forced reload or bypass your cache.
If you changed to another skin and cannot change back, use this link.
It has been reported that the Google Toolbar extension for the Firefox browser is the source of some strange problems (including blanking part of a page when editing it). If you have that extension, try turning it off or upgrading to a newer version. See bugzilla:5643 for more information.
If an image thumbnail is not showing, try purging its image description page (if the image is from Wikimedia Commons, you might have to purge there too). If it doesn't work, try again.
Some adblockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear. Also, it's surprisingly common for people to accidentally block the image server (upload.wikimedia.org) on Firefox.
If you are asked to download a file (index.php) when trying to edit, or your browser launches an image editor when trying to edit, disable "Use external editor" on your preferences.
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.
MARKUP CRISIS: NEW http://wikipedia.org/ INTIAL PAGE MISSING SEARCH BUTTON IN SOME BROWSERS
The initial http://wikipedia.org/ page (puzzle globe) as viewed in Netscape 7 and Safari 1 now lacks a submit button next to the search field and language pulldown.
There is also a spacing problemm with the logos (Wiktionary, etc.) at the bottom of the page.
It is a true scandal in Wikidom that this most prominent of pages could go live without excruciatingly thoroughQA testing!
Pix may be blocked - will recheck. Recent problem. I have RH9, Mozilla.
Math symbols in text, sometimes in LaTex etc often are distorted into what looks like random hashmarks or bird scratch. Many formulae can't be read because symbols in Greek, or special math symbols (like Intercept symbol, logical Not-, etc) are dropped. - I can read generic PDFs with same symbols etc.
wikipedia and wiki quote....
Is wiki pedia and wiki quote are the Same ...??
I just want to put my website link to wiki Quote...
How can I do that....
As far as I know, once images are deleted, they're gone. You may be able to still view them if Google or some other search engine has cached the pages on which they appeared, although it most likely won't be the original, full-resolution version. The only option left would be to re-upload the image, having determined why it was deleted in the first place by searching the Deletion Log. If the image is inappropriate or violates a copyright, it will simply get deleted again by an administrator. —QuicksilverT@17:29, 15 September 2006 (UTC)[reply]
See DefaultSettings.php for all configurable options; the relevant bit is:
/**
* By default deleted files are simply discarded; to save them and
* make it possible to undelete images, create a directory which
* is writable to the web server but is not exposed to the internet.
*
* Set $wgSaveDeletedFiles to true and set up the save path in
* $wgFileStore['deleted']['directory'].
*/
$wgSaveDeletedFiles = false;
Does anyone know what's up with Arata Kochi? The page gives the boilerplate page-does-not-exist message, but the "article" tab-link is blue, and if you go to edit the page, you see the article's current text. You can also go into the page history and find the current version — revision as of 01:01, 15 August 2006.
Thanks. I still think it's a bug, though; the article hadn't been edited for over a month, and no purging should have been necessary. Further, as I noted, the "article" tab-link was blue; that is, the software "knew" (so to speak) that the page existed, and still displayed the boilerplate page-does-not-exist message. Ruakh15:36, 17 September 2006 (UTC)[reply]
The reason why purging is not a bug is that MediaWiki is lazy: if it can retrieved a cached version of the page, it will. That means that templates aren't automatically updated on other pages unless you manually purge it. — Edward Z. Yang(Talk)19:54, 17 September 2006 (UTC)[reply]
Templates are automatically updated on pages that use them, however this sometimes takes a while (particularly if there are tens of thousands of such pages to touch). --Brion07:53, 18 September 2006 (UTC)[reply]
I've entered this as bugzilla:7401. There's clearly a problem of some sort causing existing pages to look like they don't exist. If anyone runs into another instance of this, please don't purge the page but report it (add it to the bugzilla report would be best) so the devs have an example to look at. -- Rick Block (talk) 17:39, 24 September 2006 (UTC)[reply]
Wikipedia very slow
Hi, I'd like to know if anybody is having the same problem as I: Wikipedia is taking ages to load. This has been happening only recently, and I think it is either my Internet connection, or a sudden rise in popularity of Wikipedia, so that there are too many Users using it at the same time. For example, the main page took me exactly 68 seconds to load, the others seem almost as long. | AndonicO00:15, 19 September 2006 (UTC)[reply]
This has been happening on at least 3 other wikiprojects (wikibooks, wikiversity, and now wikicommons) over the past few days too. Anyone know what's going on? --SB_Johnny|talk|books00:38, 19 September 2006 (UTC)[reply]
Same here, what I do is just open up a lot of tabs on FireFox, and then go away from the computer and come back a minute later and most are open. —Mets501 (talk)01:09, 19 September 2006 (UTC)[reply]
Hi! I'm wondering if anybody has a free! program to create those nice population charts. I mean where you have the ages 0-100(?) in the middle (y-axis) and the data as bars from the middle to the left or right (girls in red, left; boys in blue, right). I couldn't figure out how to do that in Excel. Maybe that works too? Thanks! --Hedwig in Washington(TALK)02:20, 19 September 2006 (UTC)[reply]
Lately I have been experiencing huge (i.e. on the order of tens of minutes) delays when it comes to viewing and editing pages. The lag stays around for ten or so minutes, goes away and comes back again later. Traceroute tells me nothing - packet loss at the Wikimedia servers is sometimes 75%, 50%, 10% or zero yet it still lags. There is often no other activity from my LAN. My RC patrol program still downloads from the IRC feed at browne.wikimedia.org without a problem. In fact, the IRC feed indicates business as usual. Other sites load without hassle. It seems to be consistantly happening at 13:00 utc, but today was happening as early as 08:00 utc. I am running Firefox 1.5.0.4 on Linux 2.6.13. I live in Perth, Western Australia. Could you please explain? MER-C13:28, 19 September 2006 (UTC)[reply]
I don't know what's happening either, but it happens to me on Internet Explorer on a public IP too (and from a different country than Australia); it happened yesterday in the early afternoon UTC, probably about the same time you had. So I don't think its your browser, IP, or local Internet conditions. --ais523 13:55, 19 September 2006 (UTC)
[9:48am CST] brion has changed the topic to: PLEASE DON'T COMPLAIN ABOUT WIKI BEING SLOW. Peak hours are coming up, and ongoing network maintenance means SOME people may see things slower than others.
On #wikimedia-tech just now, a user consulted with a Wikimedia server tech over the problem of latency and timeouts to en.wikipedia.org and upload.wikipedia.org. The problem was found to be a cached dns in the user's firewall (Agnitum Outpost) pointing to the outdated IP addresses. If you are experiencing connection problems, it may help to traceroute or dnslookup the wikimedia servers you frequent. If you get an IP somewhere in the 207.142.131.192/26 block, your ISP, firewall, or router may be to blame, as well as a local hosts file. This obviously will not be the only problem with slowdowns, but may be one common recent cause. The tech in question also suggests you replace your "broken" firewall or router ^_^ --Splarka (rant) 09:07, 20 September 2006 (UTC)[reply]
The IP I get is 66.230.200.110. And there's nothing like a bit of latency (as in about a minute) when the vandals show up en-masse. MER-C13:19, 21 September 2006 (UTC)[reply]
Discussion page not properly moved during page move
Not long ago someone moved "Jay Cohen" to "Jay R. Cohen" ("Jay Cohen" and "Jay R. Cohen" are two different people). New article text was posted at "Jay Cohen." However, the discussion page did not get moved correctly. When I click on the "discussion" tab in the "Jay Cohen" article, I am taken to the discussion for "Jay R. Cohen." If I click on the "article" tab next, I am taken to the "Jay R. Cohen" article. How do I fix this? SmartGuy15:46, 19 September 2006 (UTC)[reply]
By default, moving a page redirects its talk if it exists. To fix it, go to Jay Cohen, click the 'discussion' tab, go back on the redirect (using the link in the 'Redirected from' line near the top of the page, and edit that talk page to not be a redirect (for instance, blanking, replacing with {{talkpage}}, or replacing with a comment). --ais523 15:52, 19 September 2006 (UTC)
What you described originally, by the way, seems to be exactly how a discussion page is properly moved. What did you expect to be left in the place of the discussion page when it was moved? Something besides a redirect to the new location? *confused*. --Splarka (rant) 07:01, 20 September 2006 (UTC)[reply]
I expected that nothing would be left in place of the discussion page. In the instance that an article is replaced by a #REDIRECT, then I would expect that the old discussion page would be replaced with a #REDIRECT to the new discussion page. In this case, where the old article was replaced with an entirely different article, I expected that a new, blank discussion page would have been created. SmartGuy20:07, 20 September 2006 (UTC)[reply]
{{deletedpage}} has been vandalised to remove a new feature which would identify the date which the template was added. Could someone who actually understand how these things work please revert the vandalism. — Dunc|☺17:19, 19 September 2006 (UTC)[reply]
(edit conflict) It's not vandalism, it's a wheel war (as editing protected pages is an admin action). It seems multiple administrators are using rollback on each other's edits there (also an admin action). You could always try to calm down the debate on the talk page, or join the wheel war yourself (not recommended); probably the best venue is Template talk:deletedpage. (I know you know that already; still, someone else reading this might not.) --ais523 17:25, 19 September 2006 (UTC)
It seems that there's rollback on both sides (although not from Centrx) on this; the wheel war seems to have stopped for now, so just take it to talk/test it in a personal sandbox to sort it out. --ais523 17:42, 19 September 2006 (UTC)
There was one at the end from Phil after it had been clearly explained to Dunc that his change was based on an erroneous understanding of template transclusion. —Centrx→talk • 18:48, 19 September 2006 (UTC)[reply]
I understand how it works, and it won't work, at least not as well as you think it does, duncharris. To my understanding, the {{CURRENTTIME}}-like magic words may not be perfectly real time, but not what you want. You may be thinking of how Special:Cite works, where in MediaWiki:Cite text those time variables are the time of the last edit of the article, but it only works there! There the time variables are only current if enclosed in <citation> tags. But trying to use them outside the cite text won't do anything besides show the current time/date, esspecially not on a simple template. --Kevin_b_er03:57, 26 September 2006 (UTC)[reply]
At the risk of asking the obvious...
... any though to giving admins the capability to block specific users from specific articles, rather than the coarse mechanisms of page protection and user blocking? Or would this be too much of a headache for the servers, and the current means of "don't touch this page/subject or you'll be blocked" adequate?
I don't know about the technical aspects of it, but if a person is so disruptive to one article that they must be blocked from it, they will probably be similarly disruptive to other articles as well. —Centrx→talk • 01:29, 20 September 2006 (UTC)[reply]
Arbcom has handed out bans like this in the past, without needing the techinical bits to back it up (see, Wikipedia:Requests for arbitration/Admin enforcement requested... if the person ignores the ban, then they're blocked from all articles for some time). A community/admin initiated ban like this was recently given, see Wikipedia:Community probation. The technical bits certainly aren't necessary to do this sort of thing, but they might be useful if the ban is related to a small handful of pages rather than the more usual "all pages related to X" bans. --Interiot05:03, 20 September 2006 (UTC)[reply]
(In reply to EngineerScotty) Good idea. Maybe also per namespace. Another interesting thing would be the exact opposite: Specifically allow user U to edit fully protected page P. Could be useful for high use template pages or stuff in MediaWiki (like MediaWiki:Common.css). Probably not so useful for main space, though. Idea for implementation: a special page per user (User:Ligulem/editaccess ?), editable only by admins, containing something like (example):
ALLOW:
[[MediaWiki:*.css]]
[[template:cite web]]
[[template:cite book]]
[[User:Ligulem]] #See below
DENY:
[[Bicycle helmet]] #user is obsessed with this article, otherwise useful edits <signed by admin XX>
[[User:*]] #per request of the community <signed admin YY>
The ALLOW clause would enable the user to edit the listed pages even if they are fully protected, while the DENY would protect the listed pages against edits by this user even for unprotected pages. Entries in ALLOW should override entries in DENY. --Ligulem08:46, 20 September 2006 (UTC)[reply]
That page is painfully 1,212 kilobytes long, which is very unusual (mildly formulated). So I wouldn't be surprised by hickups - but an outright crash is a bit odd. Seems like a problem with your software/configuration. I do wonder what's the purpose of such monster pages on wikipedia. I left a pointer over there. See if somone of the regulars responds there and splits that monster into pieces (However, discussion looks rather dead. Last post is from end of March...). --Ligulem18:49, 20 September 2006 (UTC)[reply]
Edit links being bumped out of position by a series of right aligned images
I'm not sure why the edit links seem to get shifted out of position by a series of right-aligned images.
Originally the images were zig-zagged left and right throughout the article, but it was messy to look at, especially when printed out, so I aligned them all to the right, but now thesection 'edit' links do not line up with the right sections. Please see RepRap Project.
These templates depend on an external wiki, since the required extension isn't installed locally. That wiki seems to currently be broken. --cesarb22:55, 20 September 2006 (UTC)[reply]
Searching
I created an article entitled "Pinkham Notch". However, the article does not show up when the word "Pinkham" searched. How can this be fixed? --— Preceding unsigned comment added by Sturgeonman (talk • contribs)
When editing a page, the upper layout looks strange, you can see it by editing any page. If you have any comment or the answer, please, tell it to Pasqual (ca), or directly to Klenje (fur), who asked me about it, but my knowledges don't reach it.
Usually this means there's a missing close tag (</div> or similar) in one of the user interface messages. In particular check fur:MediaWiki:Edittools, but some of the others on the edit page might be the problem. --Brion10:36, 21 September 2006 (UTC)[reply]
I remember reading before that the ability to add namespaces in MediaWiki was going to be added. (The ability to add them through the inteface instead of having to edit localsetting.php). I can't see this option anywhere in version 1.7. What is the status of this option? 83.71.86.17711:45, 21 September 2006 (UTC)[reply]
The namespace manager was not merged into the development branch prior to the release of MediaWiki 1.7. Check the mailing list archives for wikitech-l for recentish discussion about it, or if there is none, ask on the same list. 164.11.204.5222:27, 24 September 2006 (UTC)[reply]
Adding "nofollow" to links?
Any though to adding a means whereby a URL can be encoded (other than <nowiki>) such that its "nofollow" setting will be false? Or more controversially--making all outbound links nofollow--reducing Wikipedia's value as a target for spammers and search engine optimiziers?
A discussion on the village pump policy page concerning extremist websites cited as sources (someone proposed enclosing them in nowiki so that Wikipedia doesn't boost their page count) prompted the question.
nofollow on all outgoing links was enabled briefly and met with huge opposition, if we are saying our links are not good enough for robots aren't we saying that they are not good enough for humans as well (in which case why would we be including them at all). Plugwash18:40, 21 September 2006 (UTC)[reply]
if we are saying our links are not good enough for robots aren't we saying that they are not good enough for humans No, not at all, robots have a rather different interest in our links than humans do. Martin19:07, 21 September 2006 (UTC)[reply]
nofollow is automatically applied to all external links not appearing in the main article namespace. It is assumed that articles are watched with sufficient care that link spam gets cleaned up. Dragons flight19:26, 21 September 2006 (UTC)[reply]
I would like to see <meta name="robots" content="noindex,nofollow" /> on all talk pages. Google doesn't seem to make much of a difference between namespace main and main talk. If you do have a page somewhere on the web with your name on it, you'd better not sign with that name on talk pages. Wikipedia beats everything else, even if it's only on a talk pages. --Ligulem19:37, 21 September 2006 (UTC)[reply]
Nofollow is already on talk and wikipedia and maybe a few other namespaces. This wasn't the case earlier this year, but it's now in place. Noindex has been discussed before (especially with respect to AFD discussions for BLP), but has been decided against so far. Personally, I want to be able to search talk pages with Google. --Interiot20:08, 21 September 2006 (UTC)[reply]
I just checked the main_talk, Wikipedia, and Wikipedia_talk; none of them has noindex tags anywhere. —Jared HuntSeptember 22, 2006, 06:43 (UTC)
Why not images/media/template for deletion? Anyway, if that's the case, all the redirects to AfD should be in the robots.txt as well, since search engines usually can't determine that it was a redirect (because URL is kept in Wikipedia redirects). —Jared HuntSeptember 22, 2006, 11:25 (UTC)
Because AfD discussions that go overboard can sometimes turn into commentaries on how a specific person or organization is inadequate, and those people/organizations don't like to see those pages show up in Google search results. IFD/TFD don't tend to do that. --Interiot15:24, 22 September 2006 (UTC)[reply]
True, but wouldn't you agree about adding the redirects to the robots.txt too? Read the above for explanation why. —Jared HuntSeptember 23, 2006, 06:58 (UTC)
Most redirects are from the old name at VfD, and as such are already there; I don't think there are many redirects to VfD/AfD subpages from outside VfD/AfD. Do you have any examples of such problematic redirects? --cesarb13:57, 23 September 2006 (UTC)[reply]
I've made a Panorama template for displaying panoramas in articles and elsewhere on Wikipedia. Example use:
New (thumbnail-like):
Panorama (new thumbnail version) of Dörflingen
Simple:
Panorama simple
I haven't tested it on many platforms (just firefox on several OSes), but it's based on code found elsewhere on Wikipedia (with additional documentation and liberal use of #expr maths tags to make it easier to use) so I think it should generally work. Any feedback/testing appreciated; or I'd like anyone familiar with templates and div tags to check it over and make any changes or give any needed polish. —Pengotalk · contribs11:32, 22 September 2006 (UTC) (my current RfA)[reply]
Works fine in IE too. I'd suggest removing the hardcoded 'title' on the div altogether; as it's hardcoded and in German it isn't really helpful, and as it doesn't show up anywhere it's pointless making it a parameter. --ais523 11:38, 22 September 2006 (UTC)
Brilliant work! One note is that in the example on Panorama, when the image doesn't take up 100% of the screen width (eg. that one is only 950px wide... a 1280/1600/1920 wide browser will have some whitespace to the side), in Firefox, the image is left-justified (which looks out of place next to the other center-justified images on that page), and the line-box extends all the way to the right (encompassing a lot of whitespace, rather than just the image). The outer div should probably have an explicit width set, and have "margin:0 auto" whenever center justification is appropriate. --Interiot15:15, 22 September 2006 (UTC)[reply]
Ok I've revamped it to take into account Interiot's suggestions. It's a bit more hackish now, so it might need another round of checking :) Please let me know if there's probs on your browser. I've given the vert a tiny bit more room so hopefully the vertical scrollbar issue is resolved (What browser/platform does that happen on?)
It'd be good if I could have it include a caption like an ordinary thumb image too, but I might leave that for another time. —Pengotalk · contribs11:36, 23 September 2006 (UTC)[reply]
Many times I end up mispelling a certain country's name, or a scientific term. Instead of getting a screen with commonly mispelled words that might associate with what I was talking about, I simply get a, "Sorry, this article does not exist."
Wikipedia should implement a "Did you mean..." service, similar to that of Google.
Just a suggestion.
And hopefully this is the right place to be putting suggestion.
First, please type ~~~~ after comments you make on discussion pages, to insert your signature. I believe that much more advanced search functions exist on MediaWiki than are currently available on Wikipedia, but the search function is deliberately kept simple for sever load reasons. One possible workaround is to use a Google search instead (you can type site:en.wikipedia.org in the search box to limit the search to Wikipedia). --ais523 16:19, 22 September 2006 (UTC)
More specifically, use google with site:en.wikipedia.org as one of the terms. If you get no hits, remove the site:, and Google will give you a "did you mean?". Click on the term you meant, and add site: back to the search term, and you should get the Wikipedia hits you're looking for. Granted, that's kind of involved, but it gets reasonably high quality results, and gets them now. (as an aside... why doesn't Google give you a "did you mean?" when you use site:? sure, maybe it's doing a site-specific did-you-mean, but if that gets no hits, it should fall back to the generic data set) --Interiot16:22, 22 September 2006 (UTC)[reply]
Google does "did you mean?" for me... actually... that's because i do a site search in a different way. This is my browser home page: google (you might want to scrap the .au). Though I agree with the original poster, that Wikipedia's own search feature could be much improved, but I guess that'd take someone to do some work on it. —Pengotalk · contribs09:48, 24 September 2006 (UTC) (my RfA)[reply]
You need to add <nowiki></nowiki> tags around the the first 2 ]] so that it doesn't close the link yet. Right now, your code looks like [[User:Mitchazenia|[[Mitchazenia .2]]]]. It should look like [[User:Mitchazenia|[[Mitchazenia .2<nowiki>]]</nowiki>]]. That will display [[Mitchazenia .2]] If that's not how you want it to show, just tell me how you want it to look and I will help you fix it. Hope that helps, Shardsofmetal[Talk • Contribs]20:45, 22 September 2006 (UTC)[reply]
If you wanted your name to be green, you would put <span style="color: green"></span> around your name (or the part you want green). [[User:Mitchazenia|<span style="color: green">[[Mitchazenia .2<nowiki>]]</nowiki></span>]] will show [[Mitchazenia .2]]. However, you should use the hexadecimal code for a color instead of it's name. You can find colors and their hexadecimal values at List of colors. Feel free to ask if you need more help. Shardsofmetal[Talk • Contribs]00:36, 23 September 2006 (UTC)[reply]
I think it's to spread the load amongst the various image servers. I know from experience that no matter which numbers you enter there, the image works. You may get a more detailed or more correct response at WP:VPT. --ais523 14:48, 22 September 2006 (UTC)
Someone seems to have copied my answer from WP:HD, which does not redirect here... It seems that changing the numbers works on svg files but not png files, which is what confused me (I've tried changing the numbers around in svg file URLs and it always seems to work). --ais523 15:37, 23 September 2006 (UTC)
I assume the folders are used to prevent ill effects from folders containing too many files? But how come that sometimes a wrong number still works? Shouldn't you technically speaking receive a 404 in that case? Shinobu02:30, 23 September 2006 (UTC)[reply]
Yes, they are to prevent performance problems which can happen when a directory has too many files. It's a common technique on Unix (it's used by the squid cache, for instance). A wrong number should never work; the file simply isn't there. --cesarb13:47, 23 September 2006 (UTC)[reply]
Well, I recall reading somewhere that, when a thumbnail is not found (404), a script automatically generates the thumbnail. That script probably doesn't care that you are in the wrong directory. In fact, checking just now, the first one has a date of Sep 18, while the second one seems to be dynamically generated. The first one is the one in the correct directory. --cesarb18:07, 24 September 2006 (UTC)[reply]
Hi, I installed mediawiki to my pc.
I want to get enwiki´s LocalSettings.php file.
help!
Who can help me?
I think that english wikipedia or other language wikiproject admins can help me.
I need LocalSettings.php file in wikiproject servers for references. -- WonYong(Talk / Contrib)09:58, 23 September 2006 (UTC)[reply]
You don't want that file, at all, given that it doesn't contain a huge amount of useful information. In fact, it doesn't contain a huge amount, full stop. Nor would the Wikimedia settings initialisation files be of use; the setup here is so incredibly different from most other wikis that you're really better off getting on the mediawiki-l mailing list and asking for help there. 164.11.204.5222:25, 24 September 2006 (UTC)[reply]
Articles truncated during editing
Several times recently I have made a minor edit to some lengthy article, only to notice later that my edit has somehow truncated the article (chopped it at some random point, in mid flow, so that the last part of the article is completely lost). I am fairly certain I didn't do this by accident, but that it's a bug somewhere. I recall seeing a note somewhere that this was a known bug in some browsers, but I can't find it now and I don't recall IE being mentioned (I use IE 6). It's very annoying, and a couple of times has only been spotted by other editors who have fortunately reverted. (Incidentally, to anyone reading: when you revert an edit PLEASE explain why in the edit comment). Does anyone know the status of this bug as far as IE is concerned, and what, if anything, can be done about it? Matt 12:07, 23 September 2006 (UTC).
The Google Toolbar bug involved a particular version of Mozilla Firefox, IIRC, and has already been fixed (it doesn't show up when you download the latest version of Firefox and the Toolbar, so I assume it is fixed). I never heard anything about it involving Internet Explorer. Which articles where you editing? Which browser, OS, etc. do you use? That can help us pinpoint the issue. Titoxd(?!?)07:30, 24 September 2006 (UTC)[reply]
Image:Vacuum polarization.png is the image description page, not the image itself. "What links here" from the description page shows pages linking to the description, not pages including the image. There's a list at the bottom of the description page of pages that include the image (which I assume is generated from the "what links here" database). Other than this list on the image page, I don't know how to get a list of pages including an image (although there is almost certainly some syntax to do this with Special:Whatlinkshere).-- Rick Block (talk) 16:46, 23 September 2006 (UTC)[reply]
Stub category alphabetization of firstname/lastname problems
Category:Japanese artist stubs sorting is screwed up. For example the first entry, Akihiro Yamada should be under Y not A (Yamada is the family name). I went to Akihiro Yamada page and made sure that all the stubs and cats had a |Yamada, Akihiro inside the braces, but it didn't help. Does anyone know how I can fix this? Thank you Zargulon15:35, 23 September 2006 (UTC)[reply]
I've never changed a skin, so I must be using the default, and I'm going through all of the (400 +) FAs without inline citations, and those are so far the only two which don't show the star. Sandy17:12, 23 September 2006 (UTC)[reply]
Then it's no real problem... nobody with any sense uses (bleccch) IE anyway! :-) But, while I was investigating this myself, I attempted validating one of the pages in question, to ensure that it was using valid code in the first place, and found that there's a validation error in the table code for the infobox: it had valign="center" where "center" is not a correct value for "valign"; it should be "middle". *Dan T.*18:33, 23 September 2006 (UTC)[reply]
Spaces around parameter pipes or not--is this standardized?
I recently ran into a problem regarding spaces around parameter pipes. When doing references (footnote format with "ref" tags), spaces around the pipe characters were just fine. However, when I had spaces around the pipe characters for parameters with an image, the parameters no longer functioned. Is this asepct of pipes for parameters standardized or not? If so, what is the MANDATORY standard usage--the one that must be used or things will not work? If it is not standardized, why is it not standardized?Dogface17:34, 23 September 2006 (UTC)[reply]
For template calls, you can do {{<w>template-name<w>|<w>param1<w>=<w>value1<w>}} where <w> represents an arbitrary number of white space chars (including zero). White space chars are spaces, newlines (!), tabs and the like. There is no standard for putting whitespace chars. Use just common sense (if nobody disagrees with your style on an article then that is the standard :) --Ligulem20:24, 23 September 2006 (UTC)[reply]
Activating the mapsource extension on Wikipedia
Kvaleberg.com seems to be downs these days, thus I suggested we activate the extension on Wikipedia. Based on coordinates, the extension leads to a list of links to maps, similar to the ISBN links based on Wikipedia:Book sources (see Wikipedia:WikiProject Geographical coordinates for full details]]). -- User:Docu
I think there may be a problem with links to articles on HighBeam Research (www.highbeam.com). When I attempt to load an article that used to load in the past, my browser (Firefox 1.5.0.7) stops working. Normal operation is restored only by rebooting my computer. I cannot tell if this is just a problem with my equipment and software. I have been able to fix the link in question by linking to a copy on Find Articles (www.findarticles.com), which works fine. Alan Pascoe13:32, 24 September 2006 (UTC)[reply]
Some HighBeam links are OK. As an example of the problem:
I ignore the built-in search; it's difficult, slow, occasionally disabled, and not what I'm accustomed to use -- which is, naturally, Google. I add site:en.wikipedia.org to my search terms and off I go. I have trouble, though, in 2 circumstances:
I often want to search within namespace. Mostly, I want to constrain to projectspace, which has the unfortunate prefix of "Wikipedia:". Well, every page contains this word, so the constraint fails. Can we have some sort of unique namespace tag in every page's HTML META tag?
I often want to search for existing images with Google's Image Search. This generally balls up in 2 ways. First, WP breaks furiously out of Google's frame, which disrupts my process; second, I usually end up on the internal storage page for some thumbnail -- and since I'm out of frame I'm guaranteed not to have a link to anything better. This means much direct editing in the location bar. If we're going to f*ck with Google anyhow, why don't we supply the image description page?
A wikipedia namespace search can be done by adding "wiki/wikipedia" to the google search. I'm not sure what you mean about the image search. -- Rick Block (talk) 19:43, 24 September 2006 (UTC)[reply]
Some of the extra buttons should really not be there, for example, coloured text is generally discouraged, so why have a button to make it easier to insert? Also, there are so many buttons now it is confusing, particularly as many of them are very basic in function. If you ask me, the only useful extra one is the table one (which is very useful). Martin21:01, 24 September 2006 (UTC)[reply]
May I make a suggestion? When I click the "Make Table" button a window opens to set the alignment you type the appropriate word in, may I suggest making this a drop down menu instead? --pjb00711:02, 27 September 2006 (UTC)[reply]
Suggestion for dealing with collateral damage: Flag IPs as shared.
Collateral damage is a major problem affecting many editors, including myself. Allowing anonymous edits causes problems when shared or dynamic IPs are blocked, and autoblocks are also common.
A simple solution would be to prohibit anonymous editing and removing autoblocks. Unfortunately, this is unlikely to be implemented, as admins seem to welcome anonymous vandals, and the consensus is that autoblocks do more good than harm, since the majority of IPs are static (though I believe the majority of users edit from dynamic/shared IPs).
Although the situation has recently improved with the new blocking options, autoblocks are still common, and sometimes admins forget to use the new blocking options when blocking a shared/dynamic IP.
Hence my suggestion: allow bureaucrats to flag and unflag IPs as shared. This is how flagging IPs as shared will help solve the problem of collateral damage:
When an admin attempts to block a shared/dynamic IP, a notice will appear informing the admin that the IP is shared, and the new blocking options will be enabled by default (the admin can disable them if he wishes to). When blocking a static IP, the new blocking options will be disabled by default, but the admin can enable them if he wishes to.
When an admin blocks a registered user, they do not know the registered user's IP, but the MediaWiki software knows. A notice will appear informing the admin that the registered user is editing from a shared/dynamic IP, and the autoblock will be disabled by default. When blocking a registered user editing from a static IP, the autoblock will be enabled by default.
Sounds interesting. As a first step, there should be good guidance for admins. As a newbie admin, can someone point me to the best page where the new blocking options are documented in detail (options "Block anonymous users only" and "Prevent account creation" in restricted page Special:Blockip)? I started at m:Help:Administration#Block_and_unblock and found nothing about these options. Is this underdocumented or am I just a dumb newbie :). These options should also be explained in the guiding text of Special:Blockip (at least there should be a pointer). --Ligulem16:53, 25 September 2006 (UTC)[reply]
It would be nice if the autoblocker would turn off when blocking AOL IPs (this can by done with a simply PHP regexp) and some code, rather than having our few crats have to flag thousands of IPs.Voice-of-All18:09, 25 September 2006 (UTC)[reply]
CIDR's come to mind. 'crats (or whoever) could "flag" whole ranges. This would cover the AOL case. So this would probably end in doing a list of ranges. --Ligulem21:28, 25 September 2006 (UTC)[reply]
I hope someone can help me with this. Whenever I go to Commons, almost always the links to my user page, talk page, preferences page, watchlist, and contributions are moving to the upper left corner if I move the mouse arrow over them. When I go back to en.wikipedia I have the same. Only when I restart IE everything is ok again. Reloading or clearing my cache doesn't help. I don't encounter it with other Wikimedia sites, only when I go to Commons. I use IE 6.0 and both on Commons and here I use the default skin. Garion96(talk)17:54, 25 September 2006 (UTC)[reply]
There is a bug in Internet Explorer which causes this behavior intermittently. Please contact Microsoft for technical support. (Try the IE 7 beta, perhaps it's fixed.) --Brion21:17, 25 September 2006 (UTC)[reply]
True, this could be a browser issue. (Mozilla Firefox 1.5.0.6) Twice today I've accidentally hit "return" in the Edit Summary box and had the page prematurely submitted. If a change was recently made which caused this behaviour (I'd guess that would be making the revision comment a form on its own with a single text variable as its only contents), it should be reverted or adjusted for. True, it's also not impossible that this is a new quirk of mine. But even if this is not a new feature, the user should need to reasonably positive indicate the submission of a form; accidental hitting of "return" (mistyped for the quotation marks beside it, I believe) ideally would not cause form submission. Just something to investigate and think about, and improve if easy. --SportWagon19:09, 25 September 2006 (UTC)[reply]
Hitting "return" in the "Edit Summary" definitely does submit the form--not ideal
I cannot confirm if this is new, nor immediately how browser-specific (possibly option-specific) it is
Yes it should. Type the edit, press tab, type edit summary, hit enter. Done. If enter didn't work on the edit summary box, it would require a lot more tab-presses (or shock horror, moving the mouse). ~iNVERTED | Rob (Talk | Contribs) 19:29, 25 September 2006 (UTC)[reply]
This is the standard behavior of html forms, as far as I know: typing enter on any element that is not a textarea is equivalent to pressing the submit button (or the selected button, if any). I find it quite useful. (Liberatore, 2006). 19:35, 25 September 2006 (UTC)[reply]
Sorry, now I've confirmed what you say at other places I wouldn't expect it. Given the ease with which return can be typed instead of single or double quote, I'm surprised I don't run afoul of it more often. When there are multiple submission choices, it seems defaulting to an invalid choice might be the appropriate thing to do (making sure no contents are lost). But that's debateable, so I hereby remove my complaint/suggestion. I just started hitting return instead of quote today, I guess. Most of the time I don't run afoul of this, here or elsewhere. --SportWagon19:46, 25 September 2006 (UTC)[reply]
1) It's a super time-saver for some people, so it won't be going away. 2) Even though it's a standard browser feature, I think it's possible to override it with some Javascript... [2] individual users should be able to tweak their monobook.js to do what they want. 3) since it's a feature that works on most browsers, and on almost all websites, I don't think we should change the default unless there's a really good reason. --Interiot21:12, 25 September 2006 (UTC)[reply]
This is not only the standard behavior of web forms, it's extremely useful and is how I make every single one of my edits. I'd be extremely annoyed if this were changed, as I suspect would thousands of other Wikipedia users. --Brion21:15, 25 September 2006 (UTC)[reply]
One simple workaround is to learn to use a UK keyboard; in the design I'm using at the moment, double-quote is safely tucked away above the 2 and single-quote is two keys away from Return (with # in between). The main risk here appears to be wikilinks, because ] is right next to Return (luckily, in a way that makes Return harder to hit by mistake). --ais523 07:57, 26 September 2006 (UTC)
Should this section be deleted now? Or perhaps title changed to Return in Edit Summary submits form, with a trivial section indicating "That's not a bug! That's a feature!". In my defence, the references given indicate that the feature becomes less desirable as the form becomes more complex. IMHO, browsers should make it easy for me to turn the feature off. (Problem: then it becomes impossible to submit some pages--not here, but in general). I nearly always preview before submitting, and often change the Edit Summary early in the process to make sure I don't forget.--SportWagon17:27, 26 September 2006 (UTC)[reply]
Just a simple suggestion, but maybe this could be an option in a user's preferences. I agree that this is useful, and should definitely be activated by default, but since there are some users that don't like this, maybe there should be an option to turn it off. I realize that some javascript could turn it off, but a lot of people don't know javascript. Also, even if somebody does write a script, some users know only how to view and edit articles, and would be too confused to edit their monobook.js (or any other skin js) file. A preference option would be easy for them to disable it. This is just a suggestion. I like this behavior, and don't care either way whether this suggestion gets implemented or not. It might be useful though. Shardsofmetal[Talk • Contribs]21:17, 26 September 2006 (UTC)[reply]
A user can adjust his or her Preferences so that when an edit is about to be posted without an edit summary, the user is prompted to first enter a summary. Would selecting that setting address this issue? Newyorkbrad21:20, 26 September 2006 (UTC)[reply]
I doubt it. At this point, they are already in the edit box. It probably still submits the article when you press enter. If it didn't, I'm sure it would be considered a bug. Shardsofmetal[Talk • Contribs]00:42, 27 September 2006 (UTC)[reply]
FWIW, that preference would not have helped me. I had composed a partial summary, and accidentally hit return (Enter) when I meant to hit a quotation mark. I think you could avoid javascript, and have the user profile on the CGI side decide how such a "Submit" is processed (first make sure it is identified differently from each of the three buttons). "Save", "Preview" or "Changes" would be easy to implement, but also desirable might be "Refresh". That last option would be reasonably equivalent to not submitting, except for a slight delay. Of course, at this point, this is a wiki issue, not a wikipedia issue.--SportWagon17:37, 27 September 2006 (UTC)[reply]
My cache administrator is nobody?
I wouldn't have brought this error here and just ignored it, if it wasnt for that claim. So far today, I have recieved the following message when I click the preview now button on Wikipedia 3 times now today.
I've noticed a few mathematical equations have reciently had a tiny little dash after them, for example <math>A + B = 0</math> renders as , with a tiny little dash after the 0. However <math>A+B=0</math> renders as , note no spaces in equation this time. --Salix alba (talk) 08:23, 26 September 2006 (UTC)[reply]
Are you using popups? This happened often to my friend in IE6 when he used popups. If you click the back button right after it happens, that should load the page correctly. My friend switched to Firefox, which fixed the problem. Also, when I went to the page, it displayed correctly, and I also use Firefox. Shardsofmetal[Talk • Contribs]21:30, 26 September 2006 (UTC)[reply]
I don't think I'm using popups - I must admit I didn't understand a thing on the link you gave though. I've tried hitting the back button, the page loads again and displays briefly, and again I get the IE 'Page cannot be displayed' thing. DuncanHill00:13, 27 September 2006 (UTC)[reply]
Image copyright tag
I hit the button too early on Expbolt.jpg, and didn't put in my tag. A few attempts later and I still couldn't put in a tag. I made a new one with a tag, and would like to have this one deleted. Muchos. --Zeizmic16:25, 26 September 2006 (UTC)[reply]
Tagged {{db-authora}}. For future reference, you can request deletion of a mistakenly created page or uploaded file by adding {{db-author}} to it if you are the only contributor. --ais523 16:35, 26 September 2006 (UTC)
Is there a place on WP that announces updates to the software on which WP runs? Was there a recent change that adds more buttons above the edit box? Finell(Talk)18:03, 26 September 2006 (UTC)[reply]
Thanks. I would still appreciate, from someone, knowing where one can go to see recent changes to the software. For example, a software rev in late 2005 clobbered my signature, which used the documented Signature box trick on my User profile page. It took me quite awhile to find out what happened. Thanks again. Finell(Talk)19:27, 26 September 2006 (UTC)[reply]
Go to http://en.wikipedia.org/wiki/List_of_human_spaceflights, click on the "Discussion" tab, and you'll see that you're actually taken to Talk:List of human spaceflights by program, which is the talk page for a different article (and one that the original page does not actually redirect to). Has something got screwed here, or is this by design? If by design then it's very confusing isn't it? How would one go about turning off this redirection?
This is a redirect. You can remove the redirect instruction by editing [4]. Just delete the "#redirect ..." and reclaim that talk page by adding your talk comments as you see fit. Technically, talk pages can be redirected separatley from article pages (although, this is normally not done). --Ligulem23:33, 26 September 2006 (UTC)[reply]
Hi Ligulem, that's great, thanks for your help. Matt 01:01, 27 September 2006 (UTC).
The correct title of this article...
How hard is it to make titles of articles display correctly? In a day or so, I could probably write a javascript to re-format the titles of articles correctly, as specified by the presence of {{lowercase}} or {{bracketed}} or {{wrongtitle}} or whatever templates, and I am quite the amateur programmer. How hard is it to specify the correct title with a special code inside the article and have it displayed correctly by Mediawiki? These templates are embarassing. — Omegatron02:30, 27 September 2006 (UTC)[reply]
There was already a template that used CSS that would fix what you describe, but it was deleted. Short of software modifications, it may be harder than you like to get it to work properly, though I'd love to see a solution that isn't abusable. --Kevin_b_er05:09, 27 September 2006 (UTC)[reply]
Take note taht {{Title}} is now a redirect, but the deletion discussion I linked before. It was some really hacky CSS overlay. Its still around, as user:1ne/Title, and there's issues with it working between anonymous and logged-in users as of not too long ago, so even as a userfication its still buggy. Kevin_b_er07:03, 27 September 2006 (UTC)[reply]
Doing it with CSS is probably inadvisable (I have many of the recent edits to User:1ne/Title, trying to adjust it for various sitenotice changes; now that anons and registered users have different messages, it's impossible to keep it correct for both). However, it would probably be quite possible to change in MediaWiki:monobook.js (the userfication doesn't work in non-Monobook skins anyway); I'll work out the code and post on its talk to see if this is considered a good idea. And yes, it was horribly hacky. --ais523 08:54, 27 September 2006 (UTC)
OK, here's some title-changing JavaScript for monobook.js (works on IE, and should be reasonably portable (I hope)):
//Title override
addOnloadHook(function() {
if(document.getElementById('titleOverride')!=null)
{
var h1s=document.body.getElementsByTagName("h1");
var i;
for(i in h1s)
if(h1s[i].className=="firstHeading")
h1s[i].replaceChild(document.getElementById('titleOverride').firstChild,
h1s[i].firstChild);
}
});
It replaces the original title with the contents of an element with the ID titleOverride (which should presumably be a display:none-hidden <DIV>, or even better a visible <SPAN> within a wrong-title template); see User:ais523/Sandbox as an example. I'd appreciate users checking this on other browsers. --ais523 09:17, 27 September 2006 (UTC)
There is a magic word to fix this in MediaWiki called {{DISPLAYTITLE|}}. It's turned off by default and doesen't work when it is on. The screenshot shows what it looks like when it does work. Gerard Foley16:42, 27 September 2006 (UTC)[reply]
I said it could be done with javascript just as an example of how easy it would be to implement, but I'm saying this because it should be part of Mediawiki. It's a trivial thing to implement that would solve a very old problem that makes our software look bad. — Omegatron17:23, 27 September 2006 (UTC)[reply]
Hi there, guys. We have our own WikiMedia running at work. We need to modify the 'navigation' menu on the left. Is this menu actually a special page written in wiki markup and then parsed into HTML, or is it written differently? How can we edit the menu? —The preceding unsigned comment was added by Zajcev (talk • contribs) 11:36, 27 September 2006.
Hi Zajcev, the sidebar can be a way to customise the links in your MediaWiki installation. But as of the current version, you can only customise the links above the search box using the MediaWiki namespace. --Shinjiman ⇔ ♨14:10, 27 September 2006 (UTC)[reply]
Thank you for your answer. I'm sorry I forgot to sing my post. So if I understand you well, in next version of MediaWiki, we will be able to directly edit MediaWiki:Sidebar? If yes, I see that as a very user-friendly way of doing what I need. So for now, I should modify the menu via namespace, but I have no idea how. Is this what I should read to learn about it? --Zajcev14:30, 27 September 2006 (UTC)[reply]
Other image licences
So far I've stuck to USGS images which are public domain. I have a need for Canadian and provincial gov't images which have a long non-commercial use allowance, with small print. We're non-commercial, but can't guarantee that wiki-copies are good things. Is there a way to use these images? --Zeizmic16:28, 27 September 2006 (UTC)[reply]
![[1]](http://invhost.com/share/Wikiproblem.png){kind=link}
