StrategyWiki talk:Community Portal

This page is for discussion of general community issues; if you just want to ask a question to more experienced users of the site, please use the staff lounge. To start a new thread click here. Resolved threads are gradually archived; see the archives box to the right.

Image upload warning
I'm going through categorising all the images, and it's a pain. I have a horrible feeling that people are going to continue to upload uncategorised images, so why not put some Javascript on the image upload form which checks for a category link, and pops up a message box chiding the user if the output of  is true. --DrBob (Talk) 06:43, 2 July 2006 (PDT)
 * I suggest looking into the uncategorized images page sporewiki has set up and have that installed. But if this code gets put it, If you could explain how it's done, then that'd be appreciated echelon, thanks :). -- Mason11987 (Talk - Contributions) 16:42, 2 July 2006 (PDT)
 * I think we should do both. :-P The message on form submission to stop more uncategorised images being uploaded, and the uncategorised images page to help deal with the ones which have already been uploaded. Looks quite simple to install the uncategorised images page, and thanks must go to MediaWiki (and SporeWiki) for it. :-D --DrBob (Talk) 23:00, 2 July 2006 (PDT)

Both have been done. --DrBob (Talk) 06:15, 23 October 2006 (CDT)

Display bug with IE
I've been noticing this and felt I should bring it up. It seems the All game Nav template is causing it too. Anyway, if you look at a page in IE that has that template, it seems it is too wide and it causes the text under it to be sort of "cut off" by the table. Any text following the headers (the 2 equal signs on either side) is okay. I'm surprised this hasn't been addressed. --Sivak 14:18, 25 July 2006 (CDT)


 * "Cut off" by which table? I've just looked at Counter-Strike: Source in IE7 beta 2 and the All Game Nav is too wide, but I'm getting no other problems with it. Could you perhaps link to a screenshot (or upload one as long as you promise to have it deleted afterwards :-P )? --DrBob (Talk) 14:29, 25 July 2006 (CDT)


 * I checked using IE6 on the EarthBound main page and I think he's talking about this: click here to see image-- Duke  Ruckley  14:54, 25 July 2006 (CDT)


 * Yeah, same here as dukeruckley. It seems the left edge of the main content has negative padding or something. But, it only happens on pages that have the All Game Nav on them, as far as I checked. I looked at an ealier revision of EarthBound without the All Game Nav, and it looked fine.--blendmaster 22:09, 25 July 2006 (CDT)


 * Ah. Are you sure this only happens on pages using All Game Nav? I'll look into it later, but it's probably a symptom of one of IE's box model problems. :-( --DrBob (Talk) 15:01, 25 July 2006 (CDT)


 * Why can't everyone just get Firefox? :p --Antaios 14:59, 25 July 2006 (CDT)


 * If only. However, we do have to support everyone. :-( --DrBob (Talk) 15:01, 25 July 2006 (CDT)


 * I put a screenshot of my own. It seems maybe the images on the left which make up the menu are overlapping somehow.  Check the area I put a red box over.  It gets "uncut" after a short way down.  click here to see image  --Sivak 09:42, 27 July 2006 (CDT)


 * I think you're probably right. I checked the same pages uses Monobook and there is no problem there, so it might be the skin itself.-- Duke  Ruckley  09:46, 27 July 2006 (CDT)
 * That's partly it (the top is a JPEG while the rest is a GIF) but that still doesn't explain IE drawing it too far to the left. GarrettTalk 22:52, 27 July 2006 (CDT)

I notice that all these comments are from several months ago, but I just starting using strategywiki and I am having the same "cut off" effect. I can't change browsers because I use public access computers, and many of the computer settings cannot be changed (someone suggested that everyone use firefox, that's not an option for me). This cut off effect appears on almost every page I view in strategywiki, and just as described earlier it seems to cut off the leftmost part of the text at the beginning of each article, but further down the text appears fine. New User 03:30, 25 October 2006 (CDT)

New Pokedex or Partnership?
Hello everyone. I happened to notice some edits that 0-172 was making when it occurred to me that StrategyWiki does not have it's own Pokedex. And it certainly seems that among the many things StrategyWiki should have, a Pokedex should be one of them. However, it didn't take very long until I discovered Bulbapedia and I thought, how awesome is this? So I was curious what many of you felt about approaching them and seeing if we could form some sort of partnership between them and us. Essentially, they could provide all of our visitors with (well presented) Pokedex information instead of forcing us to reinvent the wheel and write something that's been written a million times before, and we could provide their visitors with the actual walkthroughs to Pokemon games. Is this something that we need? No, but I think it would be a great way to form a mutually beneficial partnership with another Wiki site (not that we need that either, I just think it would be neat to cross polinate some of the talent that we have.) OK, I'm getting off my soap box. What do you think? Procyon 20:37, 28 September 2006 (CDT)
 * Nice find :) It would be cool to have them link to SW (we always need more quality contributors ;-) ) We could link to them on all the pokemon guides (if they're that good, we should do that anywayz).  However, how would they link back to us?  I checked out the website, and I'm having a bit of trouble finding where to go. -- Prod 21:09, 28 September 2006 (CDT)


 * Hm. They already have Pokedex entries (e.g. Poliwrath), so I'm not sure they'd need or want an external Pokedex. Also they use the evil BY-NC-SA rather than the GFDL. Hm. Copying the old Wikibook Pokedex here is certainly an idea, although linking to them or Serebii is probably just as good. The MAME guide worked out pretty well so I don't really have a problem with this either way. GarrettTalk 21:40, 28 September 2006 (CDT)


 * I thought perhaps the way that it could work, is that whenever we mention a Pokemon, we externally link to them, like so:
 * "Walk out of Pallet Town until you reach the grass. If you walk around there, you will find a Rattata or a Pidgey."
 * and so on. They appear to have stubs for each of the games like Pokemon Red and Blue so perhaps we could twist their arm to point to us instead. Procyon 22:16, 28 September 2006 (CDT)


 * It's in PD at wikiknowledge so we can easily copy it here. -- Mason11987 (Talk - Contributions) 23:49, 28 September 2006 (CDT)


 * Yes, but like so many things on that site, it's ugly and presented with little care. Personally speaking, I'd rather link to a site like Bulbapedia where you know they care about the content they have, and they will keep it updated with new information since they're passionate about it.  Plus there's the possibility of attracting new talent to our site.  Procyon 08:02, 29 September 2006 (CDT)


 * Procyon makes a good point. While we could certainly have our own Pokedex, I'm kind of leaning towards linking to theirs. We can always change it in the future if something doesn't work out. What we should definitely concentrate on, though, are getting some good Pokemon guides.  ech elon  00:40, 30 September 2006 (CDT)


 * I suggest being BOLD, and making one right now, and also link to theirs "for more information" as I'd hope they'd link to us for more information on guides. -- Mason11987 (Talk - Contributions) 14:46, 8 October 2006 (CDT)
 * And I have been bold. I'll make it a list of red links soon. :)

Well, I would have appreciated a little more patience on the matter. It's not that I object to having a pokedex on StrategyWiki. By all means, if someone is willing to put in the time and effort to make one (and I mean REALLY make a GOOD one) than we should go for it. But it's it just going to be a half-assed attempt to throw something up in order to claim that we have one, then I'd rather just rely on Bulbapedia, who has done a really impressive job. Mason, really question yourself as to how dedicated you're going to be in filling out the 386+ entries that need to be filled out. Either that, or find people who you know will be dedicated to the effort. Procyon 18:42, 8 October 2006 (CDT)
 * I won't be dedicated to it. But that doesn't mean the red links won't inspire those people who will be dedicated to it.  I think the pokedex is definitly within the scope of strategywiki and therefore we should make it as obvious as possible that if someone wants to be dedicated to something like that, then can do so.  But if not that's all good to, that's what the bulbapedia links are for. -- Mason11987 (Talk - Contributions) 20:33, 8 October 2006 (CDT)

So, any news on this? Is there a partnership or not? -- Prod 19:53, 17 October 2006 (CDT)

Parser Functions
Parser extension might make some templates a bit easier to understand as its shorter than qif. I don't know enough about this stuff, but it looks interesting. -- Prod 23:15, 28 September 2006 (CDT)
 * Are these avalaible to test? --inarius 09:51, 29 September 2006 (CDT)
 * Does anyone know if there's a way to create variables and assign values to them? I wanted to do somethere where every other Special Move template shaded itself grey.  So the first one would set some variable to 1, and the next one would read it and if it was 1, shade the table row grey and set the variable to 0.  Then the next one would read it again, see that it was zero, and draw the row white, and so on.  But there doesn't seem to be any way to make your own controls like that.  Just curious.  Procyon 20:05, 29 September 2006 (CDT)

I was looking at the Mega Man 2 page which has references at the bottom. Perhaps we could get http://meta.wikimedia.org/wiki/Cite/Cite.php installed. -- Prod 10:14, 2 October 2006 (CDT)
 * ref and note already serve this purpose fairly adequately. You can see them in action in BS Zelda: Kodai no Sekiban/Cheats. GarrettTalk 14:23, 2 October 2006 (CDT)

Newbie section
It seems that this site is starting to attract larger numbers of people (it's getting tough to keep up with recent changes now) meaning a lot of new people. Many people don't know a lot about wikimarkup and need somewhere to ask questions. What I'm suggesting is some kind of Staff lounge -- Prod 11:45, 1 October 2006 (CDT)
 * Good idea! I'll see what everyone else thinks before implementing it, though. --DrBob (Talk) 13:25, 1 October 2006 (CDT)
 * Agreed, good idea. Procyon 14:58, 1 October 2006 (CDT)
 * I've implemented this as Staff lounge, and basically lifted it from Wikibooks, then changed some stuff. --DrBob (Talk) 13:00, 4 October 2006 (CDT)
 * Sweet, now we don't have to all watch your talk page :P. -- Prod 13:03, 4 October 2006 (CDT)
 * I realized that it's somewhat hard to find that page. Perhaps a link in the nav bar would be helpful. -- Prod 13:49, 9 October 2006 (CDT)

Game Categories
I searched through the archives and couldn't find anything about it, so now is as good a time as any. Should we categorize each page of a game under the game's name (or something similar). For example Category:Super Mario World or Category:Move Lists. It will help us clean up Special:Uncategorizedpages leaving only unused pages hanging around. -- Prod 16:03, 4 October 2006 (CDT)


 * I think this would be a good idea. It will have the added benifit of being able to categorize images by game in addition to the acutal image-type (which I think we should be doing). --inarius 16:20, 4 October 2006 (CDT)
 * I'm definitely against this. This would not encourage maintenance of the table of contents for a game, and thus would actually make it harder for people to find pages (tables of contents should be easier to navigate than category listings). We already have provision for categorising images by game, as you can add a "Game name images" category (note the lower-case "images"). --DrBob (Talk) 16:53, 4 October 2006 (CDT)


 * I'm with DrBob on this one. Honestly, I hate my own Move Lists category page.  I just can't think of a better way to organize it, and it's only just started.  As I and other members add more to it, it's just gonna get uglier and uglier.  That's the only aspect of the project which I'm unhappy with the results of so far.  It seems to me that most of the pages presented here on Strategy Wiki should at least fall under one single platform, unless it's a special project like the Move Lists or the MAME guide, and then I'm not sure what to do.  But I just don't know.  Personally, I think the SMW Category is a bit extraneous.  I think it should be any sub-page's author to properly add a sub-page to the parent page's Table of Contents.  Sub-pages don't need to be categorized as long as someone is doing a good job maintaining the TOC tree.  Just my $0.02 Procyon 16:58, 4 October 2006 (CDT)
 * About maintenance of the TOC page, it doesn't encourage maintenance, but it doesn't deter it either. It's just another category to add at the bottom of the page.  About images, Category:MapleStory images works fine for me, though I'd prefer it to be categorized along with the main guide.  But that's a minor issue.  I'm not too sure how it works, but it would also give a definate link for Related Changes.  I also don't see a reason to remove it if it's already there. -- Prod 17:48, 4 October 2006 (CDT)


 * I really don't see how this would discourage maintenance of the TOC. I guess the only two resources that really need categorization are pages and images. So, I can see how this might not be as useful for pages, since all pages under a particular game should be listed in the TOC, if that's the point you were making. However, I generally work on the Zelda OoT page, and when I contemplate adding even more images to that guide, I think of how big a pain it is to get a list of them, or find the resources already avaliable for that game. I think images really need to be categorized with more detail, and don't find clever/descriptive naming very helpful. Not to mention, renaming an image is more trouble than just adding a category. --inarius 14:28, 14 October 2006 (CDT)


 * I personally don't think it would hurt, but I don't think it would be very useful and mandating something like that would be near impossible and a bad place to focus our efforts. I think our efforts would be better served on a good TOC then a cat page.  Subpages in categories looks very ugly. -- Mason11987 (Talk - Contributions) 18:29, 4 October 2006 (CDT)

Search Plugin
Firefox strategywiki search plugin -- Prod 00:39, 5 October 2006 (CDT)
 * Good work! --DrBob (Talk) 00:59, 5 October 2006 (CDT)
 * Awesome! I like this very much! :)  ech elon  12:49, 6 October 2006 (CDT)

Spoilers
I've been seeing the Template:Spoilers on a few toc pages. Considering the toc is one of the first things (possibly) that the user sees, it seems somewhat...weird. I guess giving away the story by telling where the player goes, or who the bosses are is a spoiler, but how can that be avoided in the toc? -- Prod 20:15, 5 October 2006 (CDT)
 * I think any use of spoilers in the ToC is a bit of a mistake, and that it can be remedied by perhaps changing the link captions, if anything needs to be done. --DrBob (Talk) 01:06, 6 October 2006 (CDT)


 * I agree, Spoiler templates in the TOC isn't the best idea. Titles should be changed to not be as spoilerish (if possible) but as long as they are still useful to the reader who doesn't care about spoilers. -- Mason11987 (Talk - Contributions) 21:53, 7 October 2006 (CDT)

Category:Game
We have a Category:Systems, why not a Category:Game. Put all the main pages in that category (perhaps using the infobox). This way we have a proper place to classify Category:Unreleased games. More importantly, the alphabetical index can go to the game category to find games, rather than Allpages (which isn't very useful). -- Prod 20:55, 8 October 2006 (CDT)
 * I think that category would get quite unwieldy don't you? All the games can be easily found by their system.  -- Mason11987 (Talk - Contributions) 21:52, 8 October 2006 (CDT)
 * Additionally, the search feature works quite well. :-) I think such a category would be redundant. --DrBob (Talk) 00:24, 9 October 2006 (CDT)
 * I mean it as a replacement to Quick index. Motivation being, someone who wants to see what's there, maybe something random to contribute to. Whatever the reason for that quick index applies here as well. -- Prod 00:34, 9 October 2006 (CDT)
 * It is possible to over-categorize, and I think we're rather close to being on the verge of this. Categorization should never be a replacement or an alternative to organization.  The problem is that there is an arithmetically growing number of pages that appear on this site, and it's becoming more important with each passing day that the basic organization of the site be maintained.  If I were to point to a site that has a simple and effective organization, it's gamefaqs.com.  I can't think of a single instance when I failed to find what I was looking for.  While genre, release date, and game series are nice categories, CJayC has obviously determined that a majority of people search for games on a system basis, and we should emphasize our own system selection as a way to introduce new and old users alike to the pages they are looking for. Procyon 09:14, 9 October 2006 (CDT)
 * The way I see it, there are a few basic "types" of pages (excluding subpages). System and Company are already taken, which leaves Game.  They are exclusive categories where things would only be in one.  It wouldn't be much of a problem to add the category to every main page of every game (just include the cat in the infobox template, which should be on every page). -- Prod 09:55, 9 October 2006 (CDT)
 * I dunno, I guess I'm just not understanding your fundamental drive to categorize the one specialty that this site focuses on. When would it ever be unclear to a reader that a game is... a game?  And not that I'm trying to poke holes in your design, but what categories do pages like the MAME guide and the Move Lists fall under?  Clearly not system, company, or game.  Procyon 10:36, 9 October 2006 (CDT)
 * Well, its not for classifying that a game is a game, its for saying that "here's a list of all games". Mame guide should go under systems (or nowhere as it would be a sub page of the systems guide).  Move lists is kinda weird....I guess it could get its own category (which it has).  Essentially, games are what this site focuses on, but how to filter out only the main pages to see which guides we actually have. -- Prod 11:13, 9 October 2006 (CDT)
 * Actually Prod's idea of putting it in the infobox seems exceptionally unobtrusive, and I think it doesn't hurt anything at all. Just throw it in the infobox, then leave cat:game as a top-level cat with cat:systems cat:companies  and cat:genres.  My comment about it being "unwieldy" applied because it would be hard to tag every game, but since it's reasonable and efficient to have an infobox on only the main page of every guide, then this is a perfect way of incorporating it.  I think this addresses Procyon's concerns in that it isn't a replacement or an alternative to organization, it's simply 4 extra letters at the bottom of every page, and it can be done in 15 seconds.  Then we have an easily accessible list of every game, alphabetically.  It sounds quite elegant now that he pointed out the infobox option. -- Mason11987 (Talk - Contributions) 21:49, 9 October 2006 (CDT)
 * Look, I'm not stopping anybody. If you guys are genuinely convinced that it's a good idea then go for it.  I'm not there yet, but I'm not the law of the land around here either.  If Echelon was against the idea (not that I think that he is, I'm just saying hypothetically), then I would say you clearly shouldn't do it.  But I doubt that he would object in this case, so feel free.  I would just like to continue to investigate methods that could improve navigation around the site as I don't think Cat:Game is going to be the solution. Procyon 22:07, 9 October 2006 (CDT)
 * I know you aren't. But discussion normally comes out with the best solutions, and I think throwing Cat:Games in, while still working on very efficient and good navigation (with or without cats) is the best idea.  If I had to add cat:games to every page then it would take away from other, more meaningful efforts, but I just did it so no more spending time on it.  If anyone has a problem with it then we can figure out what would be the best option from then on. -- Mason11987 (Talk - Contributions) 22:27, 9 October 2006 (CDT)
 * After doing it, even it if isn't really "useful" it's kind of cool. Category:Games. :D -- Mason11987 (Talk - Contributions) 22:36, 9 October 2006 (CDT)
 * Even I have to admit that I agree with you Mason, it does look kind of cool. Especially the mix of classic titles with modern titles.  Great job.  Procyon 09:22, 10 October 2006 (CDT)
 * Nice! I didn't realize we had that many guides on the site....320 according to that. Wow.  (definition of "guides" being relative :P). On a related topic, I've been on a lot of forums, and its awesome to have civil discussions like this, which is one of the main reasons I like this site.  -- Prod 23:30, 9 October 2006 (CDT)

I've added this category to All Game Nav's num= value as well. It will take a while for pages to begin appearing in the category, but it will ensure as many pages as possible are caught. GarrettTalk 05:20, 10 October 2006 (CDT)
 * And then we can see which subpages have that num property (which they shouldn't).

One page guides and navs
I noticed that there has been a particular push recently to add game navs to all game pages. It seems like this policy is being enforced whether the page really needs a game nav or not. There are going to be a few games on this site whose depth is so minimal that one page is going to be sufficient to cover the entire game. I can't imagine in this case that a nav is required to "navigate" the one page, which is in essense the introduction, table of contents, and walkthrough. Can we ease up on this? Procyon 15:07, 10 October 2006 (CDT)
 * It occurred to me that Garrett may have added this to Pinball in order to have a stage completion assigned to the page. I've gone ahead and added the stage completion category to the bottom of the page since it accomplishes the same thing.  Was this the only reason or was there something else? Procyon 15:13, 10 October 2006 (CDT)
 * I think all game navs should be on every page for standardisation's sake. As a web designer, I know that people get confused if the means of navigation changes from page to page, and if all game navs are appearing and disappearing willy-nilly, it doesn't help. Additionally, we rely on them for categorisation such as Category:Game and the "num" categories, and it would be self-defeating to add those categories manually (because if, for example, we decided to change/remove those categories, we'd have to additionally go to every page which references it manually, instead of just the all game nav). Another thing is that I can't quite believe that one page will cover a game completely. Every game must have something more than can be said on one page, so sub-paging would be necessary, and so would an all game nav. --DrBob (Talk) 15:34, 10 October 2006 (CDT)
 * Then I must propose that we add conditionals to the Template so that it will dynamically appear properly for games that have a TOC and games that do not. I think it looks horrible with a red TOC and Walkthrough link when they are clearly vestigial.  I'll see what I can do myself.  I'm just not sure how I'm going to do it without breaking the existing ones.  Procyon 16:10, 10 October 2006 (CDT)
 * Well, I've astounded myself by making a revision to a template work on the very first try. Now that I can apply the onepage variable to the nav, I'm satisfied.  It just did not seem like an acceptable solution to force links to appear that were never going to be created.  Procyon 16:25, 10 October 2006 (CDT)
 * Color me converted, I've just gone ahead and created a Template:Fighting Game Nav and a Template:Move Lists Nav, and it's beautiful because it solves the whole problem I had trying to figure out how to solidify the link between the game article and it's corresponding move list. So now problem solved.  The only problem I have remaining is the character set lists, as I don't have a good solution for a nav for those right now.  Something will come to me eventually.  Procyon 17:02, 10 October 2006 (CDT)
 * All game nav can be tweaked to not have the show/hide thing too, if that's what people want. I can work on it. -- Mason11987 (Talk - Contributions) 19:05, 10 October 2006 (CDT)

Categorizing Japanese names as well as American and European names
Garrett and I have been butting heads as of late, and I really don't mean to Garrett. For that, I apologize, but this issue is something I feel quite strongly about. Consider Samurai Shodown. That is how this game is known outside of Japan. In Japan, it's known as Samurai Spirits and as you can see, that title is linked to a redirect to the non-Japanese title. This is all well and good. However, the Samurai Spirits page also contains categorizations. The same categorizations (if applicable) as the Samurai Shodown page. Thus if you were to look in Category:Arcade, you would see both Samurai Shodown and Samurai Spirits listed. In my opinion, this is intentional. I feel it should be done this way for the sake of those who only know the game as Samurai Spirits and not as Samurai Shodown. This way if they navigate to the Arcade category, they will find the Spirits title and proceed to click on it, ultimately being redirected to the Shodown title. I've been following this practice with several games now, such as Street Fighter Alpha/Street Fighter Zero, and Dragon Warrior/Dragon Quest. I feel it's important to allow categorization of alternate titles so that they may be found by those who only know games by said alternate title. If people agree, we should set this as policy. If people disagree, please discuss it here. Procyon 19:25, 10 October 2006 (CDT)

I apologize again, but I have a good example to back up my own argument. Dragon Quest I & II appeared on both the Super Famicom and the Game Boy Color in Japan, but Dragon Warrior I & II only appeared on the GBC outside of Japan. Therefore, while both DQ1&2 and DW1&2 appear in the GBC category, only DQ1&2 appears in the SNES category. And it would not be appropriate to list DW1&2 under the SNES, now for two reasons instead of just one. First and again, if a person only knew the game as Dragon Quest and not as Dragon Warrior, they won't find the game they are looking for under the SNES category. And second, another person will be misinformed if they see DW1&2 listed under the SNES category, believe that it was released with that title for the system when in fact it did not. I'm merely concerned with reporting this knowledge accurately. Finally, using the Street Fighter Alpha/Zero example for illustration, listing both titles is exactly what gamefaqs.com does. (Same goes for Samurai Shodown/Spirits in that first link.) Procyon 19:38, 10 October 2006 (CDT)
 * I don't see any harm in having two correctly spelled titles for a game categorized together. Obviously one should redirect to the other, but having them there would be useful.  Is there a downside to this?  I doubt the issue is frequent enough to create over population of cats (not like that's a bad thing), and it would help navigation.  One of those things that isn't really necessary but it's a nice touch.  The only problem I see is the redirect not getting included in all the categories as the regular as we progress.  That may or may not be an issue. -- Mason11987 (Talk - Contributions) 22:00, 10 October 2006 (CDT)
 * I was thinking this was artificially raising the Category:Games totals, but it isn't, so that objection is removed. I'm not so sure about moving cats to the redirect, though; people might faithfully add the "missing" SNES cats to the main page. Also, those who find out there is "another Dragon Warrior game" on the SNES may well look for it under the English name. Similarly, if for some reason a fan translation exists people will be looking under the Anglicised name. I'm not opposed to the idea, though, it's just I'm wondering what the best way to handle the "missing cats" is. GarrettTalk 23:06, 10 October 2006 (CDT)
 * Well, the way I see it, if people have the forward thinking to realize there is another spelling, then they can duplicate the cats. If noone realizes it, then no harm done.  -- Mason11987 (Talk - Contributions) 23:20, 10 October 2006 (CDT)
 * I see. Yeah, that makes sense. If people keep wrongly catting a page a comment could be left telling them not to. I'm all for this idea now. :) GarrettTalk 23:24, 10 October 2006 (CDT)

Split the PC category?
I've thought this on and off for a while now. DOS is significantly different from Windows, and Vista-exclusive games (e.g. Halo 2) appear to be creating yet another division. Plus, some games have had DOS and Windows versions.

To me, listing these all as PC would be like putting Game Boy B&W, Color and Advance games together just because they can all run on the newest of the three. Plus it's a bit of a misnomer; although Windows is the most common, a "PC" could just as easily be running Linux or even OS X.

Therefore I'm proposing three categories: DOS, Windows, and Vista. Thoughts? GarrettTalk 22:46, 12 October 2006 (CDT)
 * Well, no one makes games for linux :P (none that really count at least), and Mac has its own category already. I have a problem separating Vista from Windows, cause technically it is Windows Vista, but thats irrelevant.  The thing with PC games, is that if you can't run it, you can (theoretically) upgrade your computer (there is no way my 10 year old comp will run vista, let alone Halo 2 :P).  With consoles, you have to buy everything new.  I'm always for categories (so I support you on that basis), but this info is already stated under system requirements (at least it should be), and it would be something someone looks at after they have decided to get the game. Essentially, take this as a null vote >.>.-- Prod 23:13, 12 October 2006 (CDT)
 * Actually, we already have a Linux category (with a couple of games in it). I'm in favour of splitting the PC up into categories which don't share compatibility, so it would probably be best to have MS-DOS, Windows 9x, Windows NT and Windows Vista, splitting them by kernel architecture. --DrBob (Talk) 00:58, 13 October 2006 (CDT)
 * I support everything DrBob just said :). -- Mason11987 (Talk - Contributions) 09:26, 13 October 2006 (CDT)
 * I've noticed the new categories created. Might I suggest leaving it in the PC category, while adding the other categories. -- Prod 13:05, 13 October 2006 (CDT)
 * I wouldn't agree with that. The new categories are already in the PC category, so if somebody's looking for a PC game, it's a simple matter of looking in one of the sub-categories, instead of the PC category itself. --DrBob (Talk) 13:12, 13 October 2006 (CDT)
 * But should cat:vista be a subcat of cat:pc AND a subcat of cat:systems? Or just the former? -- Mason11987 (Talk - Contributions) 13:25, 13 October 2006 (CDT)
 * Vista isn't a technically a system, I'd say just PC. -- Prod 13:29, 13 October 2006 (CDT)
 * What if the person searching doesn't know which system it's for. Most games are typically forward compatible, ie. they can be played on their system as well as any newer one.  Would that mean they are in all the categories or just one (say dos). -- Prod 13:28, 13 October 2006 (CDT)
 * LOL! Isn't that that cat:Games is for?  ^_^; Procyon 13:38, 13 October 2006 (CDT)
 * That's a could point actually, games should belong in PC as well as in all kernel architectures (DOS, windows 9x, windows NT, vista) that they work in. -- Mason11987 (Talk - Contributions) 13:42, 13 October 2006 (CDT)
 * As I said before, I believe that would just be overcategorisation. --DrBob (Talk) 13:52, 13 October 2006 (CDT)

I've split it and recategorised all the articles which were in the PC category. :-) --DrBob (Talk) 07:58, 14 October 2006 (CDT)

Template:Welcome
I set up a basic welcome template I took from my design at SporeWiki. What I normally do is when I see red talk links I just do on their talk page to show them that they are welcome and appreciated. I think it's kind of cool and helps keep people hanging around to help out. I put in a few links I thought were useful but definitely add to it if you like. -- Mason11987 (Talk - Contributions) 09:42, 13 October 2006 (CDT)
 * Template:StrategyWiki welcome. -- Prod 09:44, 13 October 2006 (CDT)
 * ...grrr, thanks. -- Mason11987 (Talk - Contributions) 09:45, 13 October 2006 (CDT)
 * what do you think of my changes then? -- Mason11987 (Talk - Contributions) 09:49, 13 October 2006 (CDT)
 * Looks good :D. I'm just glad Template:Welcome redirects to it, cause I keep forgetting what the name of that template is :P. -- Prod 09:53, 13 October 2006 (CDT)
 * And that's the reason why I made a new one. 11:15, 13 October 2006 (CDT)

Image:Future icon.png
can someone with some decent graphics skills make this? Either a clock or calender or something. -- Mason11987 (Talk - Contributions) 12:49, 14 October 2006 (CDT)
 * It's used here: future -- Mason11987 (Talk - Contributions) 12:49, 14 October 2006 (CDT)
 * Done, but I pinched it from the Tango Project (it's allowed). --DrBob (Talk) 13:05, 14 October 2006 (CDT)
 * Very cool, nice pinch. -- Mason11987 (Talk - Contributions) 13:18, 14 October 2006 (CDT)

ESRB
Template:ESRB T, used on Guild Wars (check the infobox). Comments?. -- Prod 14:55, 14 October 2006 (CDT)
 * Looks good. The "ESRB:" part could probably be in the template as well. GarrettTalk 15:50, 14 October 2006 (CDT)
 * Done. I'll go ahead and make the others. -- Prod 16:10, 14 October 2006 (CDT)

Should I set these up for some of the other rating systems? -- Prod 16:06, 15 October 2006 (CDT)
 * Go right ahead. --DrBob (Talk) 16:25, 15 October 2006 (CDT)

Requested guides
Needs cleanup, but here's a starting point. Requested guides. -- Prod 15:39, 14 October 2006 (CDT)

Large, frequent project tags
Okay...I've brought this up to specific people in the past, but I figured with a growing userbase, and some more time to look around at some of the changes here this would be worthwhile to bring up again. My biggest reason for brinigng this up again was due to a version of the Spore article that I started up, as well as thinking about one of the perfectly reasonable arguments against having many "starter pages". First of all, lets examine the Spore version I just had. Compare that with the version where I changed two of the large project boxes to text versions UNDERNEATH the article here. I also added the article text so you could see what it would look like if that was the case. I'm just curious, after seeing that, am I the only one who sees a pretty obvious change being necessary here? My hope is that the average user who comes to strategywiki will come here in order to look for information. If all of us actually believe that, then tagging an articles with large signs that don't really pertain to the READER is an easy way to make our more modest articles look laughable. Having stub tags at the bottom doesn't mean people won't contribute to a page, as can be seen by looking at wikipedia. There are certain tags which should be at the top of the page which are very pertinent to the reader, such as the "future game" article. I don't see why the average reader needs to know that the page needs to be categorized or fleshed out. If they have information to flesh it out, then they will see the tag at the bottom of the page and will add something, or they just will add somethign because there is an edit tab at the top of every page. I realize this is a big change, but I think it would be for the best, so what does everyone think? -- Mason11987 (Talk - Contributions) 10:21, 15 October 2006 (CDT)
 * I know I've argued against this in the past, but you put a good argument, and I think it's probably the right thing to do. However, I think stub should remain as it currently is, as users should know that what they're reading isn't complete. I'm inclined to say the same for wip, but I could sway either way. Regardless, I would definitely agree that things like cleanup and needcat should be minimised, as it were. :-) --DrBob (Talk) 10:33, 15 October 2006 (CDT)
 * Sweet, I'm not even an admin and I got a personalized message :D. Anywayz, what you've made looks nice and I'm all for it.  Another suggestion would be to have this kind of stuff in the skin.  Have a "developer" skin or something where these templates show up at the top (or not at all, as the category is far more useful), and the default skin has them minimized at the bottom.  Another possibility is a "needs improvement" template which simply lists what needs to be changed in one box rather than a box for each.  Just giving some other options, though I think yours is the easiest (well, except for the skin one, cause I wouldn't have to do anything for that :P). -- Prod 10:49, 15 October 2006 (CDT)
 * The skin idea sounds VERY good, although not being a skin maker I'm not sure how it would work. I don't really think it's a huge issue though.  IN response to DrBob, I think wip  would be fine as a top of the page box as long as it was the only such box.  I don't see why any other message is required at the top of a page that says wip.  Doesn't that say it all? Categorized of course would still be used, but a wip and a stub tag?  and a needs cat tag?  I don't know if it's been done, but I wouldn't be surprised, that's about half of my screen vertically, and I really don't want that to occur. -- Mason11987 (Talk - Contributions) 10:54, 15 October 2006 (CDT)
 * My understanding of Wip and Stub is that stub is for pages that are just starting out, wip is for longer pages which are currently being edited (ie during the previous/next week or two), meaning that both should never be on the same page. -- Prod 10:58, 15 October 2006 (CDT)
 * This skin idea is a very very very good one, and I like it so much I'm implementing it right now. :-D --DrBob (Talk) 11:12, 15 October 2006 (CDT)
 * Sweet, sadly (?) I use monobook style, is this going to look like bluecloud? -- Mason11987 (Talk - Contributions) 11:17, 15 October 2006 (CDT)
 * Also, will this allow a box to be at the bottom for those who don't use the "dev" skin, and at the top for those who do? -- Mason11987 (Talk - Contributions) 11:18, 15 October 2006 (CDT)
 * I'll make it so that the boxes don't appear for users who haven't got a special user CSS file (I'll tell you about it later, once I've got it sorted). It should work on all skins. --DrBob (Talk) 11:21, 15 October 2006 (CDT)
 * I do still think that having a text tag about certain properties of a page is useful, and so I hope this can be arranged in some manner. -- Mason11987 (Talk - Contributions) 11:27, 15 October 2006 (CDT)
 * I've done all I can, but since user CSS seems to be disabled, I can't actually make them appear again. :-P I might have a go at moving things to the bottom. --DrBob (Talk) 12:02, 15 October 2006 (CDT)
 * icons in the header is another possibility. GarrettTalk 20:08, 15 October 2006 (CDT)
 * I'm going to get on this tonight when I return from college. I'm also planning on giving DrBob access to the ftp and database, since he's already got it for Abxy and as these are on the same machine there's no reason for him not to.  ech elon  13:12, 17 October 2006 (CDT)
 * I thought about suggesting icons in the header, but if your icon's work anything like Wikipedia's, then they are significantly less accessible then the current toolbox solution, and the toolbox would allow for slightly longer descriptions per article tag as shown in my example below. Also, I want to point out that I don't really prefer either of these solutions to just some plain text at the bottom of the article, even if it has to be placed there somewhat manually. If we start using these tags, I think we might continually be tempted to go overboard with them, and place things which all potential-editors should see into a substantially less readible place. For example, if any pages were to evetually be protected, that would be a great use of the article tags. Only people who know enough to visit a discussion page and request unprotection (or administrators) will give a hoot that an article is protected. However, and  tags are most useful as an attractor to encourage more participation in expanding an article, which should should be as simple to read/understand as possible without detracting from the flow of the article. --inarius 15:14, 17 October 2006 (CDT)

I think just having them at the bottom will allow those who would be looking for them (us) see them, and also those who are new here who love a game will see them too, as long as the cat is still included I think they're fine just being at the bottom. -- Mason11987 (Talk - Contributions) 21:37, 15 October 2006 (CDT)
 * The problem with that is that it would entail moving all the current tags to the bottom, as it isn't possible with CSS. I think the best way is just to have the boxes hidden for normal users, and people who want to see them can, by adding something to their user CSS (once I've got it sorted). --DrBob (Talk) 10:50, 16 October 2006 (CDT)
 * I think hiding them by default is a really bad idea. I agree with the premise of Mason11987's proposal. But while this website should first and foremost exist as a resource (Strategy Guide) to be read by unsers here for that purpose, it should also strive to be trivially easy to contribute to, and encourage users to do so. --inarius 16:31, 16 October 2006 (CDT)
 * That's definitly true, then text tags would be best? Since that basic idea has been supported I'm going to make some changes to go to that.  If further improvements are wanted, we can work on it, but I think text labels at the bottom of the pages is the best thing for everyone.  -- Mason11987 (Talk - Contributions) 21:24, 16 October 2006 (CDT)
 * I've already explained why having them at the bottom is a bad and impractical idea, but I can easily make them show up for all users in a less obtrusive form. --DrBob (Talk) 00:46, 17 October 2006 (CDT)
 * I'm sorry if I missed it, but where have you? -- Mason11987 (Talk - Contributions) 02:00, 17 October 2006 (CDT)
 * I couldn't find it either, unless he said it on another page. I can't personally see why some being at the top and others at the bottom is a huge problem; we can't stop changing things just because previous uses would be wrong. GarrettTalk 04:37, 17 October 2006 (CDT)
 * "The problem with that is that it would entail moving all the current tags to the bottom, as it isn't possible with CSS. I think the best way is just to have the boxes hidden for normal users, and people who want to see them can, by adding something to their user CSS (once I've got it sorted).", but Garrett makes a cogent point. Regardless, I'm still against having them at the bottom, as that means that people who have got them displayed could easily miss them. --DrBob (Talk) 11:02, 17 October 2006 (CDT)
 * What about putting it in the rightsidebar? That space is wasted on most pages anyway, and it should be possible through css. -- Prod 11:41, 17 October 2006 (CDT)
 * Correct, it's not possible with CSS, but there are so many style-layouts, I wouldn't support approaching this with CSS anyway. As others have mentioned, I think it would be best, to encourage that these templates be manually placed at the end of the article instead of the beggining. Such behaviour could be outlined in StrategyWiki style/layout manuals (i.e. placing the actual template tag after all page content). There is no overwhelming need for a technical solution that will solve alll problems here. Also, as Prod mentions, placing these ion the Toolbox is not a terrible idea. Again, attention would have to be given to how this appears on other skins - and to conserve screen space, I would suggest no more than a simple icon and 1-2 words describing each template. However, this approach would be best suited for article status that almost no readers would be concerned with (i.e. if an article is protected from editing). Here's how it might look:

 Article Tags
 * [[Image:stub_icon.png|25px|left|This article is a stub]] stub


 * --inarius 12:59, 17 October 2006 (CDT)
 * I like that ^. That seems to solve every problem, eveyone will notice it, but it won't cause distraction from the article itself, and it's original too, so we don't look like wikipedia.  Doing this we can manage to keep most of the project stuff off of article pages, which in my opinion is always an improvement. -- Mason11987 (Talk - Contributions) 13:13, 17 October 2006 (CDT)
 * Looks good. However, it should probably have a short blurb about what it means.  Stub is not very descriptive (for a newbie). -- Prod 13:20, 17 October 2006 (CDT)
 * Looks great! As for a description, perhaps that could be given when the icon is moused over. There's a problem though: check out Sandbox. I've inserted two separate sidebars there (simulating how the actual templates would act) and on BlueCloud only the first one shows up (in Monobook both appear but are messed up). So I suppose this would still mean going through all the pages to change things. Another way would be to create a new style where classes determine the vertical position (thus theoretically preventing overlap); this would mean there would be gaps where the templates that haven't been applied go, but it would mean no pages need to be changed. GarrettTalk 14:42, 17 October 2006 (CDT)
 * It does have a description on mouse-over (for the image). The image caption text is stored as the Alt and Title text, so when that code I wrote is placed on a page, the icon has the mouse over text This article is a stub. As for the Toolbox stuff, there's several ways it could be approached. First, the way that content is currently added to the toolbox is not ideal. Evventually, we will probably want a sort of :, which creates the div box and adds whatever content is specified (like the sidebar does currently). This could then be expanded into a more general :, which takes a set of predefined tag names, and adds all of them and their respective templates. --inarius 15:32, 17 October 2006 (CDT)
 * Another change which should make using the Toolbox easier would be to alter the JS function domNavToc to append any .nav_toc classed elements to #nav_right instead of only a single #nav_toc element id. This would open up the possibility of adding inline-content to the Toolbox with seperate top and bottom templates, like is done in Template:Userboxtop. --inarius 18:42, 17 October 2006 (CDT)

.
Here's another edit tag as this discussion is getting long. I'm somewhat against the mini icons. They're small and easily overlooked. The problem with the Template:Toolbox, is that it would require editing onto every page, and it would be fairly confusing for newbies who want to tag pages. This might require JavaScript or something >.>. -- Prod 15:51, 17 October 2006 (CDT)
 * I really like the look and the concept of using the above design, and I think the benefits would far outweigh the problems. Users who have no concept of what these things mean are left unobstructed and oblivious, while more experienced editors know what they are immediately. The problem with this solution is that it must be elegant, expandable and easily adopted for change (for the future may hold future uses for the sidebar as well!), and cross-browser compliant. Finally, there is the ultimate problem that this will only work on the BlueCloud skin--those who use other skins must have a viable alternative to the BlueCloud sidebar. Maybe some Javascript DOM manipulation could work?  ech elon  15:57, 17 October 2006 (CDT)
 * I made Monobook compatible with the sidenav months ago. The other skins don't support most of MediaWiki's more recent tweaks, so us not supporting them won't harm things much. GarrettTalk 17:57, 17 October 2006 (CDT)
 * How about just making the templates smaller? -- Prod 15:57, 17 October 2006 (CDT)

Wip Wip This!!!
 * This is ridiculous. We're descending into flights of fancy which would require several hours worth of laborious labour to change all the templates, making everything a lot more complicated, or otherwise requiring hideous CSS which would not work properly and just act as a house of cards with a big sign in front of it saying "take a leaf blower to me". I think the original idea of just hiding maintainance-type templates from the general public is the best, the simplest, and can be implemented as soon as user CSS is enabled. Keep a level head all of you, please. >:-( --DrBob (Talk) 16:08, 17 October 2006 (CDT)
 * User CSS can probably be enabled right now if you add the appropriate @import to MediaWiki:BlueCloud.css. A bit of a hackjob, sure, but it worked when I added MediaWiki:Common.css compatibility that way. GarrettTalk 17:57, 17 October 2006 (CDT)
 * Actually, am I right in thinking nav_toc could be forked into multiple versions that each places the sidenav item in its own predefined space? I'm not too handy with CSS, but if I'm right that wouldn't require any further work. Plus, as I mentioned above nav_toc is fully compatible with both BlueCloud and Monobook, and the other skins are largely abandoned anyway. GarrettTalk 18:02, 17 October 2006 (CDT)


 * Moving a template tag, or changing one tag to another won't be as laborious as you seem to imply, although yes, it might take hours of work. However, I could never see myself agreeing to hiding these templates from the general public. Editors would have to be fully aware that there are hidden tags in order to enable them, which makes then more-or-less useless to the average user. I mentioned above, I belive the foremost purpose of these tempalates to be to encourage new or innactive users to contribute to an article. They shouldn't distract a reader, but there is no sensible reason to hide them. --inarius 18:53, 17 October 2006 (CDT)
 * I have to disagree, the CSS thing is a nice touch, but if it can't work perfectly, then it shouldn't happen. I am quite against hiding the templates.  I still think it would be best to have stub templates at the bottom of the pages (and considering category:stubs is a mere 198 pages, I would do it myself if there was community support).  The small amount of time it would take to moving a template message in 198 pages is definitly worth it when all of those pages won't have inch/half-inch bold bars distracting from their content.  Although hiding those bars is sounding like a worse and worse idea.  I'd like people to know those pages are stubs, but I'd like them to first notice what the pages already have (specifically they should see the page, then notice that we have suggested there is more to add, not vice-versa, as is currently the case).  -- Mason11987 (Talk - Contributions) 19:11, 17 October 2006 (CDT)
 * My mistake, there is near 350, still not worth leaving as is. -- Mason11987 (Talk - Contributions) 19:13, 17 October 2006 (CDT)

The Options
Since this discussion is a bit unwieldy, I think it would be best to consolidate the avalaible solutions to this problem.

The Problem: Having too many non-informational template boxes can serve to distract readers from the article.

The Solutions:
 * 1) Do nothing : It seems that there is a majority consensus that some change in the current standard should be adopted, even if the changes are not immediately implemented on all pages.
 * 2) Move to bottom: Include such template boxes below all article content.
 * 3) Text at bottom: Change to text-based templates wherever possible, and include them after all article content.
 * 4) Icons in header: Modify each template to place a small (~20px) icon in the header. Works in everything but classic.
 * 5) Icons in toolbox: Create a template to facilitate placing marginally larger icons/descriptions in the Toolbox.
 * 6) Shrink templates: Make all the templates smaller/stackable to take up a minimum of screen real estate
 * 7) Hide templates from normal users: Hide the cleanup and improvement templates (but not things like stub) from normal users, and have them shown to users who want to see them, via some user CSS.

DrBob, please add a small description of your proposal. I don't think I would understand it well enough to do it myself.

As for my preference, I find number five, my own suggestion, to be the most attractive one (I guess I'm vain), but I still see no reason to complicate and hide these templates more than already accomplished in number three. At this point, I would recommend implementing three as a policy for future articles, and modifying existing articles as they are encountered. --inarius 19:24, 17 October 2006 (CDT)
 * I've added #6 as that would only entail changing the templates themselves (no need to stick with wikipedia). They could either be at the top and just "magically?" shrink as more boxes are added (this is probably hard to do).  Or they can work like userboxes and just stack under the infobox (on main pages) or under the AGN everywhere else..  I'm somewhat against #2,3,4 because they're way too easy to overlook.  The image one I'm really against, people have to learn what each image means, which a newbie would never be inclined to do ("This page has nothing...but look at the pretty icons" -> *leaves*). -- Prod 19:41, 17 October 2006 (CDT)
 * 5 is my definite favourite. Other than the CSS issues (which I'm pretty sure aren't all that major) it's clean and unobtrusive, and makes good use of the sidebar's mass of whitespace. We'd also have to move templates like Template:Final Fantasy VII/Nav down far enough that they don't conflict (or just get rid of them altogether). GarrettTalk 20:25, 17 October 2006 (CDT)
 * Well, the two concerns are A that people who might like to/need to see those templates need to, and B it needs to allow that while not distracting. I believe #2 is better, but is still distracting, #3 (as I suggested) would solve both problems.  I realize we don't have to be like wikipedia, but a lot of their ideas are really good ones, and our general goal isn't terribly far away from theirs.  #4 fails A in my opinion, #5 COULD, and a stub icon, and text such as "Stub - Add to this guide!" would be sufficient and solve both problems.  #6 may work though.  Ultimatly I think #3 is a great solution, and #5 if implemented correctly and without errors, would be the absolute best! -- Mason11987 (Talk - Contributions) 21:21, 17 October 2006 (CDT)
 * I had a quick look at the CSS/JS #5 would need. It's very straightforward. All that's required is variations of nav_right with unique vertical positioning, and then similarly dupe the JS to move it to the right. Plus it works perfectly in both BlueCloud and Monobook (other skins could be made compatible too). I might have a go at this tonight. GarrettTalk 21:48, 17 October 2006 (CDT)
 * Yes, I know that these changes would not be a big deal. Both the JS and the templates could be made quite straight-forward. --inarius 01:47, 18 October 2006 (CDT)

Out of the options available, I'd have to firmly go with number six, or number seven. Number two would make the templates less visible for everybody, and that can't be good. Number three is just a variation on that theme. Number four would make them easily missable, and the CSS would be hacky. Number five requires the use of Javascript and CSS to rejumble the page, which is never a good idea, especially for such a petty thing, but number six does make the templates less visible for those who aren't looking for them, while keeping them in a prominent place for those who are (as does number seven). --DrBob (Talk) 01:23, 18 October 2006 (CDT) If anybody wants to use my proposal of hiding needcat, cleanup, etc. templates from normal users, and wants to see the templates themselves, just add .developer_header_box{display:block;} to your user CSS file (for example). --DrBob (Talk) 01:37, 18 October 2006 (CDT)


 * Why deliberately hide anything? I think I have pointed out on occasion that I am very much against this. The greatest level of hiding I have suggested has been the article tagging, which is less extreme than any other suggestions to remove the templates from the article content. Anything that we don't want to be less visible, by all means, can be left in the article. Could others weigh in on this? I'd like to know how everyone feels about the prospect of hiding templates. --inarius 02:01, 18 October 2006 (CDT)
 * Why not run an average PC with the cover off? It reduces confusion if "behind-the-scenes" templates like cleanup are hidden. I'm not suggesting we remove the templates, I'm just suggesting they're hidden. If users want to help out, they'll edit regardless of the article tagging, and they could look at the maintenance categories. If they really want to help, all they have to do is edit their user CSS page. It's not hard. --DrBob (Talk) 11:10, 18 October 2006 (CDT)
 * I would go for the text at the top if that was the most agreed upon solution, because they need to be seen by everyone. But garret says he can get it in the sidebar, which would allow it to be easily seen and still not a distraction from the page, after all we are throwing TOCs overthere, people will notice it.  If Garret can do it, I see no reason to not use the toolbox icons, if it works, solves every problem and (as a pleasant bonus) keeps us from having to move templates, we should do it.  If someone is willing enough to modify their user css so that they can see stub templates, then they can more easily be told "hey, look to the right".  -- Mason11987 (Talk - Contributions) 09:23, 18 October 2006 (CDT)
 * Thinking about it some more, putting them in the toolbox would be OK, as I now realise that we're using JS to move the DOM structure around (which is hacky, but acceptable, and much more workable than the CSS equivalent, which would be terrible). I would like to point out that with my suggestion (and perhaps with every suggestion), stub templates would/should remain as they are currently. --DrBob (Talk) 11:10, 18 October 2006 (CDT)
 * Yes, I may have confused things by using the stub template as my example article tag. I also pointed out that was too extreme as stub templates should be readily visible. Other templates make considerably more sense to obscure. However I don't see any harm to placing the stub template below the article contents. I think the first thing on almost any article should be the actual article. -- inarius(T) 11:23, 18 October 2006 (CDT)
 * I resolutely think the stub template should stay at the top. Users need to know that a page is only a stub (it encourages them to edit), and it's a lot cleaner up there. Lower down in the page, its position would be complicated by float issues. --DrBob (Talk) 11:28, 18 October 2006 (CDT)
 * I can write templates to use the sidebar this evening. I can also provide the Javascript if necessary, but of course, I can't implement it. -- inarius(T) 11:17, 18 October 2006 (CDT)

Toolbox Javascript
Before I dive into editing BlueCloud.js, I wanted to pass the JS changes and proposed Toolbox structure by some more experienced editors. I've never edited built-in Wiki Javascript before -- but I am fairly experienced with JS in general.

To test the changes, you must:
 * Place the code at Sandbox/BlueCloud.js in your own BlueCloud.js
 * Place the code at Sandbox/BlueCloud.css in your own BlueCloud.css
 * Clear your cache (Ctrl-F5 should work)
 * View the Toolbox sample

--inarius(T) 12:21, 19 October 2006 (CDT)
 * The only problem I have with this is that you have to add the div nav_toc_append and /div to every page before and after the boxes. And if you put the nav_toc_append in each template, it only shows the first. Is there a way to make it so that the nav_toc_append is in each template rather than each page? This way we only need to add stub rather than   . Apart from that, very nice :D -- Prod 12:26, 19 October 2006 (CDT)
 * I was just about to make this point. You should just change .nav_toc -> .nav_toc_append, and scrap #nav_toc_append. --DrBob (Talk) 12:33, 19 October 2006 (CDT)
 * This could be done, but the JS would have to crawl the whole page DOM instead of just that element. My code will work for what I intended, but your approach could be more flexible. Here's the kind of template I envisioned for the toolbox, modeled after :


 * The toolboxtop template would begin the #nav_toc_append tag, and could add any initial formatting concerns, like another div to box things in, or a heading. The individual templates could then be severely dumbed-down. And toolboxbottom could close the tags. Not to say that I don't like your approach. Since we will want to include things in the Toolbox other than just Article Tags, toolboxtop couldn't add the grey headers, so it might be just as well to do everything by class (.nav_toc_append) --inarius(T) 13:18, 19 October 2006 (CDT)
 * Your approach would be fine if we were talking about a few standalone pages, but we're talking about pages edited regularly by people who don't know (or want to know) about our templates, so would not use the top and bottom templates properly. Added to that, hundreds upon hundreds of pages would have to be edited just to stop them breaking if this was introduced, and that's no easy thing to do. If you're worried about crawling the entire DOM, there's no need. You could just crawl the #bodyContent div. --DrBob (Talk) 14:08, 19 October 2006 (CDT)
 * The real concern is, as far as I know, there's no good JS function to get elements by class with a good level of browser compatibility, and I didn't want to roll my own slow/possibly-shotty version. When I was first writing this, I hadn't heard of getElementsBySelector, which is pretty elegant, but I'm not sure if I should use it. --inarius(T) 14:23, 19 October 2006 (CDT)
 * http://www.robertnyman.com/2005/11/07/the-ultimate-getelementsbyclassname/ --DrBob (Talk) 14:47, 19 October 2006 (CDT)
 * I saw some websites referring to this. Is there some reason you would prefer it over getElementsBySelector? It's smaller -- I guess I'll use it. --inarius(T) 15:03, 19 October 2006 (CDT)

I have updated the code and Toolbox sample. --inarius(T) 15:28, 19 October 2006 (CDT)
 * The rearranging works for me (works in ie7 too). I changed the "templates" so that they were all the same, since template order shouldn't be relevant.  -- Prod 15:45, 19 October 2006 (CDT)
 * I don't like it that way. I think it defeats the point of looking simple and saving screenspace. Part of the idea here was making them small and towards the top so they could be placed on any article, and any other Toolbox-content or mini-TOCs woouldn't be too heavily demoted. As for how I envisioned it, I never really planned for a solution that wouldn't require editing pages, and if that was neccessary, would prefer a total lack of the gray headers to this. However, I did also think of a way that should get the gray header there without requiring the editing of any pages. It might be a little less accessible (browsers with crappy use of CSS or Javascript might simply see the Article Tags when there are _no_ article tags). I'll check it out later tonight. --inarius(T) 17:53, 19 October 2006 (CDT)
 * I agree :P. I think the code works, now it's just a matter of deciding on layout.  I would prefer if there was some kind of description of what to do, but a link to a good description page should suffice.  Of course, we could get rid of the images, and just have a colored box with a few words (perhaps two rows of text total).  I'll change up one of the blocks as a proposal. -- Prod (Talk) 18:02, 19 October 2006 (CDT)
 * I agreegree. Although I seem quite opinionated - beyond how it should work technically, I don't have much of a feeling for how it should be layed out. But with such a small space, I have a general feeling that the smaller the description, the better. The Toolbox is fixed-wdith: increase the browser font size by a few points and all it fits is three words without images on a single line. The images could be made smaller, but some of them don't look great small... Multiple lines would probably look fine... Fancy javascript to expand descriptions is probably going too far, but it wouldn't be less accessible... --inarius(T) 18:20, 19 October 2006 (CDT)

Toolbox Prototype
UPDATE: I have reached what I believe qualifies as a final prototype for the Article Tags. I am please with it and think it is ready to be put into place. I have updated the directions above, to test the code itself, however, so everyone can easily see the changes, a screenshot of the final product is located to the right. All that is required to generate an Article Tag on a given page is to place or  anywhere on the page. Thus, no changes are required for all existing articles. --inarius(T) 12:20, 20 October 2006 (CDT)


 * DrBob has made some changes after-the-fact, and I wanted to show them sepearately so they can be discussed. The original prototypes is left, his is right. We did some discussing about expanding the descriptions above, but not a lot, so no consensus was reached. Personally, I think short and sweet will be a benefit with so much screen space at stake, and I intentionally made each tag description no more than three words. Also, I deliberately didn't include any links for work in progess. The entire header-box for the existing template only contains a single link to the article's edit page, and I think even to new editors, that's a fairly obvious operation. However, eventually, we should make a page that explains what a "work is progress" articles is other than the template itself. At which time, that could be linked to. --inarius(T) 12:41, 20 October 2006 (CDT)
 * I probably should've told you, but those descriptions are actually hideable via the CSS in my user CSS page, which I have now moved out into the wild. --DrBob (Talk) 13:17, 20 October 2006 (CDT)
 * To cite my opinion on the matter, I think this has turned out well. What I would suggest is that when these new templates are incorporated into the old ones, the markup for the old ones should remain, but hidden via CSS. That way, if anybody (such as me) wants to keep the header boxes at the top of the content (i.e. in the current place), they just have to change their user CSS. --DrBob (Talk) 13:48, 20 October 2006 (CDT)
 * That looks great, and those who want those boxes should be easily able to have them. Options are fantastic, this just allows those who aren't that familiar with this system here to get a fantastic looking default option that provides all the info they need, while still allowing them to see the guide without being too distracted.  Well done guys. -- Mason11987 (Talk - Contributions) 14:33, 20 October 2006 (CDT)
 * Yeah, looks great. When will this go live? GarrettTalk 14:39, 20 October 2006 (CDT)
 * Yes, I apparently saw your edits well before they were finished. I do like them a lot - although the hover effect (in compatible browsers) is distracting to me, since it heavily moves the TOC. I edited the CSS to displace the description to the left like a CSS menu. --inarius(T) 15:03, 20 October 2006 (CDT)
 * Wow, that looks even better. :) GarrettTalk 15:39, 20 October 2006 (CDT)
 * Yeah, nice. --DrBob (Talk) 15:39, 20 October 2006 (CDT)

SVG file format
I can't upload SVG format images, someone should allow that so I can upload a particular image from wikibooks which is PD. -- Mason11987 (Talk - Contributions) 11:44, 15 October 2006 (CDT)
 * Yup, this has been talked about waaay back. I really want SVG support for the buttons I make. Echelon or another admin just needs to install the plugin for it. --blendmaster 12:48, 15 October 2006 (CDT)
 * It's not even a case of installing a plugin, I think. afaik, all somebody needs to do is change a configuration option, but since those are only accessible via FTP, I can't. :-( --DrBob (Talk) 13:04, 15 October 2006 (CDT)
 * Sorted, and I've uploaded the three merge images. I do think they need replacing though, as they're yucky. :-P --DrBob (Talk) 11:36, 18 October 2006 (CDT)
 * How exactly do I get SVG files to show up properly. When i go to Image:Mergefrom.svg its a png image. When I go to http://strategywiki.org/w/images/0/0f/Mergefrom.svg its the svg code. If I save the file, then open in Firefox, it comes as a proper picture.  Is there something up with the MIME type or is it on my end? -- Prod 11:41, 18 October 2006 (CDT)
 * They're rasterised to PNG for display because most browsers don't support them. --DrBob (Talk) 12:21, 18 October 2006 (CDT)

Trademark/copyright
IANAL, but a lot of websites which have info about games/movies/other peoples products, usually has a disclaimer at the bottom saying that all trademarks are the property of their respective owners, or something similar. Shouldn't there be something like that here? -- Prod 16:44, 15 October 2006 (CDT)
 * Potentially that could be due to their commercial nature? -- Mason11987 (Talk - Contributions) 17:56, 15 October 2006 (CDT)
 * GameFAQs doesn't have one. The discreet link to General disclaimer should be sufficient. GarrettTalk 19:41, 15 October 2006 (CDT)
 * The only problem is it doesn't mention anything about fair use and copyright images in there IIRC. If we add that, it should be fine Minun  12:23, 16 October 2006 (CDT)
 * Agreed. -- Mason11987 (Talk - Contributions) 12:48, 16 October 2006 (CDT)
 * I'll have a disclaimer up when I get home tonight.  ech elon  15:57, 17 October 2006 (CDT)

Half-Life 2 image size
So I started taking in-game screenshots of Half-Life 2 and uploading them...however, the file sizes are very large, exceeding 600,000 bytes most of the time. Should I compress the images or upload them as they are? I know StartegyWiki has a lot of space on the server, but I just want to make sure the size limitations don't exceed too high. I plan on having tons of images for the walkthrough, so expect at least 150+ screenshots for the entire game. I'll stop uploading them now and wait for a general consensus. Thanks. --Antaios 21:24, 16 October 2006 (CDT)
 * Since most images will be shown as thumbnails until enlarged I don't see the need for full resolution, full size images. That's just my opinion though.  I don't think 150+ full size images are necessary for a strategy guide since you don't need to see complete detail in all of them.  Of course having a lot of pictures to explain certain things is great but they don't need to be all full res.  Although if the storage space is a complete non-issue I'm sure echelon will say something different. -- Mason11987 (Talk - Contributions) 21:30, 16 October 2006 (CDT)
 * While we're still on a single server, our hard drive is limited to 100 GB. We run Abxy, DSmeet, and StrategyWiki off this same machine. This includes all of the software--Linux, Apache, whatnot, as well as the software that runs each site. The databases and associated file uploads are also on the server. I haven't tallied the total usage thus far, but I do believe we are still far from reaching our limits. Nevertheless, we should be wise and conservative in our use of uploads until the time we are able to buy additional hardware through Abxy and DSmeet's income. You can still have very nice, fairly large images that have some compression. Why not upload a few examples for us to take a look at?  ech elon  16:00, 17 October 2006 (CDT)
 * Set up a paypal donation thing and I may drop a few bucks on this project. -- Mason11987 (Talk - Contributions) 18:57, 17 October 2006 (CDT)


 * That might be a decent idea. I'll see what I can do about it.  ech elon  23:55, 17 October 2006 (CDT)


 * Yeah, I'll probably have to narrow down the amount of pictures. All of the pics are in-game at 1280 x 1024 resolution with maximum graphics settings, so the pics are expected to be of that quality and size. I'll try compressing a couple to see how it looks; if it still looks good, then I'll start uploading those. --Antaios 20:56, 20 October 2006 (CDT)
 * Try png images, they often look sharper then jpeg (from my experience) and they are smaller. Although someone with more image knowledge could probably give better advice. -- Mason11987 (Talk - Contributions) 11:15, 21 October 2006 (CDT)
 * Try saving both ways, and just compare. I would recommend sticking to images at 640x480 or even lower.  It doesn't have to look amazing, just give the information.  -- Prod (Talk) 11:29, 21 October 2006 (CDT)

"Unofficial" policy of the week
These have to be taken care of sooner rather than later. Perhaps we set one policy as a policy of the week (selected here) for the next 5 or 6 weeks. As Layout is mostly done, I nominate that as the first one (the easiest :P). -- Prod 23:17, 16 October 2006 (CDT)
 * I'll whip up Categorisation as weary as I am of the spelling ;). -- Mason11987 (Talk - Contributions) 23:32, 16 October 2006 (CDT)
 * I prefer the letter 'z' as well, and Firefox keeps complaining about that spelling :P. Well, if you're going to work on that, I'll change my nomination to that one. -- Prod 23:48, 16 October 2006 (CDT)

Nomination for this week: Naming. -- Prod (Talk) 09:08, 22 October 2006 (CDT)

New game template
I created New game. I tried to stick to something every main game page would have, to avoid parameters which would make it less useful. Anything that should be added? -- Prod 21:32, 17 October 2006 (CDT)
 * Good idea! I've added a single parameter for the game's name, and standardised it a bit. :-) --DrBob (Talk) 01:25, 18 October 2006 (CDT)
 * I've replaced it with . This way it's filled in automatically. A similar method could be used to turn  or similar into the full template. GarrettTalk 03:11, 18 October 2006 (CDT)
 * Well AGN shouldn't be subst'd, keep the dynamic nav out of the average page code. This page has useful, organized templates contained within one template that can be subst'd. -- Mason11987 (Talk - Contributions) 09:10, 18 October 2006 (CDT)
 * Should we subst FULLPAGENAME? If the game is moved it won't automatically update, but it will be easier to understand if there is a need to change it then FULLPAGENAME.  I'm not particularly strong either way on this, but I just thought I'd bring it up. -- Mason11987 (Talk - Contributions) 09:12, 18 October 2006 (CDT)
 * I had tried using but that ended up getting substed with New game :P.  I also added the needinfobox because an empty infobox is the same as no infobox. -- Prod 10:21, 18 October 2006 (CDT)
 * I had to rig it, but template complexity (especially when included, and in doing so, becomes very simple) isn't really a bad thing as long as it provides functionality, check out my test in the sandbox. -- Mason11987 (Talk - Contributions) 11:48, 18 October 2006 (CDT)
 * Well, I managed to clean up your solution a bit :P. I would classify what is done as a hack >.> -- Prod 12:01, 18 October 2006 (CDT)
 * Nice, I just tossed in what I knew would work, but that works even better. -- Mason11987 (Talk - Contributions) 14:38, 20 October 2006 (CDT)

Bot
Ban User:Boothby (bot)! He's gone crazy!!! -- Prod 14:54, 18 October 2006 (CDT)
 * I've stopped the bot, and will go about rectifying the damage. (I didn't filter the image names against "Portrait_*".) --DrBob (Talk) 15:14, 18 October 2006 (CDT)
 * All done. :-) --DrBob (Talk) 16:09, 18 October 2006 (CDT)

PC keys?
Should there be a Category:PC keys? I think it would be useful, but I'm not good at graphics, so I'm bringing it up here as the template told me to :). -- Mason11987 (Talk - Contributions) 20:38, 22 October 2006 (CDT)
 * I'd say something more like Category:Keyboard buttons since it isn't for only PC's but all computers (minor distinction :P). Also, some of the category naming at Category:Controller buttons seems inconsistent. I suggest these changes (should be easy for you botters ;) ):


 * Category:Xbox360 controller buttons -> Category:Xbox 360 controller buttons
 * Category:DS controller buttons -> Category:Nintendo Dual Screen controller buttons
 * Category:Playstation controller buttons -> Category:PlayStation controller buttons
 * Finally, the buttons also need to be added to the Category:PlayStation 2 controller buttons and Category:PlayStation Portable controller buttons, though I don't know too much about the differences between the controllers. -- Prod (Talk) 21:07, 22 October 2006 (CDT)
 * Why is everything in Category:Controller buttons as well as their own specific category? -- Prod (Talk) 21:16, 22 October 2006 (CDT)
 * Don't call the Nintendo DS by "Nintendo Dual Screen". That isn't official, nor is it even its colloqual name! I would not support a move to do this. While it might be good to aim for consistency between game platform categories and the button categories, please continue to use the standard naming for each: basically whatever the company uses and the community knows best.  ech elon  23:31, 22 October 2006 (CDT)
 * I would support the first and third movement suggestions, and I'll set my bot on them. :-) --DrBob (Talk) 04:11, 23 October 2006 (CDT)
 * Done. I've now set the bot on removing all images from the Controller buttons category, leaving them just in their system-specific categories. --DrBob (Talk) 04:42, 23 October 2006 (CDT)
 * In that case, I suggest the Category:Nintendo DS controller buttons. As I was looking through the official Nintendo website, I found that they referred to the systems as Nintendo Entertainment System/Super Nintendo Entertainment System (and as the NES/Super NES) rather than as the Nintendo/Super Nintendo. So, Category:NES controller buttons and Category:Super NES controller buttons would seem like the appropriate terms in this case.  For that matter, Category:Super Nintendo should be moved to Category:Super NES (just like Category:NES). -- Prod (Talk) 11:25, 23 October 2006 (CDT)
 * I'm not sure about that. Fans always call it either the Super Nintendo or the SNES, never the Super NES. GarrettTalk 14:47, 23 October 2006 (CDT)
 * Well, those are the official names, and we can set up redirects for the others. -- Prod (Talk) 15:08, 23 October 2006 (CDT)
 * I think they're fine as they are, really. The categories I renamed were definitely wrong, but these ones aren't. --DrBob (Talk) 15:16, 23 October 2006 (CDT)

Fixed redlinks, but I'm not sure what the consequence is
There's a nasty little line in /includes/SkinTemplate.php that was causing the red links, so I decided to comment it out:

I'm not sure what the function of importing this was, but it's no longer done. All it was doing was changing our default missing article links, which were purple, into ugly red ones.  ech elon  23:28, 22 October 2006 (CDT)