From StrategyWiki, the video game walkthrough and strategy guide wiki
Jump to navigation Jump to search
This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the main talk page.

September 2006 | October 2006 | November 2006

Talk link

I noticed theres not a link to the talk page on an articles page, so I have to manually type the URL of the talk page. There should be a "discussion" tab on the tab bar Minun 14:43, 1 October 2006 (CDT)

It's at the top of the right-hand column. :-) --DrBob (Talk) 14:46, 1 October 2006 (CDT)
Oops, sorry for not noticing, cheers Minun 14:47, 1 October 2006 (CDT)
Speaking of which, I just notice, the 'Watch' command is listed in the Toolbox, while 'Unwatch' appears as a tab above the article. This is quite counter-intuitive. --inarius 13:06, 2 October 2006 (CDT)
We will have a new skin soonish that will solve these oddities. GarrettTalk 14:24, 2 October 2006 (CDT)

Interwiki linking

I've created this template to help attract some other visitors. Currently it's only being used on MapleStory to test it out. It still needs one of those site images. With that, it can probably also be used on wikibooks. We also should eventually get an article over there specifically about StrategyWiki, but it's bad form for any of us major contributors to write it (NPOV and all that). What are other peoples thoughts? -- Prod 18:05, 3 October 2006 (CDT)

I REALLY don't think that'd be acceptable at wikipedia, and if that template were put up for deletion I couldn't realistically vote for keep. It isn't the kind of thing that's a good thing to put on wikipedia (imagine the potential abuse, boxes everywhere) but if there are pages about video games still on wikibooks, I think that would definitly be useful. Although the scope of wikibooks is in general on topics that have textbooks written about them, and so an inclusion of a strategywiki link, especially in something more then an offhand external links section, doesn't flow well with that. Nothing against your work at all, but I don't think those boxes are useful at either wikipedia or wikibooks, and I expect the wikipedia one to be deleted in the near future.
Wait, it is up for deletion with a good explanation of the nomination, I'm gonna have to support the removal and I would encourage people to look over wikipedia policy to comment on this (don't wish to accidentally create a "pile-on" vote for keep). -- Mason11987 (Talk - Contributions) 19:24, 3 October 2006 (CDT)
On the note of a strategywiki page. I'm going to go through the process to get comment on whether it should be created or not. Then if it gets nominated for deletion after created (if people think it's a good idea) then I can reference that discussion. I'll link to it soon, but again I don't encourage people to push for the addition without completly looking through wikipedia policy. I'm not sure if this site is notable enough by their criteria to have a page yet. I'm sure it will be at some point even if not now. -- Mason11987 (Talk - Contributions) 19:26, 3 October 2006 (CDT)
Yea, I didn't want to start the StrategyWiki page cause by now I'm way too biased. About the template, didn't know what their policies were on it one way or another. Took 5 minutes to make so decided to see what happened :P. I guess I'll just stick to external links at the bottom. -- Prod 22:57, 3 October 2006 (CDT)
I think a template like the wikia templates is a great idea, because we could have an external link that would be VERY useful for a lot of information. But a box was just a little much in my opinion. I asked on WP:WEB about it, so I'll wait for a comment. -- Mason11987 (Talk - Contributions) 23:50, 3 October 2006 (CDT)
Current version of Template:StrategyWiki has been accepted. -- Prod 10:19, 4 October 2006 (CDT)


It doesn't seem that Common.css is being used while using the bluecloud skin. This was already shown by the problems with Template:Infobox. I would imagine there are some conflicts between them, but some of the features that common.css adds would be very useful. Right now, bluecloud shows me

<style type="text/css">
@import "/w/index.php?title=MediaWiki:Bluecloud.css&action=raw&ctype=text/css&smaxage=18000";

whearas monobook shows me:

<style type="text/css">/*<![CDATA[*/

@import "/w/index.php?title=MediaWiki:Common.css&action=raw&ctype=text/css&smaxage=18000"; @import "/w/index.php?title=MediaWiki:Monobook.css&action=raw&ctype=text/css&smaxage=18000"; @import "/w/index.php?title=-&action=raw&gen=css&maxage=18000&ts=20061003224226"; @import "/w/index.php?title=User:Prod/monobook.css&action=raw&ctype=text/css";


-- Prod 18:36, 3 October 2006 (CDT)

Yeah, this is a known flaw that will be addressed with the new skin. Manually adding an @import to MediaWiki:Bluecloud.css should work in the meantime. GarrettTalk 19:06, 3 October 2006 (CDT)
Thanks, works for me now. One of the main thing I wanted was the italics on Special:Allpages/Z which weren't there before (for telling which are redirects). -- Prod 23:09, 3 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! :) echelon 12:49, 6 October 2006 (CDT)


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)


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 StrategyWiki: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 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 {{Header 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 Header 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 Header 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 Header 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 Header 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)
Header 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 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)

Do we categorise with the earliest which can handle the game, or the latest? -- Prod (Talk) 09:28, 1 November 2006 (CST)
The earliest for which the game was released, as we do with consoles :-) --DrBob (Talk) 11:10, 1 November 2006 (CST)


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 {{subst:welcome}} 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)


Template:ESRB, 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)

I think I've gotten all the important ones at Category:Content rating systems (check what links to them). Use them with {{Infobox}}. God of War seems to have quite a few examples on it. RSAC is weird since it has three variables. I had to split it into RSACV, RSACS and RSACL. The other confusing are CERO and OFLC since they changed their ratings schemes. The new rating schemes are accessed with the regular acronym, the old one has old at the end of the acronym. The new CERO was only implemented this March, so most older games use the older CERO old parameter. Options are mentioned on the infobox template. -- Prod (Talk) 22:30, 7 November 2006 (CST)

These are looking very nice. Great work! --inarius(T) 01:13, 8 November 2006 (CST)

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 [1], 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. echelon 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, {{stub}} and {{wip}} 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:

<div id="nav_toc" style=" padding: 0.5em;"> <div style=" text-align: center; background-color: #DDDDDD; margin-top: 1em;">'''Article Tags'''</div> * [[Image:stub_icon.png|25px|left|This article is a stub]] <span style="line-height:25px">[[StrategyWiki:Perfect stub article|stub]]</span> </div>

--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 StrategyWiki: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 {{toolbox}}, 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 {{articleTags}}, 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? echelon 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)
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:

--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 <div ***>{{stub}}</div>. 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 {{userboxtop}}:
| properties = ...


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) --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 {{cleanup}} or {{wip}} 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 {{wip}} 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 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)

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 {{FULLPAGENAME}}. This way it's filled in automatically. A similar method could be used to turn {{AGN}} 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 {{subst:PAGENAME}} 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)


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)

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:

$sitecss .= '@import "' . $this->makeUrl('-','action=raw&gen=css' . $siteargs) . '";' . "\n"; 

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. echelon 23:28, 22 October 2006 (CDT)

"Disappearing" images?

I don't know how many of you have encountered this strange phenomenon, but I've noticed that some of the pictures that I once uploaded that appeared fine are now no longer appearing. The weird thing about this is that the pictures are clearly there. This has just happened to me with a new Xevious screenshot that I recently uploaded. To see what I'm talking about, check out Pac-Man and go down to the box art gallery. The TI-99/4a box picture is missing. And when you try to look at the Image:PM_TI99_box.jpg page, it's clearly there, but you still can't see the picture. Only when you click on the blue link to PM_TI99_box.jpg can you actually see the image. Well, the same thing just happened on the Xevious/Strategy page. I uploaded a series of pictures to illustrate the position of the hidden Sol Towers. All of them uploaded fine, but the second picture will not appear on the page. Again, if you go to Image:Xevious TowersB.jpg, the page exists, but you still can't see it until you click on the link to Xevious TowersB.jpg. I noticed this for the first time when I tried to upload an portrait of Maki from SFA3. I had to append an underscore to the filename to make this go away, but now that I realize it's happening to older images (like the Pac-Man one) as well as new ones, I thought another solution should be discovered. Procyon 14:48, 25 October 2006 (CDT)

I could not reproduce any of these problems in Firefox 1.5. It sounds like a cache problem, or if you are running Internet Explorer, I know it can have issues with storing cookies from URLs containing underscores. Perhaps it has similar issues with cached images? I tried opening a few of these pages in IE6 as well and I still couldn't reproduce it. --inarius(T) 15:13, 25 October 2006 (CDT)
It's because you have adblock (plus) with filterset G (most likely). Mediawiki creates thumbnails and puts them in folders with random characters, there is a possibility of the subfolder being called /ad/ and so the image will be blocked. Make an exception for that image and you'll be fine. -- Mason11987 (Talk - Contributions) 15:31, 25 October 2006 (CDT)
And I'm correct, the thumbnail is here:
Interestingly enough, I also filter out the powered by mediawiki button because it has 88x31 in it's title. How bout that. -- Mason11987 (Talk - Contributions) 15:34, 25 October 2006 (CDT)
Thanks Mason! You were absolutely right. I had no idea, that's so odd. I set a general exception for, I just wonder if there's any other way to avoid that. No matter though, problem solved. Thanks again. Procyon 15:39, 25 October 2006 (CDT)
No problem, I had encountered it a lot before on sporewiki, uploading dozens of images, so it's good to share :). -- Mason11987 (Talk - Contributions) 00:01, 29 October 2006 (CDT)
Ah, this also explains the problem I had with some button images. Maybe we should prevent mediawiki from putting images in a directory /ad/ so if someone happens upon this site and has adblock+filtersetG on, they won't think we're sloppy about uploading images or something. --blendmaster 18:30, 25 October 2006 (CDT)
I doubt that Echelon or any of us have any direct control over that unfrotunately. It's most likely a hash algorithm that determines what the the two letters are going to be. It's a bit like asking dice not to roll snake-eyes. You can't prevent it from happening, even though it's unlikely. Procyon 18:33, 25 October 2006 (CDT)
The hash algorithm is the exact same one we use on ABXY:
m = md5_file(image);
There's not much we can do about this, unfortunately. Even Wikipedia does this. echelon 12:30, 26 October 2006 (CDT)
It's actually an amazingly cunning way of doing things, and it's unfortunate that some of the Adblock filter sets don't have exceptions for things like this. --DrBob (Talk) 07:35, 27 October 2006 (CDT)
I know it'd probably just be easier to ask the filtersetG people to add wikimedia image directories to a whitelist, but couldn't you just add an if statement to test if m{1}m{2} == "ad", and if it does, use a different hash or something? --blendmaster 12:15, 29 October 2006 (CST)
That's a dirty hack, and it really shouldn't be done. Talking to filtersetG is the way to go. --DrBob (Talk) 14:09, 29 October 2006 (CST)

WP template

I created a {{WP}} template for linking to wikipedia. I'm not sure if going through wikibooks to get to wikipedia is going to be permanent, but if the way it's done ever does change, it'll only be one place to change it. ex. {{WP|Main Page}}. On a similar note, can we get a bulbapedia interwiki link? -- Prod (Talk) 10:53, 27 October 2006 (CDT)

Now that DrBob has FTP access (I think) it shouldn't be difficult for him to add to the interwiki list. GarrettTalk 13:58, 29 October 2006 (CST)
Try now. I've added "wp" and "wikipedia" links to Wikipedia, and "bp" and "bulbapedia" links to Bulbapedia. --DrBob (Talk) 14:22, 29 October 2006 (CST)

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 Wikibooks: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 StrategyWiki: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)

Requested guides

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


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 StrategyWiki: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. echelon 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? echelon 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. echelon 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 StrategyWiki: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 StrategyWiki: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: StrategyWiki:Naming. -- Prod (Talk) 09:08, 22 October 2006 (CDT)

Controller button category name changes

some of the category naming at Category:Controller buttons seems inconsistent. I suggest these changes (should be easy for you botters ;) ):

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. echelon 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)

Category renaming

This is kinda a separate discussion, heres the summary (in order of controversy, least at the top):

  1. Add images in Category:PlayStation controller buttons to Category:PlayStation 2 controller buttons and Category:PSP controller buttons (refer to Category:Xbox controller buttons and Category:Xbox 360 controller buttons)
  2. Category:DS controller buttons -> Category:Nintendo DS controller buttons (consistency with Category:Nintendo DS rather than Category:DS)
  3. Category:Nintendo controller buttons -> Category:NES controller buttons (consistency with Category:NES rather than Category:Nintendo)
  4. Category:Super Nintendo -> Category:SNES (Official name)
  5. Category:Super Nintendo controller buttons -> Category:SNES controller buttons (refer to #4)
  6. Category:GameCube -> Category:Nintendo GameCube (Official name)
  7. Category:PlayStation/Category:PlayStation 2 -> Category:Sony PlayStation/Category:Sony PlayStation 2

My main reasoning is, it's far easier to stick to official company standards (which are easily accessible) rather than community standards. -- Prod (Talk) 11:17, 25 October 2006 (CDT)

Agreed on all points. Of course, only the appropriate images should be added to the PS2 and PSP categories. --inarius(T) 15:08, 25 October 2006 (CDT)
I can agree with the other changes, but I really don't agree with using Super NES. It's a less common name and even Nintendo calls it the SNES now. GarrettTalk 19:52, 26 October 2006 (CDT)
I didn't realize they considered SNES official. I think is a better example. Updated above. -- Prod (Talk) 20:43, 26 October 2006 (CDT)
OK. I think I'll agree with 1, 2, 3 and 6, and also suggest that Category:PlayStation -> Category:Sony PlayStation (and the same for PlayStation 2, inline with 6). --DrBob (Talk) 07:39, 27 October 2006 (CDT)
For Ps -> Sony PS: Nintendo mainly calls it the Nintendo GameCube, whereas Sony calls it the PlayStation. I have no objection to adding Sony, but I don't fell it's necessary either. -- Prod (Talk) 09:47, 27 October 2006 (CDT)

I finished some of those off. I still think that we should change 3/4. If I can figure out the add cat functionality of this bot I'll finish off #1 shortly. -- Prod (Talk) 12:03, 21 November 2006 (CST)

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). -- Prod (Talk) 21:07, 22 October 2006 (CDT)
Separated out other talk so we can get more comments about this. -- Mason11987 (Talk - Contributions) 15:29, 25 October 2006 (CDT)
Yea, sorry about that. I kinda hijacked your thread. The category is probably needed, especially for games like Final Fantasy VII. My image skills are pretty bad, but I'd suggest probably white keys, black borders, raised inner square with a nice large letter in the middle. Also an Enter button shaped like the old ones (the triangle thing). -- Prod (Talk) 16:34, 25 October 2006 (CDT)
DavysBigKeyCaps is a nice font for that. Another way to make keyboard buttons is to make a template with a plain square keyboard image as a background and the letter centered, with special cases for irregular keys. Then, it'd be more accessible as well. --blendmaster 11:45, 29 October 2006 (CST)