Kairosoft Wiki
Register
Advertisement

This is a style manual for editors of the Kairosoft Wiki, to allow users to use the same style.

When using a Wiki with many different active contributors, articles can inevitably be written in many different ways. To help prevent arguments about how the wiki should be run, these guidelines have been devised to help keep things organized and inform Wiki contributors on how to layout certain things.

For details on page layout for new games, see: Project:New game

Basics[]

  • Use headings for new topics, so they can be linked to easily, as well as splitting content in a consistent format.
  • Do not copy information from other websites.
  • NPOV - All information on articles should be "neutral" (should not contain words like "I", "my", or "we").
  • This is an English wiki.
  • This wiki formats numbers using commas for a thousands separator, and periods for a decimal point.

Writing[]

It is generally safe to follow style guidelines as outline by Wikipedia's Manual of Style.

CSS vs HTML attribute[]

Whenever possible, CSS should be used in place of HTML attributes, as CSS is more future-proof (more likely to still work in 10-20 years in all browsers), and CSS is also more flexible, allowing it to be overwritten with a CSS class if need be. It's also easier to add multiple css styles on a single element than it is to add multiple HTML attributes.

Also, in many common cases, the HTML attribute is depreciated (thus the previously mentioned future-proofing). An example is the align attribute (some disadvantages of using align explained: link).

Tables[]

Many tables have similar columns, and as such, they should be formatted a specific way to keep them consistent across the wiki.

  • Name - This column may be labeled something other than "name" (ex: Company, Skill, Item, etc), but it should always be the first column unless there is an "order" column (a unique sequential list). This column should have the text left-aligned, and as this column contains the data's "unique identifier", it should never be blank.
  • Unlocks / Unlock (Unlock Condition) - Should be the right side of the table. The only columns that should be to the right of the Unlock Column (if applicable) should be: Description, Notes, and Name Reference.

Table Order[]

The order of a table is also important. While tables can be made sortable for the desktop (see below), this isn't true for mobile, so it's important to have a logical default order. The following should usually be considered in the order listed:

  1. In-game order - In many cases content may be listed in-game in a specific order (sometimes "logically", sometimes not). Unless there's a reason not to, this is the order that should be used. (example: a bestiary, a list of structures that can be bought, a "jobs" list, etc)
  2. Pick the most logical column - If there's no in-game order, the column that best shows the data listed from "best->worst" / "least->most advanced" should be used.
  3. Alphabetical - If there's no better way to order content / it's most most logical way, alphabetizing a table by the "name" column should be used. Example: A "skills" could use this, assuming it's not listed in-game, and couldn't be order by "SP"/etc value.

Sometimes it may be best to "mix" and math these; and example where this may be a good idea is Employees (Game Dev Story). While the game doesn't list every possible employee, each employee has a specific "hiring method", which is (one of) the logical way to order them. However, we then have multiple rows that meat that criteria, we we should also order, based on another criteria.

Class[]

Tables on this wiki use the wikitable class, as well as some other common optional classes:

  • wikitable - this affects the table's style to allow all tables across the wiki to have a standard format.
  • oddrow - this darkens every other row on a table.
  • sortable - this adds the ability the sort table rows based on the values inside a specific column. (Advanced table sorting techniques can be found at Help:Sorting.)
  • centertext or ct - centers all text in the table (or the "centertext" class can be used).

Enter one or more of these values in place of the X in

class=" X "

Example:

{| class="wikitable oddrow sortable"
 |+Example Table 1
 |-
 !Kairosoft Game
 !Animal that most resembles the game
 |-
 |Game Dev Story
 |Monkey
 |-
 |Mega Mall Story
 |Wombat
 |-
 |Waku Waku! Manga Dojo!
 |Felis canihassus
 |}
Example Table I
Kairosoft Game Animal that most resembles the game
Game Dev Story Monkey
Mega Mall Story Wombat
Waku Waku! Manga Dojo! Felis canihassus

Style[]

Style is also sometimes used in tables.

  • margin:0 auto; - This will center your table on the screen.
  • text-align:center; - This will horizontally center all text in the table.

Enter one or more of these values in place of the Y in

style=" Y "

Example:

{| class="wikitable" style="margin:0 auto; text-align:center;"
|+ Example Table Deux
 !Number
 !Not a Number
 |-
 |1
 |Banana
 |-
 |2.3
 |Kumquat
 |-
 |4567
 |Your face!
 |}
Example Table Deux
Number Not a Number
1 Banana
2.3 Kumquat
4567 Your face!

Cell templates[]

Two common templates used in conjunction with tables are:

{{Blank cell}} is used on table cells that are purposefully blank, to indicate that the information is not needed or non-existent (as opposed to simply not known).

{{Initially available}} is used on table cells, typically in columns with the Unlock or Unlocked by header, to indicate that the row item is available at the start of the game. See: Furnishings (Dream House Days) for an example of this template in the wild.

Cells with this template should not have any style formatting (centered/left, etc), as the template will overwrite it.

A full list of cell templates can be found on Category:Table cell templates.

Example:

{| class="wikitable"
 |+ Example Table Deux
 !Hea
 !der
 |-
 |cell 1,i
 |cell I,2
 |-
 |cell B,omg
 |{{Blank cell}}
|cell charley,omega
|{{Initially available}}
|}
Example Table 3
Hea der
cell 1,i cell I,2
cell B,omg
cell charley,omega Initially Available

Files / Images[]

When putting an image in a page, only File: should be used, not Image: which is depreciated.

File Types[]

  • Non-animated Images should be .png (this way it's easy to update an image with transparency)
  • Animated Images should be .gif
    • When animated images are used to show different version of the same thing, they should be separated by 2-3 seconds (2000-3000 milliseconds). "Fades" between frames can also add some "classiness" to it.
      • Example: Azalea-HotSpringsStory
    • Animated images that are resized will not be rendered as static images.

File Names[]

File names should meet the following criteria:

  • Lowercase1 - All letters are to be lowercase (Do to wiki syntax, the capitalization of the first letter does not matter).
    • Example: [[File:name.png]]
  • No CamelCase - Each word should be separated with a space (or an underscore ( _ ), due to wiki syntax treating them the same). Camal casing should not be used for file names.
    • Example: [[File:my example.png]]
  • Include game's name - If related to a game, it must be followed with " - game name". Example: An item called "Beehive" from the game Dungeon Village would have an image name such as:
    • Example: [[File:beehive - dungeon village.png]]
  • No punctuation1 - with the exception of the dash separating the file moniker from the game name as seen above. So something called "Building (small)" from the game Oh! Edo Towns would have an image name like (notice the ! and () are removed):
    • Example: [[File:building small - oh edo towns.png]]
  • Why? - the intent is to create a standardized name format, that also doesn't require using the shift key (makes typing long file names on multiple files easier, and also make it easier add less letters/symbols to "guess" when searching for the file name).
  • While not a requirement, it may sometimes help to "categorize" images in their names by specifying a word at the front, such as "shop - shop name - game name.png"

1. Some exceptions to this would be game icons / banners so as to preserve the capitalization/punctuation of the page name.

Monobook, Mobile, and Wikia apps[]

While normal things such as text rarely propose an issue, each of these can be "problematic" / something to consider when using templates, html, css, etc.

Monobook skin[]

Monobook is the default wiki "skin" (Wikipedia). Wikia wikis do not use this by default, but it may be enabled through user preferences. Some people prefer this skin, as it has no adds, a less noticeable rail, and takes up the full width of the page. It is possible to view any page with the monobook skin by adding the useskin=monobook URL param; example: http://kairosoft.wikia.com/wiki/Kairosoft_Wiki?useskin=monobook. Normal inline CSS (style="") does work in monobook, but some things break because of this, do to different color schemes / different wiki layouts (excepting something to be a certain min/max width, but not being so on monobook). Monobook-specific CSS can be found on MediaWiki:Monobook.css, and JS on MediaWiki:Monobook.js. Monobook is effected by MediaWiki:Common.css and MediaWiki:Common.js (and most CSS/JS changes should be in these, instead of the normal MediaWiki:Wikia.css / MediaWiki:Wikia.js, which only effect the default skin). Due to few people using it, it's usually fine to just have "acceptable" support for this skin, such as making sure things don't break the page / everything is legible.

Mobile skin[]

The mobile skin is, well, the default mobile skin. The most important thing to note about it is that inline CSS (style="") does NOT work on mobile, and neither do the default CSS / JS pages. This can break many templates, or certain pages (such as the main page). Using some "hacks", it is possible to style the mobile skin through MediaWiki:Handheld.css, and the front page on mobile is redirected to Kairosoft Wiki/MobilePage.

While some things need CSS fixes / separate pages to "work", most things can be displayed nicely on mobile through some smart behavior / "tricks". First of all, html such as divs and span do work in mobile (albeit without the inline styles) and default to their normal behaviors (as such it's important to use the "logical" HTML attribute for fallback purposes). Wiki syntax (such as bolding text, etc) also works. Since inline styles don't work, it's also possible to hide stuff on desktop that shows on mobile using style="display:none;" (making it "mobile only"), and it's possible to hide stuff on mobile but show on desktop using the class="mobile-hide".

This skin can be viewed using the useskin=wikiamobile URL param; example: http://kairosoft.wikia.com/wiki/Kairosoft_Wiki?useskin=wikiamobile. It is also possible when editing a page to "preview" it in mobile.

Wikia Apps[]

This is where it gets tricky. Even using hacks, it is NOT possible to add custom CSS to Wikia Apps, or hide things on Wikia apps. It IS possible to only show things on Wikia apps by using style="display:none;" class="mobile-hide", since this will hide it on desktops / mobile, but these values are both ignored in Wikia apps, showing the content within.

You also don't land on the front page; instead, Wikia Apps depend heavily on categories to navigate from the land page. The categories shown can be controlled via Special:CuratedContent, and the image / description for the landing page is the same content used in Special:Promote (currently disabled).

While it's important to make things display as nicely as possible on Wikia Apps, the low degree of control makes is difficult to make anything display perfectly at this point in time.

Project:Placeholder[]

Some "administrative" categories (such as Category:Missing manual) may at any given time be void of any pages have that category. To avoid these showing up as "unused categories", Project:Placeholder should have these categories added to it.

Advertisement