Well if SC1 and SC2 can coexist in the wiki peacefully, without it making the wiki ugly, I'll agree with it.
But let's say we have two articles with relatively the same name. What then? It defaults to the SC2 article and just links to the SC1 ('if you were looking for the sc1 article on insert article theme here, click here')?

Wiki code updated, hopefully now everyone can sign in.

I actually liked how the Mass Effect wiki solved the problem: Each page contained the ME1 stuff first and after a bit of scrolling the ME2 infos were listed.
So you could link to the SC2 part of the page or reverse the order and link to the SC1 part.

I support Nude's suggestion, with an addition... If two similarly-named entities are so different between SC1 and SC2 that they can't share an article, then they can be renamed to "Foobar (SCI)" and "Foobar (SCII)", etc.. Hatnotes (italicized indented short notes at the top of an article) can be added to both. (:''For the StarCraft II version of Foobar, see [[Foobar (SCII)]].'')

I would prefer it if the wiki portal page had two options, much as Nibbits has for the main site. From there, you could go to either the SC1 or SC2 main page.

Splitting the two games into their own section seams to be the only logical pick. It would save someone time, instead of accidentally going through SC1 articles looking for SC2 information and such.

Well, we could always try a test case.

I took the liberty of transferring the old-wiki article on terrain to [http://www.staredit.net/wiki/index.php/Terrain Terrain] on the new wiki. I added room for an SCII section. I'm thinking that if IP okays it, we can just add SCII info to that section, and if the article ends up being unmanageably large, then we separate everything. Otherwise, we can decide on a case-by-case basis.

On a side note, we can't upload images. MediaWiki blocks IMG tags (to hinder Goatse-related vandalism), so until this is changed, we can't have images in articles. Like, at all. Not even inline non-resized pics. Major issue for things like the SC1 extended terrain section in the previously-mentioned article.

Nice, someone took initiative ^_^
We can certainly see how it plays out.

I enabled uploads for images and I also made wiki use short urls (hopefully I didn't break anything).

I might try skinning it pretty soon.

Attempting to upload yields an error.

Try now.

Works perfectly. Thanks.

How would I separate the wikis unless I make an entire new separate wiki for each game?
Maybe SC1 articles should just be prefixed with "Starcraft I" and anything that ends up similar, gets a disambiguation link.

That might not be necessary.

If something exists only for SC1, and there are no similarly-named entities in SCII, then leave the title as-is. (Example: "Death Counters" would remain "Death Counters". Actually, it'd be "Death counters".) If you wish to have two separate articles for an entity that exists in both games, you could name them "Terran Command Center (StarCraft)" and "Terran Command Center (StarCraft II)", and have them link to each other using hatnotes.

BTW I'd recommend installing these MediaWiki extensions.

• Cite allows the use of REF and REFERENCES tags, which can be used for both inline citations and endnotes.
  
• ParserFunctions gives templates the ability to do some logical computations. Very useful.
  

I'd also recommend that we all:

• Adopt a wiki-wide Manual of Style. Wikipedia's is a good start.
  
• Decide on organization. (E.x. will we have one article for every unit?)
  
• Create infoboxes and standard formats for article types (units, etc.). (I can handle this.)
  

Well, I won't be doing anything in this wiki then. Wiki formatting has no structure, so it's impossible to know which symbols do what unless you have a reference side-by-side. It also formats text whenever it comes across any non-alphanumeric character, which is obviously a problem.

You might want on the front page two pictures, one for SC and one for SC2. Then inside each would be another home looking page with common articles such as Ammo systems, or trigger concepts.

As for SC1 articles, just putting StarCraft I in the title would probably be a fine filter, considering everything else is for SC2

Edit: And now I dont have a login anymore and the previous error has returned.

Post has been edited 1 time(s), last time on Apr 26 2010, 1:05 am by Dark_Marine.

Dark, what is the error? I had to restart the wiki because I actually installed it to the wrong database (thus it wasn't finding the users it should, it was using like 2 year old member's table).

I agree, Starcraft I in all the titles of starcraft articles, we'll link it nicely enough to suffice. It's settled.

The wiki says my name does not exist when I had registered once, and the old error where you would register and it told you there was an error (Stated earlier in this thread, im too lazy to go find it).



Theres a screenshot.

I've taken the liberty of creating the wiki's community portal, which was tentatively modeled after Wikipedia's. If we ever get to the point where multiple wiki-specific projects (e.x. implementing a MoS, updating articles to fit it, etc.) need to be concurrently discussed, we can use the portal's task list (once we decide how we're gonna implement that).

What exactly would you use parser functions for? I fail to see the use in a static content environment.


Dark, pm me your sen pass please? I need it for testing.

Infoboxes with optional rows is the very first thing that comes to mind, though that particular use would only be applicable if we had infoboxes for specific types of entities, e.x. units.

Consider, for example, an infobox for SC1 units. We may have a field for subunit type and capacity for units like Carriers and Reavers, but because this field doesn't apply to all units, it'd be best if we had some way to hide it. The #if ParserFunction grants this functionality: if the field is left undefined when the (presently hypothetical) template is called, then the row would not be displayed.

Along a similar vein, we could have an "Evolves from" field for Zerg units only; a "Morphs into" field for units that can change form (be they Zerg Drones or even the two types of Terran Siege Tank); a "Unit capacity" field for both transport units and buildings like Terran Bunkers; etc., and these fields would only ever be shown on the infoboxes for the specific units they apply to.

The #ifeq function has similar uses. Again using the example of a unit infobox, we could display different supply icons based on the race. #ifexist could be used to detect if a specified unit portrait exists, and display a placeholder image if it does not.^[1]

Oh, and I meant to link to the ParserFunctions extension, not to the list of all parser function extensions.

---

^[1] If we really wanna go overboard, we could even do this inside of the infobox, for unit portraits:

This would take the title of the current page (using the PAGENAME magic word), use that to generate a filename (such as File:SC1 Unit Portraits - Terran Command Center.png), and check if that file has been uploaded to the wiki. If not, it would output a placeholder image (File:SC1 Unit Portraits - Missing.png). The effect would be that we wouldn't need to specify the location of a unit portrait -- it would be automatically included. This is, of course, assuming that all unit portraits adhere to the naming convention "File:SC1 Unit Portraits - <name>.png".)

We totally don't have to do that, but it's a good demonstration of some of the lower-level things you can do with templates and ParserFunctions.

Post has been edited 1 time(s), last time on Apr 27 2010, 11:02 pm by DavidJCobb. Reason: Fixed page stretching