The technical section of the village pump is used to discuss technical issues about Wikipedia. Bugs and feature requests should be made at the BugZilla since there is no guarantee developers will read this page.
This tends to solve most issues, including improper display of images, user-preferences not loading, and old versions of pages being shown.
No, we will not use JavaScript to set focus on the search box.
This would interfere with usability, accessibility, keyboard navigation and standard forms. See task 3864. There is an accesskey property on it (default to accesskey="f" in English). Logged-in users can enable the "Focus the cursor in the search bar on loading the Main Page" gadget in their preferences.
No, we will not add a spell-checker, or spell-checking bot.
You can use a web browser such as Firefox, which has a spell checker.
If you changed to another skin and cannot change back, use this link.
Alternatively, you can press Tab until the "Save" button is highlighted, and press Enter. Using Mozilla Firefox also seems to solve the problem.
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 before doing anything else. Some ad blockers, proxies, or firewalls block URLs containing /ad/ or ending in common executable suffixes. This can cause some images or articles to not appear.
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.
added question about navframe
<br clear="right"/> and other undocumented features
I saw an article use <br clear="right"/> to force whitespace so that text stays aligned with corresponding embedded images (see User:Ideogram/how to avoid jammed up edit links for an example). I also seem to recall seeing another way of accomplishing this, but I can't find it now. I looked on Meta for documentation of this and other potentially useful tags, but I didn't find this or anything new. Is there a complete listing of all tags MediaWiki accepts? --Ideogram 01:52, 20 March 2007 (UTC)[reply]
A list of allowed HTML is available here, although it doesn't go into the different options for each tag. --MZMcBride 02:18, 20 March 2007 (UTC)[reply]
{{-}} is the other way to do it. GeorgeMoney (talk) 05:13, 20 March 2007 (UTC)[reply]
Or {{clear}}. Or anything with style="clear: both". You can do lots of cool things with the style attribute; read the Cascading Style Sheets specifications for more information. Check also Category:Formatting templates, which has lots of useful templates. --cesarb 00:41, 21 March 2007 (UTC)[reply]
According to my personal notes about wiki editing, I learned about this use of the <br clear="..."> late last year, by following some link from Help:HTML in wikitext:
10/12/2006 1:01AM: I managed to control how much text floats next to
the table, by using the <BR CLEAR=all> tag I read about here:
http://www.htmlhelp.com/reference/html40/tables/table.html
The deprecated ALIGN attribute suggests the horizontal alignment of
the table on visual browsers. Possible values are left, right, and
center. Browsers generally present left- or right-aligned tables as
floating tables, with the content following the TABLE flowing around
it. To prevent content from flowing around the table, use <BR
CLEAR=all> after the end of the TABLE.
tags using "header=1" are screwing up the edit section links
See User talk:Cthorntonjr for an example of what I mean. I used {{subst:nonsensepages|Bud Brothers|header=1}} there, and it leaves behind a section header like this: {{#if:1|=={{{header-text|[[:Bud Brothers]]}}}==}} ... when clicking on the section edit, it won't take you to that section. I suspect Mediawiki doesn't parse the #if statement in a section header properly. This is a problem of all speedy notification tags that I've encountered so far that use the "header=1" parameter, and possibly others besides CSD notifications. — coelacan — 03:29, 2 April 2007 (UTC)[reply]
I believe this could be fixed by changing the innards of the templates to have a couple of <includeonly>subst:</includeonly> tags. I think this would work:
It's pretty ugly, but the result should be that only the wikitext for the header ends up in the page, without the parser functions. Mike Dillon 03:37, 2 April 2007 (UTC)[reply]
I see that the templates had these, but ais523 removed them.[1] I'll ask that user to take a second look. — coelacan — 04:53, 2 April 2007 (UTC)[reply]
The problem is that with the old coding, the header appeared even if header=1 wasn't used. I'm not sure that I know a solution to this; ParserFunction/subst mixtures have always acted unusually in my experience. If you can make the change and it makes it possible to use the template without the header, please feel free to do so. (I was unaware that the new coding had a problem.) --ais523 13:47, 2 April 2007 (UTC)
Gallery display issues?
I haven't done any sort of bug reporting yet, mostly because I haven't heard of anyone else having the same problem. Many (not all, though close) of the pages I've gone to won't display images if they're part of a gallery. Sometimes a few thumbnails are shown, sometimes all but one or two, sometimes none, and the number in the gallery doesn't seem to have any effect on how many are(n't) shown. When the images are just regular thumbnails within the [[Image:]] tags, they're ok (though I believe there've been one or two times when those won't display, either), as are images within infoboxes. I've tried purging and refreshing, but it doesn't help any. A few times it's even resulted in fewer pictures being displayed. Between all this, I'm seriously wondering if it's an issue with Wiki (in general, this issue isn't contained to Wikipedia), or with my computer (which is also why I haven't sent any bug reports). Anyone have any ideas what could be causing the problem, or how I can fix it? -Bbik 22:26, 14 April 2007 (UTC)[reply]
Which images are they? I believe this note from the top of this page applies:
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.
If you can point out an image you're having an issue with, we can see if the issue affects just you or others as well. Hope that helps. Mike Dillon 23:22, 14 April 2007 (UTC)[reply]
That line (among others) is exactly why I specified that I'd tried purging already. However, as for specific ones I'm having issues with, most recently it's this page, and the specific pictures are (working across, starting at the first one after the panoramas):
Small Town: 1, 4, 5, 8, 10, 15
Big Town: 5-9
I can find other pages I've had issues with too, if it'll help. If the numbering doesn't make sense, let me know and I'll copy the specific pages from the edit box. -Bbik 23:52, 14 April 2007 (UTC)[reply]
Just wondering if anyone has any ideas on this, since it's moved quite so far up the list by now, and no response to the listed pictures, either... -Bbik 07:54, 16 April 2007 (UTC)[reply]
So, should I assume no one has any idea about this, and I should just submit it as a bug, or? -Bbik 04:31, 20 April 2007 (UTC)[reply]
Sorry I lost track of this discussion. I'm not seeing any problems with the page you pointed to. Mike Dillon 04:52, 20 April 2007 (UTC)[reply]
Ok. I'll blame it on my computer for now and see if it's still a problem once I get it fixed (hopefully in the next few days), and then submit it as a bug if it is. Thanks anyhow. -Bbik 23:27, 20 April 2007 (UTC)[reply]
????
I uploaded some pictures in my Art Gallery at Crocodile Lake National Wildlife Refuge. The problem is, sometimes I am unable to see the pictures. Whenever I use a PC it doesn't work... and whenever I use a Mac it does. Is there some type of formatting/programming that I should use in order for me to see the pictures no matter what type of computer I'm using? Would Internet security programs interrupt my viewing of the images possibly? 1013-andy 16:34, 30 April 2007 (UTC)[reply]
Collapsing a lengthy caption?
Is it possible to use a script of some sort to hide a specific lengthy caption until the reader clicks "show caption"? This is suggested for the long caption at Atheism#Rationale. Something like what is used in {{hat}}, for example? Thanks! — BRIAN0918 • 2007-04-17 00:45Z
engineer
thank you for your time and answers, I may yet become an engineer.
Recent changes to unwatched articles
Would it be possible to add an option to restrict Special:Recentchanges to articles that only a few (maybe less than twenty) people have on their watchlists? --Derlay 22:03, 18 April 2007 (UTC)[reply]
I don't believe so; the system doesn't store who has what watched like that (it's all tied through the account, not the article). EVula// talk // ☯ // 02:57, 19 April 2007 (UTC)[reply]
Admins have access to Special:Unwatchedpages for pages with 0 watchers, but a recent-changes for it would probably be too taxing on the database without some serious reprogramming. --ais523 15:13, 20 April 2007 (UTC)
How about this: every time a watchlist is viewed, update a timestamp on every page on the list, and filter Recentchanges by that timestamp. That should be feasible to implement, and actually better than a watchlist count, since watchlists of inactive users can't affect the result. --Derlay 23:45, 22 April 2007 (UTC)[reply]
That is a good idea Derlay. HighInBC(Need help? Ask me) 00:13, 23 April 2007 (UTC)[reply]
Is anyone going to implement this? Or do I need to mention it somewhere else? --Derlay 22:21, 29 April 2007 (UTC)[reply]
Bunched up edit links
Wikipedia:Meetup/London1 is vexing me. This is being done by the huge Wikimeetup template, not by images, so those fixes didn't help me. Is there any way to fix this? hbdragon88 06:28, 24 April 2007 (UTC)[reply]
I've made a change here that fixes the problem. The issue was that a few images were floating on the right below the template and they were pushing all the section edit links to the bottom. With a template that long also right-floating, just avoid any right-floating images after it. Jaksmata 15:03, 3 May 2007 (UTC)[reply]
I can see edit links there. Maybe you need to check your preferences? Look in the Edit tab, first option is to enable editing sections - make sure it's checked. Jaksmata 15:07, 3 May 2007 (UTC)[reply]
Why do I have the option of editting other people's comments?
Or deleting the entire "Talk" page, for that matter. Doesn't this take "anyone can edit" a little to far? — Preceding unsigned comment added by Lumarine (talk • contribs) 16:16, April 24, 2007 (UTC)
Nope, it works great. If a user abuses the privilege then they can be blocked, and any damages easily undone. HighInBC(Need help? Ask me) 16:17, 24 April 2007 (UTC)[reply]
Not to mention, there's pair of bots that automatically revert page blankings of any kind--VectorPotentialTalk 16:18, 24 April 2007 (UTC)[reply]
No, this is stupid. Comments belong to a historical record which should never be edited, only appended to. The Wikipedia system is looking at everything as a nail because you have a hammer. --Ideogram 21:00, 26 April 2007 (UTC)[reply]
The issue comes when someone posts "OMG U GAYWAD!" There's no reason why we should have to go through a long post deletion process to remove that. -Amarkovmoo! 21:04, 26 April 2007 (UTC)[reply]
Let admins delete entire posts just as they can delete entire articles now. There is nothing most people should be able to do to another person's post; and only uninvolved admins should be able to delete it if it is abusive. --Ideogram 21:17, 26 April 2007 (UTC)[reply]
Actually, one thing lost on modern wikipedia is the will to wiki:ReFactor (for instance from wiki:ThreadMode to Wiki:DocumentMode). In one sense, the ability is vestigial. In another sense, it's sad that this has been lost --Kim Bruning 21:05, 26 April 2007 (UTC)[reply]
What we really need is dynamic views on the underlying data where you can choose to view the unfiltered historical record, or a "cleaned-up" version approved by (someone). --Ideogram 21:22, 26 April 2007 (UTC)[reply]
I am so going to look into wiki interface design, sometime in my copious free time. --Kim Bruning 21:24, 26 April 2007 (UTC)[reply]
All comments are kept forever in the history tab. HighInBC(Need help? Ask me) 03:40, 27 April 2007 (UTC)[reply]
Sure, but finding them back can be fiendishly tricky. --Kim Bruning 04:02, 27 April 2007 (UTC)[reply]
Edittools problems on personal wiki
I have copied part of MediaWiki:Edittools for use on my personal wiki (thanks for making that box, by the way -- it's really handy) and installed the CharInsert extension. However, some of the characters that look just fine in Wikipedia turn up as diamond-enclosed question marks on my wiki. I have scoured the CSS on this site as much as I can, but couldn't find anything that fixed the problem. How can I make the characters work? Thanks in advance to anyone who can help. — Tuvok[T@lk/Improve me] 03:57, 25 April 2007 (UTC)[reply]
It sounds like a character encoding problem related to copying and pasting. Is you wiki public? Mike Dillon 03:59, 25 April 2007 (UTC)[reply]
Unfortunately not. It's actually only local as of yet; I'm still looking for hosting. I can post the code from any pages I have in user subpages if it'll help (like LocalSettings.php or MediaWiki: namespace pages). Thanks for the quick response! Too bad I wasn't online :).
I actually tried copying and pasting a couple problem characters directly from Character Map, but it didn't fix the issue, at least with the character or two I tried it on. — Tuvok[T@lk/Improve me] 21:22, 25 April 2007 (UTC)[reply]
You might try copying and pasting the contents with a different browser to see if you have the same problems. Mike Dillon 01:00, 26 April 2007 (UTC)[reply]
And here I thought IE would be good for something... Wish I could say it worked. Thanks for the tip, though. I noticed that my edits copying from Character Map weren't actually saved. Since the characters didn't change (according to MW, at least), it didn't save the edit. I'll have to keep working on this... — Tuvok[T@lk/Improve me] 03:40, 27 April 2007 (UTC)[reply]
I don't suppose anyone else has an idea? I've done everything I can think of, even changing the collation in the wikidb database to utf8_bin, but it didn't work. Any help greatly appreciated. Thanks in advance! — Tuvok[T@lk/Improve me] 01:55, 2 May 2007 (UTC)[reply]
Help with load time, resource use
Hi. Minneapolis, Minnesota was really slow to load, so I cut some text and templates. Now I am wondering if there was something else I ought to have done instead. Why is it so much bigger in bytes than these comparable articles? Are there ways to use bytes better? Thanks. -Susanlesch 19:13, 25 April 2007 (UTC)[reply]
Looks to me that Minneapolis is just a larger article with more pictures; compared to say the Ann Arbor example you give. If there is twice as much stuff, it will take twice the time to load; can be a little less than double (there is a fixed cost in loading anything) but also can be a little more (there is a quadratic effect, a longer load is more likely to collide with other network traffic or system usage, and face longer delays). Pete St.John 20:43, 25 April 2007 (UTC)[reply]
Thank you for the reassuring opinion. Yes, "just larger" makes sense in the case of Ann Arbor. But I am not so sure, looking down the list. Could 32 citations make that much difference between, for example, Minneapolis and San Francisco -- which has a larger "Edit this page" at 92K, but smaller "Pre-expand" etc.? While I am asking, what is the relationship between the "Edit this page" byte count and the others (850946, 317371 and 245963 in the case of Minneapolis)? It may help to note Minneapolis has three templates above the footer (which explains the high "Template argument" maybe). -Susanlesch 23:31, 25 April 2007 (UTC)[reply]
Templates normally count much more towards the pre-expand include limit than non-template text (they don't count any more towards the post-expand include limit unless they expand to a lot of text, but it's the pre-expand limit that's hard on the servers). See Wikipedia:Template limits; yes, it is all the cite templates that are hard on the servers, as they contain a lot of ParserFunctions and similar complicated code that take time to parse. --ais523 07:54, 26 April 2007 (UTC)
Many thanks for the link (it answered a couple of questions I had). Would omitting the approx. 130 cite templates help speed up the page? It would only take a short time to rewrite them to look like the same format (and might even save a few more bytes in the page in the process). -Susanlesch 19:41, 26 April 2007 (UTC)[reply]
The content is just about the same as before, but I removed the cite template markup in Minneapolis, Minnesota to see what would happen, see table below for before and after. Is this removal of the 'cite's going to speed up loading? Save server time? Or am I better off reverting to the cite templates that other editors are accustomed to? (Regarding editor preferences, I added about 120 of these in the first place so can comfortably go either way I think. I'll check to see what style of citation markup was used last year. Trimming 6k seems worthwhile to me.) -Susanlesch 06:20, 27 April 2007 (UTC)[reply]
edit this page in K
footer templates
notes
total page imgs
bytes
Before
77
3
131
29
Pre-expand include
850946
Post-expand include
317371
Template argument
245963
After
71
3
131
28
Pre-expand include
271269
Post-expand include
164407
Template argument
70092
Getting a partial source, with action=raw?
Is there a way to get the source (ie. raw wikitext) of a section of an article? I tried adding §ion=x to the URL (as per how section editing is done) but it still pulls the whole article. If there is no current way to do this via a URL, is there a good way to parse the whole wikitext to split into sections (ie. a regex to split on)? —Daniel Vandersluis(talk) 21:11, 25 April 2007 (UTC)[reply]
Here's the MediaWiki parser regex for making headings (converted to JavaScript):
for ( i = 6; i >= 1; --i ) {
var h = "";
var r = i;
while (--r >= 0) h += "=";
re = new RegExp("^"+ h +"(.+)"+ h +"(\\s*)$", "gm");
text = text.replace(re, "<h"+ i +">$1</h"+ i +">$2");
}
You could a split/explode just before the regexp, and you'd have an array of sections. As far as I know, there's no current way to do this via URL. Datrio 07:37, 26 April 2007 (UTC)[reply]
Is there a known problem with numerals following arabic text? See the first line of Sirr Al-Khatim Al-Khalifa, for an example. If I change that capital i at the start of the date to a figure 1 the whole date jumps to before the arabic text. It's obviously something to do with arabic reading from right to left. Sandbox experiments confirm the problem and it happens here whether I'm logged in or not, on XP using Firefox or IE. If I replace the space following the arabic with it renders OK in the editor, but still jumps on the page: viz.
سر الختم الخليفة 1234 456 789 test
I can fix it by entering some plain text (e.g. born) before the numeral, but that's not the point! I've tried searching for references to this, but the nearest I can find are this and this (search for "arabic text"). I'd appreciate if someone could confirm this is a problem, and is not just something wonky here. Is there a fix? - a <span> perhaps? Smalljim 21:53, 25 April 2007 (UTC)[reply]
Yes, simply use {{bdo}} (a template replacement for the unsupported <bdo> tag):
سر الختم الخليفة 1234 456 789 test
As to the rendering order on the editor, I have #editform textarea { direction: ltr; unicode-bidi: bidi-override } on my user stylesheet; it's the exact same CSS the template above uses, but being applied to the edit area. I don't know if it still works; I added it a long time ago, and the skin might have changed in the meantime. It's worth a try. --cesarb 23:59, 25 April 2007 (UTC)[reply]
That CSS will cause the entire edit box to render left-to-right no matter what's typed in it (including Arabic); I suspect that wouldn't be an appropriate fix for someone who reads or writes Arabic, as it would be a similar effect to all the words appearing backwards in English (which would be hard to read!). --ais523 07:51, 26 April 2007 (UTC)
Thanks for pointing me to the {{bdo}} template, cesarb. That's allowed me to fix the article. I'm not too bothered about rendering order in the editor: I don't expect to come across this often, and the addition of the letters in the template cures it. But it is odd that it only happens with numerals following Arabic. How do I find out if it's a known bug, or something I ought to report somewhere for the good of the community?Smalljim 09:53, 26 April 2007 (UTC) Oops! edit collision - thanks for the explanation below, Tim. Smalljim 09:58, 26 April 2007 (UTC)[reply]
The problem is that the HTML specification and all the browsers use the Unicode Bidirectional Algorithm, which although it may be quite versatile, does need tweaking at times to get things to display correctly. The problem here is that weak characters such as numerals adopt the type of strong characters logically before them, which in this case is the arabic text, not the latin text following. I wouldn't recommend using the override characters (LRO/RLO or HTML's BDO), since their purpose is to make text go backwards, e.g. {{bdo|rtl|unicode}} -> unicode. Rather I'd suggest separating the numbers and the arabic text with an LRM character. LRM is a non-displaying character with strong left-to-right type, so it makes weak characters after it become left-to-right. Using a pasted LRM character works both in the edit box and on display:
In case it hasn't been noted here already: The Spanish Wikipedians are proposing that all Wikipedias in all languages gain an "Appendix:" namespace (like the ones in the Spanish Wikipedia and the English Wiktionary) and that all Wikipedias have an Encyclopedic Support Contents Policy. Uncle G 23:21, 25 April 2007 (UTC)[reply]
Technically doable, but please, let's not. Basically, it boils down to some people thinking that tables, reference lists, and lists shouldn't be in the main namespace, but others disagreeing. Titoxd(?!? - cool stuff) 23:26, 25 April 2007 (UTC)[reply]
Agree with Titoxd. No more red tape. Please! ValentinianT / C 23:35, 25 April 2007 (UTC)[reply]
The place for discussion is the talk page of the Meta page linked to above. The people making the proposal won't see know about your objections if you write them here. Uncle G 15:20, 26 April 2007 (UTC)[reply]
Well, I'm talking about the English Wikipedia here. Other wikis may find it useful, but not here. And they do know about me not liking it, I participated in the process to enact that thing... Titoxd(?!? - cool stuff) 04:04, 27 April 2007 (UTC)[reply]
How do I close a page that I made from being editted?
You don't. This is the encyclopedia anyone can edit, it's a collaborative process--VectorPotentialTalk 00:34, 26 April 2007 (UTC)[reply]
This is not entirely true. They can request for the page to be protected. I'm not sure the requirements, but you could look into this. --AjaaniSherisu 11:14, 26 April 2007 (UTC)[reply]
The most common reasons to protect an article would be a high amount of vandalism from several different users, and an edit war. See Wikipedia:Protection policy. --ais523 15:21, 26 April 2007 (UTC)
Closed, user blocked indefinitely. Tizio 16:57, 26 April 2007 (UTC)[reply]
Please remember that if an editor is blanking a biographical article, xe might be ineptly attempting to remove negative biographical information. That is not necessarily vandalism, and your immediate reaction should not be to block the editor. In this instance it was negative biographical information sourced to an article in the St. Petersburg Times. Uncle G 12:13, 27 April 2007 (UTC)[reply]
Revert to specific revision sometimes fails when vandal actively at work?
I had one unhappy reader inadvertently point out to me that a reversion using Lupin's popups didn't quite work correctly. Pointing at the correct revert point, I got a mix of that version and the most recent vandal edit. Thinking all's good I wandered off having left vandalized text in the article!
Now today I see that this happened to someone else, under pretty much the same circumstances, but using another tool Twinkle. So I'm thinking this is a bit more a problem than what tool is used.
Peek at this history listing starting with the revert. Mentality has pointed to the last good version "revision 125237527 by JoanneB" and started the revert. And nothing complains. But, the second bad edit by 67.128.112.59 sneaks in and remains after the revert is finished. A whole section of text got deleted without anyone the wiser.
So... how do you know a revert hasn't worked, in that yet another vandal edit has snuck in? Do you have to do a "Compare selected versions" with the revert point and the result, just to see they aren't the same again/anymore? Shenme 05:05, 26 April 2007 (UTC)[reply]
It happens when the vandal is editing a section that isn't being changed by your revert, so usually that means they're editing a section they haven't edited before. I usually check the user's contributions after doing the revert just in case. I revert manually and it's happened to me as well - see my edit and this edit to Australian Security Intelligence Organisation which removed some vandalism but also added some in a different section of the article. Graham87 07:11, 26 April 2007 (UTC)[reply]
Hmm, but I thought Twinkle checked for reverts made during the revert process? In other words, even if they make a change whilst you're in the process of reverting their vandalism, it reverts both of them? And why does the wiki history display their vandal-edit before the anti-vandalism revert? I don't know I've just woken up :( Mentality 08:20, 26 April 2007 (UTC)[reply]
What happens is that the vandal makes a change to a section that isn't vandalised during the revert process, and the vandal's edit saves first. Then, when your revert saves, the server notices the edit conflict but thinks 'those edits are to different sections, I can avoid the conflict by just changing both sections the way the users wanted' and silently merges the edits, so the vandalism done while you're reverting isn't reverted. (This relies a lot on the exact timing.) Twinkle doesn't notice either because the edit-conflict warning never came up from its point of view. I hope that explains what's happening; I'm not sure how to avoid it (it's a case of two simultaneous changes which have to be placed in some order in the history!). --ais523 08:25, 26 April 2007 (UTC)
Ah, I get it now, thank you :-) Mentality 08:52, 26 April 2007 (UTC)[reply]
Indeed, pointing out that different sections are involved makes sense. Drat, more work. Thanks! Shenme 19:22, 26 April 2007 (UTC)[reply]
I have just done some further reading and experimentation and I have discovered that the above is either completely incorrect or there has been a change in MediaWiki of which I am not aware. A more likely explanation of the problem is server lag. help:revert#Reverts do not cause edit conflicts explains that reverts never cause edit conflicts. I have checked all the examples above plus three more I know of using the ISO 8601 date format (which is the only direct way of getting at the times of edits to the nearest second that I know of); it can be accessed in the date and time section of the preferences. Looking at the following diffs plus the ones provided above in ISO 8601 format should make things clear: [2], [3] and [4]. In all of these examples and the ones given above, the maximum time between edits is 6 seconds, which is most likely not enough time for all the servers to be alerted that an edit has taken place. Therefore, the problem is related to server lag, and has nothing to do with edit conflicts. Graham87 14:01, 27 April 2007 (UTC)[reply]
Location map dot varies location between Firefox and IE; one correct, one not.
{{Infobox City}} has a provision using the template {{superimpose}} to manually superimpose a dot atop of a blank map. When I first tested it, it seemed to work great. However, now on certain pages there seems to be a glitch when viewed using Internet Explorer (WinXP), but Firefox (MacOS 10.4 and WinXP) is fine. Here is an example—Airdrie, Alberta. I thought that maybe it was the map itself (Image:Division No. 6, Alberta Location.png) but Didsbury, Alberta uses both this map and Infobox City (aka Infobox Settlement) and there doesn't seem to be a problem or a noticeable difference in dot placement. As a control, Langdon, Alberta uses this map and the {{superimpose}} template but doesn't use infobox city and it seems to be fine. Can anyone explain this and is there a solution for this? —MJCdetroit 19:49, 26 April 2007 (UTC)[reply]
Looks fine in IE6, but not in Firefox 2 on WinXP. I'm pretty sure it's because the image is centered in the table cell. See this table with exaggerated width:
We need a way to make the surrounding <div> wrap around the image only, and not the entire table cell. –Pomte 01:19, 27 April 2007 (UTC)[reply]
In your preview, when viewed in FF 1.5.0.11 and Safari Version 2.0.4 for Mac OS, the dot is about 2½ inches left of the shaded area. I'll preview it tommorrow in WinXP and IE & FF when I get to work.
It looks like the author of Template:Superimpose may have had a problem with IE and png images before. I would have asked him if this is the problem here, but Papayoung is currently inactive. —MJCdetroit 02:31, 27 April 2007 (UTC)[reply]
At least in this example, the issue is not with the type of image but with CSS layering. One way to solve it is by specifying the width of the <div>:
I've added a removable red border to make it obvious what has changed. Someone with more knowledge of CSS may have a better idea. –Pomte 03:23, 27 April 2007 (UTC)[reply]
Some localised infoboxes use {{Location map}}, which does not contain superimpose. I haven't seen any faults when viewing that with Firefox of IE. Maybe the difference between the two template codes could reveal something. - 52 Pickup 13:11, 27 April 2007 (UTC)[reply]
{{Location map}} does specify the width of the div (albeit with +3px for padding), so I'm going to get the same change at {{superimpose}}. –Pomte 21:00, 27 April 2007 (UTC)[reply]
Are there any articles already using image_dot_map in {{Infobox City}} that had dot_x and dot_y changed due to this problem? Looks like the parameter was added recently, so there shouldn't be too many to fix. –Pomte 23:37, 27 April 2007 (UTC)[reply]
I don't think that any have been changed. Changing the dot placement is what brought this problem to the surface at Airdrie, Alberta. If there infoboxes that need to be "fixed", most would be in Alberta, Canada and a few in Western New York, USA. —MJCdetroit 00:28, 30 April 2007 (UTC)[reply]
UPDATE: I made some changes to a test template located at Template:Infobox City/Test1. I also made the Category:Settlement articles requiring maintenance to help fix the pages that have this problem. There are 59 pages where this is used, so fixing will be pretty easy. I tested the fix in FF2 and IE7 for WindowsXP and Safari 2.0.4 & FF 1.5.0.11 for MacOS X (10.4.9). Everything seemed fine. For evaluation purposes, I edited Redcliff, Alberta and Airdrie, Alberta to use the "Test1" template. Does this fix seem reasonable? If it does I'll go ahead and change the 59 pages to correctly display the dot. —MJCdetroit 02:42, 30 April 2007 (UTC)[reply]
I see no problems with that and in fact I have incorrectly attempted to simplify the code. I will withdraw the edit request at {{superimpose}}, unless there is some situation other than {{Infobox City}} when {{superimpose}} is used on a center-aligned image. –Pomte 03:22, 30 April 2007 (UTC)[reply]
The change has been made to {{superimpose}}. I have made the minor corresponding change to {{Infobox City}}. Your suggested /Test1 is now unnecessary as the extra div becomes redundant. The dot_x and _y values need to be fixed for all articles in Category:Settlement articles requiring maintenance. Anything I can do to help speed this process up, or can you handle it? –Pomte 18:23, 1 May 2007 (UTC)[reply]
Any help that is offered is always welcome. For the Alberta maps (which are all 180px), the dot_x seems to be off by about +35. I have been subtracting 35 from what ever the dot_x says and double checking it in google earth. It gets the dot pretty close. The dot_y seems to be ok. If you changed the live template then I will start just changing the dot_x values in the infoboxes in that category. Thanks, —MJCdetroit 19:17, 1 May 2007 (UTC)[reply]
Password restrictions changed
Due to an attacker mass-abusing accounts with weak passwords, passwords that are the same as the username can no longer be used. Affected accounts can reset their password by e-mail to something more secure. --brion 21:55, 26 April 2007 (UTC)[reply]
I've tested r21640 locally. Such accounts are in fact blocked from logging in, however if the attacker has obtained a session cookie for any remaining user accounts with eponymous passwords (obtained prior to the software change), he could still edit with those accounts by providing old (yet non-expired) cookies. —freak(talk) 23:17, Apr. 26, 2007 (UTC)
What about users that didn't specify an e-mail address? --24.178.78.17 01:28, 27 April 2007 (UTC) (was User:All in [All in's password was the same as the user name])[reply]
No, I get the error message "Login error: Incorrect password entered. Please try again." when attempting to log in. --24.178.78.17 01:35, 27 April 2007 (UTC)[reply]
I think you need to register a new account. I was going to suggest usurpation, since the legal issues don't exist if you're the account holder, but you don't really have any way of proving that you are. --Deskana(fry that thing!) 01:36, 27 April 2007 (UTC)[reply]
Annoying image preview issue
It used to be the case that you could only click on an image on its image page if it had a higher-resolution version than that shown in the preview. If the preview (the image embedded in the image page) was at the maximum size, you couldn't click on it, which gave the user a clue (without having to read the full and preview dimensions) that you could view a bigger version. Now the image is always linked, so you often end up clicking on it to see a bigger version, but it's just the same. The new behavior is annoying. Is it a bug or a feature? Example of new behavior: Image:Raunkiaer.jpg; it used to behave like this: [5]. --TotoBaggins 05:14, 27 April 2007 (UTC)[reply]
I think the caption makes it pretty clear:
Size of this preview: 600 × 406 pixels
Full resolution (600 × 406 pixel
In Special:Preferences -> Files, you have a preference for the maximum image size shown. If an image is smaller than that limit, then that's the original size. –Pomte 06:59, 27 April 2007 (UTC)[reply]
I cropped this image from the original because it was off-centre. Now it seems to be displaying a stretched and distorted version of the original image when it displays at 100 and 200px. But at 80 and 120px it displays correctly. See the image page for sample displays. Is this a server purging issue, and if so why won't it fix? I'm seeing the same thing from IE as well as FF and a good 10 minutes has elapsed, so I presume its not in my browser cache. Any help appreciated. —Moondyne 06:34, 27 April 2007 (UTC)[reply]
The original uploader has now reverted the image back to the off-centre version (which is fine), but then the 80 and 120px thumbnails changed to centred versions with distortion. And now when I look, all thumbnails have changed to off-centred with no distortion. I'd love to know the answer to this, please. —Moondyne 07:28, 27 April 2007 (UTC)[reply]
Sometimes when you upload an image, it loads the new image but not the dimensions of the new image, causing the new image to be displayed exactly the same size as the old image. I think this is more of an issue with your browser cache than it is with MediaWiki software. A forced refresh normally fixes the problem, which probably explains why when you came back to it later, it showed it correctly. --Deskana(fry that thing!) 12:28, 27 April 2007 (UTC)[reply]
Well why would I have seen the same problem in both my IE and Firefox browsers? Another user saw the problem also. And in between I refreshed my browser cache with F5 and Ctrl-F5. I'd just like to get to the bottom of it if possible. —Moondyne 14:36, 27 April 2007 (UTC)[reply]
The only time I've had this problem is with the above conditions, it is entirely possible there is another unique set of conditions causing exactly the same symptoms. Has anyone had this problem too? --Deskana(fry that thing!) 01:21, 28 April 2007 (UTC)[reply]
Reducing image file size
Hello. I have been cleaning up some images. In some cases I find images that I can reduce the file size for but with little visual change. For example, optimising a PNG image with optiPNG. I have been replacing images if the file size is approximately halved. This will conserve bandwidth, and make the image more accessible to people on slow connections, but fill up the server with potentially unnecessary files.
Is it worth optimising the image and uploading a new version? If so how much difference makes it worthwhile?
I think in most cases the server reprocesses the image before sending it to the browser. This may make optimization irrelevant, but I wouldn't like to say for sure. Notinasnaid 07:18, 27 April 2007 (UTC)[reply]
Yes, images that are resized lose the advantage of optimisation. In some cases a smaller resized version may have a bigger file size than the large original! So optimisation may only be worthwhile for viewing large originals, but is it even worth it for them?Iain 07:33, 27 April 2007 (UTC)[reply]
Odd internal error message
I just tried to delete an image and got this message:
There seems to be a problem with your login session; this action has been canceled as a precaution against session hijacking. Please hit "back" and reload the page you came from, then try again.
This is the first time I've got this - is it happening to anyone else? If not, what's the reason it might have happened to me? – Rianaऋ 12:15, 27 April 2007 (UTC)[reply]
Have you ever had the "loss of session data" error when trying to edit? It may be related to that, but that's juts a hunch. Are you still getting the error? --Deskana(fry that thing!) 12:21, 27 April 2007 (UTC)[reply]
I do get "loss of session data" every so often, but that seems to fairly common - I've never had this one before! And I've got it twice since. – Rianaऋ 12:27, 27 April 2007 (UTC)[reply]
Either way, I've changed my password just in case. – Rianaऋ 12:32, 27 April 2007 (UTC)[reply]
I wouldn't think changing your password is necessary, this seems to be more of a software problem than anything else. Your account is as likely to be secure as mine is, I think. --Deskana(fry that thing!) 12:34, 27 April 2007 (UTC)[reply]
Well, it sure didn't help - I just got it again. Grrr – Rianaऋ 12:37, 27 April 2007 (UTC)[reply]
Presumably what's happened is that it's got confused about the cookies and thinks you're trying to hack your own account? (By the way, I don't think the password's got anything to do with the seession data.) --ais523 12:49, 27 April 2007 (UTC)
That's strange. I got logged out a few times too. – Rianaऋ 12:55, 27 April 2007 (UTC)[reply]
Edit links bunched, floating doesn't help
See Template:Infobox Skyscraper and Circle on Cavill. I changed the template to add float: right; clear: right;, but it's not working. I purged both pages several times as well. I also checked out Wikipedia:How to fix bunched-up edit links, but it just said to do float: right; clear: right; which I had already done, and putting a section clear I don't think will work, and the div solution doesn't seem needed here, as it's an infobox and this problem doesn't exist elsewhere. Any help will be appreciated. MECU≈talk 12:54, 27 April 2007 (UTC)[reply]
Nevermind, it was the image. MECU≈talk 12:57, 27 April 2007 (UTC)[reply]
A little help perhaps?
I apologize for making a personal request, but…
I just would like to request a little help. IF you are not busy doing something constructive, and you know a bit about wikicoding, could you please take a look at my user page, and tell me why my stupid menu bar is refusing to stay up at the top, and continues to hide at the bottom where no one can see it? Thanks! N i g h t F a l c o n 9 0 9 0 9' T a l k 13:21, 27 April 2007 (UTC)[reply]
You forgot to close your "table" tag, which tends to make things float a bit. You may want to touch up the formatting a bit so that it blends a bit more with the rest of your userpage. :-) --Deskana(fry that thing!) 15:39, 27 April 2007 (UTC)[reply]
Silly question but I need answer
Yesterday I could not find the Tecnical Pump!
I need to go on a Wikibreak as quickly as possible and want to know how to do it -- where to get the banner, etc. I also need to have my pages protected while I am gone, as there isa person who blanks parts of them. If I am not around to guard my pages, I cannot protect them myself. Is this possible? Thank you? --Mattisse 13:23, 27 April 2007 (UTC)[reply]
The fastest way to find this Village Pump is to type WP:VPT into the search box and press Return. To 'go on wikibreak', type {{wikibreak}} at the top of your talkpage (and userpage as well if you wish); this will add the banner. You can request an administrator to protect your userpage/talkpage at WP:RFPP, but normally this wouldn't be done (normally RC patrollers would revert vandalism to people's userpage in their absence); in particular, usertalk pages are rarely protected because people might need to send you messages (which you would then be able to read when you came back from Wikibreak). Hope that helps! --ais523 13:29, 27 April 2007 (UTC)
That you so much for you answer. I do not need my talk page protected. It is my user page and other person pages. A person has been blanking selected parts of them. Vandal patrols have not noticed nor have they reverted them. I have had to go through each page, look at the history and try to restore the blanked sections. Do you have a suggestion? (I have considered saving all such pages in a text file on my desk and then just replacing my user pages with the text file when I return. That is all I can think of to do.) Sincerely, --Mattisse 13:56, 27 April 2007 (UTC)[reply]
If a particular user is targeting you for vandalism, you could let administrators know at WP:AN/I; you could request for your pages to be protected or the user in question to be blocked there, if it's a big enough problem. (If other people don't edit the pages in question, you could just revert them to the pre-wikibreak version when you come back from a wikibreak; Wikipedia saves the old version for you so you don't have to save it yourself.) Hope that helps! --ais523 13:59, 27 April 2007 (UTC)
The wiki break template does not seem to work. I put it on my user page {{wikibreak}} -- and that is what shows up. What am I doing wrong? Sincerely, Mattisse 14:08, 27 April 2007 (UTC)[reply]
P.S. The vandal suggestion I have explored and no dice. The vandal changes his name. I don't know where "old versons" of pages are kept but in the past I have never been able to get one. Also, the vandal blanks only selected parts of the page, not the whole page. I have discussed this with Admins but they have decided AGF regarding the vandal. Would not my solution work - save a text file of each page, and then replace the pages with my text version on my return? Sincerely, --Mattisse 14:08, 27 April 2007 (UTC)[reply]
Your solution would work; to access an old version of a page, click on 'history' and then the date of the old version. (If you click 'edit' and then 'save' while viewing the old version, the page will revert back to that particular old version.) --ais523 14:12, 27 April 2007 (UTC)
If it's reasonable to assume it's the same vandal with different accounts, let the admins know. They can arrange a checkuser to see if they really are the same person, and take appropriate action. --h2g2bob 14:21, 27 April 2007 (UTC)[reply]
How do I apply a wiki break banner to my page?
Placing {{wikibreak}} as I have been previously advised, does not work for me. Sincerely, --Mattisse 14:48, 27 April 2007 (UTC)[reply]
Typing {{wikibreak}} worked when I tried it in preview mode on your userpage and talkpage for me. What goes wrong when you try? --ais523 14:52, 27 April 2007 (UTC)
I've done it for you. --Ezeu 14:54, 27 April 2007 (UTC)[reply]
and many small images are showing to be very large.
For example File:ASmily.gif is becoming
When using [[Image:ASmily.gif|thumb]] - [[Image:ASmily.gif|frame]] & <gallery>Image:ASmily.gif</gallery>. I am not using the Google Toolbar. Could someone explain why this is happening? Thanks, Razorclaw 20:07, 27 April 2007 (UTC)[reply]
This is intended. When you select "thumb" as an image display option, the image (by default) displays with a width of 180 pixels (not sure why it's 120 for you. You can see your user preferences' file section). See Wikipedia:Extended image syntax for more information on getting images to do what you want. GracenotesT § 21:33, 27 April 2007 (UTC)[reply]
Really Its the gallery I'm talking about. I did not know small images turned out huge there. «razorclaw» 22:19, 27 April 2007 (UTC)[reply]
Galleries also scale images to a specific size (~200px, I think) whether they are smaller or larger than the specified size. Smaller ones will, of course, pixelate and larger ones may lose detail. --Iamunknown 22:26, 27 April 2007 (UTC)[reply]
This is a new bug which is being worked on. --brion 16:52, 1 May 2007 (UTC)[reply]
Any suggesgtions? GDonato (talk) 21:16, 27 April 2007 (UTC)[reply]
Could you be more specific? Corvus cornix 01:20, 29 April 2007 (UTC)[reply]
I think I've found the root of the problem now.
TheGoogle made a WP:CHU request while logged out, the block (with auto-disabled) still being active on his account.
A b'crat changed TheGoogle to Raden but the block was carried over to Raden and unblocking Raden and the IP had no effect and no autoblocks could be found.
Unblocking TheGoogle should work as, according to the logs, the block by HighInBC is the only mention in the block logs.
Feel free to unblock yourself if High is offline. GDonato (talk) 10:33, 29 April 2007 (UTC)[reply]
Losing Edits
I just lost over a 100 edits after someone deleted WP:ACC..Is it possible??..Cometstyles 21:56, 27 April 2007 (UTC)[reply]
hehe..yeah but I dont think he was the one who deleted it..--Cometstyles 22:03, 27 April 2007 (UTC)[reply]
According to the deletion logs, he is. you could try to convince someone to restore the revisions from further back if you really want those edits. GDonato (talk) 22:05, 27 April 2007 (UTC)[reply]
Its not that but it made me think if it could happen on a Wikipedia page, it can happen with other articles as well and thats pretty scary and if someone ever hacked into Wikipedia and crashed it..wooo..the world will end..hehe(kind of)..--Cometstyles 22:09, 27 April 2007 (UTC)[reply]
Well, it could be restored by any other admin, so it isn't a problem. I can still see and if I wish, restore the page, for example. Prodegotalk 23:59, 27 April 2007 (UTC)[reply]
Technically, the edits aren't lost, they're just hidden from regular users and are only shown to admins on a page by page basis through Special:Undelete. The edits don't appear to admins on the user contribs page. Because this is what edit counters use to count edits, the deleted edits don't count and the total can go down. Harryboyles 00:59, 28 April 2007 (UTC)[reply]
That page will not and should not be restored, it is periodically deleted to remove user's e-mail addresses from the history in order to preserve their privacy. John Reaves(talk) 07:15, 28 April 2007 (UTC)[reply]
Of course, at first glance I thought it was just to prevent the page history from becoming excessive on an active page. GDonato (talk) 10:04, 28 April 2007 (UTC)[reply]
Actually, on a similar note has anyone ever thought of converting this page to e-mail requests (like WP:RFO) as this page could be a real target page for spammers, they're going to get about 50-100 e-mail addresses a week there, aren't they?
I suggested this some time ago at the talk page. The developers are unwilling to set up a list, however. Tra(Talk) 12:09, 28 April 2007 (UTC)[reply]
WP:BITED better not suggest it again :-}! Thanks. GDonato (talk) 12:19, 28 April 2007 (UTC)[reply]
History page showing very incorrect dates
Hi, I was looking through the history page of the Michael Goudeau article, and I noticed something peculiar in the 'earliest' history.
(cur) (last) 23:25, 9 March 2006 Jcmaco (Talk | contribs)
The first one there listed by myself (Braksator) is when I created the article, I even marked it (Creation). The ones dated April and March earlier the same year I am sure actually happened in 2007, very recently, they are to do with recent deletion proposals on the article that were ultimately challenged successfully. I am wondering if this is a bug, or have the users deliberatly set their dates backward somehow? Perhaps to make it appear as though the deletion proposal was around longer than it really was.
The page has been deleted three times already, see log page for that article. When Edgar181 restored the page he was a bit careless and restored all the old deleted stuff. Easy enough mistake to make. You should probably send him a message. --Deskana(fry that thing!) 02:39, 28 April 2007 (UTC)[reply]
Are.. you saying someone created that article twice before I did?? Braksator 03:04, 28 April 2007 (UTC)[reply]
Three times, actually, I think. Infact, no, I think you're right. --Deskana(fry that thing!) 03:10, 28 April 2007 (UTC)[reply]
Subst: a switch template?
I am working on an experiment on my sandbox subpage. However, with template substitution becoming a primer at a project called WP:NYCPT, if I transclude my sandbox page, fill in a parameter and subst: it, the editing field of the page after it is saved creates a huge mess of what's left. So what I want to do is substitute e.g. {{User:Imdanumber1/Sandbox|A}} and when is subst'ed, the editing field will show instead [[A New York City Subway service|A]]. Is this possible? --Imdanumber1 (talk • contribs) 16:35, 28 April 2007 (UTC)[reply]
Instead of <includeonly>{{#switch: ...}}</includeonly>, use {{<includeonly>subst:</includeonly>#switch: ...}}. I believe that will do what you want. Mike Dillon 17:07, 28 April 2007 (UTC)[reply]
I'm a bit confused. I'll let you implement what you are trying to say, because I don't get a link when I press save. Here's the link: User:Imdanumber1/Sandbox. Thanks. --Imdanumber1 (talk • contribs) 17:24, 28 April 2007 (UTC)[reply]
I recently noticed that SVG files I upload no longer display the Courier New font correctly, even if that font is explicitly specified. Instead, they use some other (and substantially inferior) monospace font. If I click on them and let Mozilla display them, rather than having MediaWiki convert them to PNG, they look fine. Was the renderer changed on the server side, and, if so, why? *** Crotalus *** 19:42, 28 April 2007 (UTC)[reply]
I don't know whether the rendering setup changed recently, but it's possible that the font just isn't installed on the server. The reason it works on your local machine is because it uses your local fonts in that case. Assuming you're talking about Image:TI_SN76489_pinout.svg, it looks like you specified "Courier New, monospace" as the font, which is why it is falling back. It would be nice to get a list of the fonts that are available on the image server, but I haven't seen one. It would also be cool to be able to see exactly which version of librsvg is being used. Mike Dillon 20:01, 28 April 2007 (UTC)[reply]
More fonts were installed as of 2007-04-18, see Bug 8898 comment 7. I'll put a list of fonts at m:SVG fonts. We're using librsvg 2.14. -- Tim Starling 16:49, 29 April 2007 (UTC)[reply]
Thank you for the list. Were any existing fonts removed? Courier New previously showed up properly, and now it doesn't. *** Crotalus *** 00:14, 30 April 2007 (UTC)[reply]
Never mind. I set Nimbus Mono L as the font and it worked great — that must have been what was being used previously in Courier New's place as the default monospace font. That looks much better than Bitstream. *** Crotalus *** 00:29, 30 April 2007 (UTC)[reply]
Good. I hope the documentation has been updated. (SEWilco 00:40, 30 April 2007 (UTC))[reply]
I'm working on a table for an article and it would definitely benefit from being sortable. However, I do not want a reader to be able to sort the last column. Is this possible? If so please show me a short example. --Psychless 21:24, 28 April 2007 (UTC)[reply]
Solved Problem by myself. --Psychless 22:25, 28 April 2007 (UTC)[reply]
Unless I've missed something obvious, the Category:Soviet Army is both its own parent and its own child. How can this be fixed? Greenshed 22:39, 28 April 2007 (UTC)[reply]
Please go to User:Will Pittenger#US States. There is a problem with some of the templates towards the end. I don't know why, but they are expanding. I tried creating a test page to see if I could get them to expand and they did when I substed the templates. Why don't they work? They were. Will (Talk - contribs) 01:19, 29 April 2007 (UTC)[reply]
Pre-expand include size: 2047082 bytes
Post-expand include size: 138033 bytes
Template argument size: 38361 bytes
Maximum: 2048000 bytes
Since the post-expand size is so much smaller, it looks like one or more of the pages/templates you're transcluding are a little bloated. It looks like User:Will Pittenger/templates/Flag Entry may be the culprit. You should be able to fix this using the template doc page pattern. Mike Dillon 02:44, 29 April 2007 (UTC)[reply]
I did this for a few more of your templates, but you should probably do this for the rest of your templates. You'll want to add the following to your watchlist:
If you can't find the other templates that need to have their docs moved to a subpage to get in under the size limit, I'll take another look. Mike Dillon 03:07, 29 April 2007 (UTC)[reply]
problem and feature suggestion
Problem
1. in korea wikipedia, today is not monday. today is sunday in korean time. It is error.
Suggestion
1. at a image page, make a new "move to commons" tab, please. why? if some picture is only in english wikipedia, I can move to commons very easy.
Regarding thumbnails; I've noticed that some of these have been retrospectively "scaled up" to 320px width and look awful.
One example is this "archived" article, and pretty much all versions before I fixed it. I can tell you now that the picture in the original versions of these articles was *not* scaled to 320px. I can tell you that because I've edited the article several times since then and would immediately have noticed an image that is so horribly oversized and so clearly badly scaled-up!!
What is going on? The *supposed* archived article explicitly resizes to 320px as follows:-
[[Image:UniversalHeroMastertronic.jpg|thumb|320px|right|[[Cover art]] for the game ''[[Universal Hero]]'']]
but as I said, the genuine original version didn't.
If this is someone's attempt to draw attention to misuse of "fair use low-res" (which I agree has been abused in some situations), it is wrong here, because the scan is below the 320px limit in either direction. It's also very disturbing that the archived version was (apparently) changed.
User:Fourohfour defined the 320px sizes in this edit in December 2005. (SEWilco 14:55, 29 April 2007 (UTC))[reply]
I think you meant "this alleged edit" ;) Mike Dillon 14:57, 29 April 2007 (UTC)[reply]
Please cut out the smartass comments. You'll note that that the edit in question was the one where both images were changed to proper thumbnails so that I could add a caption.
For one thing, it wasn't until I researched this issue that I had any idea that "320px" was the proposed maximum size for "fair use" images. So either this is a coincidence, or it has something to do with its fair-use, non-free nature.
But let's assume for a second that I really did miss it. Given how obviously oversized, blocky and generally horrible the resized images are (especially the "Universal Hero" cover scan lower down), the question is... If it was there for over 16 months, why did no-one else notice it? 15:33, 29 April 2007 (UTC)
(edit conflict) When you start implying that people are altering the article history to make it look like you did something you didn't,
Nope, sorry. You're reading too much into my comments that was never there. I didn't believe (nor imply) that the reasons for any such changes was likely to be personal. Nor did I assume that they were restricted to my articles. My assumption was that it was most likely an automated process to do with image-handling.
a smart-ass comment is hardly out of line. I'm sorry you took it as some sort of general slight of you abilities or perceptiveness,
No, I just thought it was rude.
but it was really just a reaction to your paranoid tone about the changes (you're the one who called the archived article "supposed").
I was sceptical about whether the article was identical, but as I said above, it wasn't something I believed was targeted at me personally, so your use of the word "paranoid" is somewhat inappropriate.
Archived articles and their history aren't unchangeable, and on occasion it's possible to even inadvertantly mix them up (e.g. history merges). It's not beyond the realms of possibility that the article had been changed for some reason. Fourohfour 16:34, 29 April 2007 (UTC)[reply]
That being said, I'm sure plenty of people noticed it, but I doubt the article in question gets enough traffic from active editors who would know what to do about it. (looks like Ruud figured it out) Mike Dillon 15:56, 29 April 2007 (UTC)[reply]
You specified the thumbnail size to be 320px. Until a few days ago the software would only scale down images and would refuse to scale up image, causing the thumbnail to be displayed at the same size at the original (256px). This "bug" has now been fixed so thumbnails can scale up images, even in archived versions. —Ruud 15:49, 29 April 2007 (UTC)[reply]
That explains it, thank you. While I accept that in all probability I did specify the 320px, it wasn't exactly obvious to me back then that there was no upscaling, and nor were the reasons for the article suddenly being obviously changed, even on the archived copies.
Hope they improve the upscaling BTW, it's a bit.... yeuch at the moment. :-) Fourohfour 16:05, 29 April 2007 (UTC)[reply]
So what's the rationale behind blowing up an image when a user specifies a lager dimension than the actual image. It was fine before, IMHO. --ChoChoPK (球球PK) (talk | contrib) 23:52, 29 April 2007 (UTC)[reply]
This change may have been ill-considered. Where may one comment on it. to try to reach a new consensus about what the software should do? Notinasnaid 12:52, 1 May 2007 (UTC)[reply]
This is an accidental regression in behavior as a side effect of some major changes to the image handling code. It'll be fixed soon; for future reference, please use our bug tracker at http://bugzilla.wikimedia.org to report bugs like this. --brion 16:47, 1 May 2007 (UTC)[reply]
Page title with ~~~
On this whatlinkshere page, it shows that Image:Hebb_bobby~_sunny~~~~_101b.jpg is transcluding the template, but this page is not accessible due to the bad title error. The database dump of the mainspace titles shows that there are some other broken pages like this one (WP:~~~, WP:~~~~, WP:~~~~~, ~~~, ~~~~, and ~~~~~). What can be done about these? --- RockMFR 20:21, 29 April 2007 (UTC)[reply]
A developer should deleted those as titles containing three or more tildes are not longer valid since the last software update. —Ruud 22:29, 29 April 2007 (UTC)[reply]
Repeating my answer from a section earlier on this page: if it gives the "Bad title" error message, the only way to delete it is to wait for the next time when the developers run their bad title fixing script, which will rename the page directly in the database to a valid name prefixed with Broken/. After that's done, since the title is no longer invalid, it can be deleted normally. I don't know, however, if that will rename the image file; it's possible that the image becomes broken. --cesarb 00:01, 30 April 2007 (UTC)[reply]
Ahh, thanks, I missed that. --- RockMFR 01:40, 30 April 2007 (UTC)[reply]
Drop down box on "confirm protection"
Perhaps discussed before, but would it be possible to have on the "confirm protection" page a drop down box for the expiration time? The same as is on the "block user" page. Garion96(talk) 21:17, 29 April 2007 (UTC)[reply]
Image no longer shown in Infobox
ResolvedDone, not sure what you did wrong, did you include right align, tha's no good, I think. GDonato (talk) 23:05, 29 April 2007 (UTC)[reply]
The Image:Teresa Teng.gif still exists but is no longer displayed in the Infobox; the template displays a red link as if the image had been deleted, see this version of page Teresa Teng. As a workaround I have just added a link outside the infobox. If this is a general problem then editors will be deleting red links all over the encyclopedia, so I hope it can be fixed soon. - Fayenatic london(talk) 22:57, 29 April 2007 (UTC)[reply]
Done by myself. GDonato (talk) 23:05, 29 April 2007 (UTC)[reply]
Thanks, GDonato. It appears that it was the image size tag (which you deleted) that was disabling it. Something has changed in the template or the wiki software, because that tag has been there all along and it used to appear just fine. Well done anyway! Fayenatic london(talk) 23:11, 29 April 2007 (UTC)[reply]
I fixed it by a sort-of-accident (probably couldn't've done it if I tried!). Images aren't really my strong-point. ;-) GDonato (talk) 23:15, 29 April 2007 (UTC)[reply]
Yeah, I noticed this with a different infobox. Syntax like {{{parameter|}}} no longer works when not inside a parserfunction, I believe. --NE2 23:47, 29 April 2007 (UTC)[reply]
px should not put behind the number in the Img_size parameter because it is already provided. See {{Infobox musical artist}}. –Pomte 23:51, 29 April 2007 (UTC)[reply]
OK, it says that now, but "px" did not cripple the image until recently. If you search for "Img_size px" you will find lots more articles which were fine before this infobox code was changed, but now have red links. Some other infobox templates still allow "px". Can someone please either revert this change, or use AWB or a bot to remove "px" from the infobox code of all articles using {{Infobox musical artist}}? - Fayenatic london(talk) 18:02, 30 April 2007 (UTC)[reply]
N.B. If checking my argument with a search for "Img_size px musician", skip the first few pages of results as I have started fixing some... but there may be thousands. Please would someone make the Infobox template tolerant to "px". - Fayenatic london(talk) 12:33, 1 May 2007 (UTC)[reply]
Going through the edit history, the image line was changed last on November 6/7, so it's not the infobox's fault. There has probably been a change in how images are shown. Before, it might have been that "200pxpx" was acceptable and interpreted as "200px", because that's essentially what those thousand infoboxes had been doing. –Pomte 17:04, 1 May 2007 (UTC)[reply]
Nevermind, "200pxpx" is actually interpreted correctly. I now think it has to do with the m:ParserFunctions behind {{min}}, because trying to compare "200" and "300px" results in Expression error: Unrecognised word "expression". –Pomte 17:18, 1 May 2007 (UTC)[reply]
I have requested an edit to the infobox template at Template talk:Infobox musical artist#Accounting for px at the end of Img_size's value. This is a solution that checks the value given to Img_size. If the length of the value is greater than 3, then set that value as the dimension without doing any {{min}} comparisons. Adding px to the end of the number can be an honest mistake and we can account for that. If it is necessary to fix all of the transclusions, that can be done eventually with time and AWB. Thousands may be an exaggeration though. –Pomte 18:08, 1 May 2007 (UTC)[reply]
The "min" was originally added in August of last year. If "px" was working in November, the problem is a change elsewhere. Anyway, changing this to support "px" will break the landscape option (unless "320pxx200px" magically works somehow). And the naive implementation suggested by Pompte will allow overenthusiastic fans to override the maximum image size by the simple expedient of adding "px" to the size, which is not a desirable outcome, IMO. It might be possible to design a better implementation that supports all options, but the code is already quite arcane. Fixing the uses (and better documenting the usage) seems somewhat preferable to me. Xtifrtälk 01:14, 2 May 2007 (UTC)[reply]
"320pxx200px" actually does work with regular images, but not with my suggestion for the same reason. You're right that increasing the image size above 220px shouldn't be allowed though. If anyone is interested I have made another wild crack at the cause of this apparent change at m:Help talk:Images and other uploaded files#Parsing px at the end of the caption. –Pomte 03:45, 2 May 2007 (UTC)[reply]
I changed the template to check if {{{Img_size}}} is a number; if not (such as if it ends with px) it is replaced with 300.--Patrick 07:04, 2 May 2007 (UTC)[reply]
How can I use an external editor for editing SECTIONS
I've successfully setup external editor by using ee.pl. But it can only deal with the entire article which maybe very long. is it possible to use user javascript to add some link called 'external edit' beside the normal 'edit' link to edit sections with external editor?
I don't think Mediawiki supports this, considering that &externaledit=true or &action=raw don't seem to work with §ion=N. Alex Smotrov 03:05, 30 April 2007 (UTC)[reply]
Forgot password
What do i do if i forgot my password. My username is user:bucs10 and I forgot the password to it.--75.82.22.125 23:51, 29 April 2007 (UTC)[reply]
"If you entered your e-mail address when you signed up, you can have a new password generated. Click on the "Log in" link in the upper-right corner. Enter your user name, and click the button near the bottom of the page called "Mail me a new password". You should receive an e-mail message with a new random password; you can use it to log in, then go ahead and change your password in your preferences to something you'll remember."
If you haven't entered in an email address, as far as I'm aware, we can't do anything about it. It appears you've created a new account, which is what I'd have recommended. Harryboyles 06:00, 30 April 2007 (UTC)[reply]
Is it possible that someone hacked into my account and changed my password on me, because I wrote my password down on a paper and I couldnt find that paper until today, and when I type it in it doesn't work.--Yankees10 21:13, 1 May 2007 (UTC)Yankees10(use to be known as Bucs10)[reply]
I doubt it. Was your password the same as your username? If you have e-mail enabled, you can get a new one sent to you. John Reaves(talk) 21:17, 1 May 2007 (UTC)[reply]
no it was different, I don't know why it isn't working I know for a fact that this was the password.--Yankees10 22:07, 1 May 2007 (UTC)Yankees10[reply]
I have the same problem (not on en: but in an other wiki). Yes, the password was the same as the username, but there was no eMail adress. Somewhere on en: was written to contact an developper, but no response. I do not understand why they did this without warning before. Eruedin 17:09, 2 May 2007 (UTC)[reply]
Signature problem
I just found out that my 4 tilda signature is messed up, like
Ah, this must have been a new feature. Thanks for responding so quickly. --ChoChoPK (球球PK) (talk | contrib) 00:06, 30 April 2007 (UTC)[reply]
For the record, the above isn't a new feature, it's been around for as long as I can remember. Wouldn't be the first time stuff like that has spontaneously changed though :-) --Deskana(fry that thing!) 02:13, 30 April 2007 (UTC)[reply]
It is a software change, although it's quite an old one now. --ais523 10:25, 30 April 2007 (UTC)
Watch new features?
Which page should we monitor so we have a chance to notice when such changes appear? (SEWilco 00:49, 30 April 2007 (UTC))[reply]
Wikipedia:Wikipedia Signpost. New features/changes are usually noted there, together with lists of which bugs were fixed and other related things. If you want to know about the changes more often than weekly, however, the only way is to monitor the IRC channel and the server admin log. --cesarb 23:52, 30 April 2007 (UTC)[reply]
Double protection with expiry
If Admin A semi protects a page with no time set (indefinitely), and then Admin B semi protects the same page (without unprotecting first) with a time, when the time is up, does that page become unprotected or does it go back to the indefinite one? Second, Admin A does the same thing, but admin B fully protects it with an expiration date. When the date comes, does it become unprotected or goes back to semi protected? --TeckWiz is now RParlateContribs@(Let's go Yankees!) 00:17, 30 April 2007 (UTC)[reply]
See this. The page is now unprotected. Hopefully this answers your question. --Deskana(fry that thing!) 00:21, 30 April 2007 (UTC)[reply]
Yes it does. Thanks. --TeckWiz is now RParlateContribs@(Let's go Yankees!) 00:27, 30 April 2007 (UTC)[reply]
Problem linking to Commons image
Could someone have a look at Robbie Williams. I deleted a copyvio photo that was being used in the infobox and so replaced it with Image:Robbie Williams Hamburg 2006.jpg, a free image from commons. It working fine here on the right, but the infobox shows a redlink to the file name only. The image's page says its linked to by Robbie Williams, it just ins't showing up there. Anyone know whats going on? WjBscribe 03:02, 30 April 2007 (UTC)[reply]
Fixed although it's now enlarged and therefore looks horrible. The problem is with the infobox template, as it says the following on the template page:
"| Img_size = <!-- Only for images narrower than 220 pixels -->"
I don't see why such a restriction is needed but then again I haven't looked over the code (and don't have time to right now). Yonatantalk 04:46, 30 April 2007 (UTC)[reply]
I'm trying to make some corrections to List of cities by population, but can't for the life of me figure out how to use a sortable wikitable. For instance, Lima needs to be moved from the 19 spot down to 39, but how do I do that and have things change automatically? Please leave a message on my talk page. --Criticalthinker 08:08, 30 April 2007 (UTC)[reply]
[Sort-function] - it is now possible for tables to have the option to be sorted by date, alphabetical order or numerical order. However, it is not possible to sort numbers with a dot or comma in them. Javascript must be on to make it work. Use "class="prettytable sortable" for the table.
Dots and commas work fine on this Wikipedia. Elsewhere adapt MediaWiki:Common.js in the same way.--Patrick 20:43, 30 April 2007 (UTC)[reply]
I don't get what you guys are talking about, at all. --Criticalthinker 00:57, 1 May 2007 (UTC)[reply]
See m:Help:Sorting. Note however that it just sorts, it does not display automatic rank numbers.--Patrick 05:09, 1 May 2007 (UTC)[reply]
Due to the footnotes numeric sorting of the population column does not work. For populations < 1,000,000, use the invisible prefix <span style="display:none">&</span>.--Patrick 20:37, 30 April 2007 (UTC)[reply]
Problems with Special:ProtectedPages
I was working on tabulating protected articles when I noticed some problems with Special:ProtectedPages. The list of fully protected articles doesn't seem to be complete - for example the redirects
American West, Bubble hash, and many more are not listed. These pages do have nonempty protection logs. CMummert · talk 15:43, 30 April 2007 (UTC)[reply]
It does not yet contain a list of all protected pages. See bugzilla:9386 for more details. --Iamunknown 16:14, 30 April 2007 (UTC)[reply]
Thanks. Is there any way via query.php, api.php, or any other public interface to actually get a list of all protected pages? CMummert · talk 16:37, 30 April 2007 (UTC)[reply]
None that I know of. --Iamunknown 18:06, 30 April 2007 (UTC)[reply]
One problem is that when they are migrated in, they will show up as the newest ones. I'll probably change the (earlist/latest) links to reflect that then. Voice-of-All 17:58, 1 May 2007 (UTC)[reply]
That's fine - api.php can query log events to get the protection date, sysop, and comment; the problem is getting a list of protected pages in the first place. CMummert · talk 18:09, 1 May 2007 (UTC)[reply]
At WT:PP, I've mentioned a script I've added to do that. Voice-of-All 20:07, 4 May 2007 (UTC)[reply]
Problem with my contributions
I would swear that up through yesterday I used to see 500 items by default when I show my contributions. Today I am only seeing 50. I am looking in my preferences and I don't see an option for this (but I think I remember setting this as a preference many months ago). Is something wrong, or am I loosing my mind? --After Midnight0001 16:13, 30 April 2007 (UTC)[reply]
50 is the default value. I don't think there is a "forgetable" way to change it. I've always thought that more than 50 as the default would be better (~500) GDonato (talk) 16:25, 30 April 2007 (UTC)[reply]
My contribs definitely used to show 250 items by default (I have 250 set as my recent-changes and expanded watchlist defaults). It's showing 50 by default now. --ais523 10:11, 1 May 2007 (UTC)
Why does the Wikipedia use such a difficult-to-read font? It hurts your eyes and slows down your reading.
Can I suggest that you use arial or some other common, highly viewable font?— Preceding unsigned comment added by 80.169.162.172 (talk • contribs)
What browser are you using?--VectorPotentialTalk 17:39, 30 April 2007 (UTC)[reply]
You can probably change the font used by your browser to display Wikipedia pages by changing your browser preferences. Nihiltres(t.c.s) 17:59, 30 April 2007 (UTC)[reply]
AFAIK, Wikipedia uses your browser's own default font. It's possible your browser is misconfigured, and you didn't notice because a lot of sites don't respect the user's preferences. --cesarb 23:45, 30 April 2007 (UTC)[reply]
Wikipedia uses Arial by default, but you can change it in your monobook.css if you are a registered user. Wikipedia never uses the browser's default font unless you tell it to in your monobook.css file. - MTC 10:07, 1 May 2007 (UTC)[reply]
Where is it specifying Arial? I looked through all the CSS files for Monobook (you can see a list at Wikipedia:Catalogue of CSS classes), and the font that's specified is "sans-serif". Your browser might be configured so that sans-serif defaults to Arial, but it's not Wikipedia that's chosing it. --cesarb 19:07, 1 May 2007 (UTC)[reply]
Ah OK I missed that, you're right Wikipedia only specifies sans-serif by default. I was going by the fact that my default is always set to Times New Roman but Wikipedia has always used Arial (on every computer I've ever accessed Wikipedia on, even before I set up my monobook.css). - MTC 19:54, 1 May 2007 (UTC)[reply]
Template formatting breaking stuff
[6] The welcome template seen here, which is adjusted by Pilotguy (unintentionally), seems to almost certainly be broken (or badly designed). The template uses unicode charater codes to prevent {{helpme}} and ~~~~ from executing. Of course, the simple way to fix the template to work properly, and not be destroyed when any sort of unicodifying tool runs over it, is to user nowikis. Unfortunately, my welcome template knowledge is not what it used to be, and I'm having trouble pinning down the culprit(s) (otherwise I'd {{sofixit}}) - could someone take a look for me? Martinp23 21:26, 30 April 2007 (UTC)[reply]
Just a note to say that I've done an emergency release of NPWatcher to prevent these issues, but I doubt that such fixes will be released for any other tools. Martinp23 21:27, 30 April 2007 (UTC)[reply]
That seems like the best solution - NPWatcher shouldn't change HTML escapes on non-article pages as part of leaving unrelated messages. Are you saying there are other tools that do that? CMummert · talk 21:46, 30 April 2007 (UTC)[reply]
AWB has the option to do it, and most users will probably leave that checked. Not sure about any other bot frameworks, or software. Would it not be wise to fix the template (if anyone knows which one it is), to prevent issues like this, and perhaps show by example to the newbie how to use nowiki (yes, an unlikely point :))? Martinp23 20:19, 1 May 2007 (UTC)[reply]
Entities that correspond to characters in the ASCII range 32 to 126 shouldn't be unicodified in my opinion, as they're almost certainly there to deliberately nowiki rather than as a typing aid. --ais523 11:29, 2 May 2007 (UTC)
How do we use a user-defined css in wikipedia?
Can we define some css classes and ids and use them whenever we want? If it is posssible, how? By wikipedia templates or something else? Thanks.
- PegasusRoe 01:19, 1 May 2007 (UTC)[reply]
Short answer: You can't.
Long answer: You can do it so that it displays only from your account, by using Special:Mypage/Monobook.css, but the css for the whole site, MediaWiki:Common.css, is permenantly protected so that only administrators can edit it, and there is no way it can be unprotected due to intentional security features in the software. --Deskana(fry that thing!) 01:23, 1 May 2007 (UTC)[reply]
That's frustrating, since I am editing a wikibook in chinese and I want to have my own style of looks, but thanks anyway. - PegasusRoe 04:26, 1 May 2007 (UTC)[reply]
The above answer applies only to the English Wikipedia, if that wasn't clear. If you're talking about a different language Wikipedia, you should ask there. Similarly, if you're talking about a Wikibooks wiki, you should ask at that site, not here; and if this is a personal wiki, that's another matter entirely. -- John Broughton(♫♫) 17:41, 2 May 2007 (UTC)[reply]
for example. Now if we click on History, it will take us to the ARTICLE'S HISTORY. But what happens if we want to directly go to the article's TALK HISTORY? I know I should be proposing features on bugzilla, but I don't have an account. Would someone be so kind to do it for me and to let me know? Thank you.100110100 07:17, 1 May 2007 (UTC)[reply]
On another note, we have tabs for 'edit this page' and 'history'. Now these tabs are fore pages you are currently on. I would like 6 tabs. article, discussion, edit article, edit discussion, article history, discussion history. Same as the above, would someone be so kind to report this to bugzilla and let me know? Thanks!:-D100110100 07:21, 1 May 2007 (UTC)[reply]
I'd be happy to make a user script for you, 100110100. That is the best solution, I think. Two catches, though: first, I can't do it within the next six hours, since I'm editing from... a less-than-ideal browser, and can't view a page's source. I could do it later (or someone else could do it now.) Second: if you have a large watchlist, it may be better to include a link that, upon clicking, populates your watchlist with talk history links, rather than making it an event that occurs when loading that page (your browser could crash). GracenotesT § 13:43, 1 May 2007 (UTC)[reply]
I think that this sort of thing's been a feature of navigation popups for ages. However, I didn't find it that useful when I used popups (and eventually turned popups off altogether). --ais523 13:50, 1 May 2007 (UTC)
Everything's a feature of popups, so no surprise there :) GracenotesT § 13:50, 1 May 2007 (UTC)[reply]
Yes, that's right. So, I'd like to still put these up on Bugzilla if someone would be so kind to volulenteer, & let me know. Thank you!100110100 06:37, 2 May 2007 (UTC)[reply]
Hi there. I'm trying to start a new sub-sub-category under the parent Category:Arab, in the sub-Category:Arabic culture, called Category:Arab Diaspora Organizations (for which I have created a page). But I don't think I have done this in the right way at all and would appreciate some guidance on how to do it correctly. Thanks. Tiamut 13:06, 1 May 2007 (UTC)[reply]
What's wrong with it? I got to it fine. The only thing I can see is that perhaps "Diaspora" "Organizations" should be lower-case. Are they proper nouns? — Frecklefoot | Talk 16:21, 1 May 2007 (UTC)[reply]
I bent my monobook
I made some changes to my Monobook.js, and now it's completely broken, failing to do anything. MediaWiki seems to be using a failsafe default Monobook now. Can someone take a look at my monolithic monobook and help figure it out? Luigi30 (Taλk) 14:37, 1 May 2007 (UTC)[reply]
If your monobook doesn't work, please start by reverting the file to the last version that worked. We've recently had a case where a user couldn't log in due to a malfunctioning monobook. After you've done this copy the following to your browser's address bar: http://en.wikipedia.org/wiki/User:Luigi30/monobook.js?action=purge.
That should give you the last functioning version of your monobook. The actual file is a protected file, so actual editing of it is impossible for other users except administrators. ValentinianT / C 15:00, 1 May 2007 (UTC)[reply]
I dropped it back to the last working version. It seems to be so delicate that just about any change I make completely breaks it. Luigi30 (Taλk) 15:03, 1 May 2007 (UTC)[reply]
In this edit you replaced ) with } on line 345. –Pomte 21:20, 1 May 2007 (UTC)[reply]
Transmitting in UTF-8
(I posted this on the Bot owner's noticeboard too, but I'm not sure if this would be a better place.)
I am having some trouble with UTF-8 encoding with my bot. I am trying to write text to wikipedia that contains UTF-8 characters (pulled from wikipedia in the first place), but am having inconsistent results – some characters are translating properly, whereas others are not (and are coming across as ?'s). All of the characters look proper in my browser on the original page, so it's not a browser issue.
I am using PHP. I tried calling utf8_decode() on the incoming text, and utf8_encode() on the outgoing text, which lead to the condition described above where only some of the characters come across properly. I'm not sure what I'm missing or what I can do to fix it; any help would be greatly appreciated.
For an example of the problem, see this diff. The left side is what it is supposed to look like (manually inserted), and the right is what the bot is putting. Note that while the à (in "U.S. Città di Palermo") is being retained, ā, ō, and ū are turned into ?'s. —Daniel Vandersluis(talk) 15:35, 1 May 2007 (UTC)[reply]
I don't think you want to use those functions as they seem to be limited to characters that can be represented in ISO-8859-1. Here's the description for utf8_decode: "Converts a string with ISO-8859-1 characters encoded with UTF-8 to single-byte ISO-8859-1". Since ā, ō, and ū are not part of ISO-8859-1, utf8_decode is turning them into question marks. Mike Dillon 16:24, 1 May 2007 (UTC)[reply]
You're right. I took those calls out (never used utf8 encoding at all before, so I thought that they might help), and also explicitly added charset=utf-8 to the content-type header and it seems to be working now. Thanks! —Daniel Vandersluis(talk) 16:28, 1 May 2007 (UTC)[reply]
Database Locks
Is it just me or have there been more database locks for the "slave" servers to catch up to the masters than normal? Prior to the past week, I had only experienced one in all my time on Wikipedia. In the last several days, I have been through 3, the last of which lasted over 2 minutes. Is there some sort of technical or hardware problems causing these issues? Cool3 22:31, 1 May 2007 (UTC)[reply]
It's actually an article with an initial space in its name that is categorized, but Mediawiki just quietly strips the space, so the link points to a completely different article. --Derlay 09:14, 2 May 2007 (UTC)[reply]
Looks like the invalid article name was created by a page move: Special:Contributions/Dips_286. Mediawiki seems to handle leading spaces inconsistently; they are mostly stripped, but not in the target of a move, or in links like [7] and [8]. This can be quite confusing. --Derlay 20:46, 2 May 2007 (UTC)[reply]
Please file a bug report, to make sure it gets fixed. --cesarb 00:42, 3 May 2007 (UTC)[reply]
That article should probably be deleted too (the "real" article by that name was deleted earlier). It's essentially unreachable. I would put a {{db-g6}} on it, but then it would categorize into the speedy deletion category the same way. Mr.Z-mantalk¢ 00:00, 4 May 2007 (UTC)[reply]
Actually, don't delete it yet (It's an example on the bug report. (bug:9870) Mr.Z-mantalk¢ 00:20, 4 May 2007 (UTC)[reply]
Bug is now fixed; I'm running a bad-title check in the background which should fix up the page to be reachable. --brion 21:17, 4 May 2007 (UTC)[reply]
dontcountme=s?
Does anybody know why and where the "dontcountme=s" parameter for MediaWiki's index.php originated and what, if any, use it had (or has). This parameter can be found in many installation codes for user scripts, as in:
I've also wondered about this... GracenotesT § 03:40, 2 May 2007 (UTC)[reply]
I would guess it has something to do with access log processing for statistics and that it has always ignored by the MediaWiki software itself. Mike Dillon 05:53, 2 May 2007 (UTC)[reply]
Well "common selse" would suggest that it relates to MediaWiki's hit counting feature. I can't speak to wheter or not it actualy has any effect in the current MediaWiki version. I know hit counting is disabled on the English Wikipedia and probably most other MediaWiki projects for performance reasons so around here it defenently doesn't do anyting regardles. The way it's used would suggest the intention was to avoid having stylesheet and javascript pages like MediaWiki:Common.css or MediaWiki:Common.js show up as the most viewed pages on the site. People have then just copied the syntax used to load those pages when they created theyr own user css and js pages, but I'm pretty sure it can safely be done away with seeing as the hit counting mechanism is turned off anyway. --Sherool(talk) 06:33, 2 May 2007 (UTC)[reply]
It was a hack for webalizer, which considered all URLs ending in "s" to be JavaScript or CSS and therefore uncountable. Of course we haven't used webalizer for a few of years now. -- Tim Starling 11:08, 2 May 2007 (UTC)[reply]
Just to make sure: we can remove dontcountme=s from our script now, right? (And also from importScript() in MediaWiki:Common.js) — Alex Smotrov 13:27, 2 May 2007 (UTC)[reply]
Nobody can help you unless you provide more information, such as the actual error message. --Deskana(fry that thing!) 14:21, 2 May 2007 (UTC)[reply]
It just comes up with a "this page cannot be displayed" error: I think it could be to do with the large file size.--h i ss p a c er e s e a r c h 14:27, 2 May 2007 (UTC)[reply]
Is there an official guideline/recommendation for the use of class="wikitable"?
Hi,
I am wondering whether class="wikitable" is to be prefered over other table layouts. I find that there are way to many lines in wikitable, but maybe there is some rationale behind this? Please see http://en.wikipedia.org/wiki/User:Jasy_jatere/Sinhala_tables for examples of what I mean Jasy jatere 13:33, 2 May 2007 (UTC)[reply]
The second is much better. Use wikitable when it looks good to use wikitable. — Omegatron 13:37, 2 May 2007 (UTC)[reply]
Wikitable is preferable in general, although there are always exceptions to the rule. Feel free to convert tables in articles to wikitable style if they're otherwise plain - they'll look better that way. Nihiltres(t.c.s) 15:41, 2 May 2007 (UTC)[reply]
This example of sections generates incorrectly formatted TOC: the last H3 does not have enough indent from the left. In HTML this means that <ul> tag is closed too early on preceding H2.
It looks like a Mediawiki bug to me. Or did I miss something? — Alex Smotrov 15:02, 2 May 2007 (UTC)[reply]
I'm editing with FireFox, Windows XP, and agree - it looks like a bug (I pasted your six headings above the heading for this section, then did a preview; the final heading (2.1) should be indented in the TOC (like 1.1) and isn't. Odd. Definitely something the developers should look at. -- John Broughton(♫♫) 17:35, 2 May 2007 (UTC)[reply]
Yes I just came here to file a similar report (wished I'd checked, could have saved myself a lot of time). Someone should definitely file a bug report. Paul August☎ 22:24, 2 May 2007 (UTC)[reply]
Update: I think it might be this problem [9]. Paul August☎ 22:29, 2 May 2007 (UTC)[reply]
We will see it fixed when Mediawiki software on Wikipedia servers gets updated. The bug says fixed in r21814, Special:Version shows only 'r21778'. Let's try to relax and do something else for now ;) Alex Smotrov 23:58, 2 May 2007 (UTC)[reply]
Relaxing is fine; in the meantime, it's very hard to get anything done at WP:FAR, with the TOC in complete disarray, and the backlog increases. Can anyone inform us of the next step needed to get this addressed ? This isn't territory I normally deal with. SandyGeorgia (Talk) 16:45, 3 May 2007 (UTC)[reply]
Strange TOC bug?
Just did some editing to Los Angeles Police Department, and cant figure out why the TOC wont collapse fully, instead in hide mode it hides the first main header only. The page's infobox appears to be working normally. -Stevertigo 09:36, 3 May 2007 (UTC)[reply]
I too ran into this bug since the weekend: if there is a subsubsection heading in the TOC, it won't "hide" sections after that one properly but will only partially collapse the sections which preceded it. — Athaenara 10:11, 3 May 2007 (UTC)[reply]
Yeah, just ran into this one on YouTube as well. Probably the same thing as this, which apparently should be fixed soon. WarpstarRider 10:22, 3 May 2007 (UTC)[reply]
I think this occurs when there is a ===subsection=== heading which follows a ====subsubsection==== heading, and I've been able to duplicate it. I almost copied my test here but then realised what it would do to the TOC for the entire page. — Athaenara 10:28, 3 May 2007 (UTC)[reply]
If anyone is following or working on this, I removed the level 4 headings from one FAR review, and this semi-corrected the TOC, although now there's a new error at the TOC in WP:FAR. SandyGeorgia (Talk) 19:07, 4 May 2007 (UTC)[reply]
I wrote one, but I haven't maintained it for ages and it's got very out of date, and I have no idea how portable it is. If anyone technically-minded wants to update it, it's at User:ais523/autotag.js. However, I wouldn't recommend using it in its current state. --ais523 15:56, 2 May 2007 (UTC)
Did you remember to bypass your cache? (The script is very outdated; some of the warnings listed there are redlinks nowadays, for instance.) --ais523 16:44, 2 May 2007 (UTC)
Yay!!!!!!!!!!!!! I fried it!!!!!!!! --Pupster210 20:02, 2 May 2007 (UTC)[reply]
making Wikipedia more user-friendly
Anyone know whether the wikipedia code can be changed so that (1) when you open the homepage, the blinking cursor is automatically located in the "search" box (since 99.9% of the users will have to take their hands off the keyboard, put their hand on the mouse, move the cursor to the box, click the box, and then put their hands back on the keyboard), (2) you can use keystrokes to find text within a page (i.e., use Alt+Edit+Find; ctrl-Find works, but the Alt pull-down menus don't work)?
The two are connected, in fact. In the browser you're using, Alt-menus aren't working because your browser's using Alt-key combinations for keyboard shortcuts; see Wikipedia:Keyboard shortcuts. So for instance, you can jump to the 'search' box by pressing Alt-Fm without having to take your hands off the keyboard. The reason the cursor isn't in the search box by default is that users expect the 'up' and 'down' keys to scroll a page, and they won't when the cursor's in the search box. You could use the multilanguage search page, http://www.wikipedia.org, instead, where the cursor is in the search box by default, as there's no info to scroll through. Hope that helps! --ais523 17:48, 2 May 2007 (UTC)
It will crash IE. --Pupster210 20:01, 2 May 2007 (UTC)[reply]
Just do it yourself, turning off javascript in your settings. Prodegotalk 20:03, 2 May 2007 (UTC)[reply]
Settings restricted here at school. --Pupster210 20:05, 2 May 2007 (UTC)[reply]
I'm sorry you're having trouble with your monobook, but I just don't think any of these scripts are going to work in an IE based browser, at least not without a lot of bugs--VectorPotentialTalk 20:32, 2 May 2007 (UTC)[reply]
I think that in order or use most javascript codes on WIkipedia you will need Firefox. The code I use for warnings is WP:TWINKLE. -- Hdt83Chat 23:50, 2 May 2007 (UTC)[reply]
That will only work in Firefox. I (think I) know that popups works in IE for vandal reversion, but it's not as elegant. GracenotesT § 13:59, 4 May 2007 (UTC)[reply]
strange bug
This happens in Firefox but not IE.
Go to Wikipedia. Don't log in. Go to WP:FAR (or WP:FAC or WP:GAC). Try to use the page down or arrow keys. They don't work. Go to the Main page. They work. Go back to WP:FAR. They work. --Wclib 21:57, 2 May 2007 (UTC)[reply]
Same here. Arrows work fine for me on both pages.Tugbug 23:45, 2 May 2007 (UTC)[reply]
Firefox has a known bug where it can lose track of the keyboard focus sometimes. Clicking on the page usually fixes it. --cesarb 00:33, 3 May 2007 (UTC)[reply]
Wiki skin change?
Has there been some higher-than-user-level Wikipedia:Skin change of page background colours in the past few days?
When I first saw this about 48 hours ago, I thought it was because of a new hard disk and Mac OS X 10.4.6 and Safari 2.0.3 installs on my own computer, but colour changes appeared only on Wikipedia (including MediaWiki) pages while off-Wiki webpages (google, etc.) continue to display normally.
Anomaly: page margin, Table of contents background, quoteboxes background, the categories box, "Save page" "Show preview" "Show changes" buttons and small "This is a minor edit" and "Watch this page" checkboxes below page edit areas are now pale pink, while the background of the main portion of any Wikipedia page is now ice blue.
I can corroborate the font problem (but not the other problem with the strange background colors). I've tested the page linked above (the one with the font table) on three browsers - Safari, Firefox, and Internet Explorer 5.2 (mac) - only around 1/3 of the fonts display correctly. Most of the others show up as san serif (looks like Verdana) and a few of them show up as a serif font (I think it's New Times). The text of the code on that page seems to correctly define the font names, but they are not showing up properly when rendered. Parzival418Hello 08:23, 3 May 2007 (UTC)[reply]
No, bypassing or emptying my cache does not affect this. I've tested it on two computers and multiple browsers, same result. They are all Macs, though, I don't have a Windows machine.
I also tested the &action=purge method of requesting re-rendering of the page. Also, no change to the problem.
What happens if you view the table with a skin other than Monobook? (For instance, [10]). --ais523 08:53, 3 May 2007 (UTC)
I can't answer the larger question about monobook, but I can tell you my own monobook.css page is empty and always has been. I looked at ais523's link and saw the same examples not displaying the fonts they'd been formatted to display. Purge: no change. Bypass your cache: no change. I've emptied my own browser cache daily (as usual) this week: no change. — Athaenara 09:21, 3 May 2007 (UTC)[reply]
I've been looking through what's effectively Recent Changes for the software. There were no changes connected to the skin 'about 48 hours ago' that weren't reverted almost immediately, but it's possible that there was a typo in some code elsewhere that's causing this. (Sometimes, extra whitespace is left at one end of a file; for reasons I don't understand, this sometimes corrupts the data that the servers send out, causing it to display in 'quirks mode' and interpreting the page differently, if I remember correctly, although I've never checked this myself.) What happens if you load up the page in Firefox, and then type 'javascript:' in the URL? (It opens a box explaining errors and warnings that came up on the page; the only expected one would be about 'column-count'; anything else may be what's causing the problem.) (By the way, thanks for the info so far, it's really helping to narrow this down. I see no problem on IE6 for Windows, by the way.) --ais523 09:28, 3 May 2007 (UTC)
OK, I checked the javacript in Firefox, I'll paste the resulting text below. I have to sign off for tonight and will check in tomorrow. Please let me know if you need me to check anything else. Thanks for your help. --Parzival418Hello 09:38, 3 May 2007 (UTC)[reply]
Error: Warning: unrecognized command line flag -psn_0_54788097
I'm not quite sure what's going on here. I'll take a look at it myself later (I have to go offline for a bit too, not sure if it'll be minutes or hours). --ais523 09:55, 3 May 2007 (UTC)
Identically with these seven skins, all but the same few examples do not display as formatted when I view them. The twelve exceptions: Arial Black, Arial Narrow, Arial Rounded MT Bold, Brush Script MT, Comic Sans MS, Courier New, Georgia, Gill Sans MT, Impact, Times New Roman, Trebuchet MS, Webdings. — Athaenara 10:07, 3 May 2007 (UTC)[reply]
The fonts which end with numbers don't work for me either (they all produce error messages on the JavaScript error console), using Firefox on Windows, but all the rest work, so this seems to be Mac-specific. I still have no idea what's causing it. (Are the fonts you can't see installed on your system? There seems to be nothing in the source that would suggest one skin over another.) --ais523 10:32, 3 May 2007 (UTC)
Edwardian Script ITC was the one which first caught my attention, because I'd used it for my sig since last year. It was never installed on my computer but always (until this week) displayed as it should. — Athaenara 10:40, 3 May 2007 (UTC)[reply]
On my system, around half of the fonts are installed - but that's only explaining part of the issue. Of the fonts not displaying properly, some of them are not installed, so that makes sense. But of the fonts I do have installed on my system, only around half the ones in the list display properly. For example I have all three webdings fonts installed and working fine, however on the Wiki page listing the fonts, all three webdings examples show up as if they were all using the basic webdings fonts. Webdings 2 and 3 show the same list of symbols, even though those symbols only exist in basic webdings and all three are installed. Very confusing!
Here's another strange thing - on my system the font Athaenara mentioned as a problem, Edwardian Script ITC, is displaying correctly on that chart. --Parzival418Hello 17:14, 3 May 2007 (UTC)[reply]
I tried to fix it by quoting everything; it probably would make a difference only in the ones which end in numbers. I cannot test it, however; looks like I have none of the fonts on that table installed on any of my computers (the table doesn't include fonts like Bitstream Vera or DejaVu, which I do have installed). --cesarb 23:36, 3 May 2007 (UTC)[reply]
Thanks for giving that a try. The quoting did not make a difference on my system. This has not been a problem in general using Wikipedia, though it is kind of strange, especially since it happens only in MediaWiki software but regualr HTML pages are displaying fine. I can't think of any other tests I can do, so unless you have further questions for me I guess I'll just let this go for now. If you do have questions, I'm willing to do some more tests, but please let me know on my talk page, I need to un-watch this page for a while. Thanks again. --Parzival418Hello 18:11, 4 May 2007 (UTC)[reply]
"What links here"
Hey guys - Sorry to bother you but I wish to know what order the articles are in the "What links here" option.--PhilltalkEdits 12:22, 3 May 2007 (UTC)[reply]
They aren't ordered. There must be something that determines the order, but it's based on number of links, time of addition, phase of the moon... So it's effectively completely random. -Amarkovmoo! 13:46, 3 May 2007 (UTC)[reply]
Okay. Everyone knows that their personal menu (which includes a link to their user page, talk page, their preferences, watchlist, and stuff) is supposed to be aligned right at the top, opposite to the Wikipedia logo button, right?
Well, today, at the time of this addition, whenever I roll my mouse over it, it gets messed up by aligning itself to the left side, hiding the userpage button behind the logo. Is there any reason (aside from either the school server's or the Wikipedia server's allergies to me) that this happens? 8o8 TToTT
'Tis random allergies. I've never found a cause for it. Close the browser and open it again; it should work. -Amarkovmoo! 13:44, 3 May 2007 (UTC)[reply]
Okay, but if it doesn't work than I'm yelling at you. Chef Clover 14:10, 3 May 2007 (UTC) MyTalk[reply]
Is there any way to display an archived version of an image? Any way at all? (I don't mind how wordy the code gets.) Thanks.--Pharos 14:25, 3 May 2007 (UTC)[reply]
On the image page, just click the time and date of the revision you want in the file history section on the image description page. Harryboyles 14:31, 3 May 2007 (UTC)[reply]
Let me clarify. I mean, is there any way to display an archived image inline on an article page?--Pharos 14:34, 3 May 2007 (UTC)[reply]
It's disabled on this Wiki, see here. Matthew 14:42, 3 May 2007 (UTC)[reply]
It wasn't my desire to link to display an external image per se, but rather an archived image on our servers (really, just I want to link to a 'stable' version of an image). I don't suppose there's any way around that?--Pharos 15:05, 3 May 2007 (UTC)[reply]
Not as far as I'm aware. Otherwise there'd be no point to the whole image version system. You can't display inline an old version of an image. --Deskana(fry that thing!) 00:51, 4 May 2007 (UTC)[reply]
The other day I was thinking this would be an excellent idea. The graphics lab and featured picture candidates frequently need to show two versions of an image with minor differences between, just so the edit can be discussed and reviewed. The way these groups do this now is to create completely separate filenames, which seems pretty unwiki, insofar as we usually use the built-in versioning system to collaborate on small changes, except for this one odd area. I also hope this is a new feature that can be implemented at some point. --Interiot 01:19, 4 May 2007 (UTC)[reply]
Yeah, for what it's worth I was looking into this to try to simplify the process of protecting MainPage images, which can be quite a chore right now with downloading and uploading images from Commons. Well, I guess there are no magic shortcuts, then. Oh well.--Pharos 05:58, 4 May 2007 (UTC)[reply]
There is one magic shortcut... sitewide css (or js). You can set any URL (even old images) as a background image on an element with MediaWiki:Common.css. This has a bit of a caching issue though (unless you plan about a day ahead). --Splarka (rant) 07:57, 4 May 2007 (UTC)[reply]
Is the solution at WP:AOL still working? Also, is/was 209.x.x.x an AOL range? -- NORTHtalk 22:44, 3 May 2007 (UTC)[reply]
It's hard to say without more numbers there, there's no way to do a WHOIS search without the first 6 digits. And as far as I know, yes, the AOL fix, is still in effect, the only edits that should be coming from AOL should be from the normal dynamic IP pool, not from any of the proxy ranges, as A) They're all still blocked from editing anyway, and B) AOL sends X-Forwarded-For headers on all but the oldest AOL installations, so there shouldn't be any activity from those ranges anyway--VectorPotentialTalk 23:41, 3 May 2007 (UTC)[reply]
Defiantly not registered to AOL, you'll find that IPvandal is a useful template for this sort of thing--VectorPotentialTalk 23:55, 3 May 2007 (UTC)[reply]
To be specific:
IP: 209.244.30.231
Location: United States [City: Philadelphia, Pennsylvania]
OrgName: Level 3 Communications, Inc.
OrgID: LVLT
Address: 1025 Eldorado Blvd.
City: Broomfield
StateProv: CO
PostalCode: 80021
Country: US
HOW TO TURN A STUB INTO AN ASSESSED ARTICLE? I can't figure out how to do this. I turned a a stub on the Victorian Church architect Thomas Garner into an article (using historical documents recently found). It remains a stub - what is the next step please? Thanks May 2. Keoghse 05:28, 4 May 2007 (UTC)[reply]
Thomas Garner doesn't seem to have a {{stub}} template anywhere, and as far as I can tell it's also a good length, I don't think it is a stub--VectorPotentialTalk 13:19, 4 May 2007 (UTC)[reply]
If you're talking about the assessment in the banner on the article's talk page, that is changed by hand based on an editor's best judgement. Just change {{Architecture|class=Stub|auto=yes}} to {{Architecture|class=Start|auto=yes}}, or whatever class you think is appropriate. WikiProject Architecture's assessment guidelines are located at Wikipedia:WikiProject Architecture/Assessment, you can also make a request on that page for someone else to assess the Thomas Garner article, if you want. jwillburtalk 16:36, 4 May 2007 (UTC)[reply]
TOC Indent issue
In Virginia Tech massacre the TOC seems to only indent the first header's subheadings. In all the other header's sub-headers in the table are not indented.
Thanks, Monkeyblue 10:39, 4 May 2007 (UTC)[reply]
Resolved
