From StrategyWiki, the free strategy guide and walkthrough wiki

Shortcut:
SW:SL
SW:STAFF

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: --~~~~)

Contents 1 Control table styles 2 Collapsible infobox 3 Community Meeting 4 Message templates 5 alphabetTOC JavaScript

[edit] Control table styles

First section archived: Part 1

Update: Surprisingly, no one has really said we shouldn't move away header cells, so it seems that Wanderer's proposal has been accepted by consensus. What remains to be worked out are styling issues with the new table format. To boil down the above discussion, the two primary style proposals are:

1. Controls column(s) center-aligned (not sure if bolded was wanted as well), explanatory text column(s) left-aligned
2. All columns left-aligned.

I'm assuming everyone's fine with keeping controls on the left, explanatory columns on the right and using a header row, as no one has mentioned changing those aspects. The style would already have been decided, except for a disagreement between the aesthetics of center-aligning controls and the ease of creating the table. Please voice your opinions, thanks. — najzere^T 20:34, 17 October 2009 (UTC)

Since the controls columns are mostly images anyway, I don't think the bolding really matters. Wanderer 00:08, 19 October 2009 (UTC)

I agree. I prefer them center-aligned, but could care less about the bolding. It would be nice if we could put together something that would make the wiki code cleaner, though. --~Vizeroth · (c)~-- 22:27, 19 October 2009 (UTC)

I suppose Skizzerz's idea of making a template and CSS classes for it could work, and it would let us change the styling rules later if we wanted to. But I see no reliable way to apply the different styling rules to the description columns without putting a class attribute on each description cell. Even if the last-child selector were sufficiently well-supported, we'd run into problems with tables that have multiple description columns (example) and possibly ones where the description cells cross rows (example). Maybe a second template could be made for description cells to add the class attribute? Wanderer 03:45, 22 October 2009 (UTC)

I wish someone besides myself and Wanderer would opine on whether it's worth the hassle to have center-aligned control images. Speaking as the person who will be fixing all these complicated tables new users attempt to make, it's in my own personal best interest to keep things simple, which, by the way, is a pervasive maxim in nearly ever endeavor existant. — najzere^T 06:40, 22 October 2009 (UTC)

I still don't think this is an issue. I think the standardization for SW is an issue. I see no value in following "Web standards." No casual reader is going to care what the tables look like or how they are centered as long as they can read it. --Notmyhandle (talk • contribs) 06:03, 24 October 2009 (UTC)

So that's currently two votes for centering (Vizeroth and myself), one vote for left-aligning (Najzere), and one vote for "I don't care" (Notmyhandle). Anybody else? Wanderer 18:06, 24 October 2009 (UTC)

I think by changing things we are making things worse. If we have to choose, then I choose left align. Left align requires no formatting, right? --Notmyhandle (talk • contribs) 18:56, 24 October 2009 (UTC)

I think using templates would allow the necessary formatting rules to be applied without that much work on the editor's part. Something like {{yes}} or {{n/a}} could do the trick. It really wouldn't be as difficult as Najzere seems to make it out to be; a bot could probably do it. Wanderer 19:34, 24 October 2009 (UTC)

A bot would help in fixing existing tables, but it won't stop problems with all the future controls tables. No matter which style is decided on, we'll have to spend a lot of time updating all the existing tables, so that's not a concern of mine. From my experience with new users' edits, many of them know how make a standard wiki-table, perhaps from editing Wikipedia or Wikia, or maybe from clicking the "insert a table" icon. Even with our current guideline of making controls header cells and descriptions data cells, we still have to do a lot of cleanup – and that only requires an exclamation mark and putting descriptions on a separate line. Anything more complicated than that will just create more cleanup work and less people will be able to correctly create a standard guide element. Beyond the work to clean up the controls pages, this would also require more talk page discussions as we try to teach our control table methods. I still feel that the costs outweigh the meager benefits (if any). — najzere^T 18:13, 28 October 2009 (UTC)

I've created a couple of templates ({{Controlstable}} and {{L}}) for this purpose and set up a demo to show how this could work (see User:Wanderer/Sandbox). It's very simple, easy to use, and seems to work well. Currently the templates apply the styles inline, but they could be modified to use class attributes instead if we wanted to put the style rules in a style sheet. Wanderer 19:09, 29 October 2009 (UTC)

Update: We need more voices on what control tables will look like. Thanks. — najzere^T 07:39, 4 November 2009 (UTC)

[edit] Collapsible infobox

Here is a mockup: User:Najzere/Sandbox#collapsible infobox. It came up in a different discussion that some of the fields in the infobox can become quite long, and collapsing them was mentioned. I've seen this used on Wikipedia, but I can never seem to find a usage of it when I want one. The current WP infobox doesn't seem to have the ability to collapse individual fields, but rather one big parameter to collapse the entire infobox down to the image and title.

If this functionality is deemed useful, I see two ways to incorporate it: either as part of the {{infobox}} template or as a separate template of its own, to be used within infobox parameters. The former method would be very complicated in an already complicated template, so I would recommend a separate template to handle this. The title could be decided on once, e.g. "Click link to expand", or it could be left up to the user, if there's a benefit to that.

Another option would be to use WP's whole-infobox collapsing, perhaps even by default, so main pages would just have the title and box art. Some additional parameters that would be good to leave out of collapsing might be the preceded by, followed by and series parameters. Anyway, I'm interested to see what people think of this, as finding a way to shorten lengthy infoboxes would make a lot of guide main pages look cleaner. — najzere^T 19:49, 19 October 2009 (UTC)

I like the general idea, but I'm somewhat in favour of the WP method. I figure most of the information will be looked at once (if even), and then never again. I think the most important ones to make unhideable would be expansion packs and series. After that would be preceded/followed by, but with the series link, I don't think those are that necessary. -- Prod (Talk) 05:31, 20 October 2009 (UTC)

I actually prefer the whole-infobox collapse as well, but didn't think such a radical change would meet with much enthusiasm. Also, as you say, with the series parameter, preceded by and followed by aren't all that necessary as non-hideable fields. — najzere^T 07:10, 20 October 2009 (UTC)

My only real issue with hiding is that we lose the "many eyes" benefit of the open content. If nobody sees the mistakes, nobody corrects it. Based on that, I'd say we're probably a bit too early to implement that. I'm sure we've got more infoboxes <100% accurate than infoboxes that are 100% accurate. -- Prod (Talk) 05:04, 22 October 2009 (UTC)

Naj, those are both great alternatives. There's also the issue Prod brought up. Perhaps we should start a SW todo list to keep track of future implementations. I feel that if and when we choose to implement this, this sort of thing should be a part of user preferences, as it affects the standardized view. We're used to large ToC's that are of relatively the same length; for instance when we set up the main page layout standard, ToC length was ignored because we had maybe 1 or 2 super large infoboxes (i.e. it wasn't apparent at the time that we would need to deal with it). --Notmyhandle (talk • contribs) 05:44, 22 October 2009 (UTC)

@Prod: Every edit gets patrolled, so if they haven't been fixed by now, it's going to take a long time (by this I mean years) before a random user comes around who can fix it. In the meantime we're not implementing something which at least the three of us deem useful. Personally, I don't see much benefit to waiting. Having looked at every edit to the wiki for at least the last six months, I don't think I can recall even one infobox fix from a non-admin to an existing guide main page. 'Course, that's not very scientific. :P

@NMH: User preference would be ideal, if harder to implement. I'm sure Prod or Skizzerz could come up with a way to do it though.

— najzere^T 06:40, 22 October 2009 (UTC)

If we hide it, that random user will never come along. Patrolling the edits for vandalism is one thing, but correcting minor inaccuracies is quite another. Can you link to an example of this infobox hiding somewhere? -- Prod (Talk) 14:18, 22 October 2009 (UTC)

collapsible=yes search string reveals many. For illustration purposes I'd say by leaving infobox open, you'd improve your odds of a random person fixing it from 1/1,000,001 to 1/1,000,000. The only people who change infoboxes are people who contribute to the guide, and if they're interested in checking the main page for accuracy, I don't think a show/hide link is gonna stop 'em. — najzere^T 15:24, 22 October 2009 (UTC)

That's a good point. Random contributors cannot be relied upon to fix infoboxes. I like the collapsible elements, particularly for multi-line entries such as the Release Dates and System requirements (as Naj simplified in the first example). I don't like the third example as much because a lot of the quickness of the infobox is lost; people browsing the site, even myself, will not be aware of all of the possible data on the page. Collapsing only a select few boxes is useful, as it cuts down on whitespace, but tells people that there is something there. However, I don't think we will have a problem if we implement either form of this; people learn. --Notmyhandle (talk • contribs) 15:59, 22 October 2009 (UTC)

Figured I should mention this, but we're on a wiki, where random contributors are expected to fix everything. -- Prod (Talk)

I think that's an overstatement. We should imagine contributors as fellow guide writers, not grammar checking robots. We should be considering contributors as people interested in the games they play, without concern for this site as a whole. Most of the people who come to this site have no idea what we're about, just what we have available. I think Najzere shares my view that editors typically only edit things on the main page if they care about the guide that's on SW. It's like, if a reader comes and views a page for information, the majority of them won't help with the page or the guide as a whole, they will just move on when they have received the information or find that its not sufficient. The others, the ones that edit, are either too shy or whatever to invest in the guide (e.g. the random anonymous spelling fixes) or feel like its worth contributing to. We should be focused on those that find us worth contributing to. These are the people like us who continue to focus our efforts to improving things on a massive scale. By relying on the "random contributors" we are just being lazy. --Notmyhandle (talk • contribs) 06:00, 24 October 2009 (UTC)

Update: This use on Wikipedia is most often accomplished with collapsible list. It is used on thousands of articles, such as on Sam & Max. For collapsibility in general, the series templates at the bottom of many articles are all collapsible, and many are collapsed by default. For us, while the full infobox collapse might be a bit much, a simpler one like collapsible list might be good and would serve the original intention, which was to shorten overly-long fields. — najzere^T 07:39, 4 November 2009 (UTC)

Again, I agree that we should start using this for select entries on the infobox. On the topic of collapsible series templates, I think we should enable the ability to do this, but reserve it to large ones like {{Hokuto no Ken}}. --Notmyhandle (talk • contribs) 04:07, 5 November 2009 (UTC)

I think our series navs are fine as is, since they're at the bottom out of the way. For Hokuto no Ken, I think there's a different problem, as even if you expanded it from being collapsed, I'm not sure how usable it would be. I had the same problem with {{Dungeons & Dragons}}, and I just made as many sub-series as I could to condense it. Someone more knowledgeable (or who wants to spend more time on it) might be able to organize huge series navs like these ones in a meaningful way. {{Final Fantasy}} looks good to me and {{Batman}} or {{Naruto: Clash of Ninja}} might be reasonable ways to split long-lasting series up too. — najzere^T 06:00, 5 November 2009 (UTC)

Update: I imported that collapsible list template from Wikipedia, as it might come in handy elsewhere besides just the infobox. The sandbox example has been updated to use it. It's pretty easy to use, just wrap any existing content with the template (only needs the first parameter) and add a title parameter and you're all set. The default settings seem to look good in the infobox as it is, and custom ones could easily be #switch'd out if there's ever some other place we want to use this a lot. — najzere^T 21:10, 17 November 2009 (UTC)

[edit] Community Meeting

There will be a community meeting a week from tomorrow. Although it's already going to be a fun filled meeting, please add comments on any other (preferably minor) topics you would like brought up. -- Prod (Talk) 21:49, 30 October 2009 (UTC)

Is this replacing November's meeting? — najzere^T 21:57, 30 October 2009 (UTC)

Good catch, apparently I can't tell the date anymore. -- Prod (Talk) 23:52, 30 October 2009 (UTC)

I don't have my forum or IRC passwords at the moment, so I am unable to comment on the thread, nor will I be able to easily verify my identity when I show up on IRC. I am planning on being at this meeting. --Notmyhandle (talk • contribs) 00:32, 31 October 2009 (UTC)

It's today, don't forget. — najzere^T 18:19, 7 November 2009 (UTC)

[edit] Message templates

In our last meeting, we agreed that less pushy talk page messages were in order, specifically with regards to {{consolidate}}. Category talk:Message templates has been set up to work on these templates, so feel free to lend a hand fixing them up. Please indicate here whether any or all of them are ready to be changed out, so we know which ones we have a consensus on and which ones still need work. Thanks, — najzere^T 19:06, 9 November 2009 (UTC)

[edit] alphabetTOC JavaScript

This is a proposed addition to MediaWiki:Common.js of a JavaScript function that de-links the letters in {{alphabetTOC}} if no corresponding section is on the page. Currently, pages using this template either have linked letters that don't do anything when you click them (E, J, N, Q, U, V, X), or dummy section headings (J, Q, V, X, Z) are included in the page to get you close to where you're going. This has come up before in various conversations I've had, so I don't think I'm the only one interested in this. Anyway, the code (alphabet_links() at the bottom) has been reviewed for errors by Skizzerz, so it just remains to decide if it's worthwhile for any random user to have this functionality. For non-technical types (can't think of any admin this applies to, but whatever), the function only executes on pages that contain the template and requires no additional changes to the template itself, so anyone with JS off would just see the normal everything-is-linked ToC. — najzere^T 22:28, 9 November 2009 (UTC)

I think this is a useful, and needed, addition. Of course, I don't have much of use to add to the conversation ;p --~Vizeroth · (c)~-- 21:45, 15 November 2009 (UTC)

Same. I also think it would improve the template. --Notmyhandle (talk • contribs) 04:52, 16 November 2009 (UTC)

Unavailable letters being inactive is the expected behaviour for alphabetical navigation so it makes sense to implement this. Garrett^Talk 09:28, 16 November 2009 (UTC)

Well, I think my opinion on this is also obvious, and I think the general consensus is that you should go ahead and implement it. --Skizzerz 08:47, 17 November 2009 (UTC)