Hosta

This page is automatically archived by Werdnabot. Any sections older than 7 days are automatically archived to Wikipedia:Village pump (technical)/Archive. Sections without timestamps are not archived.

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.

Got my own wiki set up =)

Except I've noticed that other wikis like our very own and Memory Alpha both don't have the "Main Page" header at the very top... how can I replicate this on my own wiki for my main page?

Thanks in advance! :)
Kareeser|^Talk! 22:27, 6 February 2007 (UTC)[reply]

These might help: m:Customize page layout, m:Layout customization, MW:Help:FAQ#How do I change the main page?. --Teratornis 23:15, 6 February 2007 (UTC)[reply]

Look at the top of MediaWiki:Monobook.css. —Ruud 23:51, 6 February 2007 (UTC)[reply]

Thanks to both Teratornis and Rudd... however, now that I know what I'm looking for, I can't find a monobook.css file in my own wiki... sorry for all the seemingly obvious questions >< Kareeser|^Talk! 00:03, 7 February 2007 (UTC)[reply]

It's located at MediaWiki:Monobook.css on your wiki as well, though it might not exist yet. Just start a new page (only admins can do that, though.) —Ruud 00:26, 7 February 2007 (UTC)[reply]

Finally got the hang of it... after a week... turns out I had to modify common.css instead :) Thanks for all your help! Kareeser|^Talk! 20:09, 10 February 2007 (UTC)[reply]

I was wondering if it would be possible to make the semiprotection notice when you go to edit or view the source of a semiprotected page be made more prominent and provide more information (when you do not have enough access to edit a page, a "view source" tab appears instead of the "edit" tab). The current notice on the "edit" tab is, "Note: This page has been semi-protected so that only established users can edit it." The notice on the view source tab is at the bottom of this post. In addition to being more prominent, I think that it should have the same information that is on {{sprotected}}. This would allow us to do away with the semiprotection notices on articles. The template puts the article in a category as well as notifying readers, but the template could be modified so that it just puts the article in a category.

I think that this would be a wonderful change. The semiprotection notice currently blemishes many otherwise excellent articles. In addition, for a significant number of articles, the semiprotection is permanent. It is not necessary for readers of the article to know whether an article is semiprotected or not. Editors can easily tell that they are unable to edit an article by the lack of an "edit" tab and the presence of the "view source" tab. If that is not enough, perhaps another tab should be put on protected articles. It could be called "protection" or something similar and it could give all of the information needed. Another option would be to have an easy to recognize symbol that an article is protected, such as a padlock. Clicking on the symbol would send you to a page with the information. The symbol should be at the top of the page, like the tabs are, not inside the article.

Notice on the view source tab:

This page is either protected or semi-protected.

• If the page is fully protected, only administrators can edit it; if it is semi-protected, only established registered users can edit it.
• Why some pages are protected
• Discuss this page with others or request unprotection
• You may sign in if you have not done so already

You can view and copy the source of this page:

Kjkolb 20:44, 9 February 2007 (UTC)[reply]

It is easy to do, MediaWiki:Semiprotectedpagewarning just needs to be edited. But you will need to suggest exactly what you want it to say, and gain consensus for that version, before an admin will change it. Prodego ^talk 04:04, 10 February 2007 (UTC)[reply]

I suppose that I could change it myself after I gain consensus, as an admin. ;-) Thanks for posting about how it is done. I never know what things are editable like that and what requires a developer. As for the exact form, I guess making it the same as the {{sprotected}} template would work (the template is what is in the box only, the rest is usage information). So, is anyone for or against making this change? I'll post notes on the Village Pump policy page and the semiprotection policy talk page. -- Kjkolb 04:51, 10 February 2007 (UTC)[reply]

I'm in favour of doing away with the "view source" tab, which is unhelpful and confusing to new editors. Users should see an "edit this page" tab on every page, even if it's not possible for that particular user to edit the page (it would of course be explained, when they click the tab, why they can't edit that page). As Wikipedia is supposed to be "the free encyclopedia that anyone can edit", newbie editors need to be told which pages have editing restrictions and more importantly why they have those restrictions.

As for the {{sprotected}} warning - if the objection here is that the warning is ugly and "blemishes" articles, then it could be made smaller and less obtrusive. There are undoubtedly more elegant ways to display such warnings, but I'm opposed to anything which hides the fact that the page is protected. For the sake of being open and helpful to newcomers, a page's protection status should be prominently displayed, not hidden away. You are correct to say that readers do not need such warnings - but editors do, and editors tend to start out as readers (perhaps not at first realising that the wiki can be edited).

Incidentally, I've come across a number of semi-protected articles which lack {{sprotected}}/{{sprotected2}} tags and which provide no reason for the semi-protection in the talk page or edit history. If this is deliberate, it is a worrying trend. I will always add {{sprotected}} to such an article whenever I find one. AdorableRuffian 16:04, 10 February 2007 (UTC)[reply]

In particular, with the addition of auto-expiring page protection, the more automated our protection notices are, then probably the better. I've seen proposals for a MediaWiki message to be displayed, in the place of templates like {{sprotect}} and the like -- would save us all time adding the templates, with the added bonus of avoiding manual removal of {{tprotected}} and such. – Luna Santin (talk) 07:31, 12 February 2007 (UTC)[reply]

For MediaWiki:Semiprotectedpagewarning, it could be very helpful to add "If you cannot edit this page, you can still suggest improvements to the article on its talk page", where "on its talk page" is a wikilink to the article's talk page. -- John Broughton (♫♫) 14:30, 12 February 2007 (UTC)[reply]

As often happens, I forgot about this discussion because there are so many to keep track of. Anyway, in response to AdorableRuffian, I strongly disagree with keeping the notice so prominent, and therefore necessarily unsightly, because some articles are to be permanently semiprotected. If it were temporary, it would not be nearly so bad. That is why I have no objection to cleanup, wikify and similar templates. To have such an unsightly template on a well written article is crazy to me.

There is now an image of a padlock that links to the semiprotection policy on pages that are semiprotected (I do not know how long it has been there). I do not see what is wrong with just having that image as notice, as well as an explanation when someone clicks on the "view source"/"edit this page" tab (the explanation could be what is currently in the notice template). The padlock image could be made larger, if necessary. Alternatively or in addition to making the image larger, text could be placed next to the padlock, perhaps something like "semiprotected". -- Kjkolb 05:59, 19 February 2007 (UTC)[reply]

My mistake. The padlock is an alternative template for the semiprotection notice. Therefore, it appears that this situation has been dealt with. -- Kjkolb 06:09, 19 February 2007 (UTC)[reply]

Having an automatic notice at the top of each protected page would be trivial to implement. However, in my opinion, any message at the top of every protected page is highly undesirable; as such I don't intend to implement such a notice. I don't know how other developers feel about it, but I vaguely remember having a discussion about it a few months ago in one of the tech IRC channelsWikipedia:Requests for arbitration/The need for the existence of #mediawiki? and I'm not the only developer to have this view. — Werdna talk 06:14, 22 February 2007 (UTC)[reply]

pl anybody help with with adding assment rating to the Template:Wp pakistan templete. User talk:Yousaf465

Admins, take a look at Special:Undelete/Help talk:Starting a new page/w/index.php. Some anon managed to edit the page after it had been deleted to enable cascading protection. (Compare timestamp of last deleted revision with the time of David Levy's deletion.) I've no idea whether it's a problem with the {{protected title}} template which is used to transclude the deleted page, or even cascading protection itself. Awyong Jeffrey Mordecai Salleh 06:44, 15 February 2007 (UTC)[reply]

I'm not an admin so I can't see the deleted revision you're referring to but I think the problem is because the template uses the #ifexist: ParserFunction which is not updated immediately upon deletion. Therefore, the cascading protection only comes in a short delay after the page is deleted. Tra (Talk) 13:22, 15 February 2007 (UTC)[reply]

I don't get it... when I add the deleted page into WP:PT, the notice that "this page is protected" will appear when I try to edit it just minutes later. How would that fit in with your reply? Awyong Jeffrey Mordecai Salleh 15:24, 15 February 2007 (UTC)[reply]

I just managed to create User talk:Skysmith/w/index.php, a page on the list. Upon purging the cache of the protected page list, I could no longer edit it. Someone with knowledge of how cascading protection is implemented could probably explain exactly what needs to be done to trigger protection. --- RockMFR 15:28, 15 February 2007 (UTC)[reply]

This is an educated guess, but I think that if the page is transcluded to PT first, then deleted, it won't be protected until next time PT is edited or purged, because otherwise PT's transclusion list won't be updated due to the ifexist. --ais523 18:07, 15 February 2007 (UTC)

I don't think that the "ifexist" element is the culprit. The template is designed to transclude the page if it doesn't exist (and display a message and deletion link if it does), and I'm certain that the transclusions began immediately upon the pages' deletion (meaning that the "ifexist" detection was functioning properly).

The problem appears to stem from a minor bug in the cascading protection feature, which causes it to work with deleted pages only when the deletion occurs before the cascading protection is applied or when the protected page's cache is purged. I'll add "purge" links and instructions to the PT pages. —David Levy 18:37, 15 February 2007 (UTC)[reply]

Eh, cascading protection uses the templatelinks table, which is updated when the source page is edited. It's not really something I'd be willing to fix, seeing as it's a very obscure edge case that would result in non-trivial performance trade-offs. — Werdna talk 06:19, 22 February 2007 (UTC)[reply]

Hi folks -

I tried to fix the vandalized page for the featured article (on Sly & TFS)... but it looks OK on the edit page.

Sorry if this is a FAQ, but could someone jump in and fix it & lock it temporarily?

THX -

-CC

Hello,

I'm wondering if there are any plans to integrate geographical coordinate information with Wikipedia entries.

I ask this b/c I would love to have my GPS receiver tell me all of the things that have a Wikipedia entry as I drive past them, so that I can pull over and look up the article if I want (in my case I'd use my blackberry for this, but soon more PDAs will have built in GPS, etc.)

I know there is a microformat (Geo) designed to do inline lat/long coordinates. So one option would be to simply create a wiki formatting style for coordinates to allow article editors to add them to places, etc.

However the use case that I'm imagining is that someone would want to download lat/long/article information for a given geographical area, such as California, the Southwest US, or Paris, for example...

So it might make sense to tag an article in the database with coordinates so that someone could easily search for all entries with coordinates between four points.

I'm a programmer and would gladly submit a patch to enable this, but I wanted to get an idea of whether anything like this is already in progress or if there are any constraints or concerns I should be aware of.

-matt

Mmmurf 19:35, 18 February 2007 (UTC)[reply]

The semantic extension of the media wiki software will have this feature. See the experimental installation of this at Ontoworld. This page on sugarloaf mountain has coordinates - [[1]] 81.187.181.168 16:59, 24 February 2007 (UTC).[reply]

Selecting the "printable version" link of the article http://en.wikipedia.org/w/index.php?title=Aloe_vera&printable=yes, then doing a print preview, locks up Firefox 2.0.0.1 and SeaMonkey 1.1a. Works OK with IE 7.0.5730.11. Print preview on other articles' printable version works fine. MeekMark 22:17, 19 February 2007 (UTC)[reply]

Worked fine for me (using Firefox and Safari). John Reaves (talk) 23:22, 20 February 2007 (UTC)[reply]

Whenever I leave the site, I am automatically logged out despite the fact that I have "remembered my password" checked. This has started happening even when I don'tthe site too. This has never happened to me before. (I'm using Firefox and a Mac.) Any ideas as to why? John Reaves (talk) 01:59, 20 February 2007 (UTC)[reply]

My guess would be that some automated security thing you have deletes cookies once you leave a site, to prevent tracking cookies. -Amarkov moo! 02:08, 20 February 2007 (UTC)[reply]

Any ideas as to how I could reinstate the cookies? John Reaves (talk) 02:24, 20 February 2007 (UTC)[reply]

I'm having the same problem too, but I have checked my cookies and bypassed caches. I am also a Firefox user, it just started happening now. Philip Gronowski ^Contribs 02:42, 20 February 2007 (UTC)[reply]

There's definitely something going on. My guess is the developers know about it. If it doesn't clear up in a few hours I'll be shocked. -- Rick Block (talk) 03:53, 20 February 2007 (UTC)[reply]

For me it only happens at the Main Page and its talk page. If I purge my cache it reloads with me logged in, but if I reload the page it goes back to being logged out. Weird. - Trevor MacInnis (Contribs) 04:41, 20 February 2007 (UTC)[reply]

It's been happening to me too. I don't even have to leave the site; browsing from one page to another sees me getting logged out (and then back in without logging in). ShadowHalo 05:14, 20 February 2007 (UTC)[reply]

I don't have such a problem. A Firefox bug, perhaps? Yuser31415 06:09, 20 February 2007 (UTC)[reply]

There was a bug affecting caching for a few hours tonight; it should be fixed now, though it's possible some lingering pages remain in cache. Purge pages as necessary if it still crops up from time to time. --brion 07:44, 20 February 2007 (UTC)[reply]

Confirmed that bad cache entries are still around. :( They're harmless, though, just kind of annoying. :) --brion 08:20, 20 February 2007 (UTC)[reply]

Have you updated Firefox? I've heard of Mac/Firefox having a different problem, and the latest stable version might be poorly named... EVula // talk // ☯ // 20:19, 20 February 2007 (UTC)[reply]

It's nothing to do with Firefox. --brion 21:08, 20 February 2007 (UTC)[reply]

Correct. I'm using IE7 and if I go to David Weber or Wikipedia:Esperanza, I get logged out. –Llama man 01:34, 21 February 2007 (UTC)[reply]

I've been using IE7 and the issue is just about resolved now, though there has been an occasional page where it still happens. ShadowHalo 02:39, 21 February 2007 (UTC)[reply]

Would it be possible to add a feature that allows non-admins to delete and restore pages in their own userspace? This would bypass having to add more pages to the backlog of speedy deletion candidates to get a subpage deleted. Talk pages might need to be exempt to prevent malicious deletions. John Reaves (talk) 10:24, 20 February 2007 (UTC)[reply]

Anyting is possible, but I suspect such a feature request would not be given very high priority, since it would probably involve a fairly substantial rewrite on how the delete access is handeled (currently you can either delete everyting or nothing at all, no way to filter by namespace, let alone spesific subpages) for very little gain (it's not like deletion of user subpages is the biggest cause of backlog at CSD). --Sherool (talk) 10:56, 20 February 2007 (UTC)[reply]

Then you could delete any page that's not move-protected. So.... I'm gonna say no on that one? :) --brion 18:13, 20 February 2007 (UTC)[reply]

Explanation: users can move pages to under their user space (this is called "userfying" in wikipedia slang). So if this would be implemented, John could move Earth to User:John Reaves/XXX and zap that page together with its complete history. A good reminder for admins to look at the history of pages before deleting them... --Ligulem 18:43, 20 February 2007 (UTC)[reply]

Just leave it simple. I'm sure the admins don't mind :P. Yuser31415 19:30, 20 February 2007 (UTC)[reply]

Okay, thanks for the feedback. I should have thought that one through a little bit. That's the last time I propose anything at 5:00 am. John Reaves (talk) 20:13, 20 February 2007 (UTC)[reply]

It would be interesting to get feedback from admins as to how much of their time is spent doing speedy deletes in user space. Lingulem has pointed out a flaw in the original proposal; the solution (which makes the proposal more complicated) would be to only allow users to delete pages where 100% of the edits were done by that user. I suspect that would still be to hard to write into the software.

An alternative would be to give an admin bit to a bot that would do speedy deletes of pages where the db-author tag was in place and the bot confirmed that 100% of the edits were by the same user (ergo, by the user placing the tag). I realize the repulsion that a part of our community has at the thought of an admin bot of any kind; that's why it would be interesting to find out how much admin work such a bot would actually eliminate. -- John Broughton (♫♫) 02:47, 21 February 2007 (UTC)[reply]

Just to be clear: it was Brion who pointed out the problem with John's idea. I just wrote down an example use case (which I hadn't thought of myself when I first read John's idea). Thank you John and Brion for the lesson :-). --Ligulem 08:46, 21 February 2007 (UTC)[reply]

Seems like a waste of developer time to me. We have plenty of other stuff to work on (per-page blocking, title blacklist, tor blocking come to mind as being on my to-do list). This provides very little benefit and would probably take a few full days of developer time to create and perfect, which is about as long as it took me to do my protection rewrite. — Werdna talk 06:22, 22 February 2007 (UTC)[reply]

How about a non-admin bot that checks speedy-deletes to verify whether all edits are by the same user, and marks them as such for admin attention, saving the admin the trouble of doing the checking "manually"? --Coppertwig 04:55, 26 February 2007 (UTC)[reply]

I'm having a technical problem. I asked for help over on Meta but have gotten no responses thus far. I think I messed up my monobook profile or something. Now when I highlight a section while editing it pops up above the edit section area in a blue tinted version. Also it's very hard to highlight a section in order to cut and paste it or delete it, as it always includes other irrelevant paragraphs and pops them up above the edit section box. How do I turn this off? Quadzilla99 13:03, 20 February 2007 (UTC)[reply]

It's caused by Navigation popups; see Wikipedia:Tools/Navigation_popups/FAQ#Popups_appear_in_edit_mode. To disable, put the following in your monobook.js:

popupOnEditSelection=false;

—Xhantar^Talk 19:45, 20 February 2007 (UTC)[reply]

Oh my god, thanks a ton. You have no idea how aggravating that was. It wouldn't be bad except every time you hghlight a section it always includes the surrounding sections that weren't highlighted. Quadzilla99 20:11, 20 February 2007 (UTC)[reply]

When editing an article, I sometimes have to highlight text in the text box. Recently, I noticed that highlighting text in wikilinks (i.e. [[double square brackets]]), the focus is taken away, and the text is echoed just above the text box. What is the purpose of this feature? More importantly, how can I make it stop? It is rather annoying to have the focus repeatedly taken away from what I was editing. --Cheers, Folajimi (leave a note) 21:31, 20 February 2007 (UTC)[reply]

I think its a new feature of popups. If you add

popupOnEditSelection = false;

to your monobook.js it seems to go aways. It could be useful for checking you have got the wikilink correct. --Salix alba (talk) 23:15, 20 February 2007 (UTC)[reply]

Thanks for the tip; it was a wee bit too aggressive for me. --Cheers, Folajimi (leave a note) 19:21, 21 February 2007 (UTC)[reply]

The feature was fantastic before (select a link in edit mode and get a small popup). Now I have to turn it off? Motto: If it ain't broke, don't fix it. --kingboyk 12:22, 24 February 2007 (UTC)[reply]

For me (and this may to some extent be browser dependent), the article British_coin_One_Pound has some layout problems. Between "The reverse designs are as follows" and the text following is a huge piece of vertical white space. I know why this is happening (I think). The ordinary text (terminating at the line "The reverse designs are as follows") can "wrap around" the right hand infobox, and so fit into the space to the left of it. The text after this is a table, which can't. By adjusting the % width of the table until it just fits in the space I can fix the problem. However, this seems an unpleasant ad hoc solution, dependent on the precise measurements of things which may change, or be different in different browsers. What is the correct way to fix this robustly? Thanks, Matt 02:47, 21 February 2007 (UTC).

I removed the width spesification on the table with eliminates the vertical whitespace problem (but will make the table look "squashed" on small screens). If you want to have the text in the table flow around the infobox you have to remove the table though. The entire table is one "layout element" so all of it is "squashed" to fit beside the infobox as long as part of it is next to it. The easiest "fix" would probably be to break the table into lots of small tables (one for each row for example). Then each mini table would be sized independently and the ones that are located beyond the infobox would expand to use all available horizontal space. --Sherool (talk) 09:06, 22 February 2007 (UTC)[reply]

Hi Sherool, thanks for the info. Matt 00:39, 23 February 2007 (UTC).

I've just followed a link from Seamus Heaney to the University of California, only to find that I was apparently no longer logged in; following a further link from the latter article took me to another page which did recognise who I was... I've repeated this a few times, and get the same effect every time. Does anyone else get this effect? If so, what's going on? (If not, the problem would seem to be with me, and I still don't know what's going on, but that's my problem.) --Mel Etitis (Talk) 11:39, 21 February 2007 (UTC)[reply]

WTF?!! I'm still logged in but when I visit that page, but it says I'm not, even when I reload the page. It shows my login when I click "edit" though. Funky... Grandmasterka 12:25, 21 February 2007 (UTC)[reply]

?Don't have that problem. --Van helsing 13:02, 21 February 2007 (UTC)[reply]

The problem is explained at #Constantly being logged out above. To clear the server cache of a page, you can make a null edit, or purge the page (I have a script that can do this), and that easiest way to otherwise do it is to click on the "Edit this page" button, change "action=edit" to "action=purge", and go. Gracenotes^T § 14:21, 21 February 2007 (UTC)[reply]

As stated in the title, all of my settings in common.css (a#new, #personal colour changes, etc...) disappear when mod_rewrite is activated in apache's httpd.conf, even when I don't use the rewriting engine at all. Is this a bug?

I'm using WAMP5 Server 1.6.6

Apache httpd 2.0.59

PHP Version 5.2.0

mySQL version 5.0.27

TIA! Kareeser|^Talk! 14:58, 21 February 2007 (UTC)[reply]

You want mediawiki.org. Mediawiki isn't supported here. --kingboyk 12:20, 24 February 2007 (UTC)[reply]

Can the "Your continued donations keep Wikipedia running! " be moved up onto the line under sign in/create account (-10px?) or over left to the middle (500px?), because it is covering up templates like the help contents back, the semiprotect templates and many others and its really irritating. Thank you, 00:07, 21 February 2007 (UTC)

I suggest asking at Wikipedia:Village pump (technical) - that's where the developers and technical folks hang out. (And please sign your questions by using four tildes, not five - if you sign with five, you leave only a date/time stamp, without a username.) -- John Broughton (♫♫) 02:26, 21 February 2007 (UTC)[reply]

I can confirm that this is a problem for logged-out users; there is no problemn for logged-in users. The problem is that people are using the same space for two different messages. For the time being, you could avoid the problem by creating an account, although I agree that a better solution will need to be found in the long term. --ais523 10:19, 21 February 2007 (UTC)

• Moved from the Help Desk. --Darkest Hour|DarkeBot 16:18, 21 February 2007 (UTC)[reply]

Hi. It seems that the <math> tag does not consistently italicize text which it encloses. For example, compare "" and "". Why is the first one not italicized? This also occurs all the time for single letters like "". I just don't get it. Thanks for any insight. —Dfass 23:45, 21 February 2007 (UTC)[reply]

... It is, on my browser, Firefox 1.5 on Windows XP. What are you using? --Golbez

Firefox 2 on XP. —Dfass 00:31, 22 February 2007 (UTC)[reply]

Interesting! I just tried it on IE7, and it looks OK. Now, I'm really perplexed! Is this a Firefox 2 issue??? Does Wiki generate a different HTML page for different browsers (cause it appears it's not working correctly for Firefox 2)? —Dfass 00:34, 22 February 2007 (UTC)[reply]

Using Firefox 2.0.0.1 on XP here. It's italicised for me... Kareeser|^Talk! 00:39, 22 February 2007 (UTC)[reply]

Unless you've set your preferences otherwise, Wikipedia will render some simple math expressions as HTML, which may display differently from stuff that gets rendered as an image. Zetawoof^(ζ) 00:43, 22 February 2007 (UTC)[reply]

Thanks everyone. I guess I must have something funky with my system. But as long as other people see it correctly, I'm not going to worry about it. Thanks. —Dfass 05:00, 22 February 2007 (UTC)[reply]

I'm getting the same using firefox 1.5. It seems like mediawiki is serving different html code for the two equations one has <span class="texhtml"> and <i> around the equations and the other does not. It looks like a bug to me. --Salix alba (talk) 13:13, 22 February 2007 (UTC)[reply]

Try experimenting with your Special:Preferences (click the Math tab). It seems different code is rendered depending on the "complexity" of the expression. -SpuriousQ (talk) 13:23, 22 February 2007 (UTC)[reply]

Need some help to get Template:ta and template:oa to work right. Here is the syntax we want. Here is the general idea. Im going to give a shot. -Ste|vertigo 10:19, 22 February 2007 (UTC) PS: Wikipedia:Topic archive -SV[reply]

Over the past few days, I've noticed that if I highlight a section of text while editing an article, the text appears (mostly) as it would in the article in a purple box, similar to a preview. When was this feature added and what purpose does it serve that we didn't already have? The box gets rather annoying when I'm trying to cut and paste large sections of text, as it has a tendency to push the edit dialogue off the screen. When it previews the wikicode, it doesn't even display everything correctly. I've had instances where the preview in the purple box is different from the actual preview I get by pushing the preview button, which has always worked just fine for me before. I'm sorry if I'm missing something, but I really don't see the purpose of this highlight code. Hersfold ^(talk/work) 16:28, 22 February 2007 (UTC)[reply]

It's a new feature of navigation popups (one about which there have been many complaints recently). See #Technical editing problem, above, for how you can turn this off. --ais523 16:33, 22 February 2007 (UTC)

Ah, ok. Thanks! Hersfold ^(talk/work) 23:01, 22 February 2007 (UTC)[reply]

i'm doing a little personal research into the types of articles on wikipedia, and have been using Special:Random to get a random sample of pages (and getting a surprising percentage of soccer club articles and small-county-in-minnesota type stubs). i'd just like some confirmation that this feature does, indeed, return a random (or near-random) article.

• obviously it isn't returning user: or wp: or talk: pages. but does it return lists or categories or anything else with a ":" in it? (it appears not to)
• is it skewed towards more recent or older articles?
• is it filtered or censored in any way to avoid freaking out the faint of heart?
• if i understand correctly, once a day (or every hour or once a week; can't find the info now) an indexing bot looks thru all the new articles and makes them searchable, but this isn't instantaneous. does a new article title have to be indexed (or whatever it's called) before it can show up?

to cut to the chase, does every article in the main article space at the instant the button is pushed have an equal chance of being returned? any info is appreciated. thanks much. -barneca 19:36, 22 February 2007 (UTC)[reply]

No, not all articles have an equal chance. We have an index called page_random, which is a random floating point number uniformly distributed between 0 and 1. Special:Random chooses a random floating-point number with 2^-64 quantizaton, and returns the next article with a page_random value higher than the selected random number. Some articles will have a larger gap before them, in the page_random index space, and so will be more likely to be selected. So the actual probability of any given article being selected is in fact itself random, with probability unrelated to age or quality. I seem to remember doing some analysis of the distribution at some time in the past, I've probably got an Excel spreadsheet around somewhere if anyone is interested. -- Tim Starling 20:17, 22 February 2007 (UTC)[reply]

thank you, tim. i guess i'm not as concerned about true randomness as i am about "probability unrelated to age or quality", so that answers my main question. i originally got to thinking about this because i believe (can't be positive, but i really think it happened) that Special:Random sent me to the article Shelob twice in the same week. the odds on that seem astronomical if it is truly random.

if anyone has insight on my other, more minor questions, re: colons and indexing bots, i'd welcome that too. -barneca 20:51, 22 February 2007 (UTC)[reply]

It returns any non-redirect in the main namespace, which is not quite the same as articles with no colon in the title. There are no categories but there will be list pages. See Help:Namespace for more information. Articles can be returned instantly after creation, there is no delay. -- Tim Starling 21:02, 22 February 2007 (UTC)[reply]

thanks again, tim, that's the info i was looking for. if it ever returns Shelob again, i'm immediately going out and buying a lottery ticket, and i'll share the winnings with you. -barneca 21:28, 22 February 2007 (UTC)[reply]

Just a note that Probability is famously misleading to intuition, even among probabilists. If you pick two articles at random from a category that has 10, "with replacement" (what you're doing by clicking "random page"), the chance they are different is 90%, only a 10% chance you'd unluckily get the same article both times. What if you chose 10 articles from 100? The chance they are all different would be about 63%, almost even odds. Wiki has on the order of one million pages. If over the course of two weeks you chose 1000 randomly, what are the chances they would all be distinct? 61%. Hardly any different from picking 10 from 100. I expect you examined fewer than 1000 but getting two the same may not have been so unlucky as it seemed. Also, of course, Shelob is inescapable, unless you happen to have a magical elven dagger handy :-) Pete St.John 22:20, 22 February 2007 (UTC)[reply]

For sortable tables, are there any future plans to allow the use of sort keys? I'm specifically thinking of tables with people's names, where you might want to display "John Smith" but sort by "Smith, John". I posted this question to the meta Help:Sorting talk page a few days ago, with no response. Is there some place where sortable table functionality is being actively discussed? Or should I submit it as a bug report? Jwillbur 22:45, 22 February 2007 (UTC)[reply]

Aha, someone already has submitted it to the bug tracker. Bug 8288: Sortable tables don't properly sort lists of names Jwillbur 01:13, 23 February 2007 (UTC)[reply]

Is a sort key possible? It seems that because the sorting is done client side, it can't use anything that doesn't show up in the normal way in a browser. - Peregrine Fisher 20:50, 23 February 2007 (UTC)[reply]

There could be a hidden field (style.display = 'none') for sorting a visible field. — Randall Bart 17:06, 25 February 2007 (UTC)[reply]

Sbrools was good enough to follow up on my request to replace a fair use map with a "home made" SVG version. However he's having some trouble getting MediaWiki to render thumbnails for the image (Opera at least can render the raw SVG just fine). Can anyone see any obvious problems in Image:Europejews.svg that prevents it from beeing "MediaWiki compatable"? I know next to nothing about SVG syntax and what MediaWiki supports and not, but I guess the standalone="no" bit in the header may be a problem, and if xlink:href="EmancofJews.gif" does anyting (as far as I can tell the map is made up of "path" elements not a embeded gif) I guess that would be a no-no too... Is there a page somewhere that list SVG features you need to avoid to make SVG's work properly under MediaWiki? --Sherool (talk) 08:50, 23 February 2007 (UTC)[reply]

AFAIK Mediawiki does not render SVGs with external references for security reasons - the GIF has to be either removed or embedded in the SVG. --Dapeteばか 10:47, 23 February 2007 (UTC)[reply]

Yeah, removing the xlink bit seems to have done the trick (the GIF is not actualy used, so not a problem). Thanks. --Sherool (talk) 12:52, 23 February 2007 (UTC)[reply]

Things seem to be in different colors now than before a week ago. Also the contrast is very faint (I can't see commas and footnotes etc.) The print seems small and faint. Also I can barely see the bars on the side (to move the page up and down with). I upgraded my Firefox browser to 2.0.0.1. Could that be it? Thanks! --Mattisse 20:32, 23 February 2007 (UTC)[reply]

It looks the same to me. Try anothe browser. - Peregrine Fisher 20:46, 23 February 2007 (UTC)[reply]

I'm using the same IE that I have been using for a while and see no changes. But when I use a different PC with a newer IE, different colors are noticable, so it probably is your browser. Mr.Z-mantalk¢ 20:47, 23 February 2007 (UTC)[reply]

That's what I'm beginning to think too. Just have to get used to it I guess. Thanks! --Mattisse 20:50, 23 February 2007 (UTC)[reply]

How does one categorize articles? Thanks in advance. N734LQ 21:54, 23 February 2007 (UTC)[reply]

See WP:CAT. In general, you just place [[Category:Name of category]] at the bottom of an article.↔NMajdan•talk 21:59, 23 February 2007 (UTC)[reply]

Simply put a category link on the page (by convention these are usualy placed at the end of the page, but technicaly it can be anywhere). For example adding [[Category:Living people]] to a page will add that page to Category:Living people. If you want to link to a category rater than including the page in the category you add a colon at the start of the link like so [[:Category:Living people]]. See Help:Category for more details and info on sorting entries within a category and such. --Sherool (talk) 22:08, 23 February 2007 (UTC)[reply]

The title and tab arrangement on my Sandbox/Page1 looks fine in Firefox, but it's not so good in MS Internet Explorer v6, as can be seen in the images.

Neither problem is a disaster, and the one with "The Title" can be gotten around by reducing the size, but I'm sure there must be a solution. I'd like to get it fixed because the test version in my sandbox is a copy of the one in use on the energy portal. I've tried various ideas, but have reached the stage where assistance would be gratefully received...

Further documentation on this talk page Gralo 23:09, 23 February 2007 (UTC)[reply]

Having resolved the original issues above, one more minor problem has now emerged. In Firefox the "edit" link appears as intended; in IE it doesn't. Probably needs someone who understands CSS to resolve? Gralo 17:22, 25 February 2007 (UTC)[reply]

I want to use CSS hover effects in a navigation template I'm working on. Is there any way to define a CSS class on a wikipedia page? Is there a template or something that would directly let me do hover effects (I'm specifically looking for a change of background color on hover) --froth^T 01:34, 24 February 2007 (UTC)[reply]

You would have to create a site-wide class on MediaWiki:Common.css. That's the only way I know of. Titoxd^(?!?) 02:45, 25 February 2007 (UTC)[reply]

In CSS3 you can do it with inline style I believe, but unfortunately that's not here yet, so as Titoxd said only mediawiki:Common.css (Or special:mypage/monobook.css if its for yourself). Bawolff 03:05, 26 February 2007 (UTC)[reply]

I have recently made some editing to the above mentioned article on Wikipedia.

However after having saved such changes they were temporarily made visible but then when I checked the following day they were gone.

Why has this happened?

Thank You —The preceding unsigned comment was added by 88.203.67.110 (talk) 13:05, 24 February 2007 (UTC).[reply]

Check the "history" tab - next to the edit tab. when I look at this it does show edits being deleted or reverted recently so it may be that what you saw was a the preview and you didn't then "save page". Hope this helps. —The preceding unsigned comment was added by 81.187.181.168 (talk) 17:18, 24 February 2007 (UTC).[reply]

Hi, I'm following up on a recent checkuser result but seem unable to create Category:Wikipedia sockpuppets of Somethingoranother. Is creating such categories restricted in some way? WjBscribe 14:24, 24 February 2007 (UTC)[reply]

Done. You couldn't do it because you tried to create a category with a null edit, which is not allowed. — Ambuj Saxena (☎) 16:48, 24 February 2007 (UTC):[reply]

Thanks for clearing that up. WjBscribe 17:06, 24 February 2007 (UTC)[reply]

It was a positive step to add icons next to media files showing their type (eg. audio), without having to click or hovering mouse over the hyperlinks. However, I found that even the links to the deletion log pages of such files show the icon, even when the media doesn't exist in the first place. (ex. this). Shouldn't these be shown as normal external hyperlinks? — Ambuj Saxena (☎) 16:57, 24 February 2007 (UTC)[reply]

This is due to some "clever" css selectors (see main.css):

** keep the whitespace in front of the ^=, hides rule from konqueror
** this is css3, the validator doesn't like it when validating as css2
*/
#bodyContent a.external,
#bodyContent a[href ^="gopher://"] {
 background: url(external.png) center right no-repeat;
 padding-right: 13px;
}
#bodyContent a[href ^="https://"],
.link-https {
 background: url(lock_icon.gif) center right no-repeat;
 padding-right: 16px;
}
#bodyContent a[href ^="mailto:"],
.link-mailto {
 background: url(mail_icon.gif) center right no-repeat;
 padding-right: 18px;
}
#bodyContent a[href ^="news://"] {
 background: url(news_icon.png) center right no-repeat;
 padding-right: 18px;
}
#bodyContent a[href ^="ftp://"],
.link-ftp {
 background: url(file_icon.gif) center right no-repeat;
 padding-right: 18px;
}
#bodyContent a[href ^="irc://"],
.link-irc {
 background: url(discussionitem_icon.gif) center right no-repeat;
 padding-right: 18px;
}
#bodyContent a.external[href $=".ogg"], #bodyContent a.external[href $=".OGG"],
#bodyContent a.external[href $=".mid"], #bodyContent a.external[href $=".MID"],
#bodyContent a.external[href $=".midi"], #bodyContent a.external[href $=".MIDI"],
#bodyContent a.external[href $=".mp3"], #bodyContent a.external[href $=".MP3"],
#bodyContent a.external[href $=".wav"], #bodyContent a.external[href $=".WAV"],
#bodyContent a.external[href $=".wma"], #bodyContent a.external[href $=".WMA"],
.link-audio {
 background: url("audio.png") center right no-repeat;
 padding-right: 13px;
}
#bodyContent a.external[href $=".ogm"], #bodyContent a.external[href $=".OGM"],
#bodyContent a.external[href $=".avi"], #bodyContent a.external[href $=".AVI"],
#bodyContent a.external[href $=".mpeg"], #bodyContent a.external[href $=".MPEG"],
#bodyContent a.external[href $=".mpg"], #bodyContent a.external[href $=".MPG"],
.link-video {
 background: url("video.png") center right no-repeat;
 padding-right: 13px;
}
#bodyContent a.external[href $=".pdf"], #bodyContent a.external[href $=".PDF"],
#bodyContent a.external[href *=".pdf#"], #bodyContent a.external[href *=".PDF#"],
#bodyContent a.external[href *=".pdf?"], #bodyContent a.external[href *=".PDF?"],
.link-document {
 background: url("document.png") center right no-repeat;
 padding-right: 12px;
}

Example: #bodyContent a.external[href $=".ogg"], #bodyContent a.external[href $=".OGG"],. The $= selector matches the end of an element attribute value. In this case, <a class="external" href="blahblahblah.ogg">. You can defeat this with a simple query string rearrangement: like this. Congrats though: you have a ~CSS3 browser! --Splarka (rant) 08:23, 25 February 2007 (UTC)[reply]

Thanks for the info. I use Firefox. I tried to see this page in MSIE 6.0 and it turned out that the log page link appears as a normal hyperlink. Even my UTF-8 signature doesn't render correctly in MSIE. — Ambuj Saxena (☎) 11:48, 25 February 2007 (UTC)[reply]

Before reporting a bug, I want to make sure I am doing this right. According to DEFAULTSORT's help, you can have multiple defaultsort statements. However, Oliver Twist didn't do as I expected in Category:Big Read Books - it sorted under "Twist, Oliver" instead of "Oliver Twist."

{{DEFAULTSORT:Oliver Twist}}
[[Category:1838 novels]]
[[Category:Novels by Charles Dickens]]
[[Category:Serialized novels]]
[[Category:London in fiction]]
[[Category:Black and white films]]
[[Category:1909 films]]
[[Category:Big Read Books]]

{{DEFAULTSORT:Twist, Oliver}}
[[Category:Charles Dickens characters]]
[[Category:Fictional orphans]]
[[Category:Fictional thieves]]

Is this the correct arrangement? — RevRagnarok ^{Talk Contrib} 17:06, 24 February 2007 (UTC)[reply]

I'm not sure you're allowed to use more than one {{DEFAULTSORT}} key. --MZMcBride 21:05, 24 February 2007 (UTC)[reply]

The help says you can, which is why I am asking: Once this has been included in an article, the new default sort key will remain in force until the end of the article, or until a fresh {{DEFAULTSORT}} is used. — RevRagnarok ^{Talk Contrib} 21:09, 24 February 2007 (UTC)[reply]

The help page is ambiguous and misleading. What is actually means is that the last {{DEFAULTSORT}} will be used, no matter what previous ones might contain. You may want to make a feature request to do what you'd like to do. --MZMcBride 23:27, 24 February 2007 (UTC)[reply]

Actually, the help page reflects what the code should be doing, as far as I can remember when I wrote it. Looking into this. 164.11.204.56 10:18, 26 February 2007 (UTC)[reply]

I have just created a new page on Hydrogen in the Kannada wikipedia and put a link to that article from the English wikipedia (i.e., it shows up in the "in other languages" section). Is there a way to automatically get this inter-language link from other language wikipedias as well? or do I have to manually go and put [[kn:xxxx]] link everywhere (i.e., say in the Hindi wikipedia, Japanese wikipedia etc.)? I realize that somebody reading the Hydrogen article in the Japanese wikipedia might not be very interested in reading it in Kannada, but just thought I would ask. Thanks. --Sarvagna 17:26, 24 February 2007 (UTC)[reply]

There is a tool called the Interwiki-Link-Checker being used to create a database of articles that should be linked. The actual editing to add the links generally seems to be done by a variety of bot operators. As far as I know, there isn't a tool that will automatically propagate newly added interlanguage links (although this should be quite possible). You might want to bring this up at Wikipedia talk:Multilingual coordination. -- Rick Block (talk) 18:48, 24 February 2007 (UTC)[reply]

Thanks. For now I will add the links manually. --Sarvagna 19:40, 24 February 2007 (UTC)[reply]

Not quite sure if this is the right place to ask, but anyway: I've had navigation popups installed for quite a while, and I just installed 3 more scripts, those being navigation shortcuts, speedy deletion tabs, and edit intro section. They work just fine, but the instructions to clear my browser cache are gone in my monobook.js, and the formatting looks all weird. It even has a random speedy deletion tag stuck in the middle of it! How do I fix all these problems? Here's a link to my monobook.js page: User:Pyrospirit/monobook.js. Thanks, Pyrospirit ^{Flames Fire} 00:59, 25 February 2007 (UTC)[reply]

I sometimes see that immediately after I edit my monobook.js. It normally goes away after a while but to make it go away now, put //<pre> at the start of the page and //</pre> at the end. Tra (Talk) 01:23, 25 February 2007 (UTC)[reply]

You can also press Crtl +Refresh. (or Command + Refresh on a Mac). ≈ jossi ≈ (talk) 02:08, 25 February 2007 (UTC)[reply]

The actual way to fix this is to purge the squid cache on the Wikimedia servers. Clicking here will purge the cache of anyone who clicks it. Prodego ^talk 02:22, 25 February 2007 (UTC)[reply]

Thank you very much, I will try both of those. Pyrospirit ^{Flames Fire} 18:40, 25 February 2007 (UTC)[reply]

It worked! *randomly starts dancing* Pyrospirit ^{Flames Fire} 19:00, 25 February 2007 (UTC)[reply]

When viewing Wikipedia pages, I've noticed that the letters in italicized (or oblique) words are shifted "downstream" by two letters. In other words, "apple" now reads "crrng." As one can imagine, reading pages with a lot of italicized words becomes impossible!

I'm using a Macintosh G4 with OS 10.4.8 and Safari version 2.0.4. Is there a setting I need to make in order to correct this problem?

Thanks, Bill Pitts (E-Mail removed for security purposes) —The preceding unsigned comment was added by Bill Pitts (talk • contribs) 02:05, 25 February 2007 (UTC).[reply]

Seems to me you have the wrong encoding set on your browser, or a corrupted font. I am viewing this with a Safari and Mac OS X 10.4.8 and I do not see that problem. ≈ jossi ≈ (talk) 02:07, 25 February 2007 (UTC)[reply]

For some reason, on some Wikipedia edit windows (it only does it there) my browser randomly moves back a page. I am using IE ver. 6. Is there any way I can fix this? Mr.Z-mantalk¢ 02:39, 25 February 2007 (UTC)[reply]

Most likely the backspace key is what's doing it. Backspace is a hot key for the browser's 'back' function. If you hit it while accidentally moving focus away from the edit area, it will shoot you back. SubSeven 08:29, 25 February 2007 (UTC)[reply]

It didn't use to do that, is there a way to turn it off? I don't use backspace to go back a page anyway. Mr.Z-mantalk¢ 17:37, 25 February 2007 (UTC)[reply]

It would depend on which browser you use, but I don't know of any way to disable it in either IE or Firefox. Maybe somebody will jump in here. SubSeven 04:11, 26 February 2007 (UTC)[reply]

Can somebody add {{tnavbar}} so that it is at the right in the top row of {{Harry Potter characters}}? When I tried to put it in, it appeared a line break down. Thanks. --Fbv65edel / ☑t / ☛c || 05:40, 25 February 2007 (UTC)[reply]

Done. --MZMcBride 05:51, 25 February 2007 (UTC)[reply]

Is there a page that documents how to use preload links? (like ) I've noticed some of the params don't do what I'd assume they should do (autosummary, autominor). Are these disabled or something? --- RockMFR 05:56, 25 February 2007 (UTC)[reply]

I think you're looking for Special:Allmessages; things such as autosummary are listed there (under "autosumm-replace"). --MZMcBride 06:02, 25 February 2007 (UTC)[reply]

I can't imagine that there is any way to do just a link like that (One click vandalism!). I can write up some Javascript for an automatic tab if you'd like. -Amarkov moo! 06:05, 25 February 2007 (UTC)[reply]

Could we display the total number of articles in a category? For instance, it would be nice to know the total number of disambig pages. This total might include or exclude articles in subcategories, or maybe we could get both counts. --Smack (talk) 06:11, 25 February 2007 (UTC)[reply]

We seem to have problems converting SVGs to PNGs for display. See here and here. They render fine in Camino, Firefox, Opera, and Inkscape. The second one looks like this when it should look like this. What's going on? --M1ss1ontomars2k4 ^{(T | C | @)} 07:25, 25 February 2007 (UTC)[reply]

Wikipedia uses rsvg to generate PNGs from SVGs. Rsvg doesn't support any way to do superscript/subscripts (eg. the baseline-shift="sub" attribute is used in the examples given), so you need to use some sort of workaround to achieve the same effect... either change the text to a path (which increases the filesize by quite a bit, and makes it a little harder to edit), or make a separate text box and try to align it (though it's frequently difficult to make sure that the text lines up properly). --Interiot 07:56, 25 February 2007 (UTC)[reply]

Are subscripts not part of SVG 1.1? If it's just an rsvg flaw I'd be reluctant to create a workaround. --M1ss1ontomars2k4 ^{(T | C | @)} 19:01, 25 February 2007 (UTC)[reply]

I tried to copy an SVG into a Powerpoint and the bottom showed up black. Please advise. ThanksElatanatari 01:59, 26 February 2007 (UTC)[reply]

It could be that PowerPoint can't handle SVGs correctly. Try pasting in the PNG file that is automatically generated instead. Tra (Talk) 02:06, 26 February 2007 (UTC)[reply]

Hi, I've been noticing the job queue more and more recently, and it seems to be an issue with the size it gets. Right now it's at 140,000, and its occurred to me (and others) that we should have an archive and graphs to highlight those times when it's all going wrong. A few people have asked stuff like "is 33,000 a large queue?", and without some sort of easily interpreted data archive (eg. a graph), the job queue is just a meaningless number, and there's no point in displaying it to none techies - Jack · talk · 11:22, Sunday, 25 February 2007

The raw number can still be quite useful, if you for example rename a stub category and want a rough idea on how long it will take for the change to propagate fully so you can check back if any articles are still lingering in the old cat (substed templates, manually added cats etc.), and things of that nature. One thing that could be useful would be some kind of log over edits that trigger more than X job queue jobs or something like that. I've seen the job queue as high as 500.000 which makes me wish I could track the source and see if someone is edit warring on a common template or something. --Sherool (talk) 12:32, 25 February 2007 (UTC)[reply]

How could we create this log? Would a request need to be made to developers? How would we do that? Jack · talk · 12:53, Sunday, 25 February 2007

It was at 700k (or so) when I checked earlier today. I know modifying the album infobox creates a 30-50k one. I agree that some actions may need a confirmation (in example, when saving the infobox, stops you with some message like "Saving this page may generate a 30k queue log. Save again to accept." However, we should protect all those that may be used for vandalism (we would be telling people "Dude, modify this template, save it, and you will have the servers processing for some time"). -- ReyBrujo 02:15, 26 February 2007 (UTC)[reply]

Heh, good point. But that's not what I meant, I just wanted to know how to get a graph created to see the job queue? The following table is something I found on my travels (in Wikipedia:statistics), but I'm not entirely sure if it's what I want - Jack · talk · 00:10, Tuesday, 27 February 2007

Requests	hourly	daily	weekly	monthly	yearly
Traffic	hourly	daily	weekly	monthly	yearly

I recall seeing something like 1.8 million, but that was caused by a Mediawiki bug. Dragons flight 17:06, 26 February 2007 (UTC)[reply]

I've created this template. But I can't seem to get certain pieces of info (such as Man of the match) to appear in it. Buc 14:04, 25 February 2007 (UTC)[reply]

Working on it. Gimmetrow 15:35, 25 February 2007 (UTC)[reply]

Is there any tool or such that can be used to create a sub watchlist; IE if you just want to be notafied on one type of article you're watching.

Take me for example, recently, I tagged a ton of articles about a proposed merge, but i need to keep an eye on the talk pages; however, I'm already watching a ton of pages not related to the topic, I don't want to remove them from my watch list, but I also wish to view 'just' the changes in articles I'm recently tagged. Is there anyway of doing this?--Honeymane_{Heghlu meH QaQ jajvam} 19:49, 25 February 2007 (UTC)[reply]

You can make a user subpage with a list of links to of the articles that you're interested in, save the page and click on 'Related changes' in the sidebar, to see the recent changes to just those articles. Tra (Talk) 20:23, 25 February 2007 (UTC)[reply]

If you don't mind going off-site you can also hook an aggregator or some such into the RRS feeds from selected page histories. Maybe the new Yahoo! Pipes thing or whatever (never tried it myself though). --Sherool (talk) 22:05, 25 February 2007 (UTC)[reply]

Not exactly what you are looking for, but to make sure you know it: You can create a page, let's say User:Honeymane/watch1, with links to pages and then use Special:Recentchangeslinked/User:Honeymane/watch1. This also works for categories: Special:Recentchangeslinked/Category:Retired Atlantic hurricanes. --Ligulem 23:50, 25 February 2007 (UTC)[reply]

Is there any way I can turn off the "edit merging" feature that combines changes made by two users to the same page at the same time? The feature relatively often merges vandalism reversions with more vandalism (example). These merges are annoying as they may go unnoticed. I would rather just get the "edit conflict" message every time I edit a page simultaneously with someone else. --KFP (talk | contribs) 22:18, 25 February 2007 (UTC)[reply]

I'm running Firefox 1.5.0.9, and have loaded two fairly large scripts into my monobook.js page as follows:

importScript("User:Lupin/recent2.js");

importScript('User:Lupin/popups.js');

They both run fine (thanks Lupin!), but every time I reload a page (using the buttonbar or F5 - not Shift-click), both scripts get re-downloaded (nearly 400kB). This slows things down and also causes unnecessary load on the servers, I guess. Does this happen to anyone else and is there any way I can persuade Firefox to always use the cached copies? TIA

--Smalljim 23:31, 25 February 2007 (UTC)[reply]

Check if your browser.cache.check_doc_frequency setting is something other than 3. You can access it by typing about:config in the URL, and then searching for it. -- ReyBrujo 23:43, 25 February 2007 (UTC)[reply]

And remember to do one hard refresh (with ctrl+f5, not shift+f5) at least to update your cache stamp. -- ReyBrujo 23:45, 25 February 2007 (UTC)[reply]

Thanks for the quick reply, ReyBrujo. Just checked that setting - it is default - integer - 3. I have done several hard refreshes, and even cleared out the whole cache, but it still happens. Should say I'm running Windows XP Home. When I reload a page I can see, with Explorer, the files being re-downloaded into Firefox's cache. The odd thing is that it doesn't happen when I open a new page - only when I reload one that's already opened. It's as if the Reload button has been reprogrammed to do a full refresh.

Thanks for the pointer to about:config, which I'd forgotten - I'll have a browse around in there and see if there are any settings that change the behaviour of the Reload button. I do have a number of Extensions installed, so perhaps it might be a clash with one of them?

Failing everything else, does anyone know if can I store the scripts on my hard disk (as .js files) and get monobook.js to point to them somehow? --Smalljim 00:21, 26 February 2007 (UTC)[reply]

I haven't tried it, but it might be possible to convert the popups.js to a greasemonkey script. That way the script will always be on and you wouldn't even need to be logged in! — Ambuj Saxena (☎) 05:06, 26 February 2007 (UTC)[reply]

Thanks, I can look into greasemonkey scripts - but it may be a bit beyond me! Incidentally I've found that the same thing happens with Opera, so I guess it actually happens to everyone and I'm just particularly fussy about download times!

I have found that a partial workaround is to click the article tab instead of the Reload button. This seems to update the article without re-downloading all the .js files. --Smalljim 12:10, 27 February 2007 (UTC)[reply]

The referenced article is very large (286 KB, I think the edit window said on one of my edit attempts). I had considerable trouble editing it -- when I saved the page, it would not be redisplayed after the save -- and now I can't display it at all. The page load terminates without displaying any content at all. Using Shift+F5 doesn't help, and neither does adding &action=purge to the URL. Is this to be expected with such a large article, or is something else going on? Thanks. --Tkynerd 00:59, 26 February 2007 (UTC)[reply]

Interesting. The history works, maybe you hitted Wikipedia' sweet number for wikilinks :) -- ReyBrujo 01:02, 26 February 2007 (UTC)[reply]

Apparently was a cache issue. -- ReyBrujo 01:05, 26 February 2007 (UTC)[reply]

Had it been a cache issue, I would have expected one of the two remedies I mentioned above to have worked, but they didn't. At any rate, it seems to be working for me too (more or less) now. Thanks. --Tkynerd 01:17, 26 February 2007 (UTC)[reply]

I inspected the headers with LiveHTTPHeaders (unfortunately I did not save them), but apparently the squid was returning "No changes" with a cache miss. I have suffered from this in the past (will pay more attention next time), but from what I see the squid detected there were no changes in the page, and returned an empty page due the cache miss. -- ReyBrujo 01:30, 26 February 2007 (UTC)[reply]

OK, thanks for the additional detail. :-) --Tkynerd 01:54, 26 February 2007 (UTC)[reply]

I'm not sure what you mean by squid and whatnot, but that page doesn't display in my browser. - Peregrine Fisher 04:58, 26 February 2007 (UTC)[reply]

I was talking about Squid cache. The page works for me, maybe you can try a full refresh. If that does not work, try appending ?action=history to the URL, and then trying to see a revision, or ?action=purge to purge the content (note that these work with the en.wikipedia.org/wiki/ urls, not with the en.wikipedia.org/w/index.php ones, which require & instead of ?). -- ReyBrujo 05:10, 26 February 2007 (UTC)[reply]

To be honest, this article is much too long anyway, and should definitely be split or deleted. It eventually loaded in my browser (Firefox 2.0.0.2) but my CPU spiked to 100% for several seconds and my whole browser locked up, which is obviously not something we want happening when viewing an article. Jayden54 18:20, 26 February 2007 (UTC)[reply]

This is kind of a proposal (sorry if this has been proposed before). When using a <ref> multiple times in an article, the reflist automatically separates each instance into letters (see the first ref in Peter Jennings for example). This is nice. However, the refs in-text don't have the corresponding letter labels, which would be even better. Instead, all of them are labeled [1]. This makes it difficult for readers to return to where they were in the text, as I doubt many of them would keep track of how many times a reference had been used so far in the text. Making refs in text appear as [1a], [1b], [1c], etc. would be better IMO. Of course, using the back button works for most people, but clicking on a ref to return to the text seems more intuitive to me. What do you all think? Gzkn 07:23, 26 February 2007 (UTC)[reply]

The <ref> tag citations are done using an extension called Cite.php. You may want to look through that extension's talk page. --MZMcBride 03:04, 27 February 2007 (UTC)[reply]

MediaWiki:Anonnotice is clashing with many of the top-right-corner icons for anons at the moment (see the thread linked in the section title for details). So it probably needs to be moved to the left. Per discussion in that thread, I'm taking the matter here for dicussion. --ais523 10:08, 26 February 2007 (UTC)

{{bots}} is protected, so its edit page says, because User talk:Redvers is protected with cascading. However, the latter is only semi-protected, and it's caused full protection on the template! Surely this is some sort of MediaWiki bug, but the BugZilla link on this page isn't working for me at the moment. Any ideas on what's going on or how best to report it? Thanks. --Tardis 16:56, 26 February 2007 (UTC)[reply]

This is a known issue. Cascading protection applies full-protection to all included pages even if semi is used. Dragons flight 16:59, 26 February 2007 (UTC)[reply]

I was wondering about the community's opinion on what parameters to use for the newer user warnings (such as {{uw-vandalism3}} or {{uw-delete1}}). The following are all possibilities.

Parameter name or option	Description
1	A numbered parameter; the value would be the page name that the template-receiver edited. This must stay in place; apprently it's ancient. :)
#ifexist hack	This is a way to code the template so that if "1" exists, text similar to "as you did to [[:{{{1}}}]]" shows up, but if it doesn't, text similar to "as you did to {{{1}}}" will appear. This is helpful for listing multiple pages. Suggested by Gracenotes (talk · contribs).
diff	A link to the diff of vandalism. Can be used as a substitute for, or in conjunction with, 1. Suggested by AzaToth (talk · contribs)
oldid	This is an extension of diff, but it's not really needed, since it's much easy to copy an entire link than a specific page revision Suggested by AzaToth (talk · contribs)
header	An option to have a header above a template. It does minimize customizing said header, however. Boldly implemented by Esprit15d (talk · contribs), but then discussed and reverted by Khukri (talk · contribs).
2 (or "sig")	Puts a notice at the end of a template
subst	all ParserFunctions in all templates are preceded by "{{{subst}}}". So if a template is substituted, and "subst" is set equal to "subst:", the messy syntax will disappear. Suggested by AzaToth (talk · contribs) (known bugs: even if 1 doesn't exist, the ParserFunction will pretend that it does)

So which ones do you like, and which ones are you less partial to? Gracenotes^T § 19:06, 26 February 2007 (UTC)[reply]

I made a note of this discussion at WT:UW. I think it would be useful to have the diff in the template. I'd say no on the header because I like the way WP:UW proposes we handle these - creating a ==Warnings== section with month subsections and having each warning numbered. A section heading in the template would throw this off. Unless it was optional as it is with many of the speedy delete templates (such as {{empty-warn}}).↔NMajdan•talk 19:14, 26 February 2007 (UTC)[reply]

All of the parameters above would be optional. Gracenotes^T § 19:30, 26 February 2007 (UTC)[reply]

The diff and oldid parameters might be useful, especially if automated tools are being used to revert vandalism. I don't think the header should be added, for reasons Najdam gave. The #ifexist hack would be useful, but unless it's substituted, it would mean that if the vandalised page is later deleted, the red link would eventually be removed, so there would be no easy way to access the deletion logs of the page. I think a good way of dealing with messy template code would be to use <includeonly> tags to make the subst: commands only work when the template is used, but this would break the template if it's transcluded and not substituted. Parameter 2 would probably only be useful if it's the type of message that goes in a box, like some image-related warnings. Tra (Talk) 19:37, 26 February 2007 (UTC)[reply]

There's something strange going on at Wikipedia:Help desk. For some reason, section edit links have disappeared from the page; I've looked for an errant __NOEDITSECTION__, but haven't had any luck with that. A few other users have reported that as well. Any ideas? Titoxd^(?!?) 22:14, 26 February 2007 (UTC)[reply]

Yes, I've noticed it as well. Someone on the Help Desk said that if they logged of they saw the section links, but this didn't work for me. Mr.Z-mantalk¢ 22:33, 26 February 2007 (UTC)[reply]

"Weirdness at the Help Desk" would be a really good album title. (Sorry, but somebody had to say it.) Have you tried going back through the page history to find the latest working version? That would help locate the problem. Raymond Arritt 22:37, 26 February 2007 (UTC)[reply]

No, section edit links don't show up on history revisions (I already tried). The only thing I can think of would be to keep reverting back one revision at a time until we finf one that works. I would do it but the vandal fighters might not like it. To prevent that, we would have to have an admin lock the page and then do it. Mr.Z-mantalk¢ 22:42, 26 February 2007 (UTC)[reply]

Indeed, section edit only works in the top revision. Going back and reverting things sounds like a recipe for agony... Titoxd^(?!?) 22:43, 26 February 2007 (UTC)[reply]

Found the problem. The page User:Darkest Hour/TAB was being transcluded in it, and that page transcluded Wikipedia:Tutorial/TabsTop which contained the __NOEDITSECTION__ command. Tra (Talk) 23:11, 26 February 2007 (UTC)[reply]

Bear with me, I am an old refugee from the eight-bit world. I took the link supplied by Soporific and what I found was somewhat opaque to me. Does it tell me, somewhere on that page, that I can enter a command that will make all the lists alphabetical by last name when I see them? I did not find anything in "my preferences" about alphabetization.

Dynamic lists are alphabetical by first name (or title, if that comes before the first name) in Wikipedia and other Wikis I have consulted. Alphabetizing by first name is ok for a 13-year-old's address book but I find it monstrously off-putting. I think there is a practical argument in favour of my attitude too, not just a cultural one: it's not a good idea to to have to work one's way through a long line of "John"s.

• If I understand your question, just see several sections above: #Sortable tables - sort keys?. The only think that I can think of is to have two columns: one for first name, one for last name. This makes sense, as most databases store people's first and last names separately.

First name	Last name
Abby	Smith
Charles	Guy
John	Can
John	Smith
Sarah	Can

Hope this helps. Gracenotes^T § 23:44, 26 February 2007 (UTC) Or this, which makes the names look more natural:[reply]

First name	Last name
Abby	Smith
Charles	Guy
John	Can
John	Smith
Sarah	Can

Gracenotes^T § 23:47, 26 February 2007 (UTC)[reply]

There's been a proposal on WP:VPR for a new way to prevent vandalism. It seems to involve some non-trivial software changes, though. Do people think it would be feasible? Thanks. Canderson7 ^(talk) 01:36, 27 February 2007 (UTC)[reply]

A much simpler and at least equally effective option, which is already available and well-tested in the MediaWiki software, is for Wikipedia to join the rest of the wiki world and require users to log in before editing. (If you started your own wiki, would you allow anonymous users to edit it? That might have made some sense in 2001, when very few people knew what a wiki was, and the most important thing was to sell the idea to people who had never seen a wiki before, to gain critical mass, but today wiki users are much easier to attract, and vandals and link spammers are fully up to speed.) However, for some reason I cannot yet fathom, Wikipedia has a remarkable amount of institutional fondness for the idea that every adolescent on the planet must be free to anonymously participate in the creation of an encyclopedia, and evidently this begins at the very top. As I opined at length, there is a certain Potemkin Village disingenuousness in the notion that Wikipedia must appear to be free to everyone, because just behind those apparently unlocked and beckoning doors lurks an elaborate array of protection schemes, some of which are, unfortunately, labor-intensive. There has been a gradual tendency for a seemingly reluctant Wikipedia to add progressively more protection over time (see: John Seigenthaler Sr. Wikipedia biography controversy#Wikimedia Foundation reaction). The number of articles receiving some form of protection from anonymous edits seems to increase monotonically. Instead of protecting Wikipedia one article at a time (at some incalculable cost in volunteer labor which could have gone instead into editing articles), why not just require users to log in before editing? I think it's time for Wikipedia to get over its apparent inferiority complex, and be confident that its status as one of the world's most popular Web sites should be enough to attract new editors even if we ask them to fill out a form and click a button first. --Teratornis 18:21, 27 February 2007 (UTC)[reply]

Is there a way to make bulleted text align with non bulleted text. This is specifically an issue in the last parts of Mount Hood#Incident history, but is easily demonstrated here:

• This is a lead for this section. It introduces the subject.

These lines are the meat of the section, and expand and clarify with full gory details, and should be aligned with the lead paragraph. There is one indent on this paragraph for the closest alignment.

No indentation, like this paragraph looks much worse. —EncMstr 01:45, 27 February 2007 (UTC)[reply]

My suggestion would be to write such a section with normal paragraphs, instead of a bulleted list. Bullets don't really belong in such a setting. —Bkell (talk) 02:07, 27 February 2007 (UTC)[reply]

• This is the lead section.
  These lines are the meat of the section, and expand and clarify with full gory details, and should be aligned with the lead paragraph. There is one indent on this paragraph for the closest alignment. --MZMcBride 02:48, 27 February 2007 (UTC)[reply]

Thanks! Two excellent suggestions. —EncMstr 03:28, 27 February 2007 (UTC)[reply]

I am proposing that we add the number of bytes of each edit (as seen in watchlists) to the history of articles. This would make it far easier to spot vandalism and blanking of large sections when looking to revert an article, especially when deciding which revision to go for RyanPostlethwaite^{See the mess I've created or let's have banter} 01:50, 27 February 2007 (UTC)[reply]

I would be worried that will lead to even more reversion of any sort of content removal, even if it was justified. -Amarkov moo! 01:53, 27 February 2007 (UTC)[reply]

I agree with that, but good faith suggests that users will still check the history diffs RyanPostlethwaite^{See the mess I've created or let's have banter} 01:57, 27 February 2007 (UTC)[reply]

Assuming good faith doesn't have any effect on whether people act in good faith or not. AGF refers to individual actions, not patterns (from different editors). Nonetheless, I want to see those little numbers everywhere! They're quite helpful. And people can edit their monobook.css to disable it (display:none), as always. Gracenotes^T § 02:23, 27 February 2007 (UTC)[reply]

• This information is not stored anywhere. The only place it is buffered is in rc_old_len and rc_new_len, which stores it for at most a month (usually less), and then it is discarded. A field for this could be added to the revision table, but that would entail having to calculate it for all of the 100 million revisions in the English Wikipedia. I have no clue how many revisions there in all of the other Wikimedia wikis, but I imagine we would be talking about 250 million revisions here. While it is doable, is it really that necessary? Titoxd^(?!?) 02:51, 27 February 2007 (UTC)[reply]
  • One way around would be to make the process dynamic. Whenever the history page of an article will be accessed by a user, the byte changes for the hundred-or-so revisions will be calculated on the spot. While this would save on storage space and facilitate implementation without amassing a backlog, it will probably be more expensive on the servers because of the frequency with which the history pages are accessed. I am not sure how the MediaWiki displays the history pages, but it is quite likely that it maintains a separate index for it. Adding byte count would mean to change the basic structure of the way these details are stored and accessed. Possibly someone with a better understanding of the software can detail the technical complications involved. As far as the issue of necessity goes, I can tell from personal experience that I had been doing fine for more than a year I have been here without the bye-count support. But now, it is a necessity for me and I feel handicapped using the history pages of the articles. — Ambuj Saxena (☎) 07:36, 27 February 2007 (UTC)[reply]
    • It would surely be possible to fetch the numbers out of the Recentchanges table for those changes recent enough: anything older than that is somewhat moot. HTH HAND —Phil | Talk 15:41, 27 February 2007 (UTC)[reply]

Has anyone else been getting errors like this lately, I just got 2.

WIKIMEDIA FOUNDATION Fout Fel Fallo 错误 錯誤 Erreur Error Fehler エラー Błąd Errore Erro Chyba English The Wikimedia Foundation servers are currently experiencing technical difficulties.

The problem is most likely temporary and will hopefully be fixed soon. Please check back in a few minutes.

For further information, you can visit the #wikipedia channel on the Freenode IRC network.

In the meantime, you may be able to view Google's cached version of this page.

Wikipedia is now one of the most visited sites on the Internet by traffic and continues to grow, and as a result the Wikimedia Foundation has a constant need to purchase new hardware. If you would like to help, please donate.

If reporting this error to the Wikimedia System Administrators, please include the following details: Request: POST http://en.wikipedia.org/w/index.php?title=User_talk:68.42.20.1&action=submit, from 68.41.148.42 via sq24.wikimedia.org (squid/2.6.STABLE9) to 10.0.5.3 (10.0.5.3) Error: ERR_ZERO_SIZE_OBJECT, errno [No Error] at Tue, 27 Feb 2007 03:38:33 GMT

Mr.Z-mantalk¢ 03:41, 27 February 2007 (UTC)[reply]

Yeah, intermittently. Which is strange, because I hadn't seen that error in half a year or so. I guess that is a good thing and speaks volumes about the good job the devs are doing. Titoxd^(?!?) 03:45, 27 February 2007 (UTC)[reply]

I just uploaded Image:Population density.png to replace Image:Pop density.jpg, but now the oceans are white (because the PNG has an alpha channel and it's composited against a white background by default). Is there any way to change the background to blue? I could always just upload a separate pre-composited PNG with no alpha channel, but that seems like a needless waste of space. —Keenan Pepper 04:08, 27 February 2007 (UTC)[reply]

You could put it on an element with a blue background, but to make it a blue background 100% of the time you'd have to disable the alpha layer (as it is contrary to the goal). --Splarka (rant) 08:32, 27 February 2007 (UTC)[reply]

Thought I would ask here, found nothing useful at Meta. I read some comment that Wikipedia:Broken/ is generated due a bug with unicode or so. I spend my time deleting these pages from smaller Wikipedias, and am curious as to why the page is generated by an ip and gets full protection by default. Thanks -- ReyBrujo 04:36, 27 February 2007 (UTC)[reply]