StrategyWiki talk:Community Portal

This page is for discussion of general community issues. To start a new thread click here. Resolved threads are gradually archived; see the archives box below.

Key Issues:
 * License
 * Articles to delete
 * Others to be added...

Table of Contents markup
Over a number of guides, I've seen ToC markup which isn't good. It's using outdated, deprecated, non-semantically loaded tags to do the jobs of titles. (I am referring to ToCs which use to emphasise section titles - an example would be The Legend of Zelda: Ocarina of Time.) Instead of this, they should be using headings (usually === Section title === ) to make it more accessible and semantically correct. If you don't know what semantics are, either look them up, or don't reply. ;-) --DrBob (Talk) 12:40, 26 June 2006 (PDT)


 * You're about to see why I did that. Check out The Legend of Zelda: Ocarina of Time again. (If I had used == 's, the new Table of Contents would break the page.  ech elon  16:41, 26 June 2006 (PDT)

A new table of contents
What are your thoughts on The Legend of Zelda: Ocarina of Time's new table of contents system? It needs a bit of polishing, but I think this will become a standard for larger guides.  ech elon  16:44, 26 June 2006 (PDT)
 * It's pretty nice, and I think it should be automatically visible. Or at least easier to notice (it took me a second to see where it is). Alex 16:51, 26 June 2006 (PDT)
 * I'm thinking of storing the show-hide preference in a cookie. You're right about making the link more apparant, though. We need a small icon or something to go with it. Maybe two images: an up and down triange.  ech elon  17:10, 26 June 2006 (PDT)
 * I think it should be shown by default on the first page. Right now it's little different from the old cover page idea, a click is still required to see the TOC. I also prefer the sidenav just a little bit more since it's always there and makes use of the otherwise wasted right-hand column. GarrettTalk 17:53, 26 June 2006 (PDT)
 * The sidebar required for the sidenav TOC isn't present in other skins. I am thinking of an option that lets the user choose whichever type of navbar they want, though. (I didn't by any means delete the sidenav script.) Currently, I must say that I prefer this new inline TOC to the sidebar one; it allows much more options, such as organized multi-column navigations and inline images. Plus, you don't have to scroll down the page to see the whole TOC, and that's a very annoying part of the sidenav TOC. Again, I'll still try to find a solution that allows the user to choose either one though. Just keep in mind that I am not done by any means--the new inline TOC needs some kind of image to make it more obvious, a little tidying, a saved user preference, an init variable, etc.  ech elon  21:45, 26 June 2006 (PDT)
 * I think I made some useful changes that appears to work very well on both bluecloud and monobook. The .js file can be edited so that the nav always shows up by default, but I think having it hidden by default is best (unless you can store it in cookies, that would be even better).  I had to edit a few files to get it to work the best, and couldn't find the "GuideTOC" style anywhere so I used something without that.  Sine that style probably won't be used outside of that template I don't see why it should be a reference in some file that is uneditable, you know?  I think this is simple and clean, while being very useful at the same time.  It could use some polish of course, but I think it's even better now. -- Mason11987 (Talk - Contributions) 22:57, 26 June 2006 (PDT)
 * It looks nicer, but the show/hide doesn't seem to work anymore. (I did dump my cache...) Do you plan to reimplement that? I think the hiding feature is the best attribute of the template. I'll try to add cookies support tomorrow.  ech elon  23:04, 26 June 2006 (PDT)
 * Try it again. You changed the dynamic nav stuff to be specific to TOC related things.  This chang allows dynamic nav to be used in all kinds of things, including the todo lists (check your user page in a little bit to see the changes I'm making to that). -- Mason11987 (Talk - Contributions) 23:15, 26 June 2006 (PDT)
 * When you click on "show" in the new ToC, there is a minor bug where it still says "Show" underneath "hide". In other words, you get two words meshed together.  Can that be fixed?  Other than that, everything looks great!--Dukeruckley 05:59, 27 June 2006 (PDT)
 * I'm not that good at javascript so I'm going to leave this to echelon or drbob. It's odd that this bug doesn't exist when using monobook, but does in MediaWiki:BlueCloud.js, even though the .js files are exactly the same...how strange eh?  Good luck guys :). -- Mason11987 (Talk - Contributions) 08:23, 27 June 2006 (PDT)
 * Eh? You called? What do you want me to do? (BTW, I think the ToC template is too big at the moment: imho the border should be removed, to let the ToC contents fit in with the rest of the page.) --DrBob (Talk) 08:52, 27 June 2006 (PDT)
 * Well, the TOC at the top of every zelda page (and actually the dynamic navigation system as a whole) functions without that little bug duke mentioned only when it's on monobook, on bluecloud it has that bug he mentioned, and with your "BTW", are you referring to the zelda TOC page itself or the dynamic nav system used in all game nav? -- Mason11987 (Talk - Contributions) 09:38, 27 June 2006 (PDT)
 * I'll take a look at the bug later, but I am referring to the dynamic nav system itself. IMHO, the "Table of Contents" link in the All Game Nav proper (i.e. the one which has always been there) should be emphasised more, and when clicked, expand the full table of contents, with a light grey border around the bottom, left and right to separate it from the content, and perhaps with a "tab" effect applied to the Table of Contents link the user just clicked. I don't like the fact that it's expanded by default (takes up far too much space), and the current border and grey title bar doesn't fit in; neither does the reduced width. --DrBob (Talk) 10:04, 27 June 2006 (PDT)

I believe I get what you're saying. It is strange to have a TOC link and also have the dynamic nav, and if possible I would like to be able to have clicking the TOC link bring down the whole nav. Perhaps the entire content of all game nav should have a border around it to seperate it from the content? I think that would make things clearer. It's kind of hard to get exactly what you mean, but if you set up a test All game nav to mess with styles it might be easier to follow. -- Mason11987 (Talk - Contributions) 11:11, 27 June 2006 (PDT)
 * I've fixed the show/hide problem (a dirty hack, because the function creating the show/hide links was being called twice and I'm not about to debug that) in BlueCloud, but not Monobook because you said the problem doesn't occur with it. I've also created a WIP mockup of what I was thinking of for the ToC stuff, incorporating your idea of bordering the all game nav entirely. --DrBob (Talk) 12:37, 27 June 2006 (PDT)
 * I think that is very cool, I changed the Counter-Strike:_Source/Table_of_Contents page so that it didn't include the infobox. Perhaps it can be set up so that the infobox is shown on the page whe you view it, but when it is included it sets up the TOC horizontally?  It seems like a lot of effort for this to be done on most multi-page guides, but I definitly like the style.  I think this will look amazing on the zelda guide, just each guide will have to figure out exactly what will be included in the template. -- Mason11987 (Talk - Contributions) 20:25, 27 June 2006 (PDT)
 * I made some more changes, so it appears exactly the same on the TOC page itself, but when used in the template it looks much cleaner. -- Mason11987 (Talk - Contributions) 20:33, 27 June 2006 (PDT)

'''Whooops... I meant to actually put this on the Todo Talk page, I'll move it there now'''

Another odd fluke... Using MediaWiki:BlueCloud.js, when I click on "edit" where it says "Games I'd Like to Work on Eventually" on my user page it comes up with the edit box for the section below it "Games Currently Playing". Likewise, when I click on edit for "Games Currently Playing" it goes to edit "backburner" which is below that one. Above the To Do list, it work correctly so I think its a problem with the Todo template. Thoughts? (Not a big deal, but something that might need to be addressed at some point).--Dukeruckley 08:04, 28 June 2006 (PDT)

Another note: It does the same thing with other users as well.--Dukeruckley 08:08, 28 June 2006 (PDT)

End random section that doesn't belong here


 * Starting a new indent. While I like the look of the menu that Mason did more than mine (it's more compact, more noticiable to the user, and a little more organized), I can't help but feel that it was a step backwards:
 * The new version is attempting to be the show/hide template from Wikipedia, thus in essence trying to be a more general script. The one I designed was specific for the purposes of the Table of Contents alone. In my opinion, the biggest problem with the new one is that it requires a seperate bar for the "show/hide" portion of the Table of Contents, and that looks cluttered. I don't know how many saw the one before, and though it was certainly not perfect, it made the "show/hide" link a part of the All_Games_Nav itself. I think the new one, while more noticable, is a bit too jumbled looking. We need something that employs the benefits of both, but we absolutely have to get rid of that bar at the top; it looks far too cluttered.
 * The original ToC that I designed was not set into any formal kind of standard. Different guides may require different types of data displayed under the Table of Contents--perhaps diagrams or images. While I'm not sure if this is the case or not, but the new one seems like it wouldn't fit those types of things.
 * I hope I'm not trying to backstep or be redundant, but I do feel that we should revert back. The show/hide template for Wikipedia will have uses here, I just don't feel we should use it for the Table of Contents. (Sorry Mason, I know you must've put a lot of work into it :(  ech elon  13:09, 28 June 2006 (PDT)
 * I'm not quite sure what you mean here, although it has been a long day. Have you looked at my spiffied up version?
 * I kind of get what you're saying, but I think as it is now it's got it's advantages over the older one, but if you have improvements to this or even a completly different style that has more advantages I think it'd work great. The spiffed up version DrBob made is quite a big improvement over the one I made and I think it takes into account some of your ideas.  Also, I didn't get the show/hide on the version you had before, although it IS possible that was my fault.  I think the bold change you did with the all game nav got us into a Bold-revert-discuss cycle which is one of the best ways of getting the most out of this.  Feel free to change the one I made, but I DO think it is an improvement over what was there before, even if it has it's faults which is completly open to change which DrBob has done. -- Mason11987 (Talk - Contributions) 15:30, 28 June 2006 (PDT)
 * The version that DrBob is working on looks great! This is the first I've seen of it. It's pretty much a better looking mix of your version and mine. The only thing that might be problematic in his version: I'm not sure about the use of ==Heading== markup, since doing so causes the wiki-generated table of contents to go berzerk. If we could replace the headings with and bold markup, it won't interfere with the toc and would be flawless.
 * As for the show/hide on my version, DOM javascript turned the old "Table of Contents" link into a "Show Table of Contents/Hide Table of Contents" link. It was rather obscure, and it needed some kind of image or something--DrBob's version fixes that and looks even better than before. Let's go with his, and if there are any further improvements to be made, we can make them when they arise.
 * That said, I think this is pretty cool. Our top navigation menu is really slick!  ech elon  19:26, 28 June 2006 (PDT)
 * DrBob's template looks really nice, but I really think we should change the All Game Nav template. Right now, the Introduction and Table of Contents just link straight back to the main page, so its pretty redundant. I think the always visible part of the Table of Contents thing should be customized to the guide, with links to the main sections, such as Walkthrough, Extras, Codes, and stuff like that, instead of the default main page, intro, and toc. --blendmaster 13:16, 29 June 2006 (PDT)
 * Mine is being developed as a drop-in new version for the All Game Nav, so I can't see any problem with bringing such changes into mine, and then moving them forward to All Game Nav. Your point that many guides just have the ToC and intro redirect to the main page is very valid: we should look around for some other standard pages to put in instead (although the link to the ToC should stay as all guides should have a separate ToC page when this new All Game Nav is rolled out, due to the fact that it references them). --DrBob (Talk) 14:06, 29 June 2006 (PDT)
 * I'd migrate your version in as the default now, then continue using it as an in progress version. If all game nav is going to be used on every guide (as it's name implies), we may want to have it protected at some point, and having a test version would be great too if we get it in the template namespace also.
 * But the different links could easily be set up, we just have to figure what would be the best setup. I don't think an "intro" page needs to exist, having a page for the game title (the main page), then a TOC, then a walkthrough would be good enough I think.  The rest can go in the TOC dropdown. -- Mason11987 (Talk - Contributions) 22:21, 29 June 2006 (PDT)
 * I think we need "Walkthrough" as an introduction on how to use the walktrhough portion of the guide. (If there are specifics that the reader must pay attention to, etc.) There is also an ulterior motive for this: SEO (Yahoo *really* loves StrategyWiki). I suggest a "Cheats", "Tips", or "Codes" section for the All_Game_Nav as well. Perhaps the Qif can be used to specify which elements are shown. As for the link to the Table of Contents? That's slightly important: it serves as a link to edit it. Of course it could also be obscured, though.  ech elon  19:24, 1 July 2006 (PDT)


 * I've moved mine forward to the All Game Nav page proper, and removed the "Introduction" link, but I haven't added any extra links, pending decisions in this discussion. Think, people! --DrBob (Talk) 18:25, 7 July 2006 (PDT)


 * I would try going with a link to an Extra/Appendices page, where all of the cheats, weapons information, enemy information, stage information, etc. link off of a main page. For example, in OoT, this would be under Extras, or in the Biohazard guide, this would be under Appendices. But this can't apply to every guide, since some are split into smaller sections or don't have a universal name. Anyone else think an Extras/Appendices link is important and maybe consider every guide to have an Extras page with all miscalleneous information? --Antaios 05:12, 8 July 2006 (PDT)


 * I don't think such a general title is what we need. We need to identify something present in most guides with a similar level of specificity as "Walkthrough". I really don't think a "Miscellaneous" page (which is basically what you're suggesting) would be useful. "Cheats" would be good. --DrBob (Talk) 05:59, 8 July 2006 (PDT)


 * I'm for a "Cheats" section. -- Mason11987 (Talk - Contributions) 06:53, 8 July 2006 (PDT)


 * I suppose so. Would the Cheats section have Secrets/Easter Eggs too, or just like Gameshark codes or button combination cheat codes? --Antaios 07:46, 8 July 2006 (PDT)


 * The cheats section would have whatever's appropriate for the guide. :-) I've added it to All Game Nav. --DrBob (Talk) 08:26, 8 July 2006 (PDT)


 * Ok, cool. I was just making sure. ; ). Looks good though. --Antaios 19:41, 9 July 2006 (CDT)

Open invitation for Pac-Man Patterns
In the spirit of StrategyWiki, I started a Pac-Man Patterns section in the Pac-Man entry, so I thought it would be fun if all the usual members of StrategyWiki contributed their favorite pattern to the page. To be honest, I think it's the first of it's kind, a public repository of Pac-Man patterns. If it fills up with lots of contributions, who knows, we could get a lot of press in video game blogs like Joystiq or Kotaku. I look forward to seeing any of your additions! Feedback is welcome. Thanks! Procyon 19:01, 28 June 2006 (PDT)


 * Left comment on that pages talk. -- Mason11987 (Talk - Contributions) 07:33, 29 June 2006 (PDT)

Marking GFDL articles
I've created Template:GFDL_Article to mark all the existing articles so we can begin the relicensing process. Is everyone ready to do this? (Do you think this template is sufficient?)  ech elon  19:48, 28 June 2006 (PDT)
 * Looks fine. I don't know that images need tagging though, Wikipedia and the like merrily use images regardless of what copyleft license they use. How are you going to identify untagged pages though, with a database query? GarrettTalk 19:56, 28 June 2006 (PDT)
 * Special:Allpages, unfortunately.  ech  elon  21:02, 28 June 2006 (PDT)
 * Are we supposed to mark every page within the article as well (see: Chrono Trigger) or just the introduction/table of contents?  I'm asking because Garrett did every page (as far as I could tell) while Mason did not.--Dukeruckley 08:19, 29 June 2006 (PDT)
 * I'm not sure if we legally have to do more then this, but I think if we change the template to something like "This page, and all subpages of this guide are under GNUFDL...blah blah" then I think that would be better, if we actually can do that. If we absolutly MUST do every page, then we'll do every page. -- Mason11987 (Talk - Contributions) 09:49, 29 June 2006 (PDT)

There are a few suggestions I have, and I'm going to get garret in here to check them out: -- Mason11987 (Talk - Contributions) 22:26, 29 June 2006 (PDT)
 * 1) We should only mark the main guide page, with a note saying all subpages are also under GNU, if this is legally possible AT ALL, it should be done, since you must go through the main page to get to subpages (almost always), I think it would be legit.
 * 2) We should put the single tag at the bottom of the main page, to not distract from the reader, but legally cover our butt. The tag is for almost noone, but still needs to be there, and it should be as minimal as possible.
 * 3) I thought there was another...maybe not...


 * Hm. Well, the problem is that the GFDL really wasn't designed to accommodate for pages as separate as those of a wiki. But yes this is getting silly. I think I'll stop and just do cover pages for now, and if someone whines later we can correct it then. That's the DMCA for ya. :) I'll also suitably amend the template. GarrettTalk 22:36, 29 June 2006 (PDT)

It looks like they are all done, can we do the transition now? That would be best I think, and I'll set up a page for all contributors to offer to release their content into the SWPL. -- Mason11987 (Talk - Contributions) 08:30, 30 June 2006 (PDT)


 * I made that page, and I'll begin spamming talk pages for contributors to the guides that are GNU FDL. I'll simply paste  onto their talk pages, and it should go quickly, feel free to clean up that template while this is going on. -- Mason11987 (Talk - Contributions) 08:46, 30 June 2006 (PDT)

Shortcuts
For some reason the Alt-E shortcut (and some others, perhaps all) to edit a page isn't working, this would be extremly useful if I want to go through and tag some/all guides with the GFDL template, so if someone can figure out how to put that in and get it to work, that'd be great. Thanks! -- Mason11987 (Talk - Contributions) 09:54, 29 June 2006 (PDT)
 * I'll put it on my todo list, but it won't be really high-priority. :-) --DrBob (Talk) 10:14, 29 June 2006 (PDT)

Collaboration of the Month / Guide of the Month
July has come up on us, so would anyone like to suggest a Collaboration of the Month or Guide of the Month for the front page? Our collaboration will probably be related to switching from GFDL to SWPL. As for the guide, I'm not sure. What do you guys think?  ech elon  19:13, 1 July 2006 (PDT)


 * My Half-Life walkthrough =D. As for a collaboration, defitenly the SWPL license. --Antaios 20:26, 1 July 2006 (PDT)


 * The Final Fantasy VII walkthrough seems like a fairly good one as well. It still has a few sections that could use some meat to them and it needs pictures, but it is a decent choice I'd say.  Although, Half-Life might be a better choice because we just had an action-RPG, so a different genre might be a good idea.--Dukeruckley 05:01, 3 July 2006 (PDT)

Rename the license?
I don't like "StrategyWiki Public License", for several reasons. First, "Public" is unnecessary and might make people think there's some connection with the GNU GPL; also including our name is a mistake. As echelon said, "Imagine if all wikis used a single license and it made copying possible between all wikis. Wouldn't that be awesome?" Yes it would, but I can't imagine other sites would be particularly keen on using a license that so openly belongs to another site. Dropping the Public and removing our name from it are primary goals if we want anyone but us to ever use this. GarrettTalk 04:39, 2 July 2006 (PDT)


 * So you'd have it called "License" then? :-P I agree with you here, and I think now is the time to change the name if ever, before it gets too complex. --DrBob (Talk) 04:52, 2 July 2006 (PDT)


 * Guys, check out the suggestions in User:Echelon/Open Media! Leave comments on the talk page there.  ech elon  23:53, 5 July 2006 (PDT)

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)

Image guidelines
I've finished writing the image guidelines and they're up for comment. If you've got any gripes or suggestions (particularly for things I've missed), please mention them on the talk page for the guidelines. --DrBob (Talk) 12:17, 5 July 2006 (PDT)

Control Images
I notice DrBob has been going around putting up the Needcontrols template on a lot of guides lately, with requests for controls for specific systems. As of posting, the only controller buttons are my gamecube buttons and the only page that uses them (to my knowledge) is the Super Smash Bros. Melee guide. The current buttons are fairly generic, save for the C-stick stuff and the gcube/xbox specific button colors. Because they were meant to be generic, I named them as such, like Control-up.png and A-button.png. If there are to be specific images for systems, they need to be renamed.

Another problem with the current implementation is that inserting images everywhere makes the markup look horrendous, even with the Button template. Just look at the markup for Super Smash Bros. Melee/Basics to see what I mean. If possible, there should be a away to insert buttons without generic image markup, i.e. the bold tag or the link markup in wiki markup. I don't know how easy it is to put features like this into MediaWiki, but as this is a strategy guide wiki, it would be good to put directly in the code, to keep page markup easy to understand.

One more thing: is there really a need for keyboard button images, like spacebar, tab, and WASD? If this wiki had svg support, there could be away to replace the text in an svg file with a certain letter or symbol before rendering it, but its still kind of overkill.

Well, those are my thoughts on the controller buttons. the unrendered SVG ps2 buttons are still here, if anyone wants to comment on them. --blendmaster 19:05, 6 July 2006 (PDT)


 * I agree that the png buttons are ugly when littered around the page. One thing that might help is a policy to keep pages platform-agnostic when possible--say "shoot" for instance rather than "hit (triangle button image)", then refer to a rosetta page with all the controls for each platform.  Then again, melee games really do need to list the button sequence.


 * I tried making some buttons with Unicode and CSS at Talk:Grand Theft Auto: San Andreas/Basics/Controls. I thought they looked good except for the ABXY buttons, which of course are kind of important.  DrBob pointed out that not all browsers support Unicode, and how they choose to do so is up to the browser.  That's a good point: If you saw "Hit this sequence of buttons: ? ? ? ? ?" that would be kind of frustrating!


 * Using SVG buttons would be wicked cool. The technology is only slightly less accessible than simple images -- the plugin is easily installable and has been stable since 2001.  We can use alt text in the contents of the embed element, so people who don't have/don't want SVG support can still read the page.   Even better, that alt text is HTML so we can use CSS to style that text however we want (but we should still stay way from exotic unicode glyphs).  That would give two reasonably good renditions of the page probably better looking than the current one, and preserve machine-readability. So I say go for it.


 * In terms of aesthetics, I think it's important that buttons be styled to go with the main page text. If you look at a BradyGames guide you will see that that the buttons with letters use the same font as the text, just bold.  Using different fonts tends to jar the eye a little bit. Sympleko 06:19, 7 July 2006 (PDT)


 * I can't see any problem with the PNG buttons or the markup: once sections like that are written, they're unlikely to be changed, and so it shouldn't be much of a trouble. I'm against moving controls to disambiguation pages for each platform for each game, because that means users would have to follow another link to get to what they probably want to find, which slows everything down. I'm also against new markup for buttons, as it makes upgrading MediaWiki hell due to the hassle of porting all the modifications, then fixing the bugs.
 * I'm all for SVG images. MediaWiki will automatically rasterise them to PNG unless the user has set SVG to be displayed natively in their browser, so that's OK. Using the same font as the text is fine, as it's all the same anyway (and anybody who decides to make another header template containing a custom, stylised page title will be shot). I agree that the control images should be differentiated by platform and renamed; they're not widely used yet anyway, so it won't be much of a hassle to rename them all. --DrBob (Talk) 09:18, 7 July 2006 (PDT)


 * I'm in full agreement with DrBob. I think SVG images would be a neat idea, but I don't see much of a problem with the current PNG images.  I also think that controls need to be game specific and named as such in order to create a consistent convention for when new game systems come out.  In the case of Playstation and Playstation 2 (and a few others), an exception can be made because it is the same controller (except for the addition of the analogs).--Dukeruckley 09:50, 7 July 2006 (PDT)


 * If nobody else objects, this should go ahead. Dukeruckley, do you want to handle it? :-) --DrBob (Talk) 10:16, 7 July 2006 (PDT)


 * Personally I'd prefer typing in somthing like .:left-smash:. (embedded) instead of [[Image:Gamecube-Control-Left-Smash.png||left]]  (generic), but since I'm not a great coder, I can't have much say in whether an embedded button markup is implemented or not. On SVG vs. PNG, svg images are a lot smaller(in file size), and are better at scaling to different sizes, if say the main control page had big button images, and all other pages had smaller button images. On using the same font as the text, I convert all the text in my buttons to paths, just because different SVG renderers use different default fonts, which makes the buttons look worse.
 * One thing no one talked about was the keyboard button images. Are they really neccessary? Well, I guess I'll get started on xbox and other console buttons. I'll can upload the gamecube and ps* buttons whenever the naming scheme is set. --blendmaster 16:30, 7 July 2006 (PDT)


 * I've said already that custom wikimarkup for buttons is not feasible. It makes MediaWiki upgrades a real pain. Honestly. Keyboard images would look nice, and make pages look interesting, but they wouldn't really add much. I'm sitting on the fence about them, really. As for the naming scheme, just use the initials of the system (e.g. "GC", "PS", "DC", "GB", etc.), then an underscore, then the name of the button/stick movement: e.g. "gc_a.png". Make sure to put them in the controller buttons category. --DrBob (Talk) 17:09, 7 July 2006 (PDT)


 * Well, then, now I just have to wait for SVG support in this wiki, as SVG is still a "not a recommended format". I do have another idea for naming the buttons. If they were named fairly verbosely, as in Gamecube-Control-Left.svg instead of gc_left.svg, but there was a template called then you could add buttons to a page with somthing like  or PS X, while the button images have nicer names. --blendmaster 13:31, 8 July 2006 (PDT)


 * For the disambiguation of controls on a single per-guide page, I still think that following another link when you don't know the button attached to the verb (people reading the guide will have at least had some experience with the game on their platform already) is less frustrating than having to translate button names from one platform to another. And as pages grow organically, you definitely don't want button names from different platforms on the same page.  So to keep the guides clean it seems like the choices are to either list all the platform controls wherever one of them appears (as in "hit A, or ×, or NUM0, or...") or aim to keep them all in one place.  Maybe policy is too strong, but it sounds like a good guideline to me. Sympleko 09:18, 9 July 2006 (CDT)


 * What some guides are doing (which is good) is to have subheadings for each system on the controls page, and listing the system-specific buttons that way. However, for games with too many controls (or fighting games with many hundreds of different moves attached to combinations of buttons), the best way to do it would be to list alternatives for different systems in-situ. --DrBob (Talk) 11:38, 9 July 2006 (CDT)


 * I agree on both. I think Grand Theft Auto: San Andreas/Basics/Controls and Super Smash Bros. Melee/Basics are good practice, each for their type of game. Sympleko 12:04, 9 July 2006 (CDT)

Is what we're writing here going to stay?
Should we bother updating SW while it's being moved? Are things recorded at the temporary location going to make it onto the new server? (Or are we already on the new server, just under an assumed name?) Sympleko 11:28, 9 July 2006 (CDT)


 * This is the new server, but as noted on the old server, there are some inconsistencies in the copy, thus there is the distinct possibility of everything having to be overwritten. What I would say is that if you want to do some editing, download the source of the article you want to edit, save it as a text file and edit it on your home computer. Once we've got everything sorted and give the go-ahead, feel free to upload it. :-) Personally, the only edits I'm doing at the moment are to test my bot; such edits can easily be re-done if we have to scrap the data. --DrBob (Talk) 11:34, 9 July 2006 (CDT)


 * Yes, actually. I think this is going to stay. :)  ech elon  04:04, 10 July 2006 (CDT)