Talk:Main Page/Archive 4

From Discworld MUD Wiki
Jump to: navigation, search
Filing cabinet.gif This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page, and link to sections in this page if neccessary.

Item Shop Inventories

I have noticed that there is not a comprehensive list of item shops (as far as I can find) and this could be a useful thing to put on the Wiki. This would help people find particular items which they want or need and is also a large but relatively easy project for me to research since I'm kind of a newbie. Can someone with some experience in adding to the Wiki tell me if this is a good idea? --Thistleryver 04:54, 14 April 2011 (UTC)

While it is something that would be worthwhile, especially if items are browse appraised (unfortunately you have to do it one item at a time), but since but Kefka has already made a fine database here I guess I don't feel an urgency to redo it all. --Frazyl 05:18, 14 April 2011 (UTC)


We seem to have a new breed of spammers (you can recognize them by their usernames, which comprise of a name followed by a random sequence of numbers) that are able to defeat the captcha to create accounts and then insert spam URLs into pages. Because they're using logged-in accounts, we can't use semi-protection to defend against them.

There are, however, a few things we can do:

  • At the moment, all user accounts are immediately promoted to auto-confirmed user accounts - what this means is that they're immediately able to edit semi-protected pages. We could change the default settings for auto-confirmation (would require Drakkos to do, but should be trivial) such that user accounts must make a minimum number of edits and exist for a minimum number of days before they are autoconfirmed - this is what most other wikis do, and would put spammers back at the mercy of our protection-settings.
  • Of interesting note is that all the pages targetted by this type of spammer have 'armour' somewhere in their title (presumably to create some sort of association with 'health shield' or some such). If they start getting annoying, we could just full-protect pages with 'armour' in the title for a while. Obviously, this has the downside of stopping anyone else from editing them too, however.
  • I'm not sure whether there are known vulnerabilities with reCaptcha that have been patched in a more recent version; if so then perhaps a simple upgrade will resolve matters.

--Chat 00:11, 6 January 2011 (UTC)

Changing auto confirmed settings would be the best option I reckon. Rehevkor 14:59, 6 January 2011 (UTC)
I agree. Though I wouldn't be opposed to temporarily full-protecting those pages if it kicks up again (seems to have stopped now, so maybe it was a one-off thing, knock wood), since they're not exactly busy pages. --Ilde 19:00, 6 January 2011 (UTC)
I just had to revert the armour page again :( Zexium 04:03, 8 January 2011 (UTC)
and now the category:armour page .... I've tried something that assumes the script will abort if it finds an apparently already spammed page ... there's an html comment containing what looks like the spamlink as a wikilink - fingers crossed Zexium 05:10, 8 January 2011 (UTC)
Based on how spambots have behaved in the past, I really really doubt they check the page first before spamlinking - it's just not worth their time/coding effort to do so over the blunt-force approach. There've been several pages where spambots merrily competed with themselves to rewrite links in the past, before someone got around to protecting them. In any case, I don't like the idea of putting their links into comments, as:
  • It feels too much like doing their job for them, and would achieve their goal if someone naive/stupid started editing an article and felt like following the strange, commented out link.
  • Let's say it worked, and the spambot had a script that realized the page was already spammed. I think it's possible the spambot would then have logic that says 'Aha, some of my spam still exists here! Here's a wiki that's not closely monitored, where spam/vandalism aren't cleaned up very often. Focus spam effort on this wiki!'
  • Note that the spam links appear to have some kind of revision ID in them. I assume that's going to get changed after a while (to make naive string-matching based anti-spam systems fail to spot it), at which point all the commented out links will be useless.
I'm removing the commented out link for now. If we get much more spam, I'll try locking down the armour pages for a while. --Chat 10:54, 8 January 2011 (UTC)

Another idea if the update of reCaptcha doesn't stop spammers and they make it through the time limit and number of edits would be to make accounts not auto-confirm themselves automatically.

Instead, having admin users approve new users manually either on request or regularly (by checking if there's a discworld user by that name?) would probably frustrate spammers enough that they move on elsewhere.

I'm not sure which is least annoying to actual new users, to have to go through a testing period or ask someone through the mud. For catching spammers it would be spotting bad small edits vs approving new users regularly.

--Frazyl 20:02, 6 January 2011 (UTC)

Upcoming events

3 May 2011 Xola (Talk | contribs) (6,652 bytes) (n.b. prev edit doesn't mean I'm comin, people remaining=diffrent type of ppl frm whn I was @school, met few cool ppl alrdy. the culture of cres attractd OCD & PK obnoxiousness rathr thn creativity...)

3 May 2011 Xola (Talk | contribs) (6,651 bytes) (+ current/soon/previous events ( Category:Events ))

3 May 2011 Chat (Rolling back. Not worthy of being at the top of the main page, and clashes against the existing main page layout. Use the 'people of discworld' box if you really think this is necessary.)

15 May 2011 Xola (Oh come on,"not worthy"? :) Boxes too cluttered,current &upcoming stuff is *really* important, if more people knew was a place to put stuff up,would encourage more things being organised!)

15 May 2011 Frazyl (Considering there has not been any upcoming events, it seems better to put it in "People of Discworld". Now we could put it in the navigation sidebar but I'm not sure if the category is the best page.)

Stop thinking like librarians! :)

Build it and they will come! Don't base it around what's there, make it an open environment for people to add and start new things, and it will happen! Probably!

Though I don't know why I'm doing it because none of the events are even vaguely social anymore just grindy stuff or related to minigames so pff, just nostalgia of what the place used to be I guess hehe

--Xola 09:57, 21 May 2011 (UTC)

No need to give it such prominence on the main page, there's already an events link in one of the boxes below. And there's no need to dick around with the formatting of the main page, it's fine how it is. I don't really wanna have to protect it. There's a whole wiki out there for you to create whatever articles you want. Rehevkor 14:19, 21 May 2011 (UTC)

And not long after I reverted the main page I put a link to Events in the navigation bar (to the left just below the turtle). So for a while now that link is present in ALL pages. Surely that's present enough? I suppose I could make it a different colour.
Now granted the page looks a bit messy right now, I think it would be best to turn it into a table but I haven't had the time yet. --Frazyl 19:00, 21 May 2011 (UTC)
Ok I put the Events link with a yellow background. Should stand out enough. You'll have to force refresh (not just refresh) the page to see it, or clear the cache of your browser. Or you can restart it. --Frazyl 19:20, 21 May 2011 (UTC)
I changed the Events page into a table, I think it looks usable. Just need people to add upcoming events or even past events to the table. I added some past events but getting dates for when it happened wasn't always easy. --Frazyl 20:48, 21 May 2011 (UTC)
The yellow link stands out even worse than the original overly-prominent link on the main page. Sorry, but I really don't think that's warranted - events is not the most important page in this wiki. Really it isn't. And punting it right up to the top of the main page, or putting it in an extra-special stand-out colour gives that impression.
Xole, there's a new events command in-mud (see here ) which ought to cater to your needs. If you have events to advertise, that's the command to use. The wiki really isn't suited to being an announcement medium, nor is it intended to be. --Chat 21:12, 21 May 2011 (UTC)
Yes, I suppose the yellow background stood out a bit too much. I checked the events command on the mud the other day and all there was on it was the AM council election. People mostly just post events to the boards. --Frazyl 22:40, 21 May 2011 (UTC)
Agree, the yellow isn't really necessary. Rehevkor 23:10, 21 May 2011 (UTC)

Crashing of the Swords page

Added in the data for Scimitar and now the swords page is crashing. Just a heads up. Delete this once the problem is solved. -- Baldarov

I've had to revert your scimitar changes to unbreak the swords page. The actual problem is nothing to do with scimitar - the problem's with the transcluded weapon-add templates being just too big.
If you visit swords now, you'll see that:
  • Not all the swords are actually there
  • There's some code leaking into the table at the bottom.
  • Try editing the page and you'll get 'Warning: Template include size is too large. Some templates will not be included.' at the top.
So basically, the weapon info template is now just too huge for the wiki to handle, and it's grinding to a halt trying to do so. I strongly recommend resolving this before attempting to add any more weapons. --Chat 17:41, 3 June 2011 (UTC)
Yeah, I figured that scimitar would have to be reverted to get sword back up. Should have done it myself :P. I've checked some other pages and they're getting very slow as well. Probably will have to split into pages somehow... -- Baldarov
I've now reduced the overall page size by collapsing {{ratebar}} down to an image (it was previously a big table expansion); swords and daggers are no longer reporting template inclusion size issues. --Chat 18:57, 3 June 2011 (UTC)
Cheers! I was just thinking that the big cpu/data user might be {{ratebar}} and that I'd have to check it. Thanks Chat! :) --Frazyl 19:17, 3 June 2011 (UTC)

Viewing figures

Just thought you guys might like to know - unique daily visits to the site for the month of December 2009 broke 1,000 - we hit 1,001, as a matter of fact.

For interest, here are the figures for the past few months:

Mar 2010        1104
Feb 2010        1212
Jan 2010        1114
Dec 2009 	1001 	
Nov 2009 	919 	
Oct 2009 	796 	
Sep 2009 	676 	
Aug 2009 	540 	
Jul 2009 	398 	
Jun 2009 	279 	
May 2009 	165

Great work everyone - many thanks for your continued work in making this wiki a great resource for DW players everywhere! Drakkos 21:54, 3 January 2010 (UTC)

January 2010 hit 1114 unique daily visits, FWIW. Drakkos 00:21, 2 February 2010 (UTC)
February 2010 : 1212
Interesting. Increasing fairly consistently. Rehevkor 13:31, 2 March 2010 (UTC)

Articles that are categories

I've noticed a few of these. Categories that are masquerading as articles. One example being Category:Dibbler_clones - all the information there should be in an article. I've noticed several of these scattered about. Would be there be any opposition to cleaning this up? Rehevkor 23:21, 18 December 2010 (UTC)

And also, bred and butter information such as this should not be in categories as they will not show on default searches. Rehevkor 23:22, 18 December 2010 (UTC)
Category:Furniture is a pretty bad offender too. Rehevkor 23:30, 18 December 2010 (UTC)
I'm not so sure about this. If I search for "dibbler" or "dibbler clones" then the category obviously doesn't show up in search without someone creating a redirect for it. (Redirect to specific clone within the clones page might be ugly or bad usability?) But I think there should be a page for Dibbler himself, which includes a link to dibbler clones. Meanwhile the clones page shows under category NPCs, and the pages of each of those NPCs can be grouped together that way.
Furniture is an example but is it good or bad? It has a redirect from the search term "furniture" which could also be a Furniture page (instead of category page) that explains furniture in general. The Furniture would probably need a link to the furniture category because individual pieces of furniture can certainly deserve their own wiki pages. In this case a few of them already have one and Category:Furniture indexes them nicely. Whatever is the final setup Furniture should probably also happen to Container(s) (which is a sibling category but not really parent or child) and its potential sub-category Scabbard(s). (Both currently pages but individual containers or scabbards could well have their own pages, especially if there's something special about them that needs explaining like involved acquisition, unique commands, room chat etc.
Similar discussion might also happen under Category_talk:Items since the big Items and Weapons category pages are being cleaned up right around now.
Rhonwen 12:37, 19 December 2010 (UTC)
Well the purpose of categories are to list articles currently within the wiki. The ability to add text to them is just so a brief description can be added, no information should be there that isn't already in the article space. I see no reason why this information should be listed within a category page. As for the furniture page, a good option would be to move it to Furniture and split the list itself into List of furniture, or similar. These articles can all be categorised/subcategorised as required but the infornation should be in the article space. Rehevkor 15:15, 19 December 2010 (UTC)
Hmmm. Well, I guess since it's messing up searching, it would be better to split them. It's just a bit annoying to me to have what's basically one thing split up into several pages (I mean, the category itself is a bit of an afterthought... for most furniture, I see no reason whatsoever they should have separate pages--since all the relevant information about them is in the list (in a superior format, imo, since you can easily compare it with others that way), it's just very redundant and basically extra work to make... clutter) so that you have to hunt around and wikiwalk to find something. But meh.
Maybe it would be best to just have Category:Furniture, Furniture and List of storage furniture (since that one list is really the thing making that page huge).
--Ilde 18:40, 19 December 2010 (UTC)
I guess Category-articles started off with a need to have the category pages be more useful, to combine purposes to make them more complete, especially when the content is (initially anyway) rather small. Or maybe you want to include all the member pages which you can do for free in the category page, sort of like a See also section that updates itself when anticipated new pages come in (which may not actually show up).
I suppose the list of member pages can be seen as adding little to the page, especially when they are also integrated in the text or tables... But if you do want to include them I don't think you can otherwise without adding a module. It's possible to include a normal page inside a category, but then if it's not just parts of it it's just a duplicate page without the list of member pages.
For the technical search issue it should be possible to add the Category namespace (or any other namespace) to the default search of anonymous users and users who have not changed it in preferences. There's also many other namespaces in this wiki that are not searched by default: "Discworld MUD Wiki", talk pages, user pages, template pages, Research...
So beyond the search issue which looks fixable, is it better to have category-articles with list of member pages or is this wholly undesirable or what's the criteria that makes it bad/ok?
--Frazyl 08:36, 22 December 2010 (UTC)
Hrmmmm, maybe. I think I'm coming around to the "categories shouldn't also be articles" view a bit, though, even if the search thing isn't insurmountable. I mean, in some instances it does clearly seem to be better to have them separate, like with Weapons and Category:Weapons, because the pages are for fairly different things. I was going to hold up Category:Contractor npcs as one where it does seem to work better for the information to be in the category, but actually I think that can be moved to Real estate decoration, where it will fit better. It might be neater to do them all consistently, instead of only separating them out when one or both aspects are really large... also, I guess if you click on a category from a page in the category, it's probably in order to see what pages there are that are similar, so the bit you'd be looking for is the category bit, and it's nice to have it right there rather than at the very bottom after a bunch of other stuff you need to scroll past.
One that's caught my attention is Category:Finding_and_seeking. Well, I like the table, and it's not as big as Category:Furniture was, but it seems a bit... I don't know. Like it would be better to have the table on a separate page. And maybe rename it all, too--the current name is more than a little unintuitive (I remember the search for a title that actually encompassed all the things in the category...). Maybe Scrying and tracking methods? /tangent
And of course the aforementioned Category:Dibbler clones is pretty similar. They've both got the useful tables of everything/everyone that is (or should be) in that category and in both cases separating it out would pretty much just involve cutting a chunk out of the article, moving it to a similarly-named page, and cross-linking. There does seem to be something weird about having a list of pages in a category, and then, underneath it, having the "Pages in category" thing that every category has.
--Ilde 06:35, 25 December 2010 (UTC)
Ok that makes sense. I'll leave Category:Finding_and_seeking for you to do. Maybe just Seeking methods? Since there's no seek command and seeking can mean seeing from afar it's a bit more generic that find.
--Frazyl 03:52, 26 December 2010 (UTC)
I don't know, Seeking methods as a name has the same problem with being sort of awkward and unintuitive, I think. While track is a command, in context I think it'd be clear that the category's broader than just that command (and the article titles wouldn't be similar enough that linking to the wrong one would be likely to be a problem)... and "ways to track someone" seems like a natural way to describe track, Find, Find Corpse, or flying to someone (actual scrying stuff, too, but there's an extra level there in that you have to recognize the room... a less direct (even if potentially more informative) way to find someone. I do think they're alike enough that they should all be in one category as they are currently, though).
Also, eh, some of the things in there--A Cup of Tea and Sake, Far Sight, Worstler's Advanced Metallurgical Glance and Worstler's Elementary Mineralogical Glance aren't really about finding people/things as such, but they are definitely scrying.
--Ilde 06:01, 26 December 2010 (UTC)
I don't think the name needs to be exactly what everyone will type. Say they type find, they'll see the links back to the more generic page. We can add links at the top and bottom, some redirects...
Actually, the far seeing things fit with seek because you're seeking those locations and seeking beings, corpses, etc. whereas track doesn't work so much for everything.
--Frazyl 06:57, 26 December 2010 (UTC)
Well... it's not going to be what everyone would think to call it anyway, but I think titles that are at least intuitive once you've seen them are better (I know there are pages I've made with sort of wonky titles, but it's because I couldn't think of anything better :( ). I mean, we have Category:Light sources, not Category:Things with brightness. And it should be pretty clear what a page/category is about from the title, which I'm not sure is true for it currently.
Not everything fits under tracking, no, but the others fit under scrying.
--Ilde 18:23, 26 December 2010 (UTC)
Ok I vote just Seeking them. Simple and to the point and the definition in the free dictionary fits all. If a better name is found it can be moved. --Frazyl 21:33, 7 April 2011 (UTC)

This is pretty much done except for the weapons pages and excellent weapons pages to be completed above. --Frazyl 05:55, 31 May 2011 (UTC)

Excellent weapons

I know there's been discussion of excellent weapons before with previous incarnations of judge.

Is there a way for those to make sense with the new version of judge?

I'm talking about these pages: (and links to them, those categories in weapon pages)

On the one hand once all the weapons are converted and included in the new dynamic tables in real articles (not categories see below) it would be easy to make a table including only selected weapons. On the other hand are any weapons "excellent" any more?

Chat deleted Category:Excellent swords and I do not disagree with that train of thought.

At most I think ONE page with excellent weapons (no categories please, moving items in and out as they change is unwieldy) could work if there's a way to determine objectively which weapon would be best, if that can be done at all.

What do you guys think? --Frazyl 23:04, 30 May 2011 (UTC)

There is no way to objectively determine which weapon is best. One player may consider ease of attack to be the most important variable, another may care more about damage, while a third might be most interested in parrying. As a simple example, there are now players who swear that short swords are the best sword (as they do the most ave damage), while others prefer the tiger fang (because it's more likely to hit).
The 'excellent' weapons pages were a bad idea the first time around, IMO, and have even less justification for existence now. I think we should get rid of them; if people want to work out which weapon they consider best, then they can use the standard weapon list and sort it according to whatever criteria they please. --Chat 23:16, 30 May 2011 (UTC)
No new comment for a week, deletion it is. Done. --Frazyl 05:00, 3 June 2011 (UTC)

Faith rods and batons and stuff

I've noticed that there is a page for each individual faith rod and what not. Thing is, all of the batons have the same exact judge value, and all of the maces have the same and same for the canes. I don't know about the flail(s) or the polearms though as I can't judge them.

Should these be all combined down into one page as they are all essentially the same items as each other accept for ritual affinity?

If I remember right, all have pretty much the same description, maybe could just have them all go to "faith baton", "faith mace" and "faith cane"? And have a list of the different types there with the affinities? And have a search for the individual weapons redirect to the single pages?

They also all have the same appraise for the 4 or I checked of the batons and the two maces I found.

I could do this myself but it'll be a while before I get around to it and I wanted to get opinions first. --Baldarov, 14 June 2011

I recall bringing this up at some point (might have been on the priest wiki), but it got shot down. But I support it either way, the changes between are pretty much aesthetic. Any other differences can be covered by List of Faith Rods. Rehevkor 12:51, 14 June 2011 (UTC)
This isn't the priest wiki though :). As it is a judge issue and they're all the same weapon for all intents, purposes, descriptions and appraisals, I think it'd be best to go through with redoing it all, mostly to cut down on the weapon list size and redundancy. Just a matter of someone actually doing it. Baldarov, 14 June 2011
It seems to me that the different batons vary in description, faith rod infobox and weight.
It seems likely that the weight differences are inaccuracies or errors. If so we could reuse the same weapon infobox for all those who judge and weigh the same. An example of a differing baton is the Webbed baton from Shelox that seems to be different in weight and probably in judge info too if it's like the iron broomstick vs normal broomstick.
So all the "standard" batons could include a weapon infobox from a page named like Faith baton (weapon) or something that's then included in those pages instead of their own version since those would be identical. In the maces page it would show up as only one line with the page name.
As for making all faith batons fit into one (huge) page you'd need to put all the descriptions and faith infobox for all of them which would make it long to load and difficult to edit. Also I planned to eventually make a dynamic table including each faith infobox which would not work either with all of them in one page so you'd need to keep separate pages for each infobox.
--Frazyl 21:32, 14 June 2011 (UTC)

Incidentally, the Coral baton is not just made of wood but of coral and wood. For the one weapon page for baton to work it will need to only say wood. That's a reason to keep the appraise data, because it contains information that's not in the infobox like rough dimensions and sometimes the color of the item which might be of use to those who worship Gapp. --Frazyl 21:41, 14 June 2011 (UTC)

Thinking about it some more I guess it might work to put all the faith information (with item descriptions possibly just the non-repetitive bits) in a table like List of Faith Rods without the judge info which could go in a multiinfobox for each type if there are really some types that are identical. On the other hands in List of Faith Rods they seem to differ in judge a bit. --Frazyl 07:24, 16 June 2011 (UTC)

Well, of the easily available batons that all weigh the same, they've all judged the same so far... In the past, they've also had the same measurements. Same for the maces and the canes. The ones from the named priests are the only ones I've not really poked at due to them being polearms. The descriptions and materials do vary though so doing the multiinfobox that is for all of them would be good. As for the judge info in the faith rods list, that was with Old Judge and I can't say I've ever felt it was exactly reliable :(. If I have time today, I'll collect all the rods I have vaulted and reverify that they are all the same, weight and judge. --Baldarov, 16 June 2011.
Ok should be all done. Just need judge data in those types in the first table in Faith rods. I couldn't do a multiinfobox because there was 10 types of faith rods and it would have been awkward to find anything. --Frazyl 03:37, 17 June 2011 (UTC)
Looks great! I won't be able to do the judges up til sometime this weekend. Taking a break from the MUD for a wee bit. I will verify that all are the same though. --Baldarov, 17 June 2011


Ok so FIrefox has updated itself to reflect that people are no longer using http in regular usage and are just saying "" - it would make sense if the wiki worked with that, e.g. []

http isn't really needed, we know unless specified otherwise it's not going to be ftp or whatever :) -Xola 07:56, 9 October 2011 (UTC)

I don't see the relevance of firefox 7 reportedly by default hiding the http:// protocol fragment in the address bar. Links can be made to show any text already, but require the url to still include http. If you mean change how the mediawiki software works you'd have to ask those developing it.
For many link types there's templates that allow you to concisely add a link.
For example for itemdb links please use either
{{Itemdb|123}} Kefka's item database or
{{Itemdb|123|}} [1] or
{{Itemdb|123|some text}} some text
to cut down on the source text, improve readability, and so that if the url changes we can update all the links at once. --Frazyl 17:02, 9 October 2011 (UTC)

Game Areas

Should we change this section to better reflect the traditional domain arrangements? eg Djelibeybi -> Klatch, Sto Lat -> Sto Plains? Zexium 16:58, 17 October 2011 (UTC)

I assume you mean on the main page.
That could be an idea, provided all the region pages exist already. How would you see this arranged? Something like the following?
How could it be made obvious that it's region -> most important cities without too much labeling?
There could also be a link to Category:Locations like "see all locations" or something. --Frazyl 19:08, 17 October 2011 (UTC)

Connection down discussion

See here: Status#Discussion --Xola 09:38, 21 October 2011 (UTC)

Please don't redirect this page again. Яehevkor 01:28, 22 October 2011 (UTC)

CSS Problem?

Am I the only person who's seeing the navigation menu on the left pushed down by the main content division? This doesn't happen on other wikis - is our css broken? Zexium 23:14, 14 January 2012 (UTC)

Yes it started to happen to me with firefox 9. Chromium was broken but they fixed it somehow.
The problem is in javascript of the monobook theme. The menu appears a few moments above before being dragged down by the javascript while loading. It also happens to all other wikis with monobook theme that has javascript enabled. Changing to another theme once logged in or disabling javascript looks fine but I've gotten used to the current theme and javascript things like sorting menus...
I saved a copy locally to try to diagnose what exactly made it happen but the local copy did not have the bug! Maddening. This makes it near impossible to diagnose... Well that and the firebug javascript console was broken when I tried to debug.
I didn't really find anything about other people experiencing this bug on google...
--Frazyl 00:04, 15 January 2012 (UTC)
I'm getting that as well; very irritating. It specifically started happening with Firefox 9.01.
--Chat 00:36, 15 January 2012 (UTC)

Priest wiki doesn't seem affected somehow contrary to other random monobook themed wikis. It's more up to date but I can't find any bits that might be involved... I don't really like using chromium even if it works, was hoping they'd release a fix for firefox... --Frazyl 00:44, 15 January 2012 (UTC)

Looks like we're not the only ones with this issue: [2].
--Chat 10:17, 15 January 2012 (UTC)

Thanks for that link! It makes more sense now. While the cleaner option is to update mediawiki only Drakkos or someone with access to the filesystem can do that.

Mmmm. The change that should have fixed new versions of mediawiki is said to be this which would mean that the issue is either from KHTMLFixes.css or because is_gecko is not set.

Tests with firebug show that if we revert:

#column-content { margin-left: 0; }

By removing it it looks ok.

Trying to find a way to either remove it or override it with something... --Frazyl 01:04, 16 January 2012 (UTC)

Yay putting the overridden margin worked! To see the change force refresh the page like it says in MediaWiki:Monobook.css or restart your browser. --Frazyl 01:24, 16 January 2012 (UTC)