User talk:GhostAvatar/Archive 14

Page management templates
Yeah, game-specific maintenance categories like that would probably be useful for nearly all page management templates - hopefully it'd increase the number of people actually working on the tagged pages. I've been considering it a couple of times in the past but never got anywhere with it because I couldn't make up my mind how to implement it.

Maybe I'm just overthinking it, but basically I'm trying to avoid using named parameters so the templates are quick to use. That means there has to be some sort of consistent order across all templates, i.e.  should always be the reason/game/whatever, otherwise things get very confusing.

However, after thinking about it some more now, I think we should arrange the parameters according to frequency of use in order to minimize instances where people would need to "skip" parameters (as that's something which inexperienced editors likely would have problems with). I.e. something like this:
 * -> game(s)
 * -> reason/issue
 * -> additional stuff (e.g. the page to merge with for merge)

Specifying a game is useful for all page management templates, adding a reason is supported by all but one template (Upcoming currently, and only one template would need a third parameter (Merge).

One issue I can foresee is people using the first parameter for reasons, at least for a while - we could add some sort of fallback for that though (if  does not contain a valid abbreviation, display it as a reason instead). What do you think? -- Porter21 (talk) 13:43, 14 January 2012 (UTC)


 * You don't really need to have abb return "error"; you can simply use . That's the way I'm usually doing it (and therefore making  return something if there's no valid abb would actually break quite a few abb-based templates).
 * I'll look into creating a template for generating categories based on abbreviations (similar to abblink) tomorrow. Shouldn't be hard to do, and it's something I've wanted to do for a while. Then people could even enter multiple comma-separated abbreviations. -- Porter21 (talk) 19:20, 14 January 2012 (UTC)


 * Just noticed I didn't answer your last question. Yes, you can put templates, links etc inside parserfunctions as long as they're closed within the parser function. I.e.  works, but   doesn't (even though the resulting wikitext would be valid, the parser doesn't convert it to a link). -- Porter21 (talk) 19:49, 14 January 2012 (UTC)


 * Sorry for the delayed reply - I got a bit consumed by my skin project :P I'll look into making the necessary changes later today. -- Porter21 (talk) 13:06, 19 January 2012 (UTC)

Seems like this is turning more into a general Mbox rework (who would've thought :P). I figured that we're at it, we might as well turn into a meta template which can be used for all kinds of messages and not only the management boxes (e.g. talk page messages like talkpage or those various MW warning messages you formatted). To this end, I've made the following changes so far (current version at User:Porter21/sandbox5):


 * Made image optional.
 * Added style parameters for individual sections of the template.
 * Added option to remove the colored border entirely.
 * Added the categorization feature we discussed:
 * Up to 3 categories can be specified . If none of these is specified, no category is inserted (this is basically to incorporate the "nocat" mechanic you added to some mboxes).
 * These categories are converted into game-specific ones if  is specified. Otherwise, the unaltered categories are returned (e.g. Category:Stub).

I'm then going to introduce intermediary templates for different general types of message boxes (Mbox/management, Mbox/project etc) which contain the coloring and special mechanics for specific types of message boxes (like the unnamed parameter reassignment we discussed for management boxes).

What do you think? And/or is there anything else which should be added? -- Porter21 (talk) 13:20, 20 January 2012 (UTC)


 * I'll resume working on this shortly - just so you don't think I've forgotten about it ;) -- Porter21 (talk) 13:06, 25 January 2012 (UTC)


 * The change is going live today or tomorrow. I'm still undecided about the category names though; for some templates, employing our usual scheme (game + category) would result in rather nonsensical names (e.g. "Fallout 3 upcoming" or "Fallout: New Vegas nominated for deletion". Maybe we should deviate from the norm and simply place the game in brackets at the end ("Upcoming (Fallout 3)", "Nominated for deletion (Fallout: New Vegas)")? -- Porter21 (talk) 10:51, 1 February 2012 (UTC)


 * Well, leaving "nominated for deletion" aside since it seems to be a special case (you could get around the "categories getting lost" issue by sorting all subcategories under " " which will group them at the beginning of the category and separate them from nominated categories), the standard naming scheme makes sense for about half of the templates and makes no sense for the other half ("Fallout 3 split", "Fallout 3 merge", "Fallout 3 wikify") while with the game in brackets at the end they all make sense. The brackets would also set these categories apart from "normal" categories, for better or worse. Don't know really.


 * Regarding, I didn't create it and the user who did has long since left the wiki. As far as I remember it was supposed to work similar to verify in that a date would be specified and the images be removed if they were still unused after a certain time period. I don't think anyone has used it in quite a long time though, so as far as I'm concerned you can do whatever you want with it. -- Porter21 (talk) 22:09, 1 February 2012 (UTC)


 * This is now done (mostly). Hope nothing's broken too badly - likely won't be around until next Wednesday. As usual, if something's off please let me know ;) Also created the new categories, renamed some to improve clarity and deleted the old ones, hope I got them all.
 * merge works a little differently from what we discussed - I figured with three unnamed parameters the whole thing was getting rather unwieldy in practice and it's an odd man out either way, so I made "from" and "into" named parameters (which also allows us to differentiate those two merge types).
 * I've also adapted verify to use the game-specific category mechanic while I was at it. Still need to create a meta-template for those MediaWiki messages and tweak the CSS a little bit, but I guess that can wait until next week. -- Porter21 (talk) 06:22, 3 February 2012 (UTC)


 * Had a bit more time this morning than expected, so I've created Mbox mediawiki and Mbox talk (and patched up the CSS). -- Porter21 (talk) 12:28, 3 February 2012 (UTC)

Forums
Well, I suppose the usefulness of doing this (compared to the effort required) depends on when we expect the switch to a new forum solution to happen since other than LiquidThreads all possible alternatives do not use pages in the "Forum" namespace anyway. In general, I do agree that (with the current system) ancient topics getting bumped to the top by bot/maintenance edits is a tad annoying and creating an archive is a viable solution.

Regarding Forumheader, the second unnamed parameter is only referenced by Forumintro if I recall correctly, so it shouldn't be hard to change it to a named parameter ("options" or something). If you need help, just let me know. -- Porter21 (talk) 13:43, 14 January 2012 (UTC)


 * If one of the non-LQT solutions is chosen, we can simply restrict the whole namespace to be editable by admins only, extend my DisableArchiveEdit script to the "Forum" namespace, possibly make Forumheader display a "this is archived stuff, go to this page instead" message and be done with it :).
 * Personally, I'll lobby for LQT though because I think it'll provide a more seamless integration with talk pages later down the line (I definitely would like to use it there as well at some point). I'm a bit concerned about future support for the other options; the creator of AWC's forum hasn't even posted on his own forum in months, and ShoutWiki (which is run by the WikiForum creator) no longer uses WikiForum for its own site (funnily enough, they're now using the same suite of forums/chat etc as our community site). WikiForum also suffers from the threads not having recognizable URLs (they use the old-school  URL parameter approach which isn't good for indexing). Of course, I still need to test whether LQT can be made to work with DPLforum at all (going to install it on my local MW install and test tomorrow).
 * But back to the original topic - I'm a bit confused on what you want to start with tomorrow? -- Porter21 (talk) 20:08, 14 January 2012 (UTC)


 * Eh, seems like LQT can't be used for the forums. I thought there was some option to configure the namespaces it's applied to, but it seems I was wrong. It's also causing quite the RC spam (one entry per reply, like Wikia blog comments, and advanced RC doesn't group all replies to the same page or even to the same thread).
 * WikiForum replies/edits on the other hand don't show up in RC at all... -- Porter21 (talk) 21:51, 14 January 2012 (UTC)


 * Links in WikiForum threads also don't show up in WhatLinksHere. Guess that can be viewed as both a positive (no maintenance edits/bumping required) and a negative (potentially broken links) aspect. -- Porter21 (talk) 22:19, 14 January 2012 (UTC)


 * You can restrict namespaces to be editable only by certain user groups via LocalSettings.php; users who do not have that group can then only view the source and get a "page protected message". The archive script wouldn't be used for preventing the edits (sorry if that wasn't clear), it would only be used to make the archive nature of the threads more apparent to users.
 * Regarding the forums, the RC spam isn't even the main problem with LQT, it's mostly that I can't make it apply to the "Forum" namespace at all. Basically you install it, it's applied to all talk pages, the end. In addition, parts of the interface are indeed broken as described on the extension page (I thought that comment maybe only applies to the trunk version); for example, if you try to move a reply in order to create a new thread, you get to watch the AJAX load indicator forever and nothing happens. Guess we're better off waiting for LQT 3.0.
 * The issue with links not being tracked will likely affect all special-page-based forums; I think MW generally doesn't track links from special pages. Been looking around, but I haven't found any other alternatives. The only other option I can think of is reviving an old idea of mine for enhancing the current forum system via JS. The basic concept I had in mind was basically wrapping user messages in a template when pressing "save page"; that template would include the signature and provide the structure for the forum post.
 * Other than that, I'm out of ideas. Question is whether not being able to track links is that much of an issue though; with the current situation, you can't really track broken links on the community site either. -- Porter21 (talk) 23:45, 15 January 2012 (UTC)

SEO
Any idea what has happened to our Google ranking? The main page/site has dropped out of the top 10 for the search query "fallout wiki"; we have one page showing there, but that's a news item from the community site. The first result from the main site is on 15th place, but it's again not the main page but the JSawyer article. Reckon it might be related to the description issue you mentioned in the bug report thread? Another possibility would be that we have been hit with a "duplicate content" penalty or something.

I also think we should look at getting an extension for generating keywords to further aid our rankings. Unfortunately, there doesn't seem to be one which can generate these automatically, but if we get one which works via parser functions we could integrate it into a few key templates (e.g. Infobox and Overviewintro). What do you think? -- Porter21 (talk) 13:43, 14 January 2012 (UTC)


 * Ok, I was just wondering because the main page showed up among the top 10 before my holiday and now it doesn't show up anywhere although I haven't used this PC in the meantime. Handy site you got there. Looking at the validator results for the main page, I've also realized why you were removing the cellspacing/cellpadding from the portal templates. Too bad we have to keep them for IE7 compatibility, but I'm going to convert them to divs some time anyway (there's no real reason for them to be tables). -- Porter21 (talk) 19:49, 14 January 2012 (UTC)


 * The thing with the cellpadding/cellspacing is that while it can be avoided for the main page (by making the portal sections div-based) I don't think we'll be able to get around it for other pages. There's no real alternative to having infoboxes/navboxes table-based, for instance, and since backwards compatiblity for border-spacing isn't great (particularly due to IE, once again) setting cellpadding/cellspacing to 0 is the only way to stop browser-specific defaults (which are almost never 0) from ruining the layouts. However, the issue is probably most pronounced on the portal pages, and it's certainly fixable there.
 * Interesting site, by the way. Haven't found the time to watch the videos yet, but it confirms most of my suspicions about SEO (SEO isn't really my area of expertise). -- Porter21 (talk) 13:06, 19 January 2012 (UTC)


 * Yeah, I'll see whether converting the portal templates before we have decided on the new site layout is sensible (I'd rather not convert it now and then have to re-do it again). If it is, I'll convert it this weekend, otherwise I'll wait until the layout discussion is finished. -- Porter21 (talk) 12:46, 21 January 2012 (UTC)


 * I've converted the main portal section template - getting a lot less warnings now. There are still a couple which stem from the content, footer and portal button tables, I'll take a look at these when I get the chance. The other errors/warnings either come from MW or the Curse footer.
 * I've wrapped the portal headers in  tags because the second site you linked mentioned that header tags are assigned higher relevance when search engines analyse the page. I guess it'd be worth considering to wrap the portal button texts in  (or even  and make the section headers h3 instead). Similarly, the headers in the content tables should probably be some variety of  as well - what do you think?
 * On a sidenote, has the meta description of the main page always been populated from the "Did you know" section or is that some new thing I've introduced through my changes? I thought it was empty previously, but I'm not sure. -- Porter21 (talk) 09:26, 22 January 2012 (UTC)


 * In fact, we're now getting descriptions on the other portal pages as well. For the other portals, the description seems to be pulled from the "About this game" sections. I guess if we could figure out the logic behind this, we could manipulate it to give the descriptions we want while we're waiting for Curse to get into gear. -- Porter21 (talk) 09:54, 22 January 2012 (UTC)


 * Got it - it's looking for the first set of tags in the parser output. I'll insert an invisible set of these at the beginning of Portal columns, then we should be able set descriptions for the main page and portals. -- Porter21 (talk) 10:03, 22 January 2012 (UTC)


 * There you go - we now have descriptions for the portals :) Feel free to tweak the default in Portal columns or individual pages (like I've done on the main page). -- Porter21 (talk) 10:19, 22 January 2012 (UTC)

Actually, I don't think Curse has done anything - I think it was the change to the portal section template (making it div-based rather than table-based). I was looking at the description code this morning when I was trying to figure out exactly how the descriptions are generated, and there are no namespace restrictions in there. What is in there however is a check which leaves out any content in tables, and prior to the change all content on portal pages was wrapped in tables, so the extension simply couldn't find anything to turn into a description.

I guess we should sustain the request for the parser function to be switched on, but at least we now have a workaround in the meantime. -- Porter21 (talk) 20:21, 22 January 2012 (UTC)


 * Regarding the Curse footer, I've re-added the validation errors to the list. You are right, it used to be on there but I removed it when they fixed the typos, assuming they had fixed the missing  as well. Assumption is the mother of all f***-ups etc ;)


 * The new navigation has introduced quite a number of new validation errors though due to what I'd consider a MW bug. Basically each navigation item gets an ID based on its name and MW doesn't account for multiple navigation items with identical names (like having "add-ons" in both the FO3 and FNV menus). I.e. you get multiple items with identical IDs which the validator understandably doesn't like since each ID should be unique on a page. Not sure what to do about this. -- Porter21 (talk) 10:51, 1 February 2012 (UTC)


 * Yeah, you're right about the global wrapper - it's unclosed as well (although I'm sure I included instructions for closing it). Probably should add the two unencoded  in the footer to the bug list as well (which should be replaced with  ). Good idea with the nbsps - didn't try it because I thought MW would strip them out anyway. Again, assumption is the mother etc ;) -- Porter21 (talk) 22:09, 1 February 2012 (UTC)

Infobox location
Only seems to happen in Webkit browsers (Chrome/Safari) and IE8+ (hence why I didn't notice it earlier). No idea what's causing it at first glance, but I'll look into it. -- Porter21 (talk)


 * That's my dirty little secret :P More seriously, there's a row with the classes "va-infobox-columns" and "va-infobox-columns-#" at the beginning of each infobox group. This row contains dummy cells which have the widths applied. It's a bit complicated but necessary so I don't have to pass around possible custom column widths in the template ten bazillion times. -- Porter21 (talk) 21:24, 19 January 2012 (UTC)


 * Yeah, that little hack fixes the problem for Chrome (and Safari, I presume). It doesn't fix it for IE8 however (the weird thing is that it works fine in IE7 but not in IE8). I still haven't been able to figure out why Webkit/IE8 behave this way - if you look at the lower examples on my test page the issue (which affects all block level elements with a px width, by the way) persists even if you take out all the infobox CSS. Once you remove the width CSS for the table, the browsers decide the table needs to be more than 500px wide. Once you set the div to 100% wide instead of 260px the issue vanishes even though both settings result in the same computed width (similar to what you found when switching the column widths to px). And to top it all off, the issue doesn't happen with the old infoboxes. -- Porter21 (talk) 22:45, 21 January 2012 (UTC)

FCW skin
If you have a bit of spare time, could you give my FCW skin a whirl and tell me what you think? Would be much appreciated. Unfortunately, I can't simply make it a gadget, so you'll have to do it the old-school way (by copying the imports in my common.css and common.js to yours). The latter prevents the collapsible nav CSS from interfering with the skin; otherwise it's not needed for any of the functionality.

Maybe you have an idea what to do with those damn language links... -- Porter21 (talk) 22:45, 21 January 2012 (UTC)


 * Glad you like it overall :) Regarding the page tabs - agreed, it's on my list. I was planning on reducing them to somewhere between 28 and 32px height.


 * I was 99% sure you'd bring up the user links menu :P I don't like it myself; it's both inconsistent (all other menus are vertical) and unnatural. My current plan is to have it this way in CSS (so the links are still accessible for users who have JS disabled) but use a little JS to turn it into a vertical menu for those who have JS enabled. Once we get MW 1.18, it can be further refined to not having the userlinks collapse at all for people with JS disabled - but I'd rather not do that without "noscript CSS" support since I personally hate it when JS visibly alters the page appearance on every page load (like with Wikia's chat rail module).


 * The reason I've done it this way is quite simply that without JS, I didn't have another choice - with a vertical setup, the dropdown menu appears "under" the ribbon and any links that might be in there (if the links go that far). It's a z-index problem which is basically unresolvable (at least in my understanding of z-indexes) due to the underlying HTML structure. The userlinks are a child element of #mw-head (like the page tabs and the searchbox), while the ribbon/logo/navigation links are child elements of #mw-panel; both #mw-head and #mw-panel are direct children of the #global-wrapper. Since z-index establishes a stacking context depending on the parent element, there are only three possible scenarios with a vertical dropdown:
 * z-index of #mw-panel >= z-index of #mw-head: All children of #mw-panel are always above all children of #mw-head; the userlinks dropdown will always appear below the ribbon/other content of #mw-panel, no matter what z-index you set for the userlinks..
 * z-index of #mw-panel < z-index of #mw-panel: All children of #mw-head are always above all children of #mw-panel; the userlinks dropdown appears above the ribbon, but the navigation links become inaccessible (since now #mw-head technically "covers" #mw-head).
 * If there are no z-indexes, newer browsers resolve everything correctly but basically all dropdowns are inaccessible in IE7; they go "under" the page content (or rather below any block elements in the page content like infoboxes, mboxes etc).
 * I'd have liked to do it via CSS only but it seems that's not doable.


 * Regarding the language links - yeah, those placements were among those I've come up with as well. The issue is that if we want the skin not to rely on JS only a placement somewhere around the header area works and personally I feel placing them at the top is giving them too much exposure. Placing them at the bottom would be my preference as well, but that'd require JS. On the other hand, they're probably not so important that they'd need to be accessible without JS. Just wish I could slightly modify the HTML, but I guess that's out of the question...


 * As for having the skin go live, while I agree with your that we have to avoid the usual endless going-nowhere discussion phenomenon, the skin isn't quite ready yet. I'll have to redo some things first so the skin can be turned into fluid width via gadget, otherwise the fluid width crowd will likely get out the pitchforks. -- Porter21 (talk) 00:13, 23 January 2012 (UTC)


 * Ideally, I'd like the background to be changeable easily. Your suggestion got me thinking though; I think if we move the banner image from #mw-head-base to #mw-page-base and move the right part of the ribbon to #mw-head-base, the userlinks dropdown should appear above the ribbon. #mw-panel would need a margin-right so it doesn't overlap the userlinks dropdown, but I think a loss of 100px menu space should be bearable (we'd still have way more space than with Oasis and also no nonsensical 7-items-per-dropdown limit). Might actually kill two birds with one stone as it should solve the problem with the NoFixedWidthGadget as well. I'll take a look tomorrow. -- Porter21 (talk) 00:51, 23 January 2012 (UTC)


 * I think the skin is now in a state where it could be rolled out site-wide if we want to. I've redone the user links menu, changed the appearance of the page tabs and added the JS for moving the language links. Please let me know what you think :) The Vault logo could probably use some sort of drop-shadow so it's more clearly separated from the banner, but I'll leave that to people more adept at Photoshop (*hint hint* :P). Also not quite sure whether the search box should be vertically aligned with the top of the page tabs or whether I should leave it "sticking out" a bit.


 * The skin should work fine in IE7+, Opera, Safari, Chrome and Firefox. I've fixed most IE7 bugs except for one where the text in the hover menu items is 1 px off-center vertically, but I have no idea what's causing that - no game-breaker either way, doubt most people will even notice). Also in IE7 the ribbon corners aren't showing since it doesn't support :after and :before. I could fix that by inserting two dummy elements into MediaWiki:Sidebar and re-purposing them or using JS to emulate :after and :before support, but I'm not sure whether that's worth it - what's your opinion?


 * Regarding the background, it's good but I've kept the one I've been using all along - simply because I think we should let the community choose the final banner and background image. Your suggestion should definitely be among the options to choose from though in my opinion. Ideally we'd need one which doesn't have noticeable tiling so it works with the NoFixedWidth gadget, but if that's not possible we'd at least need one of which we can have both a 1920 and 1000px version. -- Porter21 (talk) 12:24, 25 January 2012 (UTC)


 * I'll roll it out site-wide tomorrow unless somebody voices serious objections in the forum thread. As for NoFixedWidth, not sure whether I'm fond of fixing the header width - I'll consider it though. -- Porter21 (talk) 17:28, 25 January 2012 (UTC)


 * IE7 has a whole host of 1px/3px margin bugs, but this is not one of those. There's no margin below the list items; the padding above is 10px and the one below is 8px (instead of 9 each). It can't be something general since it happens only with the menus which are children of #mw-panel, i.e. the main navigation and toolbox dropdown. The userlink and pageaction dropdowns are completely fine (which also rules out the border thing by the way since these use the same rule for the top borders). It's likely something in the base CSS for the portlets which triggers this behaviour in IE and which I haven't managed to find yet. If all else fails, I can still add an IE7-specific rule which adjusts the paddings accordingly, so it's certainly fixable.
 * Regarding telling people to upgrade, well - once the tiny 1px off-center thing in the menus is fixed there really are no issues with the skin in IE7 other than those two corners, so I'd rather fix that than tell people to get a new browser (which some might interpret as being talked down to and cause them to leave the site). 5% is still significant enough for me - I kept supporting IE6 over at Wikia until it dropped below 1%, and that was a lot more painful :P -- Porter21 (talk) 22:25, 25 January 2012 (UTC)


 * Thanks for the logo. I think the shadow direction doesn't quite match that of the other shadows though - the settings for these are 0 2px 5px (horizontal offset, vertical offset, blur radius), no idea how that translates into Photoshop settings. I'll stop being lazy and take a look myself though :) -- Porter21 (talk) 22:33, 25 January 2012 (UTC)


 * I'll start working on the banner preview script now (then I'll sort out the mess in Vector.css). I'll let you know when I'm done. -- Porter21 (talk) 15:46, 26 January 2012 (UTC)

Preview should be working now. Clicking on an image changes banner and scrolls up; clicking on the banner takes you back to the image you clicked originally. -- Porter21 (talk) 17:04, 26 January 2012 (UTC)


 * Yeah, I was thinking the same about the navigation - there should at least be separate menus for FO3 and FNV (as the two most recent entries). We just have to find a good compromise between usability and not swamping the reader with too many options. On a sidenote, we have to be careful that the menus do not extend beyond roughly half of the search box, otherwise we'll get overlap issues with the userlinks dropdown.


 * Regarding the bugs:
 * Login button: I was pretty sure there'd be some issues with that since I couldn't really test it before rolling it out site-wide (logged out = no custom CSS). I'll look into it.
 * Floating toolbar: This is unrelated to the skin - I made some tweaks to the toolbar yesterday to improve usability (making the clickable areas larger etc) and adapted the popup menu to the general style used by the site's other hover menus while I was at it.
 * UTCLiveClock: Thanks for letting me know, I'll look into it.
 * -- Porter21 (talk) 17:26, 26 January 2012 (UTC)


 * With the toolbar, the inconsistency stems from ResourceLoader. On the pages where you're still seeing the old design your browser still has the old version cached while on the other pages it already loads the new one. In Firefox, doing a hard refresh on the pages with the old design usually fixes it, but I've noticed it can be a bit more persistent in other browsers. It'll go away eventually though. -- Porter21 (talk) 18:08, 26 January 2012 (UTC)


 * UTCLiveClock and the login button should now be fixed. Hovering over the login button still makes the border of the userlink menu show up (even though it's empty); fixing that will require a more extensive rework though which I'll postpone for now. I'll start working on properly merging the stuff in Vector.css now; I'd rather have that done before more tweaks are applied. -- Porter21 (talk) 19:18, 26 January 2012 (UTC)

Header v2
By the way, new header version coming tomorrow (most likely): screenshot. I've tried to "uncramp" it a little bit - it's now slightly larger - and I started to dislike all the bold/gold-colored stuff.

I've also added two "action buttons" (via JS) similar to the ones at Wikia on the right hand side - since we can't use that area for nav menus due to the z-index issues, might as well put something useful there:
 * The left button works similar to Oasis' "edit/move/etc" button; clicking the left area directly takes you to that page while clicking the chevron opens a popup menu with the options "random page", "recent changes" and "recent images". It remembers which option you used last and displays that by default on page load. For example, by default it displays "random page" (since I figured that's most relevant for readers) but if you select "recent changes", it'll display "recent changes" after the next page load etc.
 * Clicking the right button simply opens a popup menu with "Create article", "Upload image" and "Help". Not sure whether having that button remember the last option would be of any use; currently it doesn't.

What do you think? -- Porter21 (talk) 22:05, 18 February 2012 (UTC)


 * Well, not sure what you mean regarding the text, but I guess I'll wait and let you see for yourself when it goes live. Regarding the search box, I've considered that as well but I think rounded corners do not look that good if the suggestions popup is active (since the lower corners then cause gaps). -- Porter21 (talk) 22:39, 18 February 2012 (UTC)


 * I've moved the action buttons to a gadget so you can try them out if you want. I haven't done any serious cross-browser testing yet but I think there shouldn't be any issues in decent (i.e. non-IE) browsers. -- Porter21 (talk) 00:35, 19 February 2012 (UTC)


 * It works for me in Chrome - took quite a few refreshes though. Chrome is rather stubborn when it comes to gadget stuff. -- Porter21 (talk) 01:50, 19 February 2012 (UTC)


 * It's now live site-wide. Just noticed I forgot to set up hover/active styles for the buttons though :P -- Porter21 (talk) 10:22, 19 February 2012 (UTC)

Sorry for not replying earlier; I'm having a rather busy work schedule recently.

While I understand the point regarding consistency I think usability is the more important factor here. Not saying I'm discarding the point entirely but I think it's important to keep that in mind. Now, as far as I can see there are two alternatives to the current setup:
 * Remove "remember" functionality from left button. Not really something I'm fond of since I kind of like having direct access (without having to open a menu) to e.g. the RC link.
 * Add "remember" functionality to right button. Main problem being; what's a default option that makes sense? If the button isn't labelled "contribute", I think it's hard to understand the links which are grouped in that menu (a problem which isn't as pronounced with the left button since the non-default options are more "advanced user" material anyway). The only solution I can think of is making the default option link to a help page which serves as a starting page for new users ("How can I help? Where can I learn wiki syntax?" etc). It could also incorporate the non-default options of that button ("How do I create an article? How do I upload an image?") in case people miss the dropdown. Help:Index is more of an index (hence the name, heh) and hence doesn't (and probably shouldn't) serve that purpose. What do you think?

Regarding the noscript fallback, you're right; there's a bit of redundancy currently. That's mostly because I'm waiting for the MW 1.18 upgrade to address this and a few other issues since 1.18 will allow us to add CSS specifically for noscript-users. Here's a rough outline of what I'm planning ("JS" means how it'll work with JS enabled, "NOJS" vice versa):
 * Action buttons: Instead of having the script generate/insert the buttons from scratch, the buttons will be turned into re-styled portlets (like the toolbox menu) while keeping their current look and position. Main point being that the buttons are accessible without JS (which currently isn't possible due to z-index issue with user links).
 * JS: Adds the "click to expand" and "remember" features.
 * NOJS: Buttons work like hover menus instead of being triggered by click. No remembering.
 * User links:
 * JS: Rearrange the structure of the menu so it corresponds to the setup used by the other hover menus; add "my user page" link at beginning of dropdown so it's easier to find; move the whole thing to the beginning of #mw-panel to solve the z-index problems.
 * NOJS: User links will appear like in a default MW install, i.e. all on one line, no dropdown menu. This is to prevent z-index issues with the reworked action buttons.
 * "Navigation" menu: Remove entirely; replace with "News" menu. With 1.18 we'll finally be able to get Wikilogs and hence have enough sub-options (game-specific news, wiki news etc) to justify an own menu.
 * Hover menus in general:
 * JS: I'll replace the current CSS hover with JS-based "intent hover". This is basically an improved version of hover which determines (by tracking mouse movement speed) whether the user actually intended to open a certain hover menu or whether the mouse just "passed through" on the way somewhere else. In theory, it should minimize the "accidental" triggering of hover menus and make things a bit more comfortable/less irritating to use. I'll have to see how it works out in practice though; if it doesn't work well I'll simply keep the CSS hover.
 * NOJS: Current CSS hover.

Mostly I'm trying to preserve as much functionality as possible for people with JS disabled while avoiding JS "re-shuffling" (page elements moving) for people with JS enabled as the latter is rather irritating (at least for me). This setup means that elements are mostly altered in place; most people probably won't even notice there are JS operations going on. -- Porter21 (talk) 13:38, 2 March 2012 (UTC)

QuickLink
I seem to recall you mentioned a while back that Extension:QuickLink doesn't work for you in Chrome. Just thought I'd let you know that it works in Chrome for me; I tested it across all browsers today. Maybe some sort of script blocker is causing this? -- Porter21 (talk) 19:15, 24 January 2012 (UTC)


 * Well, at least we now know that this setting switches off QuickLink :P -- Porter21 (talk) 19:45, 24 January 2012 (UTC)


 * Yeah, unfortunately that means this extension will break once (or, given Curse's response speed lately, "if") we get MW 1.18 - the new editor doesn't have a div with that name. Same with LinkSuggest; it doesn't work either (although it doesn't depend on the toolbar div, but I guess there are other incompatibilities). -- Porter21 (talk) 20:20, 24 January 2012 (UTC)


 * Guess I can get used to the idea that I'll have to patch up one or the other to work with 1.18... -- Porter21 (talk) 22:09, 1 February 2012 (UTC)

Small Question
I'd be glad if you could answer a question of mine, so I can learn something from an admin with 27.000 edits. I've recently added a new image of the Vault 34 Overseer to the Vault 34 page. What's the reasoning behind removing it? Are there too many images already and you don't want to have a second row added? I would think the Overseer is a very interesting feature of this vault, but maybe he's not important enough? I like adding images to various articles since I think there aren't that many. I spend a lot of time walking around the game world, so I have many opportunities to take pictures. Thanks in advance for your help. OutOf Timer  Wanna chat?  23:25, 1 February 2012 (UTC)

Ban
Aww, that's fine. You don't need to tell me, I don't mind what happens to spammer accounts and whatnot. :P Nitty the Kitty! 20:43, 4 February 2012 (UTC)

Merc outfit
I split the Merc outfit (Fallout 3) page a bit ago, but when I was going through I had the feeling that some of the info, like damage resistance and weight, etc. were off. When you get a free moment could you check if the values are correct and change them if they're not? Thanks, Kastera (talk) 05:02, 5 February 2012 (UTC)
 * Thanks. I was waiting for you to get the correct values on those outfits so I could transfer them over for a FNV page, thinking they were left over items from FO3. Now looking at it, many of them have different base ID's, so I guess they are different versions. I'll create the pages, filling in what I can and probably put an incomplete infobox tag on it. --Kastera (talk) 21:45, 18 February 2012 (UTC)
 * I made the pages best I could; I mostly filled in the images, icons, repairs and ID's. The rest is for you... or me, if I can get to a GECK before you. --Kastera (talk) 01:33, 19 February 2012 (UTC)

Guten tag?
Thanks for sorting it. Guess Wikia's "we'll help you" promises are already starting to wear off ;) -- Porter21 (talk) 19:12, 11 February 2012 (UTC)

Tables
Since there were complaints about everything being so small every now and then back on Wikia, I figured using the standard font size in tables would be worth a try now that we have more content width. I've changed the table class accordingly - what do you think? -- Porter21 (talk) 08:22, 14 February 2012 (UTC)


 * Yeah, I found it a bit large as well, but I didn't want to change it until you had a chance to take a look. I'll give 95% a try. -- Porter21 (talk) 21:27, 18 February 2012 (UTC)


 * Alright, it's now at 90%. Truth be told, I was happy with the "old" 11px size as well, but I guess at least trying to make it larger doesn't hurt. -- Porter21 (talk) 22:39, 18 February 2012 (UTC)

Community site logo
Could you take a look at File:Wiki-community-site-logo.png and make the "Fallout Wiki" text a bit larger? The wrong orientation of the community site logo (and the resulting whitespace) has been bugging me for quite a bit; figured I'd change it finally. -- Porter21 (talk) 22:01, 16 February 2012 (UTC)


 * Well, it's still the same for me - maybe you selected one of the non-standard skin options? I made some little changes prior to my message (such as disabling the black boxes at the top of the article section and changing the logo to an interim version), maybe that's what you're referring to? -- Porter21 (talk) 20:50, 18 February 2012 (UTC)


 * It behaves a bit oddly occasionally - I've had that as well. Probably a bug of IP.Board rather than one of Chrome. -- Porter21 (talk) 21:27, 18 February 2012 (UTC)


 * Well, it's a bit - overwhelming :P I was thinking something along the lines of the old wordmark, just with the logo having the size of my interim version and the "Fallout" and "Wiki" texts having the same height. -- Porter21 (talk) 21:37, 18 February 2012 (UTC)


 * Yup, almost there - I think "Fallout" and "Wiki" should have the same (equal) height though, otherwise it looks too much like Nukapedia in my opinion. Guess my previous message was a bit ambiguous regarding what I meant with "same height", sorry. -- Porter21 (talk) 22:11, 18 February 2012 (UTC)


 * Works fine for me - I've moved it over to File:Wiki-community-site-logo.png (I've set the community site to use that image, I prefer being able to change things from the wiki). Thanks for your time. -- Porter21 (talk) 22:34, 18 February 2012 (UTC)

Slave outfit
Do we need separate pages for the two slave outfits? They're identical stat-wise, just like raider armor (Fallout 3). Ausir 21:45, 18 February 2012 (UTC)

Unused templates
-- Porter21 (talk) 00:22, 19 February 2012 (UTC)
 * can probably be deleted; don't think anybody has ever used it.
 * and are components of the old infobox; they're not needed anymore. I'll leave it up to you whether you want to delete them now or wait until I delete all of the old infobox stuff.
 * I'd keep so we have a complete set of Wikipedia-style cite templates.
 * The rest is all news-related stuff - we might need it again on the elusive day that we get MW 1.18 and Wikilogs. If you want to delete them in the interim, we should probably at least keep a list somewhere (formatted as external links) so we can find them if needed.


 * Yeah, I think getting rid of the empty maintenance categories won't be possible unfortunately. Moving the occasionally unused stuff to a page in the project namespace seems like a good idea to me ("deliberately unused" doesn't seem like such a fitting name though). -- Porter21 (talk) 19:00, 19 February 2012 (UTC)


 * I don't think it's possible to put a #REDIRECT inside a parser function or a template. Been a while since I last tried it though. -- Porter21 (talk) 00:20, 20 February 2012 (UTC)


 * To be honest, the question is whether something like that isn't more trouble than it's worth. Currently we only have the empty categories clogging up one special page, whereas with the alternative(s) we'd have pages/categories clogging up the maintenance categories themselves - and arguably the latter are more used than the former. Maybe it would be a better/easier solution to simply mark the maintenance categories on Special:UnusedCategories via CSS/JS (make them italic or something) so it's easier to skim over them? -- Porter21 (talk) 17:54, 1 March 2012 (UTC)

Sub-variants
I think it's enough to list the all variants of the main deathclaw species (baby, young, mother etc.) and all the subspecies (talking, hairy, experimental) in the main article, but not each age/sex variant of each subspecies (like baby hairy deathclaws, mother experimental deathclaws, baby blind deathclaws etc.) as this makes the page too cluttered. Ausir 01:48, 19 February 2012 (UTC)
 * I have now further divided the "variants" section of the article to make the distinction between variants of the regular species and subspecies clearer, and added a mention of age/sex variants under the "experimental deathclaw" heading, which I think is enough for the main article. Ausir 01:57, 19 February 2012 (UTC)

RE: Map Marker Images
Probably not all of them. There may be some like that for the other DLCs. Pikmin1254 20:42, 19 February 2012 (UTC)

Abuse filter
I was looking at the abuse filter rules and wondering about filter 5. The first three conditions prevent the creation of any page in the "Forum talk" namespace by non-sysops; adding additional checks for specific page names and anons on top of that seems a bit superfluous - or am I missing something? -- Porter21 (talk) 10:13, 2 March 2012 (UTC)


 * Ah ok, that explains why I couldn't make much sense out of it by looking at that rule alone :) -- Porter21 (talk) 13:42, 2 March 2012 (UTC)

Filter 1 gets triggered when I try to remove/replace the whole content of one of my own sandboxes. Just thought I'd let you know. -- Porter21 (talk) 12:25, 6 March 2012 (UTC)

Image
I thought so but I wasn't sure. Tagz and I decided to upload them fully sized in order to get the best quality possible, so thanks for that GA. As a side note whilst I'm here, what's happening with the banner/background? Weren't we going to star pushing for that to be finished last Wednesday? Φύλαξ [~μίλησε μου~] 23:19, 5 March 2012 (UTC)

Improved messaging
The above reminded me of an idea I've wanted to try out for a while. I've created a little gadget which alters the "last change" link in the "you have new messages" notification so it shows all changes since one's last visit to the own talk page (rather than only the last change). You can notice the script kicking in when the "last change" text is replaced by "last changes". After first activating the gadget you'll have to visit your own talk page so the cookie gets set and the script works properly.

I'd appreciate it if you could try it out and let me know what you think (or if you run into any problems) :) -- Porter21 (talk) 11:02, 6 March 2012 (UTC)


 * This is live site-wide by now. I've made it a "default-on" gadget (new MW1.18 feature) so people can turn it off if they don't like it. -- Porter21 (talk) 16:19, 25 March 2012 (UTC)

Messages
Yeah, unfortunately I'll be away from tomorrow until next Wednesday (work-related), so I'm trying to iron out the glaring issues before I leave. Stupid work - I'd much rather play with my new 1.18 toys on the weekend :P -- Porter21 (talk) 23:40, 8 March 2012 (UTC)

Hey I had a general question
I figured I'd get a faster response here. On the Van Buren pages, the background sections on pages like Spineless Stu are written with poor grammar. I was wondering if those we taken from the design documents and if so should we leave the horrific grammar? Thanks!--Kingclyde 03:54, 11 March 2012 (UTC)

Agent C needs a hand
He wants a bot to do some work on Nukapedia and I said that I'd help him out as he asked me, but I can't program the bot myself. Is there anyway you could do the coding for me? Or if you'd rather you just did it yourself, that's fine by me. What he said was: "Hi Guardian, do I remember you having a Bot? Was wondering what they do and if it might be able to help me... I'm looking for a bot to create a table as a status report for a project. Each page in a category needs to have a line in the table, but we're looking at a silly amount of man hours to do something a machine must be able to do easily. Any ideas?

Thanks. Ooh sorry, it's not the whole wiki I need, just the VB articles. A row with the category name and 3 blank colums to be manually filled as we work the articles."

- Agent C

Can you help? Φύλαξ [~μίλησε μου~] 18:51, 14 March 2012 (UTC)

Table format with new Firefox?
I just noticed that the Fallout: New Vegas ammunition tables have something weird going on since Firefox decided to download a new version of itself. If you look at the first table, there's an extra row space between the .22 ammos and the .308 ammos, but only for the last 4 columns. I never noticed that before. I checked it with IE and it doesn't do that with that browser. I played with the table formatting a bit over at NP and can get it to go away, but I thought you'd want to know. Maybe my browser's just going wiggy on me. The Gunny 01:15, 18 March 2012 (UTC)

IE issues
I'd put it in Common.css with a .skin-vector selector - I generally try to keep everything template-related in there, it's easier maintenance-wise. -- Porter21 (talk) 17:10, 23 March 2012 (UTC)