StrategyWiki:Staff lounge

__NEWSECTIONLINK__

Welcome to all users! This page is where people can ask StrategyWiki-related questions to the staff and senior community figures, and they will do their best to answer. If you want to raise a topic for discussion (rather than just ask about it), please use community issues instead. New issues are entered here, with the most recent at the bottom of the page. If your question does not pertain to editing StrategyWiki (i.e. asking for hints or game-specific information), please ask on the guide's talk page or on the forums.

Please review the Table of Contents to see if your issue has already been raised; also check the archives (to the right) in case it was discussed some time ago.

To facilitate ease of browsing and replying, please:
 * 1) Place your question at the bottom of the list
 * 2) Title the question (by placing the title between equals signs: ==title==)
 * 3) Sign your name and date (by adding two hyphens and four tildes: --~ )

Main page templates
Above are suggestions for cleaning up and making some of these templates more useful. Please add your opinions and ideas. The only one that may not be very straightforward is the change to sys. This is helpful in circumstances where the redirect is getting the system category, but there's some information you want to put in the main page's infobox. This may be a usage issue rather than anything lacking in the template. I know I've created mock "sys" divs in the infobox before, but I can't think of any examples at the moment. — najzere T 21:46, 1 October 2009 (UTC)
 * 1) infobox: Get rid of some parameters.
 * 2) *japanese: redundant, should be in the main writeup in the nihongo template
 * 3) *distributor: who cares, rarely used
 * 4) *media: noted elsewhere, rarely used correctly
 * 5) *input: noted elsewhere, rarely used correctly
 * sys: Add a parameter to not include the category, or to go even further, make a new template that just has the formatting so you can specify your own system name and icon.
 * co: Add a parameter for alternate link text.
 * I only have a strong opinion about the japanese parameter. While I agree that, in some cases, it can be redundant, it isn't always.  For example, it would be a little strange to nihongo something like "Donkey Kong" or "Super Mario Bros." because they're not Japanese names.  Yet, having the katakana in the infobox is a handy way to have something to copy/paste into Google if you wanted to see what searching in Japanese would reveal.  For me personally, this is a handy research tool, and I would hate to see it leave.  Since it's an optional parameter, if it doesn't get filled then it doesn't get filled.  But I would argue that it has a useful purpose, even if not always 100% of the time.   Pro  cyon  00:22, 3 October 2009 (UTC)
 * We might as well leave the others in, considering the future scope of SW. -- 00:48, 3 October 2009 (UTC)
 * @Procyon: Donkey Kong (ドンキーコング) looks strange? That's how I've always seen the template used, as a way to get that "?" link at the end of the Japanese. For the japanese parameter, I'm suggesting moving it out to the main body if it's not there already, so it would still be usable for searching (I use it all the time too, I definitely don't want to see the Japanese go). I always wondered why, if the japanese parameter is there, there's no "european" parameter, as there are tons of games that have an alternate PAL name. Those work just fine noted in bold in the writeup as well.
 * @Notmyhandle: Do you mean the inclusion of non-commercial and/or non-notable games? Could you elaborate on how the other parameters will be used?
 * — najzere T 06:33, 3 October 2009 (UTC)
 * I wouldn't mind seeing the |japanese go, as long as the information wasn't lost. Just because |distributor is rarely used, doesn't mean we should get rid of it.  If the information is found, include it.  How are media and input noted elsewhere?.  I don't understand your reasoning for changing sys and co.  Additionally it's too complex and widely used to complicate and increase the load on the servers. -- Prod (Talk) 15:09, 3 October 2009 (UTC)
 * The distributor has no impact or say so in the development of game, they're just a glorified middleman, so I'm not sure why anyone ever thought a field for a purely business-related item would be relevant, except that our infobox seems to be modeled heavily after WP's (meaning encyclopedic). For media and input, they're being used to show highly obvious and redundant material, such as Nintendo 64 games play on cartridges, or Windows games use keyboards. I can't even think of why we need a media field – is there a system that doesn't just play its own standard media? Input is useful if used correctly, when the input is non-standard, like when a game uses a floor dance pad or something, but it's mainly being used to display the standard controllers, or even worse, a list of all types of input that work with the game. By and large these two fields mirror what's found on the game's WP page, but I think WP's approach to articles is different than ours. The problem with all these extra parameters is that people want to fill them. We don't include them in the preload, so it's not like we want them to do that. Especially when they're mostly used incorrectly, as with media and input.


 * I remembered why I needed the formatting from sys: when a game has an alternate name/release on PC, the redirect gets categorized, but the pc requirements are found on the main page. If sys is needed in the requirements field, it will erroneously categorize the main page with the system category. Also concerning the requirements field, I've seen the formatting mocked up so we could distinguish between Windows Vista and XP, for example.


 * The co template I thought was pretty obvious and didn't expect to find any opposition to it. As it stands you have to put in the full category name, so in the case that a category link redirects to a category with a different name (e.g. Psygnosis), you wouldn't be able to put the name of the developer at the time at which the game was developed. Of less importance, you also can't use it to shorten the link name (e.g. SCE) or use an alternate name (e.g. Bally Midway). In short, there's no way to use our helpful category redirects.


 * About the server load, I'd hate to see that reasoning become an excuse not to clean things up and make the site better. Can the job queue be controlled in any way? Such as allowing the servers to perform certain tasks at designated times? I know that during the week in the middle of the day (PST), there aren't a whole lot of edits being made, though what that says about viewership, I don't know. — najzere T 16:01, 3 October 2009 (UTC)


 * We would probably just make the changes at night, or lock the database while it's working. My previous comment was referring to the possible domain changes and non-game information inclusion (i.e. "encyclopedic"). However, I'm not educated/aware of the current status of the discussions among the management involved in this endeavor.


 * The main issue with the japanese parameter, as previously stated by Naj, has always been about "why japanese and not other countries?" Pages will be fine if we remove it, and if we change it to include other regionalizations, that works just as well. It comes down to how we want to standardize our pages. Should we make the infobox lengthy and inclusive? I always prefer the infobox to hold as much information as possible, because the infobox is concise and makes it so you don't have to skim an article for quick facts. At the same time I can see how lengthy infoboxes create excess white space, so there's that aestheticism to be concerned about. -- 23:03, 3 October 2009 (UTC)
 * As I was working on this page earlier today, I was thinking that we could use expandable fields in the infobox for excessively long stuff like multi-system, multi-country release dates and huge PC requirements. I know I've seen that on some of WP's video game infoboxes, and I think it looks pretty sleek. — najzere T 23:28, 3 October 2009 (UTC)
 * I would rather not remove media, because there is a lot more useful information that can be included there, especially for PCs (I don't have a blu-ray drive or a floppy drive). Just because it's included on WP, doesn't mean we shouldn't have it here as well.  Input is somewhat redundant to our own Controls pages, so it's only true purpose is as a summary, which doesn't seem that useful.  I don't remember any of the games that have a distributor listed, what companies usually show up there?
 * Your issue with sys I believe brings up a deeper problem, that we don't really have a proper standard to tell when to use a redirect with categories vs. a shared main page (like Pokemon Yellow). The co issues that you bring up will affect any company where they changed the name, without being bought out.  However, the template is already fairly complex, and it's usage would need to be made even more complex to support alt-text.  How many companies are affected by this? -- Prod (Talk) 23:44, 3 October 2009 (UTC)
 * This reminded me of the issue with company categories and names. Because older games use the archaic versions of company names, I have a feeling that sometimes we have changed the links on a page to reflect the newer versions of a company's name. I can't think of an example page, but I don't agree with this method of displaying information (if it's not on the packaging/in game, our pages should not include present day information/references because it does not present it in a factual, historically accurate way; redirects and excluded ). -- 00:13, 4 October 2009 (UTC)
 * @Prod: If you say a field is useful, then that's all I wanted to know. I was just listing ones I don't find to be of any use. As for distributors, they're usually publishers as well if they're big enough (Nintendo, Sega, Midway, etc.), in which case they'd be listed twice in the infobox. The difference from the other things we note, is that you can go to the developer or publisher category and reasonably expect to find other games you might like (although not so much for huge publishers). For distributors, it's just business, they have no influence over the game's development (unless they're the publisher as well), and they'd be just as happy to ship Princess Maker games as Diablo games. For sys, you're right there are other issue to think about which might help the situation. For co, it didn't appear to be very complicated to me. I think we can get away with just putting  |  in the category link.
 * @Notmyhandle: Totally agree. It's best to have the name of the company that's on the box, rather than the third or fourth copmany down the line that's currently owning their name. — najzere T 01:34, 4 October 2009 (UTC)

Control table styles
Here's an issue I once brought up on the forums, which didn't seem to get much attention there.

Currently, the common format for control tables is to make the control cells center-aligned and the description cells left-aligned. I'm wondering, what should be the preferred way to go about this? There are two methods of applying such formatting:


 * 1) Set all the control cells as header cells (TH elements) instead of regular cells (TD elements). (Example) This is the method used in the example in StrategyWiki:Guide.
 * 2) Set the "|text center=1" option on prettytable, then set an "align='left'|" or "style='text-align: left'|" option on all the description cells. (Example) This is how I usually do it.

The example in the guide uses the first method, which implies (but never explicitly states) this method to be a guideline. However, there is a problem with this method. For compatibility and accessibility reasons, Web standards recommend keeping content separate from presentation, and using header elements for cells that actually contain data instead of headers breaks that rule. How the control information can be defined as "headers" is beyond me. Making the control images center-aligned and the text left-aligned is a presentational attribute and should not be implemented through semantic markup. Unless there is a valid reason to classify the control images as "header cells" (and "It's easier" doesn't count), the second method works better from a functional perspective. Yet the guide seemingly recommends the first method.

I see three possible courses of action:


 * 1) Leave the guide unchanged, and enforce usage of the first method.
 * 2) Change the guide to recommend, or at least allow, the second method, then optionally enforce that instead.
 * 3) Disregard the whole thing and leave the matter up to the individual editor's preference.

What say you all? Wanderer 02:04, 6 October 2009 (UTC)
 * Anything but number three. I prefer not to use header cells for the controls, but I don't know why we need to center-align them anyway. If we make a change, I'd be for using the plain prettytable with no embellishments and having the whole table left-aligned except for the header row. The major concern with changing something like this fixing all the ones that are currently using the style outlined in the guide. If everyone thinks it's worth changing every control table to match a new style, then I'm for a non-header cell format. If it's not worth the work, then I'm fine staying with the current guideline. Whatever the outcome, our controls table style should be uniform, not used at the editor's discretion. — najzere T 03:05, 6 October 2009 (UTC)
 * We could make a new template like prettytable meant to go on top of control tables. This template could employ CSS that automatically bolds all cells and center-aligns them, and then unbolds and left-aligns the description cell. -- 04:59, 6 October 2009 (UTC)
 * That would still require putting a class attribute on each of the description cells, though. Wanderer 05:51, 6 October 2009 (UTC)
 * Method #1 was not initiated on a web standard train of thought, but rather it was a simple solution to center the text and exclude the use of css/html in the page's code. Now, this may or may not be the best course of action, but I haven't seen any issues with it in Internet Explorer, Firefox, or Google Chrome. -- 16:07, 6 October 2009 (UTC)
 * @Wanderer: no it wouldn't. We could use the tr:last-child pseudo-selector to get the last element. It doesn't work on older browsers (IE6, Safari 3, etc.), but nobody cares about them anyway. -- 00:23, 7 October 2009 (UTC)
 * That's been reported not to work in even IE8. Wanderer 01:12, 7 October 2009 (UTC)