Wikipedia:Village pump (technical)

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

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

view · edit

Frequently asked questions (see also: Wikipedia:Technical FAQ)

Click "[show]" next to each point to see more details.

If something looks wrong, purge the server's cache, then bypass your browser's cache.
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 have problems making your fancy signature work, check Help:How to fix your signature.

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.

For server or network status, please see Wikimedia Status. If you cannot reach Wikipedia services, see Reporting a connectivity issue.

« Archives, 195, 196, 197, 198, 199, 200, 201, 202, 203, 204, 205, 206, 207, 208, 209, 210, 211, 212, 213, 214, 215

TOC without numerals

Is there any chance to have TOC without numerals, so just titles of chapters? --Janezdrilc (talk) 21:53, 20 November 2008 (UTC)[reply]

Look in Category:TOC templates. --—— Gadget850 (Ed) ^talk - 22:09, 20 November 2008 (UTC)[reply]

I am afraid there is no such example. All templates include __NOTOC__ within the codes, but I need toc, only without numerals ahead of titles. I would actually need this in Wikisource. Thanks anyway for helping me. --Janezdrilc (talk) 21:11, 21 November 2008 (UTC)[reply]

<div class="nonumtoc">__TOC__</div>, and you'll have to ask the appropriate CSS be copied from the local MediaWiki:Common.css. --Splarka (rant) 08:56, 22 November 2008 (UTC)[reply]

Waw, it works perfectly. Now one last thing. Is it possible to write a different word instead of Contetnts, let's say Chapters? That would be even more wonderful. --Janezdrilc (talk) 12:00, 23 November 2008 (UTC)[reply]

You'd have to change s:MediaWiki:toc. --Splarka (rant) 12:34, 23 November 2008 (UTC)[reply]

See Wikipedia:Village pump (technical)/Archive 10#55. Numbered ToC headings meaningless.

Or, concisely, add this code to your monobook.css:

/* Hide the ToC number and show bullets instead */
.tocnumber {display: none}
#toc ul {list-style-image:url(/skins-1.5/monobook/bullet.gif); list-style-type:square; margin:0.3em 0 0 1.5em;}

-- Quiddity (talk) 23:05, 27 November 2008 (UTC)[reply]

GIF scaling problems

Is anyone looking into the GIF scaling problems? Anyone know if/when this will be fixed? It's making quite a few articles look like a dog's dinner, so I'd hate for it to be ignored. —Preceding unsigned comment added by 81.156.127.116 (talk) 14:24, 21 November 2008 (UTC)[reply]

I do concur that scaled GIF images look like crap now. I also see why; the GIFs are no longer scaled(!) All GIF images now have the original image as the source. This can get quite problematic for large images. — Edokter • Talk • 15:20, 21 November 2008 (UTC)[reply]

See #GIF resizing. This Bugzilla report may be related.[1] --—— Gadget850 (Ed) ^talk - 15:58, 21 November 2008 (UTC)[reply]

May I recommend a different web browser? I know Opera does high-quality image resizing. --Carnildo (talk) 23:02, 21 November 2008 (UTC)[reply]

You're right, it's partly the fault of IE, which does a really rubbish job of scaling GIFs. However, recommending that people don't use IE to view Wikipedia is not an option. Similarly, the suggestion "for non-animated images, try using PNG" at the discussion linked above is not a satisfactory solution -- unless someone is prepared to go through and convert the thousands of existing GIF images. The thing that puzzles me is why server-side scaling of PNG images still seems to work OK. I gather that GIF scaling was turned off for performance reasons, but I don't understand why PNG scaling should be any less of a load. Matt 12:33, 22 November 2008 (UTC). —Preceding unsigned comment added by 86.146.47.118 (talk)

Because PNGs aren't animated, and animated GIFs seem to be the reason GIF scaling was turned off? A very bad decision IMO; There are many large, I mean LARGE, GIF images (even non-animated) take take up quite a bit of bandwidth when loaded. So while server performance may have been reduced, it is negated by increased bandwidth usage. Another aspect is that while scaled GIF images may look bad in IE, animated client scaled GIF images show very distorted or not at all in IE. This decision was not thought through properly. And since images are scaled only once (per usage), I think the stated performance savings is a misnomer. — Edokter • Talk • 15:57, 26 November 2008 (UTC)[reply]

If the image scaler servers crash because of overloading, you won't see any images at all. Even if they just run slow, it'll still slow down page loads for any page with an image not at full resolution. Mr.Z-man 17:09, 26 November 2008 (UTC)[reply]

So does downloading unscaled full resolution images. I find it strange how the image scalers could be overloaded, as each scaled image is cached on multiple levels, or at least should be. — Edokter • Talk • 17:46, 26 November 2008 (UTC)[reply]

(unindent) See also commons:Commons:File types#Images. PNG scaling is a more serious problem. Converting all GIF images to PNG images is not a good idea. I thought scaled images were cached. I don't understand this problem at all. The servers shouldn't need to scale images on-the-fly each time a page loads. That is because they should be pulling up the already-scaled images from a cache. Am I missing something here? GIF image scaling is normally faster in most image editors than PNG image scaling, so I don't understand this problem from any angle. I use freeware IrfanView for simple, fast image editing of both GIF and PNG images. PNG image scaling is more complicated to do well. GIF images are low-color images and scale instantly always. I don't know about animated GIF images. Would it be possible to just turn off scaling of problematic animated GIF images? And why aren't those scaled animated GIF images cached? --Timeshifter (talk) 18:16, 26 November 2008 (UTC)[reply]

Interwiki links - the default code is not a good option

At Commons I link to en.wikipedia all the time. To do so you simply type 'w:' at the beginning of the link and then just leave the rest as normal, e.g. w:Wikipedia (this works here too, though it's not necessary of course). Unfortunately, and as you can see, this is displayed as "w:Wikipedia" and not simply "Wikipedia". It's almost never the case that you actually want it to say 'w:whatever', but this remains the default. To display it normally you have to type 'w:word|word', which wastes at least a second and adds frustration every time you have to do that. Surely the preferable default would be just be showing the text after the prefix and letting people type in '|w:word' if they actually want that to be shown. Surely it would be a simple matter to change this?

The problem is that this code is so widely used. Anything that people did want to read 'prefix:word' would become 'word' anyway (perhaps they said 'type in the following code', taking advantage of the fact that you can see the prefix code by default. Is there any way we can get around this? The only thing I can think of is to create a new prefix which does the same thing, e.g. wx:Word would work the same as w:word, but would default to 'word' and not 'w:word'. The same could be used for all other prefixes, i.e. just add an x on the end to the existing ones (I know from another wiki that adding new prefixes to other wikis is a fairly simple matter). So wikt:word would become wiktx:word, and you wouldn't have to type out/copy + paste '|word' every time you used it. I'm sure I'm not the only person who has become a bit frustrated with this technicality. I suppose I should propose such a change at Bugzilla. Would anyone support it? And, as I have assumed, is it actually possible for the software to ignore the prefix by default? Richard001 (talk) 06:18, 22 November 2008 (UTC)[reply]

WP:PIPETRICK - If you just type [[w:Foo|]], its automatically expanded to [[w:Foo|Foo]] when you save the page. Mr.Z-man 06:26, 22 November 2008 (UTC)[reply]

Oh, cool. I feel like quite the newb for not knowing that, perhaps I should have asked if there was already a way to do it. Richard001 (talk) 06:02, 25 November 2008 (UTC)[reply]

Page editing issues

Directly editing a page through the edit button nearly duplicates the page. This is particularly troublesome and annoying for long pages. Anyone knows why do this happens and how to fix it? Alexius08 (talk) 11:32, 22 November 2008 (UTC)[reply]

Which edit button are you referring to and what do you mean by nearly duplicates the page? PrimeHunter (talk) 02:08, 23 November 2008 (UTC)[reply]

The one at the top. Look at what happened when I tried here. Alexius08 (talk) 08:56, 25 November 2008 (UTC)[reply]

Do you mean you clicked the "edit this page" tab, made a small change in the edit box, saved the page, and then the near duplicate showed by your diff was saved? I have never heard of such behaviour before. Does it happen each time? Have you installed something special in your browser or account? PrimeHunter (talk) 23:13, 25 November 2008 (UTC)[reply]

What browser (and OS) are you using? EVula // talk // ☯ // 23:18, 25 November 2008 (UTC)[reply]

I'm using Firefox 3.0.4 on Microsoft Windows XP. Installed plugins include Alexa Sparky 1.3.0 and Web of Trust 20081111. Alexius08 (talk) 08:03, 26 November 2008 (UTC)[reply]

Does it happen each time? Can you try with another browser? Can you try while logged out? PrimeHunter (talk) 17:24, 26 November 2008 (UTC)[reply]

Are combined watchlists possible?

Hi all -

I regularly contribute to en:Wiki, and am also an occasional contributor to commons and to a couple of other language Wikipedias. Unfortunately, I'm only on those other WPs and Commons once every couple of weeks or so... is there any way of adding the few items I have on my watchlist on those projects to my watchlist at en:Wiki? Grutness...wha? 00:00, 23 November 2008 (UTC)[reply]

No, not yet. However you can set up MediaWiki to email you when something is changed on your watchlist, on some of the smaller projects, including Commons. It's in the preferences with the other email options. Graham87 04:20, 23 November 2008 (UTC)[reply]

Right now if you are logged in you can use something like:

http://en.wikipedia.org/w/api.php?action=query&list=watchlist&wllimit=50

to check your local watchlist, but as far as I know the only way to get the same data for another wiki is to change the domain name in the url (I don't see any way to set a "site" parameter to access it from the local API):

http://commons.wikimedia.org/w/api.php?action=query&list=watchlist&wllimit=50

Cross-site AJAX which tries to get data from the API of another domain (that is, to import data from sites other than where the script is run) will fail in most browsers unless the security settings can somehow be over-ridden. (edit: this may or may not be configurable in the yet unreleased Firefox 3.1, I'd have to read further)

For slightly related reasons this wouldn't work on the toolserver either unless they make an SUL login for it. Unlike the API the toolserver has no way to know which wiki user you are. If a toolserver script did try to check for the cookies set by sites this would also be denied by the security settings of most browsers. Obviously showing your watchlist without confirming identity would make watchlist data visible to everyone and be totally unacceptable (and arguably in violation of the foundation policy on "non-public data").

This might be a good feature for a mediawiki-specific client application—something akin to AWB, Huggle, or any (other?) bot software. — CharlotteWebb 20:04, 23 November 2008 (UTC)[reply]

Yeah. Normally, you could use a JavaScript callback for JSON data, like this...

http://commons.wikimedia.org/w/api.php?action=query&list=watchlist&wllimit=50&format=jsonfm&callback=callme

However, any request with the "callback" parameter fake-logs-you-out before querying for the information (for security reasons), so checking one's watchlist in this way is effectively useless. As you mention, making it useful would create a bit of a security hole :/ Gracenotes^T § 23:42, 23 November 2008 (UTC)[reply]

A toolserver tool that implements combined watchlists could use TUSC to confirm the users' identity. Graham87 23:38, 23 November 2008 (UTC)[reply]

I don't believe the watchlist table is available to toolserver tools/users, for obvious privacy reasons. The only way for such a tool to work would be to log in as you on every project, which would require your wiki password, so it would violate toolserver rules. Short of doing cross-site AJAX, creating a tool entirely, or mostly, separate from the web browser, or a change to the software to add cross-site watchlists, the only way to do this is with the RSS feeds and an aggregator. Mr.Z-man 00:39, 24 November 2008 (UTC)[reply]

This'd be easy (with a user subpage of links on each project) if there was a method for Recentchangeslinked in the API (per bugzilla:14869). --Splarka (rant) 08:27, 24 November 2008 (UTC)[reply]

That would require, in effect, the use of public watchlists, which may not be in anyone's better interest. Plus for that a toolserver script could handle the combining and chronological sorting if it knew where to look. What would really help is a way to do a multi-project query from within the API of one wiki. Ideally this would be built into the main software at whatever stage of SUL at which local account data is phased out (assuming this is even part of the long-term plan, that is). — CharlotteWebb 20:29, 25 November 2008 (UTC)[reply]

"page" tabs

Hi, every time I load a page, the "page" bit of the tabs ("project page", "user page", "talk page", "special page") blinks away almost instantly, like there's a java-thing supressing it. Does anyone know how I can get it back, I like it? Thanks! ╟─Treasury Tag►contribs─╢ 12:26, 24 November 2008 (UTC)[reply]

TT, are you by chance using the "Friendly" script? If so, I think that it has recently introduced a new feature that reduces the text on tabs in order to allow more room for extra tabs. (See Wikipedia:WikiProject User scripts/Scripts/Friendly#friendlytabs) I think there is also a configuration option to allow for the standard text. Hope this helps. --Ckatz^chat_spy 19:39, 24 November 2008 (UTC)[reply]

Ooh, yes, thanks, I'm sure that's it - do you know how to disable it? The Friendly page isn't that clear... Thanks! ╟─Treasury Tag►contribs─╢ 11:30, 25 November 2008 (UTC)[reply]

Winter

The article about the season, Winter, is not loading correctly and the tabs (discussion, edit, history) and the entire left side of the page have vanished. Could be a problem on my end but other pages are loading correctly. 144.92.84.206 (talk) 16:56, 24 November 2008 (UTC)[reply]

Fine here. Have you tried bypassing your cache, restarting your browser, and restarting your computer (in that order)? Algebraist 17:00, 24 November 2008 (UTC)[reply]

Everything looks okay to me on that article... EVula // talk // ☯ // 23:23, 25 November 2008 (UTC)[reply]

More broken math images

Similar to previous issues (1, 2, 3), the images generated by <math>p</math> and <math>E\,\!</math> are broken: $p$ , $E\,\!$ . —Bkell (talk) 05:32, 25 November 2008 (UTC)[reply]

Move succeeded message

Something odd seems afoot with the Move succeeded page (the page that appears after you have moved an article to a new name). What appears in the first line after I moved a priori and a posteriori (philosophy) to a priori and a posteriori is this:

The page "A priori and a posteriori (philosophy)" (links) (priori and a posteriori (philosophy)&action=delete delete) has been moved to "A priori and a posteriori" (links). (revert · log)

It seems to me that the second ex link (beginning "priori and...") is broken and should have its spaces replaced by underscores:

The page "A priori and a posteriori (philosophy)" (links) (delete) has been moved to "A priori and a posteriori" (links). (revert · log)

Is this just me or do others see a difference between the two? the skomorokh 12:06, 25 November 2008 (UTC)[reply]

Look better now? {{Nihiltres|talk|log}} 13:27, 25 November 2008 (UTC)[reply]

It would look even better with fullurl since some people use secure server. By the way, the "delete" link was already present at the bottom of that message. —AlexSm 15:02, 25 November 2008 (UTC)[reply]

Fullurl magic enabled. :) {{Nihiltres|talk|log}} 16:28, 25 November 2008 (UTC)[reply]

I can't tell if this has worked until I see a fresh movesucceeded page, but I trust that you chaps have addressed the matter appropriately. Thanks! the skomorokh 14:04, 26 November 2008 (UTC)[reply]

Two technical discussions

There are two discussions taking place at WP:VPR at the moment that may be of interest to technically-minded editors. Both of them suggest configuration changes, so wide participation and affirmations of support or opposition would be greatly appreciated. The first, P: and T: Pseudospaces, is to create two new namespace aliases for the Template: and Portal: namespaces. The second, Change default category sortkeys, is to change the default method of categorisation used here. Input to both would be greatly appreciated. Happy‑melon 14:57, 25 November 2008 (UTC)[reply]

What's wrong with people that they can't type "Template" and "Portal"? Are their fingers crippled? :) --brion (talk) 21:35, 25 November 2008 (UTC)[reply]

Good thing neither of these namespaces happened to start with a "D", or we'd have real problems, see above #The D: Prefix. — CharlotteWebb 14:46, 26 November 2008 (UTC)[reply]

Copying articles that end in a bracket

I want to email an article to somebody, but if the page name ends in a closing parenthesis, eg. Laches (equity), it won't copy because the closing bracket stays outside the filename. Can't this be fixed? JohnClarknew (talk) 22:03, 25 November 2008 (UTC)[reply]

You asked the same question on the Help desk in August. I think I understand the problem now. What you see in the "location bar", is a "readable" url, but it is not the "safe" version of the url. When you copy it into an email, and send it, most email programs try to create a link that you can click. This usually goes without trouble, but when the URL ends in " or ), this often fails (because it is not the urlencoded "safe" version of the url). There is no good solution to this unfortunately. If you URLencode the brackets yourself before sending, then it will work, but that is very cumbersome. The easiest way to prevent this is the following:

Click the Edit tab for the article
Copy this url instead
Paste the url
Where it says: "action=edit" in the url, change it to "action=view"
Send and there should be no problems.

--TheDJ (talk • contribs) 22:34, 25 November 2008 (UTC)[reply]

Adding ?action=view to the end of the normal url will probably also work for you. Actually, just adding ?a should also work because unrecognized endings after ? are simply ignored, but it may confuse the recipient. Note that the treatment of url's depends on the used mail software. Some people use software that never gives a clickable link when they read mail. They may not see the same as you when you send the mail. PrimeHunter (talk) 22:54, 25 November 2008 (UTC)[reply]

Alternatively, you could use a service such as TinyURL to change a Wikipedia URL into a shorter one with no funny characters. This has the additional advantage of preventing a long Wikipedia URL from being split across lines by your e-mail program (or the recipient's e-mail program), which can often mess up links too. On the other hand, it has the disadvantage that the link is not at all clear about what it links to, because it looks like "http://tinyurl.com/2unsh". —Bkell (talk) 01:59, 26 November 2008 (UTC)[reply]

Also see Help:URL. --—— Gadget850 (Ed) ^talk - 13:00, 26 November 2008 (UTC)[reply]

I find that the easiest solution is to add ?a before sending, it works. So thanks for your suggestions to solve this very irritating problem. JohnClarknew (talk) 18:31, 26 November 2008 (UTC)[reply]

Thanks from me too. I was looking for a solution to this last year (See bugzilla:11056). (Mozilla Thunderbird trips over these urls, but Gmail and Claws Mail (the only other programs I was able to test) understood that the ")" was part of the url.) -- Quiddity (talk) 23:15, 27 November 2008 (UTC)[reply]

Search result, poses a question

Why does this search[2] appear to lead to “(section Naval service in World War II)”, rather than to where it is mentioned in Gerald Ford#Foreign policy? This question was previously asked here, but answer seemed inconclusive. CasualObserver'48 (talk) 02:09, 26 November 2008 (UTC)[reply]

How it works now is to just match section names to the query ... but we should have it look at content as well... --rainman (talk) 18:06, 26 November 2008 (UTC)[reply]

Template talk:Sample box end

The protected template {{Sample box end}} causes typesetting problems in articles like S.H.E#Musical style. I think it is misses out the parameter " </div> ". Any administrators can confirm the causes and fix this problem? Weltanschauung☯Ĥòĭnäþbåķtšýñ 06:00, 26 November 2008 (UTC)[reply]

You're correct. I've added an {{editprotected}} request on the template's talk page. Anomie ⚔ 11:56, 26 November 2008 (UTC)[reply]

Reference Desk

Do other folk see "<i>Search Wikipedia:</i> " when they look at WP:RD? Should it be there? -- SGBailey (talk) 16:30, 26 November 2008 (UTC)[reply]

Yes, looks to be from the <inputbox>. I'll inform a dev --TheDJ (talk • contribs) 16:42, 26 November 2008 (UTC)[reply]

Sorting bug with N/A elements

Sorting a table by a column seems to have problems if there are N/A elements in the table. For example, try sorting this one (click the little box near "Col"):

Col
3
4
—
2
N/A
1

Does that work strangely or is it just my computer? Seems to work differently depending on whether I use Firefox or Konqueror, but wrong in both cases. (84.250.144.242)

Fails for me also. The code for sorting tables is at:

http://upload.wikimedia.org/skins/common/wikibits.js

Don't ask me why it's on the image server. Rather than having to edit every table in every article, it might be easier to add a special case for the following html:

<td style="background: #ececec; color: grey;" class="table-na"><small>N/A</small></td>

For whatever column we are sorting by would probably want the rows which have "N/A" cells in that column to move to the bottom (regardless of whether we are sorting "up" or "down")

Since the same javascript is now being shared by all wikis we would also want to standardize any "N/A" templates on other sites so they also use class="table-na", but fixing it for us wouldn't break anything for them that wasn't already broken.

On a side note, the color and background for N/A cells should be an attribute of the css class (thus user-configurable) rather than forced. — CharlotteWebb 20:59, 26 November 2008 (UTC)[reply]

This is a bit messy. What fails and how does it fail? Did you try making a sorting template of some kind that would fix this ? --TheDJ (talk • contribs) 12:19, 27 November 2008 (UTC)[reply]

To explain this a bit. The "type" of columnsorting applied (numeric vs. alphanumeric), is determined by the contents of the first row. So because the first row in the code is 3, numeric sorting is likely applied and breaking on the alphanumeric n/a. If you need this working "right now", you can do the following: {{N/A|{{sort|0|N/A}}}} --TheDJ (talk • contribs) 13:49, 27 November 2008 (UTC)[reply]

For me it sorts in the order "N/A", 1, 3, 4, "N/A", 2 but I haven't confirmed the previous user's claim of different orders in different browsers. The solution I suggested is to, when sorting, temporarily disregard anything with the standard N/A value, sort the others, then put the N/A's at the bottom (in their original order relative to each other). Unless there is some reason to do it differently I will try to get some code which does that. — CharlotteWebb 16:39, 27 November 2008 (UTC)[reply]

Optimizing code for template

I have created a template for a table, and wanted to simplify the code below as much as possible. It's just one of the table row, with obvious repetition within it.

{{for loop|{{!!}}|{{!}}{{{FA1}}}|{{{FA2}}}|{{{FA3}}}|{{{FA4}}}
|{{Format price|{{#expr:{{{FA1}}}+{{{CL}}}}}}}|{{Format price|{{#expr:{{{FA2}}}+{{{CL}}}}}}}
|{{Format price|{{#expr:{{{FA3}}}+{{{CL}}}}}}}|{{Format price|{{#expr:{{{FA4}}}+{{{CL}}}}}}}
|{{Format price|{{#expr:{{{FA1}}}+{{{DP2}}}}}}}|{{Format price|{{#expr:{{{FA2}}}+{{{DP2}}}}}}}
|{{Format price|{{#expr:{{{FA3}}}+{{{DP2}}}}}}}|{{Format price|{{#expr:{{{FA4}}}+{{{DP2}}}}}}}
|call=1x}}

I know that MediaWiki has this template that utilizes "$n$" that increments number from 1, which would be great for my case, but unfortunately it isn't here. Since this template is rarely edited by others, I don't mind if the code is difficult to understand, so long that it works.

So, does it require another template to assist the optimization, or can it be simply shortened? Hytar (talk) 21:09, 26 November 2008 (UTC)[reply]

cross-wiki linking should be listed in editing help

One of the harder things to do is to figure out how to do cross wiki article links.

How do I link to en-wiki articles from the commons? How do I link to wiktionary from en-wiki?

Where can I find a list of all these secret keywords? This is not at all obvious, and there's nothing in the editing help that I can find that explains this. So alas here I am asking for a human to help. :( DMahalko (talk) 23:56, 26 November 2008 (UTC)[reply]

See Wikipedia:InterWikimedia links, and, for the English Wikipedia, Wikipedia:Wikimedia sister projects. Graham87 01:33, 27 November 2008 (UTC)[reply]

Server breakages?

When I use &maxlag=5, I'm getting back:

Waiting for 10.0.6.22: 12620 seconds lagged

That's a lot of seconds, isn't it? Is it a problem that unplugging something would fix, preferably at the NOC, as opposed to my own system? Franamax (talk) 01:45, 27 November 2008 (UTC)[reply]

PS I don't use 10.0.0.0 on my internal net. Franamax (talk) 01:46, 27 November 2008 (UTC)[reply]

It appears to be db12. I pinged a few sysadmins on IRC, we'll see if any bite. Mr.Z-man 04:40, 27 November 2008 (UTC)[reply]

The problem was apparently fixed. Lag seems to be going back down, it'll take a while to catch up. Mr.Z-man 05:57, 27 November 2008 (UTC)[reply]

Thanks Z. Would I be right in thinking that many, many bots timed out over the last four hours, or was I just bound to the faulting server along with some subset of users? Franamax (talk) 06:03, 27 November 2008 (UTC)[reply]

No, maxlag should return the server with the maximum lag for all requests, hence the name (though it probably only affected the English Wikipedia).`Mr.Z-man 06:52, 27 November 2008 (UTC)[reply]

Getting old pages from the cache

Hi all,

Myself and one of the other editors seem to be getting old pages from the cache. It's really annoying. Is this replication lag? Shift-reload isn't fixing it. - Richard Cavell (talk) 06:35, 27 November 2008 (UTC)[reply]

With ref to the thread immediately above, it looks like one of the servers coughed up a big fur-ball over the last several hours and is only now catching up. Many times you can see after the fact what happened at the server admin log, but I haven't seen anything there yet. This may be a "wait a few hours, try again" thing. Franamax (talk) 07:13, 27 November 2008 (UTC)[reply]

Adding ?action=purge to the page request should get you the up-to-date page no matter what. example Franamax (talk) 07:21, 27 November 2008 (UTC)[reply]

Editing others' scripts

Any way a non-admin can edit another account's scripts? In this case, my primary account's? (Maybe a whitelist or something... just guessing.) -- Menti sock 10:50, 27 November 2008 (UTC)[reply]

No, there is no way that the hardcoded protection of other users' .js and .css files can be overridden. I suppose you could do something wierd like move your scripts to an unprotected page and (very carefully!!!) write some code to load the last version of that page that was created by a whitelist of users. But that would be very messy indeed. Happy‑melon 11:01, 27 November 2008 (UTC)[reply]

Just nominate the user for adminship. It's the only way, which is annoying if people don't really want to be admins. --TheDJ (talk • contribs) 12:16, 27 November 2008 (UTC)[reply]

Actually that's a good idea, and it wouldn't be difficult to do if there is a real demand for it. — CharlotteWebb 16:21, 27 November 2008 (UTC)[reply]

Reference desk

Will someone please look at Wikipedia:Reference desk? There is some information being shown in html rather than the wiki code. Please help. Thanks. Zain Ebrahim (talk) 11:49, 27 November 2008 (UTC)[reply]

I have reported this on IRC to devs, but I guess they have more important stuff atm. I created a bug ticket so that you can track the issue. In the mean time, an admin can fix this by removing the "labeltext" line from Wikipedia:Reference_desk/RD_header. The label will no longer be present, but it should be less confusing to the users than what you see atm. --TheDJ (talk • contribs) 12:07, 27 November 2008 (UTC)[reply]

Thank you. The header is only semiprotected so I removed that line like you suggested. Zain Ebrahim (talk) 12:15, 27 November 2008 (UTC)[reply]

Wikipedia Search

High (very high), I am Janezdrilc, admin on sl:. I have a proposal how to improve a Wikipedia Search options. As admin I miss an option to search within erased articles, so I thing it would be very handy to have a one little square more on the site where you can select Erased articles. And there is one other thing: select all and deselect all options. Ok, those are just two ideas I am expecting to be realised :) Have fun. --Janezdrilc (talk) 13:40, 27 November 2008 (UTC)[reply]

This belongs on the Village pump proposals page (and we call them "deleted articles", not "erased articles"). Also, this is two separate ideas, I think; not so good to discuss them in the same topic. -- John Broughton (♫♫) 11:32, 28 November 2008 (UTC)[reply]

When non-admins can delete a page

I was suggesting that non-admins will be able to delete a page if they are the sole contributor to it. This way, the {{Db-author}} tag will no longer be necessary. -- IRP ☎ 14:44, 27 November 2008 (UTC)[reply]

Pagemoves create redirects with only a single author. It would cause a lot of confusion if such pages could be easily deleted. Kusma (talk) 14:53, 27 November 2008 (UTC)[reply]

Redirects pointing at a live page could be excluded from "Easy deletion", to give this feature a name. Jehochman ^Talk 15:02, 27 November 2008 (UTC)[reply]

So will the feature be implemented? -- IRP ☎ 15:06, 27 November 2008 (UTC)[reply]

We could use a bot to automatically delete redirects that point to non-existent pages. -- IRP ☎ 15:08, 27 November 2008 (UTC)[reply]

We could call it RedirectCleanupBot. Algebraist 15:10, 27 November 2008 (UTC)[reply]

Could this not be extended to editors for pages that are blatant vandalism or attack pages. It could be given to trusted editors like the Rollback feature. BigDunc^Talk 15:33, 27 November 2008 (UTC)[reply]

There is no way that anybody could harm Wikipedia by deleting their own pages. I also suggest that we can delete pages within our own userspace. This way we can make {{Db-U1}} obsolete. -- IRP ☎ 16:04, 27 November 2008 (UTC)[reply]

Just saying that editors who do a lot of new page patrol often come across pages with for example Joe Bloggs is gay or pages with strings of letters and instead of tagging for speedy trusted editors could delete these pages. BigDunc^Talk 16:18, 27 November 2008 (UTC)[reply]

This would require the software to reliably determine whether or not a page is vandalism (in which case it could just delete it and skip the middleman). Otherwise this has similar problems with the proposal to allow non-admins to view deleted pages (which was shot down by the foundation's lawyer) or allow non-admins to delete pages, but not undelete them. Mr.Z-man 20:44, 27 November 2008 (UTC)[reply]

_________________________|
|
A better idea would be something like Special:RecycleBin, which can only be viewed by administrators and rollbackers. Administrators and rollbackers will patrol it and either an administrator will delete a page, or an admin/rollbacker will restore a page that shouldn't have been recycled. -- IRP ☎ 17:38, 27 November 2008 (UTC)[reply]

How is that any different than C:CSD though? Prodego ^talk 17:40, 27 November 2008 (UTC)[reply]

For the pages I am talking about they will never be restored as they are blatant. You often have situations where an attack page is left for quiet a while because editor has placed a {{hangon}} template on the page. Let trusted users delete pages like this. BigDunc^Talk 17:48, 27 November 2008 (UTC)[reply]

Well, then you're entering the admin field... after all, admins are already trusted users... trusted with the delete tool. If normal users can delete as well what're admins for? -- Menti sock 17:55, 27 November 2008 (UTC)[reply]

The idea of the recycle bin is to limit the amount of people that see the attack page. Once an administrator approves it for deletion, it will be deleted. Just with a speedy deletion tag on it, anybody can view it. -- IRP ☎ 17:58, 27 November 2008 (UTC)[reply]

(edit conflict)Not every case would be clear vandalism and it would free up admins to deal with other tasks. We have all seen these pages and tagged them when we could have just deleted them. Maybe they could go to some holding area/recycle bin for review as a saftey net. BigDunc^Talk 18:02, 27 November 2008 (UTC)[reply]

Which admins aren't deleting blatant attack pages if it has a {{hangon}} tag? I may need to have some words with them... Brand new pages aren't going to be seen anywhere other than C:CSD and Special:Newpages. The risk of having them sit around in public for a couple minutes is basically nil. Mr.Z-man 20:44, 27 November 2008 (UTC)[reply]

The whole idea would lead to a splitting of the admin tools, even only for a certain kind of task. Sounds like Wikipedia:PEREN#Hierarchical structures. Regards So Why 18:06, 27 November 2008 (UTC)[reply]

You mean like the status quo? — CharlotteWebb 21:06, 27 November 2008 (UTC)[reply]

I was suggesting that non-admins will be able to delete a page if they are the sole contributor to it. This way, the {{Db-author}} tag will no longer be necessary. Is there a significant number of such cases where the {{Db-author}} templates are used? If not, let's move on.

If there is enough volume to want to remove this work from admins, then I think the best solution is a bot to delete pages marked with that template, where (as mentioned) only one editor has made all the edits to that page, including the template request for deletion. And yes, that requires giving another bot admin powers, which is always going to be controversial. But the more we can remove mundane, non-risky tasks from admins, the better.

And this discussion really belongs on the Village pump proposals page. -- John Broughton (♫♫) 11:27, 28 November 2008 (UTC)[reply]

Special:RecentChanges filtering

Is there an internal wiki link for filtering by namespace (I tried /mediawiki, /ns8 etc.) without turning it into an external link? -- Menti sock 17:27, 27 November 2008 (UTC)[reply]

Not really, but you can get close by using {{fullurl:}} and class="plainlinks", like this. —Ilmari Karonen (talk) 17:45, 28 November 2008 (UTC)[reply]

Wikipedia:Wikipedia Signpost/2008-11-17/Features and admins

What's wrong with the Austins Ferry image? Little Red Riding Hoodtalk 19:29, 27 November 2008 (UTC)[reply]

I think the file size is just way to big; the resolution is 12,919 × 1,892. Icewedge (talk) 20:38, 27 November 2008 (UTC)[reply]

Problems printing articles with blank pages

Recently I have had problems printing articles from Wikipedia. Large parts of text disappear and all that gets printed instead are blank pages. I am using Microsoft Office 2007 both at home & work and it happens in both places. Has anyone encountered this problem and have a solution ?

--Pgcohen (talk) 01:00, 28 November 2008 (UTC)[reply]

What procedure, exactly, are you using to print Wikipedia articles? Algebraist 01:01, 28 November 2008 (UTC)[reply]

I use the print button - it also happens when I try to print the printable version. --Pgcohen (talk) 01:03, 28 November 2008 (UTC)[reply]

The print button in which program? You mentioned Microsoft Office 2007 but a web browser, for example Internet Explorer, is usually used to view and print articles. If you try to copy an article to Microsoft Word then different problems can occur. PrimeHunter (talk) 01:12, 28 November 2008 (UTC)[reply]

OK - good point - I use IE 7.0. Actually, I recently copied part of an article into MS Word to print missing pages (which worked).--Pgcohen (talk) 01:18, 28 November 2008 (UTC)[reply]

Avoid having it in printable version

Those huge images in Reference_ranges_for_blood_tests#Sorted_by_concentration have a separate, vertical, image for printing: Image:Blood values for print.png

However, how to avoid these images to appear in the usual printable version of the article (where they are of little use when they are horizontal)? I know there is a tag for it, since fix-tags, such as "^[who?]" use it. Mikael Häggström (talk) 10:03, 28 November 2008 (UTC)[reply]

I don't want to be in the printable version!

Wrap it in <div class="noprint"></div>. Algebraist 15:13, 28 November 2008 (UTC)[reply]

Fix requested (IAItoc)

What is Category:IAItoc? It is empty and undescribed. Used in 3 articles and one template. Could not find the cause. Please fix, thanks, --77.4.55.167 (talk) 22:02, 28 November 2008 (UTC)[reply]