Jump to content

Wikipedia:Village pump (technical)

From Wikipedia, the free encyclopedia

This is an old revision of this page, as edited by Greedyredbag (talk | contribs) at 14:20, 24 March 2006 (Nocover.gif trouble). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

 Policy Technical Proposals Idea lab WMF Miscellaneous 
The technical section of the village pump is used to discuss technical issues. Bugs and feature requests should be made at BugZilla since there is no guarantee developers will read this page.

FAQ: Intermittent database lags can make new articles take some minutes to appear, and cause the watchlist, contributions, and page history/old views sometimes not show the very latest changes. This is an ongoing issue we are working on.

Newcomers to the technical village pump are encouraged to read these guidelines prior to posting here.

Discussions older than 7 days (date of last made comment) are moved here. These discussions will be kept archived for 7 more days. During this period the discussion can be moved to a relevant talk page if appropriate. After 7 days the discussion will be permanently removed.

Golden Gate Bridge Article

I added a panoramic image a few days ago. It displayed properly. I looked at the article today and got an error in the image space: Error creating thumbnail: convert: Insufficient memory (case 4) `/mnt/upload3/wikipedia/commons/3/3c/Ggb03162006.jpg'. convert: missing an image filename `/mnt/upload3/wikipedia/commons/thumb/3/3c/Ggb03162006.jpg/600px-Ggb03162006.jpg'.

The weird thing is it worked a few days ago.

Still trying to get rid of the banner ad in watchlist; help!

I have been trying for two weeks now to get rid of the banner ad in my Watchlist about 'e-mail must be confirmed' (I do not have an e-mail to confirm). Several people have made suggestions (thank you, all!) but none work. I have created a User:quota/monobook.css with the magic incantation. I have erased all files and temporary files. I have rebooted endless times. But I still get that banner which displaces all useful information off the bottom of the page.

Why isn't there a way to say 'yes I have seen this, thank you'? Following the links is hopeless .. one just goes around a loop.

Really would appreciate some help on this! quota 22:10, 9 March 2006 (UTC)[reply]

There's no "banner ad"; there's a helpful message someone put in about a change in the system. If you don't want to read it over and over, don't read it. --Brion 00:00, 10 March 2006 (UTC)[reply]
Well, with the huge space above and below and three lines in the box it takes about six lines of my screen, which means on the first screen ther are only 2 or 3 watchlist items. It's hard to see how that's 'helpful' :-) quota 09:15, 10 March 2006 (UTC)[reply]
Alright, the instructions for doing this are really simple, so read this several times if you need to:
  • Edit that file. Yes, it should be blank. Go to edit and it will bring up an edit screen.
  • Add this:

#confirmemail { display: none; }
...then and save the file.

  • You will then need to do a hard refresh of your browser. You will need to press Control-F5 if you're using Internet Explorer, or Control-Shift-R if you're using Mozilla/Safari/Konqueror or F5 if you're using Opera.
  • Go to your watchlist and the message should be gone.

- File:Ottawa flag.png nathanrdotcom (TCW) 00:15, 10 March 2006 (UTC)[reply]

Many thanks for the detailed instructions! They are pretty much what I'd garnered from other posts scattered about.
I've tried them again, following exactly that procedure, and there is absolutely no effect. (This on IE.) Any idea when the box will go away of its own accord? quota 09:15, 10 March 2006 (UTC)[reply]
Ah, a thought .. could it be that the reason it does not work is because I am using the 'Classic' Skin? If so, is there some other way to get rid of it? -- Thanks. quota 09:18, 10 March 2006 (UTC)[reply]
Use User:Quota/standard.css instead. Sam Korn (smoddy) 09:34, 10 March 2006 (UTC)[reply]
That seems to have worked. Thank you! 05:19, 17 March 2006 (UTC)
Maybe for these banner-boxes a checkbox 'please don't show me this again' would save many frustrating minutes and hours. I would much rather spend time editing than trying to work around this sort of thing. quota

Deleted Articles

I've noticed that it is some vandals favorite activity to create hoax articles. However, once these articles are deleted they disappear from the user's contribution list. Is there any way to see what articles a user has created, including deleted articles? It seems like it would be useful, since these articles take up more overall energy to fix than simple vandalism, and if it was known that a user tended to create hoax articles, then less time could be spent triple checking that it was indeed a hoax. Makemi 06:16, 5 March 2006 (UTC)[reply]

Not at this time. --Brion 06:57, 5 March 2006 (UTC)[reply]
But we could make note of it on their talk page esp. in the Edit Summary. It'll take an extra step to check out, but the edit summary would quickly bring this matter to attention, and it's not something the user can make go away. Rklawton 07:22, 5 March 2006 (UTC)[reply]
Is there an attempt to bring back deleted article list? --Masssiveego 03:40, 10 March 2006 (UTC)[reply]

Brion's working on changes to the way we mark specific data as deleted, which appears to include different levels of visibility. Looks like the old deleted revisions stuff will be reborn in shiny new packaging. Rob Church 07:49, 17 March 2006 (UTC)[reply]

PRE on user style pages

I noticed that the automatic <pre> style that used to be present on user style pages, and apparently on MediaWiki style pages too, has been removed, along with the warning that you have to clear your browser's cache to see changes. Manually adding /*<pre><nowiki>*/ to the beginning of a document is sort of cumbersome; why was this feature removed? Phoenix-forgotten 21:18, 8 March 2006 (UTC)[reply]

Please provide a URL to such a page. Rob Church (talk) 07:43, 10 March 2006 (UTC)[reply]

It looks like MediaWiki:Common.css and MediaWiki:Monobook.css are two examples besides my user style page. Phoenix-forgotten 01:44, 11 March 2006 (UTC)[reply]

The user subpage seems fixed to me (the cache warning shows up, and it's pre'd etc. fine) but I'm not sure about the former. Could be inconsistencies with the software's handling of what constitutes a CSS or JS subpage. Going to take a look, since I suspect the last person to poke that was me. Rob Church 07:47, 17 March 2006 (UTC)[reply]
Confirmed the user thing is fine for me. The MediaWiki:Common.css et al. pages never had this editing quirk added in the first place. I'll look into adding it since it's useful. :) Rob Church 20:38, 17 March 2006 (UTC)[reply]

My user CSS page seems to have its auto-PRE back. Dunno what was wrong last week, but it's fine now. :) Scratch that; it's still buggy. Apparently it only gets broken after I've edited it. The page probably gets stuck in the server's cache as a non-CSS page, because it goes back to normal after I purge it. Phoenix-forgotten 19:39, 19 March 2006 (UTC)[reply]

See also monobook.js rendering as wikitext sometimesOmegatron 20:18, 19 March 2006 (UTC)[reply]

Hiding robot edits in watchlist

Buzilla: 4895

Please vote for this feature. My watchlist is unusable until this feature is activated. Of the 120 items on the first page of my watchlist, over 80 are from bots. It's as simple as setting $wgFilterRobotsWL = true;... we just have to wait for a dev to actually make this change... — 0918BRIAN • 2006-03-9 20:23

Please note that Brion Vibber has now marked this bug WONTFIX. Rob Church (talk) 07:40, 10 March 2006 (UTC)[reply]
And for follow-up, it's been REOPENED pending a fix to the feature Brian cited. Rob Church 07:44, 17 March 2006 (UTC)[reply]

index.php/Article

Hi. I was wondering how you got index.php/Article to be the same as index.php?title=article. I was wondering becuase I am writing a program in php, and this would allow for a much cleaner URL. Thanks, Shardsofmetal [ Talk | Contribs ] 19:22, 4 March 2006 (UTC)[reply]

Some instructions about how to configure a MediaWiki installation are found at Using a very short URL, and that may have the answer to your question. Titoxd(?!? - help us) 22:39, 4 March 2006 (UTC)[reply]
See $_SERVER['PATH_INFO']. Note this is not always available. --Brion 00:29, 5 March 2006 (UTC)[reply]

Thank You. Unfortunately, it didn't answer my question. This is my fault, I didn't word my question the way I should have, and I apoligize. What I actually wanted to know is from a programming perspective, how is it that you can program a file so that when called with a /variable, you can tell it to set variable as a certain variable. I hope that this is worded all right. Thank you, Shardsofmetal [ Talk | Contribs ] 03:34, 11 March 2006 (UTC)[reply]

This is either closely related to, or the same as, a question I've been having: when the web server sees "index.php/Article", how is it that it does not blindly try to treat "index.php" as a directory, and "Article" as a standalone page within it? Is apache smart enough to notice that when a seeming directory compoent within a URL (a) exists but is (b) not a directory but (c) is a server-side script, it might be okay to run that script and let it interpret the rest of the pathname? —Steve Summit (talk) 05:19, 11 March 2006 (UTC)[reply]
Short answer: Yes. rspeer / ɹəədsɹ 05:40, 11 March 2006 (UTC)[reply]
Is it possible to get a long answer (or a link to where it is described), because I do not know how to do this, but would like to. Thanks, Shardsofmetal [ Talk | Contribs ] 18:40, 11 March 2006 (UTC)[reply]
Learn about .htaccess, you'll find that Wikipedia simply instructs Apache to blindly send everything after wiki/ to title variable. — Ambush Commander(Talk) 17:31, 12 March 2006 (UTC)[reply]
Well, the long answer is "Go to http://httpd.apache.org/ and download the Apache web server source code." The short answer was already given above. --Brion 05:33, 13 March 2006 (UTC)[reply]

If you haven't figured it out already, add:

RewriteEngine on
RewriteRule ^wiki/(.*)$ index.php?title=$1

to your .htaccess file. Make sure that you have the rewrite module loaded by having:

LoadModule rewrite_module modules/mod_rewrite.so
AddModule mod_rewrite.c

in your httpd.conf file. Tristanb 08:31, 14 March 2006 (UTC)[reply]

No, it has nothing whatsoever to do with rewrite rules. (Though you can accomplish similar things that way.) --Brion 08:51, 14 March 2006 (UTC)[reply]
Expanding on what Brion said, the way Wikipedia does it can't possibly be mod_rewrite, because Wikipedia does not require use of .htaccess at all, as I discovered when I downloaded mediawiki and started playing with it myself. (That is, the mediawiki installation documents do not tell you to create a .htaccess file; the -- very nicely automated, btw -- mediawiki installation procedure does not create a .htaccess file for you; and my own mediawiki installation is working just fine, including with respect to subdocuments, and there's no .htaccess file in its /wiki directory.) But it's true, there's a zillion Apache modules out there which can do all sorts of things, and the perl motto probably applies: "TMTOWTDI".
(As an aside, there's a school of thought that suggests that mod_rewrite might not be the first tool you should reach for when performing some URL-related trick. To be sure, and as its own documentation proclaims, it is "the Swiss Army Knife of URL manipulation". But its documentation also contains two cautionary quotes: "The great thing about mod_rewrite is it gives you all the configurability and flexibility of Sendmail. The downside to mod_rewrite is that it gives you all the configurability and flexibility of Sendmail. [Brian Behlendorf]" "Despite the tons of examples and docs, mod_rewrite is voodoo. Damned cool voodoo, but still voodoo. [Brian Moore]")
Shardsofmetal's question still remains, though: once apache has looked at the URI components "index.php/Article", determined that "index.php" is not a directory, determined that "index.php" is a server-side script, and called it, how does index.php recover the string "/Article"? (Yeah, I know, I could figure this out by looking at the source code, but I haven't delved into it yet.)
Steve Summit (talk) 14:17, 14 March 2006 (UTC)[reply]
I already provided exactly that information on March 5. Please read above. --Brion 00:40, 15 March 2006 (UTC)[reply]
Sheesh. Sorry. Thanks. —Steve Summit (talk) 18:19, 22 March 2006 (UTC)[reply]

RTFS. 86.134.49.239 22:02, 14 March 2006 (UTC)[reply]

Telescopic taxobox

I could never describe myself as a deletionist, but I am all for hiding information that isn't immediately useful.

So here's my proposal for a telescopic taxobox, allowing taxonomic groups which are currently missing to be simply hidden, rather than absent:

Normal view Expanded view Proposed template usage
 {{Taxobox
 | image = Pleorodeles_waltl.jpg
 | image_caption = In an aquarium
 | color = pink
 | name = Iberian Ribbed Newt
 | regnum = [[Animal]]ia
 | unranked_phylum = [[Bilateria]]
 | unranked_phylum_hide = true
 | superphylum = [[Deuterostomia]]
 | superphylum_hide = true
 | phylum = [[Chordate|Chordata]]
 | superclassis = [[Tetrapoda]]
 | superclassis_hide = true
 | classis = [[Amphibia]]
 | subclassis = [[Lissamphibia]]
 | subclassis_hide = true
 | ordo = [[Urodela]]
 | familia = [[Salamandridae]]
 | genus = ''[[Pleurodeles]]''
 | species = '''''P. waltl'''''
 | binomial = ''Pleurodeles waltl''
 | binomial_authority = ...
 | range_map = ...
 }}

The shrunk version is more readable. The expanded version is more complete. And this way little compromise needs to be made between them. A third click could perhaps hide the classifcation all together, and show just the binomial name.

I was hoping the mechanism could coopt the Hide/Show button from the Table of Contents box, but my attempts have so far failed (see /teletaxotest). A page that does does something similar (but hides the whole box, not just parts) is here: User:Essjay/CVU/IRC/Verifications

Which classifications would be hidden would be set per species or taxon. (see parameters ending in _hide in the proposed template usage above).

Anyway, I've pretty much given up on making this myself. I suspect it would need some extra Javascript that would have to be added to the main javascript file of the Wikipedia. But anyone else who wants to give it a go, please do.

Note: I have noticed that the metadata on images is collapsable, and maybe the javascript it uses can be hijacked. (e.g. see Metadata section on Australia_Cairns_Koala.jpg) but I haven't attempted to use this approach as yet.


I'm wondering if someone were to make this work using some javascript if it would be possible to add javascript to the wikipedia's main .js file? Perhaps if it were a generic solution?

Pengo 08:58, 11 March 2006 (UTC) (/rants)[reply]

The template {{Afd}} has a "show/hide" button that only modify part of the box. However, it is in a fixed position, so it may not be what you are looking for. - Liberatore(T) 15:03, 11 March 2006 (UTC)[reply]
It can not be done using the javascript as it is now, but it can easly be an generic code-snip. Simlar for this:
<div class="hiddenStructure"> <!-- Outer container-->
<div class="hiddenStructureButton">Button...</div>
<div class="hiddenStructureElement"></div>
<div></div>
<div></div>
<div class="hiddenStructureElement"></div>
</div>

using

#Pseudo code (don't remeber all js at the moment :))
foreach(element = getElementsByClassName('hiddenStructure')){
element.getElementByClassName('hiddenStructureButton').addEvent(...);
foreach(element = getElementsByClassName('hiddenStructureElement')){
element.connect(event button);
}
}

function hideElement(element){
element.style.display='none';
}

etc...

AzaToth 01:12, 12 March 2006 (UTC)[reply]

Note that the 'missing' taxons are generally left out deliberately and people working on the project will often go through and remove 'extra' taxons. Generally we show each of the major (Kingdom, Phylum, Class, et cetera) higher taxons, but not the sub-groupings (Super-phylum, Subclass, et cetera) unless one of those is the 'next higher' level above the article subject. --CBDunkerson 20:49, 12 March 2006 (UTC)[reply]
I'm not sure if you're addressing me or making a general comment here, but i'd like to clarify anyway. The point of the this suggestion is to allow the deliberately removed taxons to be merely hidden, rather than deleted. As I understand, they are only removed to save space. As the condensed version of the taxobox can be lacking in information, if not misleading, I'd like to keep them but in a hidden state, rather than have them deleted. —Pengo 01:05, 15 March 2006 (UTC)[reply]
In addition to 'saving space' the extra taxons are often left out because such 'sub-groupings' are often speculative or disputed and subject to more frequent change than the primary taxons. Also, the CSS based methods of implementing this which you are currently pursuing (hiddenStructure and the like) do not work for all users... such that if you are 'successful' the result would be that some users (people with text browsers, people with screen-readers for the blind, people on non-English language Wikipedias and Wikipedia mirrors) would always get the 'uncollapsed' format. --CBDunkerson 13:00, 18 March 2006 (UTC)[reply]
You have some valid points: Yes, some people would be stuck with an uncollapsed view, but they'd be stuck with valid information, quite unlike how some people have used "hiddenStructure" to "hide" nonsense code, so I don't see it as such a problem. The problem of the taxa being speculative and/or disputed is probably less surmountable, but I suspect that would be the exception rather than the rule? The extra taxa in the example above were all taken from Wikipedia articles. E.g. the grouping "deuterostomia" is revealed in the taxobox for chordate but is missing in all the taxa below it. Anyway, thanks for discussing this issue, I currently have no plans to persue it further as the gain is simply not that great and there are much more worthy low hanging fruit (like filling in conservation status where it's missing). Cheers. —Pengo 01:24, 20 March 2006 (UTC)[reply]

Random Number Function ?

Is there existing functionality to parse a random number using wikimarkup at this time. An extension appears to be availible on meta m:User:Algorithm/RandomSelection. And apparently other wiki's (e.g. uncyl..) are using this with success? -- xaosflux Talk/CVU 05:46, 12 March 2006 (UTC)[reply]

What would it be useful for on Wikipedia? —Simetrical (talk • contribs) 20:29, 12 March 2006 (UTC)[reply]
A random number generator would allow pages to display random content. The closest thing we have to that currently is what I've done with Portal:Featured content where a different set of past picture/article of the day are displayed from a randomized list every sixty seconds. However, that isn't truly random and it relies on a huge switch to do the evaluation. Actual random features would allow much greater flexibility with much less processing resources required. --CBDunkerson 20:37, 12 March 2006 (UTC)[reply]
Ouch, just looked at Wikipedia:Featured content/SetDate, and it looks like a great candidate for a RND() function! xaosflux Talk/CVU 05:34, 13 March 2006 (UTC)[reply]
Absolutely. A simple random function could allow the same (actually better) functionality in a vastly smaller template. Even some basic string manipulation capabilities, such as being able to do right({{NUMBEROFARTICLES}}, 1), could be used to build much better randomization. The last digits of the article count and file count at any given moment would effectively be random numbers between 0 and 9... but a real random feature would be best. --CBDunkerson 00:36, 17 March 2006 (UTC)[reply]

A {{RANDOMNUMBER}} variable as envisioned would be a serious problem for caching of content, which is what keeps us from going under. Like {{CURRENTUSER}}, this one is unfeasible. Rob Church 07:34, 17 March 2006 (UTC)[reply]

It would if it were used on main content pages, but would it have these same issues if used in templates/headers/etc to call other pages that were already cached? — xaosflux Talk 21:55, 18 March 2006 (UTC)[reply]

Je ne comprends pas. Repetez, s'il vous plait. In plain English. Examples. Rob Church 19:41, 20 March 2006 (UTC)[reply]

transwiki instructions

Where is the documentation for the procedures for doing a transwiki to wiktionary and wikisource? RJFJR 17:07, 13 March 2006 (UTC)[reply]

m:Transwiki. -Splashtalk 18:23, 13 March 2006 (UTC)[reply]

Which sucks. We need a better method, one that actually preserves the histories properly. 86.134.49.239 22:06, 14 March 2006 (UTC)[reply]

Hear, hear. -Splashtalk 22:58, 14 March 2006 (UTC)[reply]
Couldn't Special:Export and Special:Import work for this (assuming Export were made able to export the full article history for, say, just admins (right now it just exports the current state/edit details for everyone I believe))? —Locke Coletc 00:58, 15 March 2006 (UTC)[reply]
Well, yes. If Special:Export was fully-functional (yes, it's the same for admins as non at present) and Special:Import at all functional, we would probably have a viable transwiki mechanism... -Splashtalk 16:36, 15 March 2006 (UTC)[reply]

I believe the main concerns with enabling those are

  • People abusing Special:Export and increasing the load without cause
  • People inserting falsified edit histories, etc. via Special:Import

MediaWiki kinda sucks at communicating with other installations of itself. A Special:Transwiki would be an awesome feature, but going about it is a bit more awkward. Rob Church 07:32, 17 March 2006 (UTC)[reply]

Would it be possible to allow access to Special:Export (with full edit history) and Special:Import in the same way it's possible to allow access to (for example) just rollback (and not full sysop privileges)? In this way, editors could request "import/export" privileges and have them granted on a case by case basis. Agreed that a Special:Transwiki would be ideal though. =) —Locke Coletc 07:52, 17 March 2006 (UTC)[reply]

Possible but I suspect it would become unmanageable. Rob Church 19:39, 20 March 2006 (UTC)[reply]

<nopreview> and <previewonly>

Are there directives like those, similar to <noinclude> and <includeonly> ?

I have sections to edit in the middle of a large table. (take a look at Wikipedia:WikiProject The Beatles/Article Classification... each letter is a separate section) Because they are in the middle, when you edit one section, the text is not formatted in preview mode but is jumbled, making it harder to tell what you get when you save. I tried using includeonly which works if you edit an included subsection page (look at User:Lar/Sandbox and User:Lar/Sandbox/album Q, one of the sections) but not so well for what I want as when you click on the section edit tag it edits only a section of the inclusion.

Related question: how do you control the font size of the [edit] tag? It comes up in a very large font, I'd rather it was smaller than the section title. Or am I going about this the wrong way, using sections for editability? Should I be using something else? Forcing edits directly? ++Lar: t/c 23:39, 13 March 2006 (UTC)[reply]

No such directives exist because there's no need for them to. It sounds ridiculous. The styles applied to the section edit links come from the CSS files in the skins and can be overridden with the sitewide customisation or a per-user customisation. 86.134.49.239 22:09, 14 March 2006 (UTC)[reply]
I'm sorry you think "it sounds ridiculous". Frankly, I found that comment rather offputting. I'm not sure who you are so I'll try asking again. I think there is a need for these tags and I've given an example why. Did you take a look at the table I referenced? If you don't understand why, please suggest a different way to achieve it.
The section edit links in the example I gave (again, did you look at it?) are way larger than normal ones. I suspect because the section head is buried in a table cell which is changing what size they are. Changing the sitewide customisation for section heads is probably not the way to address the issue. ++Lar: t/c 23:07, 15 March 2006 (UTC)[reply]
I said it was ridiculous because it sounds like it to me. I don't see the need to hide things from preview, or only show them on preview, which is what such tags would be expected to do, no? As for the section edit links; well, providing context in the future would have helped that misunderstanding. No, changing the sitewide values isn't going to help. Rob Church 07:29, 17 March 2006 (UTC)[reply]
If you don't see the need to hide or show text or markup only during preview I suspect that perhaps you still haven't actually looked at the example I gave. Here is the problem again. Please take the time to look instead of spending time on writing snide commentary if you would be so kind (Please be civil, there is no context in which "ridiculous" is not snide or uncivil when applied to a suggestion, even if you think it actually is validly ridiculous, there are better ways of expressing your opinion). I have written it out again in more detail.
Go here: Wikipedia:WikiProject_The_Beatles/Article_Classification and scroll down to the tables... for example "Articles in Category:The Beatles albums. See how big that "edit" link is on any of the table sections? That's the first problem. Now click one, for example the "B" section: [1] What was a nicely formatted table section when looking at the whole thing is now a jumbled mess in preview, because it's a chunk of a table out of the middle. Editing it is difficult because you can't be sure you did it right, and you have no way to tell without saving (increasing server load and the number of edits to track). But if the putative previewonly tag existed, a pair of previewonly {| and |} bracketing the text would make it all highly legible.
Now... you could say, why do you want to be able to edit one section at a time instead of the whole table? Two reasons. the whole table is big, and you have to scroll around a lot to check your work, but worse, it's subject to edit conflict when multiple project members are busily classifying articles. Hopefully that explains why this is a nice to have. Or alternatively, perhaps there is another way of doing it? One way we thought of is having each table section be a separately included subpage (where using noinclude then gives you the same effect) but that creates hundreds of subpages to manage, which seems icky. ++Lar: t/c 11:48, 17 March 2006 (UTC)[reply]
That page gives me a headache just looking at the design. I see both points raised, yes. I still dispute that we should be allowing people to hide things from the preview; there isn't a massive lot of point in it for all our other pages, is there? Rob Church 20:27, 17 March 2006 (UTC)[reply]
Trust me, it gives me a headache too!... I mentioned nopreview for symmetry reasons but it's previewonly that would allow a fix, nopreview doesn't seem very useful. Do you have any suggestions for improvement of the page, keeping in mind it's relatively high traffic? We had thought (in addition to the separately included subpage mentioned above) of splitting the tables up at the sections, but that causes the cell widths to vary (even with forced percentages in the header row) from one section to the next. Thanks for any suggestions (or pointers on where else to ask for ideas). ++Lar: t/c 05:25, 18 March 2006 (UTC)[reply]

Blank edit fields

Yesterday, between 14:03 UTC and 14:31 UTC, a problem occurred when editing a page where Wikipedia would return an empty edit box when editing a page. This presents a serious problem for bots: they might end up blindly blanking large numbers of pages. Was this problem a one-time thing, or are those of us who run bots going to have to code around it?

(For anyone worried, the only effect this had on my bot was that it blanked its own talk page repeatedly.) --Carnildo 05:01, 14 March 2006 (UTC)[reply]

Is it still happening? If so, we need much more information in order to reproduce, diagnose and fix it. 86.134.49.239 22:15, 14 March 2006 (UTC)[reply]
That's what I'm asking: Is it something that's likely to occur in the future (in which case I'll need to code around it), or was it a one-time thing? --Carnildo 05:23, 15 March 2006 (UTC)[reply]
Long-since fixed, yes. --Brion 20:23, 16 March 2006 (UTC)[reply]
Thanks. --Carnildo 21:18, 16 March 2006 (UTC)[reply]
Scratch that -- the bug (or a similar one) is still there. OrphanBot just blanked an article, and the logs indicate two possibilities:
  1. The page the server supplied contained an empty edit field, or
  2. The server supplied a partial page, cut off sometime after the "wpEdittime" field but before the end of the "wpTextbox1" textarea.
--Carnildo 21:45, 18 March 2006 (UTC)[reply]

Lost amethyst

The skin amethyst was apparently deleted, I had recommended it on Wikipedia:Customisation for legacy browsers without CSS. There should be a skin not depending on CSS magic doing its stuff the old way with pure XHTML, no WP:HIDE tricks, if possible no unnecessary translations of HTML 3.2 entities to UTF-8, and proper name= anchors for <references/>.

Willing to help test and maintain a legacy skin: Omniplex  12:41, 14 March 2006 (UTC)[reply]

The skin was removed because it had something wrong with it, if memory serves. I expect the exact reason is detailed in the release notes for 1.6 or the commit logs. 86.134.49.239 22:11, 14 March 2006 (UTC)[reply]
1) it looked terrible, 2) it was monumentally broken in every browser I tried it in, 3) the author didn't seem to have any interest in fixing or maintaining it. It would have been particularly ugly in browsers with poor CSS support; try the old Classic or Nostalgia skins, or the totally-blank-slate MySkin for that. --Brion 00:43, 15 March 2006 (UTC)[reply]
Apparently I was "moved" to Classic, no problems with that - I could do without the "insert UTF-8 char." JavaScript zoo on my legacy browser with (normally) disabled JavaScript 1.1, but nice to have for legacy browsers would be a waste of time. However a hidden reset-button would be fine to accelerate the insertion of action=raw results, poor man's variant of external editor. Omniplex  02:02, 17 March 2006 (UTC)[reply]

Watchlist by namespace?

I know it's probably been mentioned before, but there's no Talk:Watchlist so I'm bringing it here. What are the odds of being able to filter your watchlist by namespace, like you can with Contributions/Recent Changes? Sometimes I can't be buggered to deal with policy/RfA/*fD questions, but would still like to ensure that no one has vandalized Picts again.

I tried to split out the non-article-space pages I participate in and use Related Changes, but that's really hard to maintain and doesn't automagically update for things like Page Moves. And as much as I'd like to know the special syntax for showing ONLY WP-space watchlisted items, what I'm really concerned about is being able to only-show-articlespace on occasion. Thanks. -- nae'blis (talk) 16:47, 14 March 2006 (UTC)[reply]

You can ask about this on bugzilla:, the developers will probably see it faster there. æle 21:02, 14 March 2006 (UTC)[reply]
Thanks. See below for what I found. -- nae'blis (talk) 22:26, 14 March 2006 (UTC)[reply]

Sounds like something which would be useful to add. I'll get onto that if I have a spare moment, although I recommend filing a feature request if there isn't one.

If there is, please let me have the bug number so I know when to mark it fixed and can take other comments into consideration. 86.134.49.239 22:14, 14 March 2006 (UTC)[reply]

1862 seems to be an identical request, or nearly so, if I'm reading Bugzilla correctly. -- nae'blis (talk) 22:26, 14 March 2006 (UTC)[reply]

I've made a user script to do this: see Wikipedia:WikiProject User scripts/Scripts/Watchfilter. —Ilmari Karonen (talk) 17:32, 18 March 2006 (UTC)[reply]

Gibberish instead of italics

I've been contributing to Wikipedia for some months now. I've just tried logging on from work in my lunch break, but on a different computer from usual. All italic text appears as garbled gibberish (see screengrab). In the past I've had problems with adding and displaying accents until I reset the Preferences in Safari to Unicode, but doing this on this machine hasn't sorted the new problem out. It's an iMac running OSX Version 10.4.5, Safari Version 2.0.3 (417.8). The other machine which I usually use is a Mac G4 running Safari 2.0.2 (416.12) on OSX 10.4.3, and the pages still display fine on there. Does anyone know whether this a Mac OS problem, or a Safari version problem, or is something else going on here? SiGarb | Talk 13:43, 15 March 2006 (UTC)[reply]

Never seen such before, could be some kind of monumental breakage in the operating system. Reboot and see... --Brion 20:11, 16 March 2006 (UTC)[reply]
Thanks. Will try again next time I'm on that machine. Meanwhile, I've reported the bug to Apple. SiGarb | Talk 20:25, 19 March 2006 (UTC)[reply]

Cite.php weirdness

The last footnote of Lack of outside support in the Warsaw Uprising unexplicably begins as bold, despite my having looked the entire paragraph for mismatched apostrophes... Can somebody gives it a deeper look? Circeus 02:13, 16 March 2006 (UTC)[reply]

It's caused by the single quote at the end of "told that the files had been inadvertently destroyed". I'm not sure how best to fix it, though; you might want to get rid of the italics there entirely. —Kirill Lokshin 02:21, 16 March 2006 (UTC)[reply]
(edit conflict) I fixed it. The closing single quote was joined with the two primes ending the italics. — Knowledge Seeker 02:29, 16 March 2006 (UTC)[reply]
m:Cite offers a list of known issues. Omniplex  00:06, 18 March 2006 (UTC)[reply]
This wasn't a problem with Cite.php at all, though. Superm401 - Talk 21:44, 18 March 2006 (UTC)[reply]

IE error seriously annoying

Is anyone looking into the error discussed at the top of this page that occurs in IE when on wiki? Specifically: "In the last week or so, I've had some problems loading Wikipedia pages, mainly diffs and special pages. When I load them the page displays, then a system window pops up saying "Internet Explorer cannot open the Internet site <page address>. Operation aborted" and an OK button. I click the OK button and the page is replaced by a "cannot be displayed" message. Strangely, when I click the back button the page displays perfectly. This happens infrequently and to seemingly random pages, but never outside Wikipedia. If I go back and forth from a page where it has happened the error tends to occur again."

The error is seriously annoying and seems to be getting worse. "use firefox" is not a satisfactory answer here. most people see wikipedia through IE.--Deglr6328 05:32, 16 March 2006 (UTC)[reply]

Seriously, try Firefox (or Opera). If it happens there, too, then you know it's either Wikipedia or your internet connection that's at fault. If it doesn't happen, then you know it's Internet Explorer that's at fault. --Carnildo 06:23, 16 March 2006 (UTC)[reply]
Ugh, I KNOW! I USE FIREFOX!!! It doesn't happen when using it, it only happens w/IE. The point is MOST people here use IE to read wiki!--Deglr6328 08:04, 16 March 2006 (UTC)[reply]
Well, having popular sites start failing in IE might just be the impetus to get more people to switch to a better browser, like hitting a mule with a two-by-four. Not that I'm advocating intentionally breaking the site in IE or anything... :-) *Dan T.* 00:24, 17 March 2006 (UTC)[reply]
That sort of talk is impractical and never leads to things being fixed. Rob Church 07:24, 17 March 2006 (UTC)[reply]
The problem absolutely must be fixed. IE is not an insignificant browser here, whatever people think. Superm401 - Talk 21:46, 18 March 2006 (UTC)[reply]
I'm not aware of any such IE-specific problem. If you can collect some information (OS versions, network providers, packet traces??) that would be super. --Brion 23:04, 18 March 2006 (UTC)[reply]
It happens on win2k with IE6 with all the latest patches and SP's installed. I have put an ethereal (or is that 'taken') dump on your talk page. --Deglr6328 08:33, 19 March 2006 (UTC)[reply]
The only accomodation I think IE users deserve is a prominent link to the downloads page. John Reid 01:26, 20 March 2006 (UTC)[reply]
Yeah! I'd throw them all in jail too! The mind truly boggles at this nonsensical, illogical zealotry. Get a clue. --Deglr6328 02:31, 21 March 2006 (UTC)[reply]
As I said above; that sort of talk is impractical, etc. Rob Church 19:32, 20 March 2006 (UTC)[reply]
Not really a solution, because many public terminals (libraries and schools) use Internet Explorer. Furthermore, on behalf of myself, I am not allowed to download Firefox onto my computer. Ingoolemo talk 02:19, 20 March 2006 (UTC)[reply]
I think the problem might be caused by malfunctioning spyware/adware that only affect IE. Try running various anti-spyware programs.
As for all the IE-hating talk, I'll say that I've been using Firefox for quite a while, and recently switched back to IE because it works so much better for me. Both browsers have serious problems, but IE's problems happen to cause me less trouble than Firefox's problems. –Tifego(t) 00:46, 20 March 2006 (UTC)[reply]
the problem is not related to spyware or adware as I am afflicted with neither. I can get it to happen again and again (the "operation cancelled" error) if when I am on the page that gives me the error I go "back" to the page to reload it within 2 seconds. however if I wait more than 5 seconds the chances of it happening again right away are much lower.--Deglr6328 04:14, 21 March 2006 (UTC)[reply]
How sure are sure that you don't have spyware/adware? Because I was having the exact same problem you're mentioning just the other day, and then I tried running Netscape's spyware scan, and suddenly I'm not getting that error in IE anymore. –Tifego(t) 00:46, 20 March 2006 (UTC)[reply]
I am absolutely 100% completely certain. Once a year (or so..) I download and run (YES with all the latest updates) spybot, AVG antivirus and ad-aware. I just did this last week and for the 3rd year in a row I've found absolutely nothing using any of these. (I don't keep them running because they slow everything down).--Deglr6328 06:20, 23 March 2006 (UTC)[reply]

When viewing the diff between two edits, there used to be a Talk and Contribs link next to the 2 editors' names. It was working fine a few hours ago, but now the Contribs link is gone and only the Talk link is there. Is this the way it'll be from now on, or is it an error? tv316 19:44, 16 March 2006 (UTC)[reply]

If you click the IP in a diff, you get its contribs; however, there's no link for contribs of a username. Who boffed this up? --Golbez 19:52, 16 March 2006 (UTC)[reply]
It's now the same as the user info links displayed elsewhere in the user interface. --Brion 20:16, 16 March 2006 (UTC)[reply]
I'm sorry, Brion, but I don't understand what you mean by that. Also, it's apparently affected my rollback button, which I get from godmode-light, and made it tell me that "Contributions" is not the most recent vandal, but the vandal is. tv316 20:26, 16 March 2006 (UTC)[reply]
Look at things like Recent Changes and Watchlist.
I don't know anything about your "godmode-light", presumably it needs to be fixed. --Brion 20:31, 16 March 2006 (UTC)[reply]
So is this format of just the talk page link in the diff view here to stay? For some vandals who have usernames and just in some cases when I want to see what a user has been up to, it's a bit annoying to have to click on the 'my contributions' button at the top and then copy and paste their name in the address bar to replace mine. Is there a reason for the change?
godmode-light was made by User:Sam Hocevar. It gived non-admins a rollback button. tv316 20:38, 16 March 2006 (UTC)[reply]
It's funny that you see this as the way to get to a user's contributions, because that's what I also thought for a very long time (long after being an admin). But on every userpage (empty or not) there's a "User contributions" link in the toolbox to the left. I felt really silly when I discovered it after having pasted in username's in urls for a long time. But maybe this fact (that many don't know about that link) is a good reason to put back the contributions link in the diffs. I don't know. Shanes 20:48, 16 March 2006 (UTC)[reply]
This is highly annoying, that link was very useful. Martin 20:40, 16 March 2006 (UTC)[reply]
I also found the contribs link extremely useful for fighting vandalism. olderwiser 20:51, 16 March 2006 (UTC)[reply]

I've come up with a fix for Godmode-light, if anyone is interested...

Find this line:

vandal = l[i].getElementsByTagName('a')[1].title.split(':')[1];

and replace it with this

vandal = l[i].getElementsByTagName('a')[2].title.split(':')[1];

That line is located in the function AddRevertButtons. If you have any questions, let me know on my talk page. --lightdarkness (talk) 20:44, 16 March 2006 (UTC)[reply]

To explain how this would work for me - I'd middle-click all the diffs in my watchlist. If I see a vandalism, I left-click rollback and middle-click Contribs, so that I can see if he has other vandalisms. Please, please change this back, Brion, you should not make vandalfighting harder for the sake of a more standard interface. --Golbez 21:03, 16 March 2006 (UTC)[reply]

The old code was broken and hacky and ain't going back. I have though tossed in a contribs link in the user tools; as a bonus this is on the Recent Changes and Watchlist too (since it's the same code). Let me know if it seems good/bad/evil. --Brion 21:23, 16 March 2006 (UTC)[reply]
The functionality seems identical to how it was before, so I've no problem with it at all. Thank you. --Golbez 21:30, 16 March 2006 (UTC)[reply]
Ditto. Me happy now. Thanks Brion. olderwiser 22:42, 16 March 2006 (UTC)[reply]
By the way, on a related note, has the edit summary in diffs been changed to italics? Here's a random diff link I just pulled off RC: [2] Or is it just that I'm remembering incorrectly? Just curious; I really don't mind either way, but I would favor plaintext. Thanks! Flcelloguy (A note?) 21:50, 16 March 2006 (UTC)[reply]
I noticed this too, I believe it has changed from normal to itallic. --lightdarkness (talk) 22:24, 16 March 2006 (UTC)[reply]
Yes, it's using the same styling as recent changes, watchlist, history, etc etc etc instead of the incorrect styling that it used to use. --Brion 23:17, 16 March 2006 (UTC)[reply]

The problem now is that the contrib link appears for registered users, but not for anonymous editors, which is where it is needed the most... Titoxd(?!? - help us) 06:28, 17 March 2006 (UTC)[reply]

The IP link takes you to their contribs. --lightdarkness (talk) 13:24, 17 March 2006 (UTC)[reply]
Right now my monobook.js contains only one line:
 document.write('<SCRIPT SRC="http://sam.zoy.org/wikipedia/godmode-light.js"><\/SCRIPT>'); 

What exactly do I have to do to fix the problem? deeptrivia (talk) 22:13, 19 March 2006 (UTC)[reply]

You have to go to Sam's page and download the whole thing, put it on your monobook.js, replace that one line, and remember to clear your browser cache. Makemi 22:23, 19 March 2006 (UTC)[reply]
What he said, I also replied on your talk page with those instructions. --lightdarkness (talk) 22:25, 19 March 2006 (UTC)[reply]

User-specified New Pages

Is ther a way to see all the "New pages" that an specific user has created, perhaps something similar to Special:Newpages but user specified? --MoRsΞ 23:08, 16 March 2006 (UTC)[reply]

Looking at a filtered Special:Newpages now; will be committing it to the codebase when I've done a bit more cleaning. :) Rob Church 20:21, 17 March 2006 (UTC)[reply]
That will be very useful. We already have Special:Log/upload so it's kind of odd that we don't have this. Thanks for working on it. Superm401 - Talk 21:50, 18 March 2006 (UTC)[reply]

Administrator needed! Please!

I did something silly and created a Wikipedia nonsense entry. Sorry. I regret it and wish to remove the entry's history. But I do not know how to do this. I suspect it requires someone with higher Wikipedia user rights than mine. My username is Marcusvox and you will see the silly entries I made on http://en.wikipedia.org/wiki/Sympatico

Can the history of my edits be deleted please, so this nonsense page will disappear for good? Once again, my apologies to the WIkipedia community for this lapse on my part. I do not make a habit of creating nonsense entries.--Marcusvox 23:34, 16 March 2006 (UTC)[reply]

That's very honest of you, but there's no need to delete them from the history since you've already reverted them out. -Splashtalk 00:28, 17 March 2006 (UTC)[reply]
Yes, there's no need to delete them, but there's also no need to keep them, so why not? Deleted. --cesarb 00:33, 17 March 2006 (UTC)[reply]
Thanks CesarB. I assume you are an admin. I will not be so foolish again. --Marcusvox 00:55, 17 March 2006 (UTC)[reply]
For one thing, they're no longer visible on the user contribs. Superm401 - Talk 02:01, 17 March 2006 (UTC)[reply]
But his request here to remove them is. --cesarb 16:06, 17 March 2006 (UTC)[reply]

WP Logo blurred in IE

File:Screenshot-logo-wiki-id.JPG
WP Logo blurred only on IE

Although this problem can easily get rid of by using Firefox, but I just want to ask if anyone have a workaround for solving this problem. The Wikipedia logo displayed blurred when using Microsoft Internet Explorer only (IE6 also confirmed). (see image) But seems that this problem is not consistent. I have found other PC with IE6 that work fine, but many disturbed with this condition. borgx (talk) 00:14, 17 March 2006 (UTC)[reply]

The reason is, that you are including your image by CSS (Monobook.css)! Maybe some versions of IE have problems doing so correctly ;-) You really should put up a request at m:Requests for logos (or better: Bugzilla!), because when Wiki.png is activated this effect will not be there any more. BTW: In my view the chief cause of this could be in ../skins-1.5/common/IEFixes.js at "Center image with hack for IE5.5", where the logo gets middled/centered. Maybe this causes that duplication (blurred logo)!? Try if the logo is shown correctly when you have JavaScript disabled, please. If yes, the following might work when added to Monobook.js:
if (isMSIE55 && !doneIEAlphaFix) {
 logospan.style.left = '50%';
 logospan.style.setExpression('marginLeft', '"-" + (this.offsetWidth / 0) + "px"');
}
If not (what I think; ->IE5.5), you could try to align the image (->#p-logo) 2px more to the left side in Monobook.css! --- Hopefully something of that will work; best regards, Melancholie 21:38, 17 March 2006 (UTC)[reply]
P.s.: Ah, there already is one: MediaZilla:5275 --Melancholie 21:50, 17 March 2006 (UTC)[reply]

Need a bunch of users' opinions on sizes

At Template_talk:Current_U.S._Senators#Size poll, we're discussing whether or not the current version (D) is as good as the suggested one (M). Which version is smaller (which is the question of the moment). Many people are saying version (D), but it sure as heck doesn't look that way on mine. More pairs of eyes (and a larger variety of browsers) are needed, I think. Thanks! Matt Yeager (Talk?) 01:11, 17 March 2006 (UTC)[reply]

FWIW, I get "D" to be smaller - Firefox, Windows XP, 1024*768px. (I also can't see the colours, but that's another matter entirely...) Shimgray | talk | 01:41, 17 March 2006 (UTC)[reply]
D is much smaller (Firefox, winXP). I can barely see the colours. -- Finlay McWalter | Talk 01:49, 17 March 2006 (UTC)[reply]
D appears smaller to me as well. Also can barely distinguish the light colors. Thanks! Flcelloguy (A note?) 02:01, 17 March 2006 (UTC)[reply]
D is smaller (Mozilla SeaMonkey Suite); the other one doesn't even fit in my screen resolution, forcing a horizontal scrollbar. *Dan T.* 02:20, 17 March 2006 (UTC)[reply]
D is smaller, but not by much (Opera, large fonts). --Carnildo 02:52, 17 March 2006 (UTC)[reply]
D has the smaller type size, with a little bit of scrolling needed. M needs a lot of scrolling to see it all (on IE6 with a 1024 by 768 screen). Both with D and M the scrolling is irritating - Adrian Pingstone 16:26, 17 March 2006 (UTC)[reply]
D fits nicely on the screen, while M overflows and needs horizontal scrolling. Both versions are perfectly readable. Mozilla Firefox 1.5 on Debian stable, 1600x1200, 132 DPI. --cesarb 00:47, 18 March 2006 (UTC)[reply]
I've explained the reason for M being bigger than D at Template_talk:Current_U.S._Senators#Size poll. --cesarb 00:59, 18 March 2006 (UTC)[reply]

Replacing the image in the taxobox, and getting an image to sit where it belongs

In the article Hythe, Alberta, I have two problems. I want to replace the map in the taxobox with the map sitting above it, but I can't find where in the code the first map's name is. It must be in the taxobox code somewhere, because when I remove that, the map disappears too. Second, failing being able to replace the taxobox map, I want the other map to sit flush right. Using the code [[Image:dwalbertahythe.png|thumb|250px|right]] ought to do it, no? But it seems it doesn't quite. Can I please get a hand with this? Thanks! Denni 04:10, 17 March 2006 (UTC)[reply]

The box is created by {{Canadian Town}}, which has hardcoded into it the use of an image called "{{PAGENAME}} Location.png". The only way to get your image into the box, short of rewriting the template to allow an override of the image name, would be to re-upload your map over Image:Hythe, Alberta Location.png.
I'm not quite sure what your alternative request is. The dwalbertahythe.png is flush right for me (but I use the classic skin, which sometimes places images differently from monobook). I would suggest you put the new image below the box rather than beside it, which you can achieve just be shifting it down the wikicode a few paragraphs.-gadfium 05:24, 17 March 2006 (UTC)[reply]
That's just the default name for the image. It can be overriden with a template parameter. --cesarb 01:02, 18 March 2006 (UTC)[reply]

Help needed to fix a glitch

Hi, I've had a bit of trouble trying to format a number of tables in the past on this page. If anybody happens to know how to fix the problem of incomplete borders around these 3 tables without changing the arrangement of the contents inside, could you please so kindly fix them for me? Thanks heaps. mdmanser 14:08, 17 March 2006 (UTC)[reply]

Try removing the style bit about the borders. --Brion 22:39, 17 March 2006 (UTC)[reply]

Images in articles give poorer google results

I discovered to my dismay that having images in an article produces poorer results from a google search (see [3]) than one without. A google hit on a wikipedia article with an image shows the caption of the image in the snippet rather than the first essential summary of the article. In the example search here for Nanortalik (search:[4]), the German wikipedia article gets #1 and with the essential information we would like to see displayed in the search result snippet. For the english Wikipedia (#10) that has an image at the start, the snippet does not encourage follow-through click due to its irrelevant snippet text. Any suggestions on how to prevent this, apart from having no images at the top of the page? Jens Nielsen 15:52, 17 March 2006 (UTC)[reply]

Wikipedia really doesn't have to worry about search engine optimization. We're the 18th most popular site on the internet, according to Alexa. If you build it, they will come. Superm401 - Talk 21:55, 18 March 2006 (UTC)[reply]

'Edit' location screwed up

In Celtic knot the location of the 'edit' link for the History section is screwed up...somehow forced lower that the headline underline, possibly due to the images on the right. I can't seem to figure out a way to get this to sit normally, on the same line as the headline. Help? --Kickstart70 16:45, 17 March 2006 (UTC)[reply]

Page renders as I'd expect; section edit links will move about to accommodate block content. You could add a <br style="clear: both;" /> which might achieve the desired effect, but it doesn't make much difference. Rob Church 19:42, 17 March 2006 (UTC)[reply]
Sam Korn came and provided a fix, which is why it looks right now to you. It's a workable fix, but kind of a hack. Previous to this, the 'edit' link was rendered on top of other text within the History section. Ideally, this wouldn't be an issue, and I think that perhaps a containing box around both the included images would solve it more permanently. --Kickstart70 20:43, 17 March 2006 (UTC)[reply]

Apparently a new section; "typo"

I just noticed this on my Watchlist, that an IP address had apparently submitted a new section called "typo", with the arrow link to the section (which is redundant and just messes around with the syntax). There is no section called typo and when I first saw I attributed it to the edit summary anyway. I went through every test I could think of to check that this wasn't just me, but I found more proof on the history page and user contribs here, the contribution to Avro Arrow. Whats with this? --The1exile - Talk - Contribs - 17:05, 17 March 2006 (UTC)[reply]

Sounds like the user entered /* typo */ as their edit summary. This would cause MediaWiki to render it as a section link. Rob Church 19:40, 17 March 2006 (UTC)[reply]
It would be nice if that syntax couldn't be forged...Superm401 - Talk 21:57, 18 March 2006 (UTC)[reply]
How would the software know? Rob Church 19:28, 20 March 2006 (UTC)[reply]

Wiki Molasses

You guys have a server down ? Wikipedia acts like Dial-up is faster, and I'm on DSL. I was directed here from WP:AN regarding this matter. Martial Law 21:27, 17 March 2006 (UTC) :([reply]

Try 120 seconds, and a "Operation has Timed out." has appeared. Martial Law 21:43, 17 March 2006 (UTC) :o[reply]

Remove item from watchlist

There's an item which has been on my watchlist for a couple months now, and it's beginning to bug me. I've tried removing it a number of times, and I've cleared my browser cache, but every time it says "Couldn't remove item 'Wikipedia:BJAODN/This is your final warning, if you attempt another bad joke , you will be deleted nonsense'...done." Any ideas? Makemi 22:09, 17 March 2006 (UTC)[reply]

Is that the exact title of the actual page on your watchlist? Does clicking this link help? This is a bit difficult to debug, since no-one else can actually see your watchlist. Could you cut and paste the part of your complete watchlist containing the page you're trying to remove below? Or could you save the entire page to disk and e-mail it to me? —Ilmari Karonen (talk) 22:32, 17 March 2006 (UTC)[reply]

The link you gave resulted in the exact same error (yes, that is the exact name). In context it is

  • White flight
  • Wikipedia:BJAODN/This is your final warning, if you attempt another bad joke , you will be deleted nonsense
  • William Hunt
  • William Joyce (writer)
  • William Shakespeare
  • Wolfgang Amadeus Mozart
  • Women's rights
  • Zac Efron
  • Zaire
User
  • User:-TheRaven-
  • User:129.252.89.201
  • User:151.198.82.3
  • User:167.206.142.194
  • User:167.206.174.28

I guess it's weird because this was actually a vandal article, which is why it shows up in regular articles, rather than Wikipedia namespace articles. (eg. the title of the page was Wikipedia:etc., it wasn't truly part of the namespace). Perhaps that's why the software is confused. Thanks, Makemi 23:38, 17 March 2006 (UTC)[reply]

Now that's weird! But I think I've figured out a workaround: try this link. —Ilmari Karonen (talk) 23:49, 17 March 2006 (UTC)[reply]
Hey! You did it! Why did that work? Thanks, Makemi 00:02, 18 March 2006 (UTC)[reply]
When you watch or unwatch a page, the talk page is also watched or unwatched, and vice versa. The name of the page unwatched by the above link begins with "Talk:Wikipedia:", which makes it the talk page of a (supposedly impossible) main-namespace page with a name beginning with "Wikipedia:", which is what you somehow had on your watchlist. So unwatching it also unwatched the corresponding article page.
In fact, I'm willing to bet that it was the oddly named talk page that you'd watchlisted in the first place. Unfortunately Special:Watchlist/edit only lists the non-talk names, which means you can't unwatch such an oddly named talk page that way. Using the unwatch tab on the talk page itself would probably also have worked. This is, arguably, a bug. —Ilmari Karonen (talk) 00:30, 18 March 2006 (UTC)[reply]
Submitted as Bug 5280. —Ilmari Karonen (talk) 01:05, 18 March 2006 (UTC)[reply]
Thank you, that sort of makes sense, although generally when have I removed pages from my watchlist which have the same circumstance (I've only edited the deleted talk page, and both article and talk page are deleted) I don't have a problem, but perhaps the "Wikipedia"ness of it was what caused the bug. Thanks, Makemi 01:43, 18 March 2006 (UTC)[reply]

Creating an account

FYI, I've added Creating_an_account to the Meta:Help, so it might show up also here in the derived help page later. This technical nit could be also a legal issue - IANAL :-) Omniplex  23:50, 17 March 2006 (UTC)[reply]

Most Wikimedia wikis only require Captchas during emergencies (bot vandalism). At any rate, the section didn't say how to create an account, only why one might not be able to. I've fleshed it out a bit. Superm401 - Talk 23:52, 18 March 2006 (UTC)[reply]
Doesn't help much, the m:Special:Captcha page still has no link to an online account manager, your link on the Help page leads to a huge list of admins with no indication who's able to handle issues with m:Special:Captcha, and the error message Can't view captcha image a second time shows again that Captchas are often coupled with technical ignorance... <sigh />  Thanks for the help page update, apparently the special page is an oddity only affecting Meta. Omniplex 09:09, 19 March 2006 (UTC)[reply]

User Contributions

Is it possible to get a list of user contributions - just the same as the present list, but filtered to exclude all pages for which the user is (top)? (That is all edits to a page marked top, not just the most recent edit to it.) -- SGBailey 00:07, 18 March 2006 (UTC)[reply]

Bug??

This may be a bug, or not, but when I go to an article, and I go to its history, and then I click 'compare selected versions', the latest version (on the right) has a '[revert as vandalism]' on the top of it and then a '[rollback] link to the right. I thought these links were only used and given to administrators. Is this a bug? Funnybunny 04:30, 18 March 2006 (UTC)[reply]

I know that Brion had been editing some things in regards to diff view, but if you did see that it was probably just temporary, as I'm not seeing the described features. --lightdarkness (talk) 05:17, 18 March 2006 (UTC)[reply]
You have "Godmode-lite" installed in your monobook.js. This gives some extra facilities to Wikipedia users using javascript. It isn't as powerful or as efficient as the tools administrators have. It looks like Voice of All (talk · contribs) installed it there for you. If you didn't ask for this, please say so and someone will remove it for you.-gadfium 05:24, 18 March 2006 (UTC)[reply]

Voice of All has been installing scripts left, right and centre; someone needs to tell him to stop, it's rude and tantamount to abusing his privilege of editing what would be considered a protected page. Rob Church 19:26, 20 March 2006 (UTC)[reply]

Patrolled edit

On Help:Patrolled edit I've just "disabled" {{Phh:Patrolled edit}} by inserting __END__ (the template didn't exist before).

So far it's documented / obvious / clear, pick what you like, but I'm less sure about the obscure {{System admin toc}} - is "disabling" it with __END__ the normal procedure to get rid of the broken link on a help page? Omniplex 08:51, 18 March 2006 (UTC)[reply]

I don't know what the "approved" way is. You have to put something in the empty page and regular spaces don't work. I just got rid of Template:Phh:Inputbox with &nbsp (an HTML character entity that stands for "non-breaking space", or as I prefer, "'nother blank space") Superm401 - Talk 00:55, 19 March 2006 (UTC)[reply]
ACK, magic word __END__ or simply &nbsp; (= &#160;) both do the trick. I only want to know what the real purpose of a broken link {{System admin toc}} was, maybe it's a part of some maintenance procdure, and disabling it was a bad idea. Omniplex 07:30, 19 March 2006 (UTC)[reply]
Now also discussed wrt to a template trying to explain this feature. Omniplex 15:59, 22 March 2006 (UTC)[reply]

Bug in article - report this

On polish Wikipedia we created a page where users may report bugs. And we add link to this page to all pages in menu (right menu - Zgłoś błąd). Page take a referer and we know where is bug. I think, that is good think to add this page in EN.wiki. What do you thing?

List reported bugs - pl:Wikipedia:Zgłoś_błąd_w_artykule. Link is add to pl:Mediawiki:Sidebar (bug in article), Name and url are in pl:MediaWiki:Bug in article-url and pl:MediaWiki:Bug in article. Source of file with form to report bugs is in: http://adamdziura.9g.pl/wikipedia/wikibug.phps. Adam Dziura 11:32, 18 March 2006 (UTC)

Um, how is this different to Bugzilla? Sam Korn (smoddy) 12:16, 18 March 2006 (UTC)[reply]
User reported bugs in articles (not in Mediawiki). Bugs - bad date birth, bad information, typo... this is better for non-advanced user. [[[:pl:Wikipedysta:Adziura|Adam Dziura]] 12:31, 18 March 2006 (UTC)
Easier than Wikipedia:Tutorial to teach them how to fix it themselves? Sam Korn (smoddy) 14:00, 18 March 2006 (UTC)[reply]
Yes. But some users (readers) can not have time to correct. Or they don't knows how to correct or to be afraid of an edition. In polish Wikipedia a lot of misconceptions were found. See the history of changes in this article. This is like send mail to administror (You have a bad day of birth in ...) A suggestions write there are useful. Many wikipedia users are reading this voice and he is correcting a mistake (searching for correct data in other sources). Adam Dziura 14:58, 18 March 2006 (UTC)
This is a really bad habit to get people into; it's also very un-wiki. You're just asking for a massive backlog. Even if people don't want to {{sofixit}}, there are better options. For minor (potential) problems, people can put templates like {{fact}} or a note on the talk page. For bigger issues, the are cleanup templates that people should learn. Having them complain to the "central authority" for every problem will be harmful in the long run. Superm401 - Talk 00:58, 19 March 2006 (UTC)[reply]
Perhaps you will allow to the test of it. So for 2 days? Perhaps you will change your mind later. :) Adam Dziura 09:37, 19 March 2006 (UTC)

infobox help

Can anyone tell me how to get tables into infoboxes ant how to create tables?

For a quick and dirty example see Template talk:-, for a more elaborated example see Template:Infobox Micronation(edit talk links history). Omniplex 14:05, 18 March 2006 (UTC)[reply]

Difficulty printing

This article can't be printed properly without having some text covered up by some images, making a mess. Some students who use WP are sometimes requested by their teacher to print out a copy of the article for school work. Can anyone help fix up the article? Some students might need it urgently... --Bruin rrss23 14:58, 18 March 2006 (UTC)[reply]

It prints ok from Safari in Mac OS X 10.4.5; some of the images are split across two pages which is mildly annoying but I see no overlapping. --Brion 22:55, 18 March 2006 (UTC)[reply]
Did you try the "printable version" link on the sidebar? Superm401 - Talk 01:00, 19 March 2006 (UTC)[reply]

I did but it still didn't work. Looks like I have to cut and paste each individual part separately... --Bruin rrss23 03:32, 19 March 2006 (UTC)[reply]

Section titles overlap with Images

The article about PCI Express has a problem in the form factors section when viewed at a sufficiently high resolution (1024x768) — the image in the previous section overlaps with the section’s headlines; in lower resolutions (or a small browser window) it is not an issue, since the text fills the space. This is probably an issue in other articles as well.

After some experimenting it seems that the solution is to add the CSS clear property to the section headlines in order to avoid this kind of problem; the use of “clear: both” should take care of large images floating on the left or right.

Perhaps someone should also check if floating images can cause problems with subsection headlines.

Please note that CSS clear has no effect for legacy floating (align=) on legacy browsers, if you're dealing with align= effects check out Template:-(edit talk links history) (technical details on the talk page). Omniplex 07:37, 19 March 2006 (UTC)[reply]
It is not about the align propery. The image on the page I mention has the CSS float=left property. The template you mention inserts a <br clear="all">, which does take care of the issue, but adds undesired extra space; furthermore, since this can be an issue wherever there is a large floating image, you shouldn't expect people to insert the template for “just in case”. I think the CSS clear=both should be added by default to any section element (<h2> is used), as it makes sense — there is no reason that a subsequent section should “flow” around an image from a previous section. --70.107.124.95 15:34, 19 March 2006 (UTC)[reply]
A default clear for headers at least downto <h2> could make sense, but on some pages huge infoboxes intentionally float to the right of the ToC and the first section, e.g. Sealand or several guideline pages. For a pure CSS situation check out Template:Clear(edit talk links history), it uses a dummy <div>. Omniplex 20:08, 19 March 2006 (UTC)[reply]

Spam filter problem

There's a problem with the spam filter, in which a person can make an edit like this one, but I'm not allowed to revert it. Can an admin revert that and someone please look into it? Thanks. tv316 22:59, 18 March 2006 (UTC)[reply]

Somebody reverted it already. No idea why you think that you can't do that, removing an unsigned Spanish text on a controversial talk page is IMHO no technical issue. Omniplex 07:57, 19 March 2006 (UTC)[reply]
It's not that I didn't think I could do it. It would not allow to me either rollback or manually revert it. Do you really think I would just post a link to the diff and say "Alright, guys. Have fun. Not my problem anymore!"? It becomes a technical issue the moment my revert gets denied due to the spam filter. tv316 22:53, 19 March 2006 (UTC)[reply]
The ON link in the "Al-Qaeda strategy" section triggers the spam filter (administrative rollbacks apparently work, though). I have fixed the problem by tweaking the link. Raul654 07:58, 19 March 2006 (UTC)[reply]

Pre-populating a new page

I've been unable to find a Help section that deals with pre-populating a new page. For example, if a user clicks to create a new page, I want the page to already have several standard templates in it and / or sections pre-built so they know what the page is supposed to look like. I assume this is common practice but I'm unable to find the documentation where it is discussed. Thanks in advance for pointing me in the right direction! Jimkloss 23:03, 18 March 2006 (UTC)[reply]

This is not common practice. There are no standard templates and pages are not pre-populated. User:Zoe|(talk) 23:19, 18 March 2006 (UTC)[reply]

It's certainly possible, but en.wikipedia doesn't do it. en.wikinews.org does, but I don't know the mechanism. I assume you are asking so you can do this on your own MediaWiki site, but this is not the place to get support for MediaWiki. I think http://www.mwusers.com/ may be an appropriate place.-gadfium 23:53, 18 March 2006 (UTC)[reply]

Add "&preload=<page who's text you want to include>" and alternatively "&autosummary=<some url encoded text>" to the end of an edit link. It's used on for example Category:Images with unknown source (along with a couple of other "magic" commands in the link that automaticaly creates a new sub-category when clicked). It only works for "redlinks", if the page already exist the prefill text is not used. an example --Sherool (talk) 00:22, 19 March 2006 (UTC)[reply]
Thank you. I'm sorry, yes I should have indicated I was asking for our new wiki and not for Wikipedia. I think you've given me enough to go on. Sorry I didn't ask over at MediaWiki. Still confused about who is what and what is where. Jimkloss
This is funny. I'm the one who made the link on Category:Images with unknown source (at great effort :) ), but I momentarily forgot about it and got into an edit conflict just now. I was just going to point out that you can create such links using input boxes (constrained input tags) or the GET urls that result. However, Sherool correctly points out that if you pair the preload attribute (one of the GET attributes input boxes can make) with the undocumented autominor, autoclick, and/or autosummary options, you can do some pretty cool things. I'll go over them:
  • preload will fill the page with the wikitext from a template.
  • autosummary will automatically create an edit summary
  • autoclick will click one of the three buttons (wpSave, wpPreview, or WpDiff)
  • autoedit will make regex replacements.
Use these cautiously.
P.S. See Meta:Names for a page that clears up our needlessly confusing names. Superm401 - Talk 00:50, 19 March 2006 (UTC)[reply]
Note that the final three actions are not documented on meta, because they're not part of Mediawiki. They're part of my popups script, and won't work without it (or User:Lupin/autoedit.js instead). Lupin|talk|popups 13:05, 20 March 2006 (UTC)[reply]
Thanks Lupin. I was wondering about that since those 3 functions didn't even appear in the PHP code. Thanks to you all I've got prepopulate working. Now, if I could just find a way to write a new page directly from a PHP hooked program I'd be all set. Jimkloss 07:29, 22 March 2006 (UTC)[reply]

finding a new article with the "search" function

Hi, I created a new article, "University of Southern California Law School," but I can only access it from links from other existing articles. How can I make it appear when a user types in relevant words into the "search" box on the left? Thanks for your help. Pbgr

The search index might take a while to update. Try again in a few hours... days... what's the lag on indexing again? æle 00:49, 19 March 2006 (UTC)[reply]
Also you can add various relevant redirects to make it easier for users to find your page. Tutmosis 00:55, 19 March 2006 (UTC)[reply]
I created the article a few days ago and it's still not coming up on the search index... Is it that slow? Pbgr
Personally I when i type University of Southern California Law School it comes up perfectly fine. Its intresting to note that when you type the exact same thing in small caps it does not cope up. I recommend making various redirects; atleast one being same thing in small caps. If you want I can do it for you. Tutmosis 01:08, 19 March 2006 (UTC)[reply]
Thanks for your help. Pbgr
Several weeks currently. --Brion 18:42, 20 March 2006 (UTC)[reply]

Getting Username in Javascript?

I'm trying to store the username (of the currently logged-in user) into a string variable. So far I've tried

var myUserName = document.getElementById('contentSub').innerHTML.match(/'(.+)'/)[1];

but that fails because document.getElementById('contentSub') returns null. I also tried using MediaWiki:Yourname but I can't figure out the syntax for it. --Tifego 03:00, 19 March 2006 (UTC)[reply]

I'd suggest document.getElementById('pt-userpage').getElementsByTagName('a')[0].href and remove the "/wiki/User:" prefix. —Ilmari Karonen (talk) 03:19, 19 March 2006 (UTC)[reply]
Thanks. (But why not document.getElementById('pt-userpage').getElementsByTagName('a')[0].text instead?) --Tifego 04:03, 19 March 2006 (UTC)[reply]
You can do:
var myUserName = document.getElementById('pt-userpage').getElementsByTagName('a')[0].firstChild.nodeValue
"text" isn't a valid object. However, the elegant way to do it is read the cookie (ideally, you should use a cookie-reading function).
var cke = document.cookie;
var pos = cke.indexOf("enwikiUserName");
var start = cke.indexOf("=", pos)+1;
var end = cke.indexOf(";", pos);
if (end == -1) end = cke.length;
var myUserName = cke.substring(start, end)
-Superm401 - Talk 05:29, 19 March 2006 (UTC)[reply]
No, I think you're wrong about that being necesssary. Mainly because I'm already using the ".text" version and it works to get my username perfectly. --Tifego 05:33, 19 March 2006 (UTC)[reply]
To clarify: "text" has special meaning that makes it valid to use here although there's no node with that name. "text" is what's inside the node, i.e. <tag>text</tag>. --Tifego 05:43, 19 March 2006 (UTC)[reply]
You're right! Keep in mind, though, the DOM standard it to use textNode . Superm401 - Talk 05:47, 19 March 2006 (UTC)[reply]
Also, I still think it's cool to use a cookie. Superm401 - Talk 05:48, 19 March 2006 (UTC)[reply]

A better way to extract the cookie, using regular expressions, is:

var userName = decodeURIComponent(/((^|;)\s*enwikiUserName\s*=([^;]*)|$)/.exec(document.cookie)[3].replace(/\+/g, " "));

This also takes care of unescaping the username properly. —Ilmari Karonen (talk) 16:08, 19 March 2006 (UTC)[reply]

Columns of content without yucky tables

I have been working to get rid of table-based visual layouts lately, and tried to tackle content in columns, like some people prefer with See also sections that have tons of links, etc. I don't really like them, but whatever; I might as well make them work well. Besides, with the CSS-based layout, people who really don't like the columns can turn them off in their monobook.css.  ;-) The original templates are at {{col-begin}}, and my new ones are at Template talk:Columns. I need feedback and it needs tweaking. Bypass your cache if you don't see the example. — Omegatron 06:14, 19 March 2006 (UTC)[reply]

Change Main Page

Anyway to override the new main page and view the old main page or am I asking for a hopeless cause. The new one honestly hurts my eyes! Mike (T C) 07:48, 19 March 2006 (UTC)[reply]

Main Page alternate (Classic 2006) (the Featured article, ITN, selected annivs, and DYK should still rotate properly) Raul654 07:53, 19 March 2006 (UTC)[reply]

help on common.css

Where can I find documentation for common.css? I copied the common.css & monobook.css from WP to my local wiki (1.5.7) , but the templates failed to displayed correctly according to the class declared on common.css, so I have to type it in "style clause" manually to get them work. Did I miss some steps? Thanks for any help. borgx (talk) 08:28, 19 March 2006 (UTC)[reply]

AFAIK, only beginning with 1.6 does MediaWiki import MediaWiki:Common.css automatically. With older versions, you have to do the import manually; look at the history of MediaWiki:Monobook.css for the manual import (I'm the one who did it, if it helps the search). --cesarb 05:30, 20 March 2006 (UTC)[reply]

Coordinates

  • Note: I posted this in the help desk and they suggested I ask the question here.

I just noticed that the German Wikipedia has an option where the coordinates of a location are inserted in the upper-right header. Here is one example: [5]. Is this possible in the English version? If so, how? Sean WI 16:29, 19 March 2006 (UTC)[reply]

It looks like a template: Template:Koordinate Text Artikel, perhaps copy the template to wikipedia? Mike (T C) 16:42, 19 March 2006 (UTC)[reply]
Started a template: Template:CoorHeader - doesn't seem to work. I think the German wiki actually has code inserted into the header. Is that a possibility? (Perhaps you could take a look at that template...I probably did it wrong. Sean WI 16:51, 19 March 2006 (UTC)[reply]
There will also be code in the stylesheet: . I suggest you engage in more discussion before going ahead with these additions, as there may be conflicts with other fields. Sam Korn (smoddy) 17:01, 19 March 2006 (UTC)[reply]
Should I continue the discussion here or could you point me in the direction of a proper forum for this? Sean WI 17:08, 19 March 2006 (UTC)[reply]
You might consider the mailing list. Sam Korn (smoddy) 17:21, 19 March 2006 (UTC)[reply]

We've been suggesting it for a year over at Wikipedia talk:WikiProject Geographical coordinates#Coordinates at the top of the article and I posted Bug 4719: RFE: geo coordinates in page title on all (common) en: .css but no joy.

--William Allen Simpson 13:21, 20 March 2006 (UTC)[reply]

Posted possible code at MediaWiki talk:Common.css and MediaWiki talk:Monobook.css.

--William Allen Simpson 11:19, 21 March 2006 (UTC)[reply]

Moving category history

Can something like this: Category:Norma Elizabeth Boyd be fixed (moved to the main namespace) by a dev or something? Or should I just cut & paste move it and delete the category? --Sherool (talk) 18:36, 19 March 2006 (UTC)[reply]

Unwatched pages

Could someone in the know have a look at Special:Unwatched pages and see what's going on? I can only see the first 1000 articles, the pages are blank after that. There's a comment on the talk page, Wikipedia talk:Special:Unwatchedpages that it has been static since the server problems in mid February, I don't know if that's connected/resolved? Thanks, Steve block talk 20:19, 19 March 2006 (UTC)[reply]

It's a cached data set with the top 1000 entries. --Brion 18:41, 20 March 2006 (UTC)[reply]
Doh. Anyway to see beyond that? Steve block talk 10:44, 21 March 2006 (UTC)[reply]

Hiding MediaWiki:Tagline

I've succeeded in copying the code from MediaWiki:Monobook.js to eliminate the appearance of the title bar for my user page, but I haven't figured out how to hide the MediaWiki:Tagline message. Any ideas? (see top of User:Spangineer/monobook.js) —Spangineer[es] (háblame) 21:18, 19 March 2006 (UTC)[reply]

The ID is "siteSub". Sam Korn (smoddy) 21:22, 19 March 2006 (UTC)[reply]
Right, but I've copied the code exactly from MediaWiki:Monobook.js that mentions siteSub, but the effect isn't equivalent. I'm not sure what's going on. —Spangineer[es] (háblame) 23:07, 19 March 2006 (UTC)[reply]
What are you trying to do? Sam Korn (smoddy) 23:18, 19 March 2006 (UTC)[reply]
And then miraculously, it started working. My userpage is basically a personalized version of the new main page, and I want it to cut the title bar just like it does for the main page. But I think I got it figured out now. Sorry for the trouble! —Spangineer[es] (háblame) 00:17, 20 March 2006 (UTC)[reply]

Most websites already have the cursor flashing in their search box when the page has loaded. This isn't the case with WikiPedia (not with me anyway) - The user must manually click the box to enter text. Is this something which can be changed? Bswee 23:23, 19 March 2006 (UTC)[reply]

I believe this has been discussed before. The reason that it doesn't default to the search box, is so that users can scroll the page using the arrow keys, and not need to have use of a mouse. --lightdarkness (talk) 23:35, 19 March 2006 (UTC)[reply]
And also so it doesn't jump about when you use a section link. Sam Korn (smoddy) 00:42, 20 March 2006 (UTC)[reply]
I personally hate it when sites mess with cursor focus like that... it often screws you up, for instance if you have clicked on an input field or the browser address bar while the page is loading and started to type something, then suddenly when the page finishes loading it moves the cursor somewhere else and the stuff you're typing winds up in the wrong place. This can even be a security risk, if what you were typing was your password in a login form; this is usually not shown when you type it, but if your cursor is moved somewhere else, it will be visible to somebody looking over your shoulder. One of the good things about Wikipedia versus lots of other sites is that it doesn't screw around with stuff like that. *Dan T.* 01:14, 20 March 2006 (UTC)[reply]

How can I get the TeX reader to recognize more symbols?

I've started to try to improve some of the economics pages, but one symbol I really need to use is the "preference" operator, seen here under the names \prec \preceq \succ and \succeq. How can I get the "math" tags to recognize these symbols? --Ossanha 03:36, 20 March 2006 (UTC)[reply]

You should file a bug on bugzilla to ask the devs to do this. Lupin|talk|popups 03:10, 23 March 2006 (UTC)[reply]
Note that m:Blahtex can handle all of these symbols (and lots more besides). We are working on making this software available in Wikipedia. Dmharvey 13:26, 23 March 2006 (UTC)[reply]

I've been searching for W.P. policy on external links to video hosted on Google video, etc. where the legal status of those video items is undeterminable. Should links be made only to those sources where license / copyright status can be determined? If yes, how does that extend to text material? See [6] for relevant discussion. Revmachine21 06:35, 20 March 2006 (UTC)[reply]

Since they're external and thus not hosted by Wikipedia, I don't think their copyright status matters; Wikipedia isn't responsible for what other websites provide. Unless it's a direct link to something highly illegal, I guess. (Obviously I don't exactly know.) –Tifego(t) 00:46, 20 March 2006 (UTC)[reply]
We strongly discourage linking to material explicitly known to be a copyright violation. Shimgray | talk | 22:11, 20 March 2006 (UTC)[reply]
I'm not a lawyer & I don't proclaim to know copyright laws, so how can I make that determination? If I went to Google Video and searched for "Hard Gay' videoes (a Japanese comic) in an attempt to enrich Masaki Sumitani page, what policy does Wikipedia provide me in order to figure this out? Also, what is the policy when I'm literate enough in a foreign language to find non-English source sites, but not literate enough to read the entire site to make copyright determinations? I'm looking for explicit clear policy here. I'd prefer a link to a Wikipedia help page rather than statements of opinion. Revmachine21 04:17, 21 March 2006 (UTC)[reply]
You could try listing something at Wikipedia:Requested copyright examinations, but that page is pretty stagnant. WP:EL is somewhat ambiguous about this, but I've removed links to Google videos because they're generally not permanent or official. I also think that if a video clip is valuable enough to an article, it should be uploaded to Wikipedia and claimed as fair use. ~MDD4696 05:40, 21 March 2006 (UTC)[reply]

New Language Wikipedias

Is there a way we can get some developers to look at Approved requests for new languages? About a dozen languages have been approved for creation, and the Norman test-Wiki has well over 100 articles already (more than nearly half of our "real" Wikipedias). No new wikipedias have been created in quite some time, however. The Jade Knight 09:17, 20 March 2006 (UTC)[reply]

Double redirects

I just had a look at Wikipedia:Double redirects to find out why Double redirects are considered a Bad Thing™.

The excuse given was that MediaWiki does not allow them to prevent infinite loops.

This is a very lame excuse.

Loop detection is a solved problem. I can imagine the programmer not putting it in as a day-one feature, but it's actually pretty simple. All you need is to remember all the article names you've visited in any redirection chain and bail out if you meet the same one again. As a sanity check you could put in a maximum hop count of say, twenty, just in case things go funny.

In fact what we have at the minute is a degenerate case of the above where the maximum hop count is one.

Surely it is better to have a proper article structure than to bitch about a few CPU cycles and a few lines of PHP.

(BTW, I am a sysadmin, database administrator, network administrator, web server administrator, programmer, etc., etc.. I do understand the technical issues. It's a little bit of extra server load, not a good reason to deny this functionality.)

Duckbill 09:53, 20 March 2006 (UTC)[reply]

You may be "a sysadmin, database administrator, network administrator, web server administrator, programmer, etc., etc.", but are you doing that for the #18 most popular website in the world on a shoestring budget? If you want it fixed, you can download the MediaWiki code and make the change yourself, and there's a good chance it'll be accepted. --Carnildo 19:08, 20 March 2006 (UTC)[reply]
Explicitly refusing to follow farther chains encourages people to keep the pathways clean, reducing spaghetti redirect chains which could be very hard to sort out when needed. So while it would be easy enough to let the software follow longer chains, we don't want it to. --Brion 21:43, 20 March 2006 (UTC)[reply]

Arrow display problem

The unicode symbols for '↘' "south west arrow" (U+2198) and '↙' "south east arrow" (U+2199) are reversed in the edit window - i.e. the arrow that should point south east points south west and vice versa. The same thing happens in <pre> formatted blocks, and in the edit window at Bugzilla. User:Thryduulf/Arrows shows the problem, Cousin chart is a real-world example of where the confusion exists.

I've reported this at Bugzilla (bugzilla:5295), but as the problem happens on Linux but not on Windows XP I'm now wondering if this isn't a MediaWiki issue but a font issue? Thryduulf 11:42, 20 March 2006 (UTC)[reply]

U+2198 (↘) is "south east arrow" and U+2199 (↙) is "south west arrow". see [7] for more information AzaToth 12:58, 20 March 2006 (UTC)[reply]

Whoops, yes I got that wrong. But the problem still remains that the arrows display differntly - it seems to be the article display is wrong. I've uploaded a screenshot to user:Thryduulf/Arrows to show the problem Thryduulf 15:45, 20 March 2006 (UTC)[reply]

It's a font issue. Threy show up just fine here. —Ilmari Karonen (talk) 16:03, 20 March 2006 (UTC)[reply]
Also the down arrow points right and the right arrow points down (but southeast and southwest both display correctly for me using Firefox 1.0.2 on SuSE 9). Slambo (Speak) 16:14, 20 March 2006 (UTC)[reply]
Here is it how it looks for me: Template:Imgbox AzaToth 19:39, 20 March 2006 (UTC)[reply]
They worked fine for me as well (Firefox 1.5.0.1, Windows XP). — Knowledge Seeker 08:55, 21 March 2006 (UTC)[reply]

My copy of the Unicode table says that 2192 is rightwards and 2193 is downwards (which is to say, in the image above, the alleged "Unicode descriptions" for those two characters are reversed, and the displays are correct). —Steve Summit (talk) 18:08, 22 March 2006 (UTC)[reply]

Popups and Godmode light

I use both Godmode-light and Navigation Popups. The problem is that when I view someone's contributions I see something like this:

  1. 12:38, 20 March 2006 (hist) (diff) m Hedy d'Ancona (Link Oxfam Novib) (top) [Erwin85&token=05a4b00f14a6262f5c4640189cc43060">rollback]
  2. 12:37, 20 March 2006 (hist) (diff) Samenwerkende Hulporganisaties (top) [Erwin85&token=83effcc91314a2d31e5598c64594cf1b">rollback]

where Erwin85 (username) is a link to the article with &fakeaction=rollback&vandal=title= added. Does this mean these two scripts are incompatible or did I do something wrong? User:Erwin85/monobook.js. Erwin85 12:51, 20 March 2006 (UTC)[reply]

I don't use godmode-lite, but I hear there are problems with popups. Try the variant godmode-lite listed at Wikipedia:WikiProject_User_scripts/Scripts instead. Lupin|talk|popups 13:10, 20 March 2006 (UTC)[reply]
This didn't fix it, but thanks anyway. I guess I'll remove godmode-lite, most of my vandalfighting is done on the Dutch Wikipedia where I use my own script for reverting vandalism, so I don't really use godmode-light that much. I can always edit my own script for the English wikipedia. Erwin85 13:39, 20 March 2006 (UTC)[reply]
you should see Wikipedia:Village pump (technical)#Contribs link in diff views, lightdarkenss made a fix. Makemi 23:33, 20 March 2006 (UTC)[reply]
The version at User:Ilmari Karonen/godmode-light.js (which Wikipedia:WikiProject_User_scripts/Scripts links to) should be fixed now, I think. I'm coming to the conclusion that what it really needs is a full rewrite, though. —Ilmari Karonen (talk) 23:58, 21 March 2006 (UTC)[reply]

Unknown new article shows up in my watchlist

File:Strange-watchlist-item.png
see the screenshot

This article Microshit suddenly showed up in my watchlist. I'm not aware of ever editing or touching this article before, in fact it only existed about 30 minutes before I refreshed my watchlist.

How'd that happen? SchmuckyTheCat 19:34, 20 March 2006 (UTC)[reply]

You are watching Microsoft. A vandal moved Microsoft to Microshit. You end up watching both. Sam Korn (smoddy) 19:46, 20 March 2006 (UTC)[reply]
I don't think it was moved. Microshit never had the edit history of Microsoft (shown in the screenshot) it linked to it and the link worked. The current article doesn't show any moves. SchmuckyTheCat 22:11, 20 March 2006 (UTC)[reply]
Looking at the deleted history for Microshit, I can see the page was moved 2006-03-17; look at the edit history for Microsoft around that date (you'll also find Mickeysoft on your watchlist from the same vandal). --cesarb 22:37, 20 March 2006 (UTC)[reply]
ah, the benefits of seeing deleted histories. so I only saw the edit history of the most recent recreation. SchmuckyTheCat 23:16, 20 March 2006 (UTC)[reply]

Anon Talk Pages

Hi all. I was wondering why the "Anonymous user talk page" footer only appears on some IP talk pages, like User talk:205.146.141.149, and not others, like User talk:207.15.198.140. Shouldn't it be on all anon talk pages? ~MDD4696 22:32, 20 March 2006 (UTC)[reply]

Issues with Godmode-light

Recently, when I've attempted to rollback vandalism with Godmode-light, I've received that message that the last editor was Contributions and not whoever the last editor actually was. Has anyone else been having this problem? If there's an easy solution can someone point me to it?

see Wikipedia:Village pump (technical)#Contribs link in diff views, lightdarkness made a fix. Makemi 23:27, 20 March 2006 (UTC)[reply]
[8] Sam Korn (smoddy) 23:28, 20 March 2006 (UTC)[reply]

Portal heading background

For the portal, how do i change the color of the heading background? Such as Selected article heading background etc. Tutmosis 23:33, 20 March 2006 (UTC)[reply]

Save Function

The save function is malfunctioning. Had to hit SAVE three (3) times for it to function. Martial Law 06:50, 21 March 2006 (UTC) :o[reply]

Log out, clear cache, log back in. Happens to me and someone told me to do this, fixed it for me. It was happening a lot to me today. Mike (T C) 07:03, 21 March 2006 (UTC)[reply]
That worked. Martial Law 07:19, 21 March 2006 (UTC) :)[reply]
Really appreciate the assisstance. Martial Law 07:20, 21 March 2006 (UTC) :)[reply]
NP, if you want the reasons it does it, search the WP:AN archives, i know it is there, around the time of a crash at the start of the year. Mike (T C) 07:41, 21 March 2006 (UTC)[reply]

blocked user

Is it true that blocked users are allowed to make edit to their own talk page on en.wikipedia? How to request this feature on other wikipedia? Thanks borgx (talk) 08:15, 21 March 2006 (UTC)[reply]

Yes, it's true. You have to ask a developer to turn it on. --cesarb 00:53, 22 March 2006 (UTC)[reply]
I wouldn't. It causes nothing but pain. -Splashtalk 01:53, 22 March 2006 (UTC)[reply]

A proposal that came out the Main Page Redesign discussions was:

  • Improve visibility of the left-navigation search box in the default MonoBook skin. Perhaps, an orange-colored border (as used on the active tabs at the top)?

This would be to aid new users in finding the search box.

this is easily shown by adding this line to one's user/monobook.css
(and presummably common or monobook css for sitewide)
#searchBody {border-color: #FABD23;}
The proposal was initially offered as an alternative to a second search box that was appearing in the headers of many redesign-drafts. (links to discussion archives: 1 - 2 - 3 (main discussion) 4 (vote and 3 colour examples))

The only question remaining is can this highlight be coded to display on only select pages? (specifically the Main Page, and possibly any others we wanted to choose) (or only for non-signed-in users, or other useful permutations?) Or is it a choice of "site-wide or nothing"?

Once this is answered, I will copy the proposal to the proposal page. Thanks. --Quiddity 09:20, 21 March 2006 (UTC)[reply]

Problem with Infobox

I was trying to edit the page University of Hyderabad. In the box on the right hand side of the page it shows text like {{{free_lable}}}. any idea how to remove it. --Bolasanibk 09:45, 21 March 2006 (UTC)[reply]

looks like he fixed it --Quiddity 10:54, 22 March 2006 (UTC)[reply]

List of interwikis

Is there a full alphabetical list of interwiki links anywhere? I keep on finding interwikis put in alphabetical order of the code rather than the language, and correct the 'out of order' ones I know about:

  • es: (Español) comes before eo: (Esperanto)
  • ko: (Hangugeo) comes before hi: (Hindi)
  • he: (Ivrit) comes after it: (Italiano)
  • ja: (Nihongo) comes after nl: (Nederlands)
  • fi: (Suomi) comes just before sv: (Svenska)

but also wonder how many others are there which I don't know about. An easily found full list that I can refer newbies to would be useful. - MPF 11:26, 21 March 2006 (UTC)[reply]

See m:Interwiki sorting order and Wikipedia:Language order poll. Martin 12:09, 21 March 2006 (UTC)[reply]
Thanks! Didn't realise it wasn't fully settled. Shouldn't the poll be advertised a bit more widely? I've been a contributor for over 2 years and knew nothing about it. - MPF 13:31, 21 March 2006 (UTC)[reply]


Is the browsebar useful?

A discussion concerning the above {{browsebar}} is taking place at Template talk:Browsebar#Is this bar useful?. The problem is, nobody really knows what use is being made of the thing (and its various other versions), or by whom. Therefore, I have two questions for you wikitechies:

  1. Is there a way of measuring usage of templates and their various links?
  2. If so, how?

Otherwise we'll just be basing any changes made to it (and its placement) on sheer guesses. Please help. --Go for it! 22:20, 21 March 2006 (UTC)[reply]

No. Whenever somebody (usually you) sticks it on a category I'm watching, I take it off again. (I'm not sure where else you stuck it in the past.) Also the other variants: "betterbrowsebar", "morebetterbrowsebar", "muchomachobrowsebar", etc.

As to your technical point, access counters are nearly impossible to do, as there are many cache, and squid, and apache servers handling the load. I'm fairly certain there's nobody correlating the logs. Certainly the ISP that I founded does not report back to Wikipedia from our logs, and we've never discussed it at NANOG.

--William Allen Simpson 08:10, 22 March 2006 (UTC)[reply]

Close-Comment Markup Provided on Server Side

Unless you believe i forged the section-name in my summary (i don't believe that [grin]), this diff testifies that my saved edit of a section resulted in the addition of the three characters

-->

at the end of the file, within a section that did not appear in my edit pane during the edit. I presume the condition that might lead to this is my having left, in the section i was editing, but later than the last close-comment on the page, an "open-comment" markup

<!--

I can see reasons why such a measure which might actually be a good idea. But it violates the convention that everything in the edit window (allowing for template substitutions) and nothing else gets into the new revision (with (IIRC) some exceptions involving only white-space). In that, it may be too clever by half. (I haven't determined if it is replicable.) If this is permanent, IMO it is a significant breach in the transparency of editing, which may undercut the sense that you can become a contributor in the first 60 seconds after deciding you want to; IMO it would deserve discussion.
--Jerzyt 22:54, 21 March 2006 (UTC)[reply]

There are various postprocessing steps done when you save an edit; for example the 'signature' and save-time includes of templates. Due to the way comments are involved in postprocessing, an open-comment without a close bit will end up adding the missing close bit back in at the end.
"Section editing" is an illusion of convenience; actual processing happens on the complete page. --Brion 00:25, 22 March 2006 (UTC)[reply]

And a very convenient illusion it is. And the sense of control is a convenient illusion apparently supported by the relative harmlessness of the distinction between an unclosed comment and one closed at the end of the page. As Buckaroo Banzai advised, i support not "tug[ging] on that; you never know what it's connected to." If it's just something i've never noticed before, it's certainly worth living with. Thanks.
--Jerzyt 03:03, 22 March 2006 (UTC)[reply]

Very nice redesign - congratulations to all.

Can a 'tomorrow' link be added programmatically to On This Day? Since Wikipedia seems to run on UTC/GMT or AAT (America Awakens Time), On This Day only changes after the four billion or so people who live east of Greenwich have already begun to experience the next day. We aren't so impressive at the watercooler/pump when we're talking about yesterday's events! Assuming Wikipedia won't undergo a virtual relocation to the international dateline, perhaps the masters of the mainpage could save us a click or two by providing a link to the forthcoming day as well as the last three? How about it? --Brian Samosa 22:42, 21 March 2006 (UTC)[reply]

Um, actually, no, when GMT is at midnight, Beijing - which is UTC+8 - is just getting to work. So they have plenty of stuff to chat about that occurred that day. So while your request is a valid one, your reasoning is a bit off. A few hundred million people live east of UTC+8, but the bulk of the "four billion" is still asleep when UTC reaches midnight and Wikipedia ticks over - in particular, India still sleeps. --Golbez 00:35, 22 March 2006 (UTC)[reply]
However I'd say the largest amount of english speaking countries are east of GMT. Mike (T C) 04:00, 22 March 2006 (UTC)[reply]

I want to add a wikipedia search bar to my site!

Hi guys,

i would like to add a search bar on my site, that directs users to wikipedia results once they have entered a term. does anyone know of any tutorials or html to do this?

thanks guys

Just add this code:
<!-- wikipedia search -->
<form name="searchform" id="searchform" action="http://en.wikipedia.org/wiki/Special:Search">
<input type="hidden" name="go" value="go" />
<input type="text" id="searchInput" name="search" size="20" />
<a href="http://en.wikipedia.org/wiki/Main_Page">wikipedia</a>
</form>
<!-- wikipedia search -->
hope that helps :) --Quiddity 01:09, 22 March 2006 (UTC)[reply]

Google's cache of en.wikipedia

Does anyone know how often or what day google re-caches or re-crawls en.wikipedia? I'm slowly correcting misspellings, and I use google to scan each article. Once corrected, it'll still pop up under the old cache with google, but going to the article reveals I've corrected it. Thus, I want to know when I should re-search to find fresh instances.

Thanks, JoeSmack Talk 01:14, 22 March 2006 (UTC)[reply]

Pretty often, I think. Google cached my user page just yesterday, but I don't know how long the time lapse was before that. I include the current date at the top so I can quickly see how old my user page on mirrors and caches is. ~MDD4696 02:11, 22 March 2006 (UTC)[reply]
I've been watching the recently created article Linda Marie Fedigan. This (still incomplete) timeline may help.
Perhaps it's related to the missing {{newpagelinksmain}} which somehow got lost when the Main Page was changed recently. I've added it back. --cesarb 16:39, 22 March 2006 (UTC)[reply]

Changing next/previous to earlier/later

On history pages, it currently says:

(Latest | Earliest) View (previous 50) (next 50)

But because it is in reverse chronological order, to get to later diffs, you have to press previous, which is silly and backwards. With your permission, I'd like to edit MediaWiki:Prevn and MediaWiki:Nextn to say "later" and "earlier":

(Latest | Earliest) View (later 50) (earlier 50)

I am worried that this might conflict with things like Category page listings, which also use (previous 200) (next 200). If so, it will need a real bugfix. See bugzilla: 5310. — Omegatron 02:16, 22 March 2006 (UTC)[reply]

I don't know what the right fix here is, but I definitely second the concern. (The labels are indeed backwards, and not just "silly" but downright confusing.) —Steve Summit (talk) 17:10, 22 March 2006 (UTC)[reply]
possibly more a policy proposal than technical? technical aspect would be easy, it's getting people to agree that is hard!
However i do agree that the keywords used are misleadingly chosen. --Quiddity 08:17, 23 March 2006 (UTC)[reply]

Suggestions

Current ordering/naming scheme

(Latest | Earliest) View (previous 50) (next 50) 

Potential reordering/renaming schemes:

(new names)

(Latest | Earliest) View (later 50) (earlier 50) 

or (original names, new order)

(Latest | previous 50) View (next 50 | Earliest}

or (new names, new order)

(Latest | later 50) View (earlier 50 | Earliest}

{others?} --Quiddity 07:45, 24 March 2006 (UTC)[reply]

Watchlist via transclusion?

I would like to display watchlist on my custom portal page together with other templates such as Template:Announcements/Community bulletin board. But typing {{Special:Watchlist}} only creates a link to watchlist and does not output the list itself. iframe tag doesn't seem to work either. Is this possible at all?Hermeneus (user/talk) 02:30, 22 March 2006 (UTC)[reply]

It's possible to add some javascript code to your monobook.js that will query the watchlist page and replace that part of your page with what it gets from the watchlist. I don't know if there is an easier way. –Tifego(t) 00:46, 20 March 2006 (UTC)[reply]
Thanks for the info. It sounds a little too diffucult for me because I'm not so fluent in JavaScript... Hermeneus (user/talk) 03:54, 22 March 2006 (UTC)[reply]
Well, most of the code is probably already written by other people, it might be pretty easy actually, let's see... –Tifego(t) 00:46, 20 March 2006 (UTC)[reply]
I am also looking for similar code to slightly different end as described at meta:Share watchlists. I would love a monobook.js script or similar that would scrape a watchlist, reformat into wiki-usable code, and copy to clipboard or better yet a user subpage as User:Here/watchlist. here 04:34, 22 March 2006 (UTC)[reply]


I got it working! Only for what Hermeneus wanted though. (There's code in there from godmode-light to parse it as XML that could be used to wikify and transfer it somewhere, but...) Right now all it does is display part of the HTML from the watch list page in place of what the wiki code {{Special:Watchlist}} becomes.

For the watchlist to show up, edit your monobook.js user page (assuming you did not change your skin away from the "standard" Classic skin in your preferences) and paste all the code from my monobook.js into there. Or, I don't know if this will work, but you could also try only adding this instead:

document.write('<script type="text/javascript" src="' 
             + 'http://en.wikipedia.org/enwiki/w/index.php?title=User:Tifego/monobook.js&oldid=44919775' 
             + '&action=raw&ctype=text/javascript&dontcountme=s"></script>');

Either way, save the page and then fully reload with Ctrl-Shift-R or (in IE) Ctrl-F5, and when you go to your custom portal page you should see {{Special:Watchlist}} get replaced with your watchlist. Right now it's set to hide your own edits and only show 0.1 days but those are both customizable at the top of the script. This has been tested in Firefox 1.5, Internet Explorer 6, and Netscape 8. (But it has a very high chance of not working in other browsers.)

Note also, I have godmode-light (rollback button), extra edit buttons, and an IE6 alpha fix installed in the script, but those are easy to disable if you really don't want them. –Tifego(t) 00:46, 20 March 2006 (UTC)[reply]

Thanks! It seems to be working fine (MacOS X 10.4 & Firefox 1.5). Is it possibe to use it on ja.wikipedia as well if I replace en.wikipedia with ja.wikipedia in URLs? Hermeneus (user/talk) 08:30, 22 March 2006 (UTC)[reply]
Yes, you can use it on ja.wikipedia with some small changes. Edit your monobook there and copy a different script into it, this monobook.js, and fully-refresh like before. Also, I don't know how to search for the japanese characters in the link that {{Special:Template}} becomes, so instead you will have to use <nowiki>{{Special:Template}}</nowiki> so it's text without a link. (Does anybody know of an easy way to convert a unicode character into its %##%## equivalent?) –Tifego(t) 00:46, 20 March 2006 (UTC)[reply]
My personal portal subpage on jawp is here and monobook.js here. jawp uses "利用者:" for "User:" and "特別:" for "Special:." Watchlist is the same "Watchlist." The watchlist link generated by Mediawiki seems to use the Japanese names converted in url code ( "特別" is "%E7%89%B9%E5%88%A5" The url code of a Japanese word could be found in the url when you google search the word), but they are accesible vis English name as well. (Both ja:User:Hermeneus and ja:利用者:Hermeneus works.) Hermeneus (user/talk) 11:27, 22 March 2006 (UTC)[reply]
When you type "{{Special:Watchlist}}" in the form of the portal subpage, it will generate <p><a href="/enwiki/wiki/%E7%89%B9%E5%88%A5:Watchlist" title="特別:Watchlist">特別:Watchlist</a></p> in the source code of the output of the subpage. Hermeneus (user/talk) 11:50, 22 March 2006 (UTC)[reply]
It seems to be working on jawp now as well. In ja:User:Hermeneus/monobook.js I replaced
var watchStringFF = '\{\{Special:Watchlist\}\}';
with
var watchStringFF = '\<p\>\<a href=\"/wiki/%E7%89%B9%E5%88%A5:Watchlist\" title=\"特別:Watchlist\"\>特別:Watchlist\</a\>\</p\>';
All seem well now. Many thanks! Hermeneus (user/talk) 12:06, 22 March 2006 (UTC)[reply]

Database error

From Wikipedia, the free encyclopedia
:Jump to: navigation, search


A database query syntax error has occurred. This may indicate a bug in the software. The last attempted database query was:

(SQL query hidden)

from within function "SiteStatsUpdate::doUpdate". MySQL returned error "1213: Deadlock found when trying to get lock; Try restarting transaction (10.0.0.101)"


This happened when I had an edit conflict, instead of the usual edit conflict page. (Note that it was an edit conflict with myself, which I'm not sure should even be possible.) Anyone care to explain, or does it probably not matter? –Tifego(t) 00:46, 20 March 2006 (UTC)[reply]

Updates to CSS and JS pages to reduce redundancy

MediaWiki:Monobook.js

  1. Replace addLoadEvent(func), as this one is already contained in ../wikibits.js; see this change on alsWP
  2. Consider adding pTitle() from alsWP; see Template_talk:Lowercase#Redrafting_title_with_a_JavaScript_trick

MediaWiki:Common.css

  1. Remove .hiddenStructure, as "speak:none" has been added to ../main.css
  2. Consider removing .plainlinksneverexpand, etc. one day; see MediaZilla:714

Best regards, Melancholie 05:09, 22 March 2006 (UTC)[reply]

The disappearing line

This is not an urgent question, but I've been wondering why the text "From Wikipedia, the free encyclopedia" can sometimes be seen under the article's title, but sometime it's gone. Even a reload can make it vanish. Thanks for your time. Mysid 10:36, 22 March 2006 (UTC)[reply]

MediaWiki pages and sidebar

Hello all. How do you edit the bar on the left, the one that holds navigation, search and toolbox and how to edit the contents of these 3 menus?

Also how do I list all the mediawiki pages or where is there a listing of the mediawiki pages? Special:Special pages works for special pages but MediaWiki:MediaWikipages does not for mw pages *sigh*

Thanks

Not to sure about the sitebar things, but I would not be supriced if they are somewhere in MediaWiki space too. To list all Mediawiki pages go to Special:Allpages and pick "Mediawiki" in the namespace filter[9]. --Sherool (talk) 22:27, 22 March 2006 (UTC)[reply]
See Mediawiki:Sidebar. This contains the navigation links. Editing search or toolbox requires hacking the PHP. See also Special:Allmessages which contains many, but not all, of the important system messages. Sherool suggestion should get them all. Dragons flight 14:48, 23 March 2006 (UTC)[reply]

Someone has vandalized this page. Patchouli 15:26, 22 March 2006 (UTC)[reply]

Are you sure? I'm not seeing it.
There are probably better places to report vandalism than this Village Pump subpage. One is Wikipedia:Administrator intervention against vandalism (a.k.a. WP:AIV), and there are probably others. —Steve Summit (talk) 18:16, 22 March 2006 (UTC)[reply]

A number of bots have repeaedly changed the interwiki link on the Torre del Greco page to the Neapolitan wiki. It needs to be Torre d''o Grieco, not Torre do Grieco. Is there anything that can be done about this? Thanks.--E. abu Filumena 21:09, 22 March 2006 (UTC)[reply]

You might want to comment on the discussion page for the offending bot, or for the bot's owner. Sometimes it might make a difference. Otherwise just remain ever vigilant and suspicious of any bot edits. —Mike 04:03, 24 March 2006 (UTC)[reply]

AFD discussions

I tried to print Wikipedia:Articles for deletion/Jill Hardy. However, when I clicked Print Preview, all the text between the top and bottom header (the "this discussion is archived") was gone. I thought this was odd, so I checked out the March 14 AFD page, most of whcih are also archived. I clicked Print Preview again and all the text showed up. Did something suddenly change between December and March? - Hbdragon88 05:15, 23 March 2006 (UTC)[reply]

Same problem here. To make things more precise: the "Print Preview" that causes problems is that of the browser (I use Mozilla); the same problem occurs when actually printing or using the "printable version". This must be a CSS problem, as downloading the page and printing the local copy (where the CSS files are not accessible) shows all content. - Liberatore(T) 13:18, 23 March 2006 (UTC)[reply]
Looks like {{afd top}} is using class="boilerplate metadata vfd". According to Wikipedia:Catalogue of CSS classes, metadata is "hidden when printed". The template is wrong; it shouldn't be using either boilerplate or metadata (and vfd would need to be modified to have the correct styling). Unfortunately, since the template is subst:ed instead of transcluded, a bot would have to be used to fix all the old instances. --cesarb 16:56, 23 March 2006 (UTC)[reply]
I have proposed changes to fix this on Wikipedia talk:Articles for deletion. --cesarb 17:27, 23 March 2006 (UTC)[reply]

MediaWiki Questions

  1. How does Wikicities get the Google adds to appear on the side?
  2. Can MediaWiki stop non logged in users from editing (except talk pages)?Found answer on Meta Gerard Foley 14:41, 23 March 2006 (UTC)[reply]
  3. Activate file uploads?

Thanks, Gerard Foley 12:25, 23 March 2006 (UTC)[reply]

I found the answers to these questions, thanks Gerard Foley 10:23, 24 March 2006 (UTC)[reply]

Is it possible to give the form on Special:Blockip a name?

It'd make making my javascript helper easier if it did. Sceptre (Talk) 12:31, 23 March 2006 (UTC)[reply]

Here's my Javascript function. It prompts, but won't fill in fields.
function block()
{
/*Yes, this is ugly, but it'll have to do for the mean while. Can someone use a "get pagename" script to work with this?*/
var user = prompt("User?");
var long = prompt("When is the expiry?");
var why = prompt("Reason?");
blockw = window.open('/wiki/Special:Blockip/' + user);
blockw.document.forms[0].name = 'block';
blockw.document.block.wpBlockReason.text.value = why;
blockw.document.block.wpBlockOther.text.value = long;
blockw.document.block.submit();
}

<ref>

I really like the new <ref>...</ref> style, but how does it work? Is it a recent software update? It doesn't appear to work on my relatively recent MediaWiki 1.5.6 installation. Similarly, how do I get variables like {{FULLPAGENAME}} to work? They appear to be hardcoded here, but not in the distribution I downloaded. dab () 14:01, 23 March 2006 (UTC)[reply]

This is one of very many enhancements to the production line version of Mediawiki, 1.6alpha. In theory you can download it out of CVS, but good luck getting it to set up correctly. I'd appreciate a developer comment on the time frame for a 1.5 -> 1.6 upgrade release. There are so many cool things in 1.6 that it is frustrating to be behind the curve. Dragons flight 14:53, 23 March 2006 (UTC)[reply]
No, it's not an enhancement to the production line MediaWiki; it's an extension called Cite.php. I don't know if it works with MediaWiki 1.5 or if it requires MediaWiki 1.6, however. As for FULLPAGENAME, AFAIK it's one of the many new variables introduced on 1.6. --cesarb 16:43, 23 March 2006 (UTC)[reply]
I believe it does require 1.6, so same difference. Dragons flight 17:16, 23 March 2006 (UTC)[reply]

Hi, Is there any way that this very useful option can be adjusted such that it displays the last reference article first? I find it very, very useful when monitoring topics of interest. I use it at least three times a day and where some of these references are getting long it is becoming more and more time consuming when checking the linked articles. HJKeats 17:03, 23 March 2006 (UTC)[reply]

Didn't fetch many responses on this question. I'm sure many people use the What links here special pages, I know I do. I believe that it would be very useful to display the latest items first as opposed to clicking through many pages to get to last item linked. HJKeats 12:39, 24 March 2006 (UTC)[reply]

I originally posted this at Wikipedia:General Complaints but haven't got any response there; maybe someone here can help. I was recently reading Marseille and noticed that the big column of right-floated images that appear at the top of the page has caused all of the [edit] links for each section to essentially be shunted down to beside the last of the images, all side by side. This must make section-by-section editing of this article impossible! Is there any solution to this either by editing the way the layout is achieved in wikicode or by changing the way the edit links are laid out by the software? BigBlueFish 17:10, 23 March 2006 (UTC)[reply]

This is a browser specific rendering issue. Depending on the nature of the problem and the relative share of the browser in question, it might be worth trying to improve platform compatibility, though. Dragons flight 17:21, 23 March 2006 (UTC)[reply]
See also: Bug 1629. Slambo (Speak) 17:28, 23 March 2006 (UTC)[reply]

listing subpages?

Is there a way of listing all the subpages of an article or user page? (Including, but not limited to, the ones you've forgotten about and don't have any extant links to?) —Steve Summit (talk) 18:08, 23 March 2006 (UTC)[reply]

Try [10]. Fill the prefix box with the page you want the subpages of. You can see an example on my user page. Gerard Foley 18:15, 23 March 2006 (UTC)[reply]
Cool! Perfect. Thanks. —Steve Summit (talk) 19:15, 23 March 2006 (UTC)[reply]


How do you add an article to a category?

Yup, the title says it. Assistance, please?

Simple. Add [[Category:So-and-so]] at the bottom to add the article to that category. Category convention is to put the last name first, in whcih case you would write [[Category:So-and-so|Last name, first name]] - Hbdragon88 04:19, 24 March 2006 (UTC)[reply]

Colours gone crazy?

On the Central railway station, Sydney page which I've done a lot of work on, the template up the top describing the Cityrail stations is supposed to have white text so it is readable. However, it seems to have changed to black and isn't recognising written colours (only Hex coded ones). So wherever "color=white" is in the code, it doesn't work.

This will be a lot of work to fix up if I have to go through every page and manually change the colour to a hex code. Is this a bug or has something changed? (JROBBO 03:19, 24 March 2006 (UTC))[reply]

Sounds like a browser issue, the article looks fine for me in Opera 8.5, FF 1.5 and IE 6 on Windows. What browser are you using? -- Tim Starling 05:23, 24 March 2006 (UTC)[reply]

Automatic additions to watchlist

Recently I've noticed that any new article I make automatically gets added to my watchlist. I find this incredibly annoying and a hassle to have to constantly keep editing my watchlist to remove these items. When was this bug "feature" added and can it be removed? Grutness...wha? 08:18, 24 March 2006 (UTC)[reply]

Check your Preferences. Under "Editing" there are the options "Add pages you create to your watchlist" and "Add pages you edit to your watchlist". This changes the default for the "Watch this page" tickbox you get whenever you edit a page (below the summary field). HTH —da Pete (ノート) 09:11, 24 March 2006 (UTC)[reply]

Nocover.gif trouble

Hello, I'm having some problems with the image nocover.gif. It is used on the We Don't Need to Whisper article, the upcoming album from the band Angels and Airwaves. Instead of showing the actual image (an empty album case), it shows a cover from "The Flaming Lips". I cleared my caché, and I visited the article from different browsers (IE 6 and Firefox 1.5), but I still got that image. Is there any way this can be worked out? Thanks! --Greedy 14:20, 24 March 2006 (UTC)[reply]