Style Guide

Last revision: April 29th, 2024

This guide explains everything you need to know about creating and editing pages on our wiki, so that everything fits together to form a consistent and professional style. If anything here is unclear, please ask about it on the talk page, or get in contact on our Discord server.

Don't let this document intimidate you! It's here to help guide you so that you aren't left scrambling in the dark. If you're unsure of what to do, edit anyways! As long as your edits are made in good faith, they can always be tidied up by someone else later. The best way to learn is by doing, your edits do not need to be perfect to be helpful.

If you're unsure what a section in this document is describing, you can look at existing pages on the wiki as examples. This also applies if you're unsure how to approach writing something on a page. You can learn a lot by copy and pasting pieces of existing pages, and this will help to keep them consistent as well.

This wiki hosts both general ukagaka knowledge, and pages for various ukagaka creations.

“Creations” (sometimes referred to as “contributions”, or “Ghosts/etc.”) includes:

• Ghosts
• Balloons
• Shells
• Freeshells
• Calendar skins
• Plugins
• SAORI
• Supplement files
• Anything that is explicitly ukagaka-related (generally, has a descript.txt and is recognized by SSP)

It also includes the following:

• Guides related to usage or creation of ukagaka
• Third-party programs that interface with ukagaka (via protocols such as SSTP)
• Third-party tools made specifically to aid in creating ukagaka

If you have something ukagaka related that does not fit into any of these categories, please bring it up for discussion so that we can decide if/how it fits on the wiki.

There are a vast number of ukagaka creations out in the world, far too many for this wiki to cover effectively. As such, our wiki focuses specifically on the English community. We also welcome creations in other languages if the creator is a part of our community and shares their work with us.

It may be helpful to visualize the scope of our wiki with the following venn diagram:

Or, put simply:

• Our wiki covers all English ukagaka creations
• Our wiki covers creations in any language that are made by members of our community and have been shared with us

Anything else is considered outside of our scope. There may occasionally be exceptions, in cases such as a shell being made by a member of our community for a ghost that would usually be outside of our scope.

Our wiki only documents creations that have been shared publicly. The works listed here are often made by individual authors, or small groups of authors, and so we try to treat their creations with care. It is not our place to publish something publicly that was not made public by the original author.

When we say “publicly available”, we are referring to a creation which may be found and viewed/downloaded by anyone on the internet (within reason), without needing to sign up for an account, be in a certain group, etc. A good rule of thumb is that if you can stumble across it by browsing the web, it is publicly available. If you must be given a link directly or have an account to access the download, it is not publicly available.

Things that are considered to be publicly available include:

• Creations shared on a personal website.
• Posts on a social media account which is not locked.
  • GitHub counts for this purpose, as accounts are publicly viewable.
• Posts on a public forum.

Things that are not considered to be publicly available include:

• Posts in a Discord server (including ours) with a file attached directly.
• Direct download links on their own, such as files shared on Mediafire, Dropbox, or Google Drive. (These are fine if included as a part of a public post, though.)

When these kinds of releases are posted within our Discord server, we refer to them as “server exclusive” releases. They may at times be listed on various event pages/materials, if permission has been given to do so.

This section will outline the various ways that things are organized on the wiki.

When listing creations, we always use the proper name as listed in SSP's menu (seen in the owner draw menu, or in the ghost explorer), if available. For guides, SAORI, etc., this can be harder to determine, but we try to list it by whatever seems to be the official name.

Creations are listed in alphabetical order, except in some cases where they are listed in separate sections (such as shells having a section for bundled shells and external shells). Creations should still be listed in alphabetical order within these sections. We use the same alphabetical ordering that SSP uses, so when in doubt, check how SSP lists them and write them in that order.

There may be instances where two creations have the same name. In this case, it is preferred to list the names of the developers after the name, in parenthesis. For example, since there are multiple Sans ghosts, we have both sans (gr33nbeen) and sans (hatterheather).

There may be exceptions to this, depending on circumstances. For example, there are 3 separate ghosts of Wilson P. Higgsbury by the same author. These are listed as Wilson P. Higgsbury (1.0), Wilson P. Higgsbury (2.0), and Wilson P. Higgsbury (3.0).

Dates (such as release dates) on the wiki should be listed in UTC, when reasonably possible.

Before October 12th, 2023, we used EST to list dates. Pages from before this time may still list dates in EST, and should be updated as we find them.

If the time zone for a release date (or other date) cannot be established, then it should be listed with whatever date is given. Perfection is not necessary and should not be stressed over. In these cases, adding a footnote that the time zone is uncertain would be appreciated.

Namespaces are like folders. In order to keep the wiki tidy and prevent name overlaps between different kinds of creations, several namespaces have been set up to organize pages and images into. You can use the Sitemap linked on the sidebar to explore the namespaces and get a feel for the setup.

Namespaces are written separated by colons. So for example, a page link to a ghost would look like so: [[ghost:Elsen]]

The following is a list of all the available namespaces and what goes into them. Most are self-explanatory.

• balloon is for balloons.
• baseware is for baseware.
• calendar_skin is for calendar skins.
• dev is for developer pages.
• disambiguation is for disambiguation pages.
• event is for ukagaka-related events.
• freeshell is for freeshells.
• ghost is for ghosts.
• guide is for guides that are hosted on the wiki itself.
• info is for informational pages on various ukagaka concepts.
• news is for news archives from the news feed.
• playground is the namespace for the playground page.
• plugin is for plugins.
• saori is for SAORI.
• shell is for shells that are for made for a particular ghost.
  • Any shells should also get a sub-namespace for the ghost they are made for. For example, shells for Hydrate would go in the namespace shell:hydrate:
• Shells that are for multiple ghosts go in the shared-shell sub-namespace. For example, the Syringe shell can be used with both Hydrate and Needle. The page is located at [[shell:shared-shell:Syringe]]
• shiori is for SHIORI (in the sense of ghost programming languages).
• talk is for talk pages. Talk pages are automatically placed here when they are created.
• template is for templates that do not fit into another namespace, such as shell templates that are not for a particular ghost.
• tool is for third-party tools.
• wiki is for various wiki resources. Editing here is restricted.

Some pages are not in a namespace at all, but these are exceptions and related primarily to wiki navigation. All creations should be in an appropriate namespace.

Images follow the same guidelines above, however, they also get an additional namespace based on the page they are for.

For example, the page for the ghost Elsen is [[ghost:Elsen]]. Elsen's thumbnail image will also be in the ghost namespace, specifically within the elsen sub-namespace. So the tag to display Elsen's thumbnail would be written as {{ghost:elsen:thumbnail.png}}

In addition to this, there are gallery sections. Gallery sections get their own sub-namespace called gallery under the namespace of their page. This is so that which images show up in the gallery can be controlled precisely.

So to continue the example from above, the gallery for Elsen could be displayed by writing {{gallery>ghost:elsen:gallery }}

Articles should contain facts, never opinons. They should only contain information about content that exists or has previously existed, not speculation or future plans.

Second person writing should be avoided where possible. “The user can ask him questions to earn his trust.” is better than “You can ask him questions to earn his trust.” Guide pages are exempt from this.

Articles should use proper grammar and spelling as much as reasonably possible. No emoticons, emoji, etc. That being said, we absolutely welcome edits and additions from users who do not speak a fluent level of English. If you are not confident in your level of English, you can apply the wiki.needs grammar revision tag to indicate to others that the grammar needs revision.

The purpose of these rules is to keep wiki content accessible to users all over the world, including those who need to use machine translation to read it. For this reason, we also prefer American English to keep things consistent.

Spoiler content and sensitive content should be clearly marked by a banner at the top of the page, with a hatnote stating what the spoiler warning or content warning is for. The spoiler/sensitive content itself should be in a folded section.

Images can be included in spoiler sections, but should not be made into a gallery section due to how the gallery's lightbox works (users can unintentionally move between galleries without warning).

We attempt to strike a balance between standardized information, and giving pages flexibility to cover anything they need to. As ukagaka are completely customizable, flexibility is needed to be able to cover them accurately. However, a certain amount of standard information organized in a specific order helps make the wiki easier to navigate.

Note that when creating a new page, the wiki has page templates that it will use to generate the skeleton of a page for you, based on what namespace you're creating the page in. Most namespaces have page templates, though not all.

The following sections will describe in detail what order the sections of a page should be laid out in, and what each section should contain.

All creation pages get an info card, which is a table that is located on the right side of the page. This contains information such as the creation's name, release date, and download link. Depending on what type of creation it is, it will have different fields that are standard for that type.

More fields may be added if they are useful, but most fields should not be removed (unless they have no useful information to show, such as the kero field in ghosts without keros, and the special font field in balloons that don't have a special font).

When a creation is based on an existing work, the original work should be listed as its origin. When possible, we try to link to the wiki for the original work. Independent wikis are preferred. If there is no wiki to link, then an official resource (such as a website) or a wikipedia page may be linked.

Each info card should also contain images where possible. First is a thumbnail if one exists, and then an image of that creation as it appears in standard use.

For balloons, instead of an appearance image, a gif should be made showing the balloon in balloon test mode. A png may be used instead if the balloon is static and does not have any motion.

Thumbnails should be named thumbnail.png. Appearance images should be named appearance.gif. Balloon test images should be named balloontest.gif. These standard names make it easier to quickly add images on other pages that reference them. The file type of the images may differ if necessary.

Other types of images may have a standard naming scheme as well; try to copy from existing examples when available. When there is no standard naming scheme, try to use short, descriptive names, with underscores in place of spaces.

What name a developer is listed by follows some particular guidelines, since names may change over time, or developers may use multiple names.

In general, developer names should be listed the same as they are listed in the craftman of the creation.

If there is no craftman, or the craftman has not been changed from the default (or it's an edit of an existing creation and the craftman was not changed), then the developer should be listed by the name of their page on the wiki if they have one already, and if not, then the name of their account where they posted the creation.

Developer names should also link back to that developer's page on the wiki, if one exists. These pages exist to help users find that developer's other works.

If a developer has a page on the wiki already, then the link should go to the existing page. If the name of the page differs from the name used by the developer on this creation, then the link's label should be changed to reflect the name as it appears in the craftman.

• Example: If the developer already has a page under the name Zichqec, but the craftman is listed as ulde3, then it would be linked as [[dev:Zichqec|ulde3]]

If a developer requests that their name be changed, such that it would no longer match the craftman, this should be done, and a footnote should be added where the craftman differs. This is to prevent confusion and keep others from reverting the change by mistake.

• Example: If the craftman is listed as Zichqec, but Zichqec requests to be listed as ulde3 on the wiki, then the name should be listed as [[dev:ulde3]]((Craftman listed as Zichqec))

If the above is not acceptable to a developer, then this should be handled on a case-by-case basis by a moderator, so that we can prevent other editors thinking the mismatched name is a mistake and reverting it.

All creation pages should start with content warnings and spoiler warnings at the top of the article, if applicable. A banner should be placed at the top of the page, just under the title, indicating there is a warning. Multiple banners may be applied if multiple apply.

A hatnote should be added just under the wiki syntax for the info card. This should describe what the spoiler/content warning is about, to inform the user so they can choose not to view the content before they read the page.

These banners and hatnotes can also be used to indicate if a wiki page needs some sort of work done, and what work specifically is needed.

A hatnote may also be applied if a page needs disambiguation, because its name matches or is very similar to another page, etc.

All creation pages should have a blurb with a quick description of the overall gist of the creation. The first word of the blurb should be the name of that creation, and should be italicized. Guide pages have slightly different guidelines; see the section on guide pages for details.

• Ghosts should get a section called Features, which lists any notable feature the ghost has which are not SSP default features (such as SNTP, checking email, etc.).
• Balloons should decribe the overall deisgn, and how many sizes/designs they have.
• Shells should describe their overall design, and whether they have any dressups or special functionality.
• Freeshells should describe their overall design, what expressions and poses are available, whether they have any dressups, etc.
• Calendar skins should describe their overall design, and any notable features they have (such as featuring different decorations for each month).
• Plugins should describe in detail how to use them. This can include usage notes for users if it has a user-accesible menu, and usage notes for developers if the plugin interfaces with ghosts.
• SAORI should decribe in detail how to use them.
• Tools should describe in detail how to use them.
• Guides are an exception, as mentioned above, and will be covered in a later section.
• Event pages should describe the rules of the event if it had rules, then list entries that were made for the event. This format may change if it does not suit the event in question.

The middle section of each page is completely flexible, and sections should be added if they are useful. This can be used to describe special features, or anything that is notable enough to fill a section. This is primarily seen in ghost pages, but it can apply to anything that requires more description.

Some examples:

Needle uses the middle section to describe its communication features, naming systems, and some easter egg features.

Aiba uses the middle section to describe her productivity features.

sans (hatterheather) uses the middle section to describe the various menu interactions and hotkeys that the ghost has.

Underneath the flexible middle section is another set of sections with a specific order. These are listed in the order they should appear. Any sections that do not apply can be omitted.

These sections are specific to ghost pages.

If a ghost comes bundled with a balloon, or lists a balloon in its descript.txt, a balloon section should be created and the balloon should be listed on the page.

If the balloon is bundled with the ghost and has never been available on its own, then the balloon should be described fully within the ghost's page. All images besides the balloontest image should be put into a folded section.

If the balloon has a separate release, then the balloon should have its own page on our wiki. That page should be linked, and the balloontest image should be displayed on the ghost's page.

If the balloon has a separate release but is not available on our wiki (due to being made by someone in the greater ukagaka community and not the Ukagaka Dream Team community, etc.), then the balloon should be displayed on the page the same way as balloons that have their own pages, rather than describing it in detail. The balloon's distribution source should be linked.

If multiple balloons are available, they should all be listed, one after another. If the ghost is specifically associated with the balloons in descript.txt, they should be listed in the same order in which they appear in the ghost's balloon switching menu. If this has not been done, then they should be listed in alphabetical order.

If a ghost has more than one shell, it should include a shell section with a table displaying all of the shells. The default shell should always be listed first.

Bundled shells are shells that come with a ghost upon download, and External shells are shells which have separate download links.

Bundled shells should be listed first, then external shells should be listed after a divider. Shells should be listed within these sections in alphabetical order.

Any shell that has its own page should have its name in the shell table be a link to that shell's page. This usually only applies to external shells, but there are exceptions.

All creation pages can have the following sections if they are applicable. They are not usually applicable to guide pages.

A trivia section may be created if there is interesting information to share about the creation, which is not a feature. For example, if the creation's release date coincides with something else, has references to another piece of media, etc. See pages such as Dusk and Dawn, Gallery 512, and Noodle.

Take care that the information listed here is relevant, and not speculation or opinions. When in doubt, it's probably better to leave it out.

Pages with extra images to show can have a gallery section at the bottom. Galleries should always be left-aligned, due to some issues with the way the wiki's gallery plugin interacts with the interface.

Galleries should contain images of the creation in use, but should not contain images that are present elsewhere in the page already.

Spoiler content and sensitive content should not appear in the gallery.

The different types of pages will often have a “standard” set of images that is typically captured for them. Please look through the galleries of some pages of the same type to get a feel for what should be shown there. Additional images may be added if there is something of interest to be shown.

Gallery images should be named with simple, descriptive names, as these are displayed as a caption below the image when it is clicked. For example, “main_menu.png” and “dialogue.png” are good image names that describe what the image is showing.

Most pages will have tags at the bottom. What kind of tags depends on the type of the creation. Please refer to the tag list to see what tags and categories of tags already exist, and further information on tagging.

If you wish to add a new tag, this can be done. Please see the information on the tag list.

Tags exist to help users navigate the wiki and discover new things, so slightly overtagging is preferred to undertagging.

If the above is difficult to grasp as written, it is advised that you spend some time browsing filled pages of a particular type to get an idea of how they are laid out.

Ghost pages in particular have the most sections that need to be in order, so here is an example of how a ghost page would be laid out:

• Any banners, and spoiler/content warnings
• Info card (on the right)
• A summary of the ghost
• A list of the ghost's features
• Flexible space where sections may be added as needed, based on what kind of documentation the ghost needs
• Balloon information
• Shell information
• Trivia
• Gallery

For a specific example, you may want to look at the pages of Needle, Tegra and Kadan, and SSP Angel.

Guide pages are slightly different from other types of pages. Guides written on the wiki are assumed to be open to editing by anyone. If a developer wishes to write a guide that no one else can edit, they can host it somewhere outside the wiki (a personal website, social media account, pastebin, etc.), and have it linked on the guide list.

New guides can be created for any ukagaka-related topic, though topics that have already been covered should be avoided unless the guide will be significantly different from what already exists.

Other than the initial info card and blurb, guide pages can be structured in any way that suits their content. The blurb for guide pages should describe the overall premise of the guide, and what it aims to teach the reader. The name of the guide does not need to be stated/italicized, unlike other creation pages.

Dev pages are created to act as a link hub between a developer's creations on our wiki. Typically, we make them for any developer who has 2 or more creations listed.

Aside from links to the wiki pages of their creations, other information should not be added to developer pages by anyone except that developer, unless the developer gives express permission to edit their page. This is to protect the privacy of individual authors. These pages are free to be left blank aside from links.

If the developer chooses to add more information, or allows others to add information on their behalf, then the pages can be a bit looser with the wiki style. They should still be easily navigable, and not deviate from the overall aesthetic of the wiki.

The following determines when it is appropriate to create a dev page:

• If a developer has 2 or more creations listed on the wiki, we'll automatically create a page for them to act as a link hub.
• If a developer has 1 creation listed on the wiki, they are permitted to make a page if they want it.
• If a developer has no creations listed on the wiki, they are not eligible for a page.

Dev pages should always contain links to all of that developer's creations that have pages on the wiki, to aid in navigation. These links should be divided into sections based on what type of contribution they are, in the following order:

• Ghosts
• Balloons
• Shells
• Freeshells
• Calendar skins
• SAORI
• Plugins
• Tools
• Guides
• Translations
• Supplements

If a developer has created one shell for a particular ghost (or set of ghosts), this shell should be listed with the name of the corresponding ghost(s) after it in parenthesis.

If a developer has created more than one shell for a particular ghost, this ghost should get a subsection in the shells section, and all of the shells for that ghost should be listed there.

If a developer has created multiple shells that are usable for more than one ghost (shells that would go in the shared-shell namespace), these get a “Shared shells” section at the end of the shell subsections.

All editors are expected to treat each other with respect when interacting with other editors. This includes on talk pages, in edit summaries, in the #wiki_discussion channel of the Ukagaka Dream Team's Discord server, and anywhere else where discussion of the wiki takes place.

If you have a disagreement with another editor, resolve it peacefully, or bring it to the attention of a moderator. Remember not to attack other people; only comment on the ideas they are proposing.

When editing a page, please leave an edit summary describing your changes. This does not need to be verbose; simple, short summaries are best.

Edit summaries let others quickly check for when specific parts of pages changed, and more. They make everyone's lives a little easier, so please include them.

Wiki spam, trolling, etc., will not be tolerated and will result in an immediate ban. If you come across content like this, please quietly report it to a moderator so that we can handle it without drawing attention to it.