User:CornerCactus/Guide
\The HentaiVerse Wiki aims to provide its users with a comprehensive guide of writing conventions that all wiki articles should follow, to resolve disputes over which style rule or formatting to use, and reach a consensus.
The wiki stores information about the HentaiVerse game in a type of page called articles, which are the focus of this guide. Content other than articles belongs in different namespaces, such as files or templates.
Article titles
Titles should generally follow a general naming format based on the type of title. Generally, titles should be written in singular form, except in-game features, or items with plural names (like "[Boots]").
If a HentaiVerse feature changes its name in a future version, it should use the current name as the title until the future version is released. After the release, the old title should become a redirect to the new name.
Articles about HentaiVerse features with display names
- Features with in-game display names should use the same name as in the game (like "The Shrine").
- Articles about multiple similar features should use a title that equally represents all of them. For example, "[Helmet]" represents all helmet types.
- The title should follow the same format as the names of those features. For example, "[Phase Cap]" is similar to how phase cloth armors are named.
- If a feature display name is different between editions:
- If it exists in Persistent Mode, the name in Persistent Mode should be used.
- If it doesn't exist in Persistent Mode, it should use its display name in Isekai Mode.
- If it exists in neither Persistent Mode nor Isekai Mode, it should use the name given by Tenboro as mentioned in an official post on the HentaiVerse forums.
- If an Isekai Mode name of a feature would require a disambiguation, but the Persistent Mode name wouldn't, the latter should be used instead.
- The title should always be the US English name.
Articles about HentaiVerse features without display names
- Features without in-game display names should use their ID as the title, written in title case.
- Game mechanics, not an individual feature or features in the game, should use sentence case (like "[Mob spawning]").
- If a feature has neither a display name nor an ID, it should follow the same naming as other similar articles (title case for structures, sentence case for mechanics or other).
- An article about a technical feature, such as NBT, should use its name as it appears in the game's code.
- If the feature doesn't have a name in the code, then its article name should be written in sentence case if such form makes sense. Content whose technical name does not read clearly as a noun should not be modified from its technical form (for example, [pane_log]).
Titles on other types of articles
- Advice articles should be in the
Advice:namespace, should not contain "How to", and should be written in sentence case. For example, "[Advice:Monster Crystal Farming]" should not use the item name "Monster Crystal".- They also shouldn't use a complex or long name, like "Advice:1H-Mage Tower Floor 100 Guide for Isekai".
Article content
Advice information should be present only in advice articles. However, advice articles may be linked from other articles if relevant.
Other information, such as quotes from Tenboro or information that is not widely known, should be sourced with a proper reference (using <ref>[external link]</ref>, or similar, next to the paragraph that needs to be sourced). A full list of references should be shown in a References section using [Create Reference Template].
If there is information that may require a proper source to be fully analyzed (as in incomplete information), the [Create Citation Template] template should be placed after it. Do not add this kind of content to an article without a proper source.
Article writing
Articles written on the wiki should be written consistently. Thus, we give some advice to specify how to write content on our pages.
To emphasize points, italics should be used, not bold or ALL CAPS. Bold text should be used in the introductory lead section of an article to name a feature or topic.
Third-person perspective
Articles should always be written in the third-person perspective and without terms referential to the reader ("you", "your", etc.). The exception to this is tutorial pages, where, in most cases, "you" is the most appropriate pronoun to use when referring to the player.
Try not to use abbreviations of words, either. For instance, sentences like "You shouldn't come close to creepers because they'll explode and kill you." should be written as "A player can be killed by approaching a creeper close enough to cause it to explode."
Terminology
All content on our articles should be referred to solely through in-game or official names, when applicable. This means that all content should be named and referred to using the title of the article that describes it.
Spelling
Pages on this wiki should use American English because this is the default localization used by HentaiVerse. Exceptions are when the in-game name is British English or when British spelling is used inside quotations.
The differences between American and British spelling can be subtle, typically in how the word ends. The following examples often arise:
- Words ending in "-our": "colour" should be "color", "behaviour" should be "behavior", "armour" should be "armor"
- Words ending in "-tre": "centre" should be "center", "metre" should be "meter"
- Direction indicators ending in "-wards": "towards" should be "toward", "forwards" should be "forward", "upwards" should be "upward", and so on
- Words with the "-st" affectation: "whilst" should be "while", "amongst" should be "among", "amidst" should be "amid"
- Words with "-ise" or "yse" suffixes: "organise", "analysing", and "realisation" should be "organize", "analyzing", and "realization", respectively
- Words ending in "-nce": "defence" should be "defense"
- Verbs ending in "-ling": "travelling" should be "traveling"
- Verbs ending with "t": "spelt" should be "spelled", "learnt" should be "learned", "burnt" should be "burned"
Capitalization
Content on the wiki in prose should be written differently from an article title. Specific capitalization guidelines apply to article content to make them follow consistency across the wiki.
The following tables will show what should and should not be capitalized:
Commas
When listing three or more items in prose, [wikipedia:serial comma|serial commas] should be used after the second-to-last item before the conjunction (and, or, nor); e.g., "A, B, and C", not "A, B and C". This practice can prevent ambiguity. However, a serial comma should not be added if including it introduces more ambiguity than omitting it; refer to [WP:OCOMMA|Wikipedia's Manual of Style] for examples and guidelines.
Section headings
Article main sections should start with level 2 headings (== Heading ==) and increase by one for subsections. Never use a level 1 heading (= Heading =); this is reserved for the article title.
- Follow sentence style capitalization, not title style, so only the first letter of the heading and proper nouns are capitalized.
- Headings should not have links or templates in them; links should be placed underneath, such as in a [Create Template] template.
- Although not required, having one space between sections and one space between the equal signs and the section name improves readability.
- Place any hatnotes and images immediately under the section heading, and then a space after those before the section content.
- Do not add blank sections unless tagged with [Create Template] to request prompt expansion.
- Sections that take the form of groupings (e.g., 'Additions') should be in plural form, even when there is only one item in the section.
Table headings
Text inside table heading cells should use sentence capitalization just like article section headings. Unlike section headings, however, table headings may include sprites and links.
Pseudo headings
Pseudo headings should use bold ('''Heading''') to highlight headings which aren't important enough to use a section heading.
- Follow sentence style capitalization, not title style, so only the first letter of the heading and proper nouns are capitalized.
- Pseudo headings may have links, images, or templates in them.
- Do not use
;for pseudo-headings, as that can cause accessibility issues, unless it is used for a description list. - Do not use
<small>for subheadings.
[Article lead here]
== Section ==
=== Sub-section ===
'''Pseudo-heading'''
* A bullet list
== Section ==
=== Sub-section ===
==== Sub-sub-section ====
; A term followed by
: at least one definition or at least one description list item
: and additional optional items, forming a list
Date and time formatting
The HentaiVerse Wiki is an international community. That is a good thing in general, but it makes a problem for numeric abbreviations of dates, such as "12/10/11": while most countries abbreviate dates as day/month/year, some Asian countries use year/month/day, and the US uses month/day/year.
So the above date could represent any of three different dates. To avoid this problem, most dates should be written in "Month D, YYYY" format, e.g. "December 10, 2011" or "May 4, 2012". Do not use superscripts or suffixes such as "April 23rd" or "4th of May".
If a numeric or terse date is needed (such as in a table), then use YYYY-MM-DD, always with 2 digits for month and day (e.g., 2011-12-10 or 2012-05-04). Besides being the ISO standard, dates in this format naturally sort properly, say if the table column is later made sortable.
For similar reasons, all times should be written using UTC in the 24-hour format, such as "17:00 UTC", for combined date times such as "December 10, 2011, at 17:00 UTC". For sorting, date times should also follow the ISO standard like "2012-05-04T17:00Z".
Try to avoid seasons for dates such as "Summer 2021" or "Fall 2022" as the northern and southern hemispheres have opposite seasons. Instead, use phrases like "Mid-2021" or "Late 2022".
Edition version names
Specific versions on specific editions of the game should always be written as an edition version name. This applies to article titles, paragraphs, lists, and trivia sections.
Versions of Persistent Mode should be prefixed with "Persistent" (e.g. Persistent 0.91).
Isekai Mode versions should be prefixed with "Iseaki" followed by the Year and Season #. (e.g. Isekai 2026 Season 1).
Article linking
The use of links is a difficult balance between providing readers enough useful links to allow them to "wander through" articles and excessive linking that can distract them from their reading flow.
Underlinking can cause the reader to become frustrated because questions may arise about the article's contents, which can be resolved only by using the search option or other sources for clarification, interrupting and distracting the reader.
Overlinking may distract the reader because links are usually colored differently, causing the eye to shift focus constantly. Additionally, if the same word is linked multiple times in the same paragraph, it can cause the reader to question whether the links are directing them to different articles or not.
The guidelines for linking are:
- Links should not be excessively added in articles; for example, a sentence with every other word as a link is likely to be overlinked. However, links should still be present in articles.
- If it affects the sentence's wording and readability negatively, two links should not be next to each other in the text so that it looks like one link.
- Links for any single term should not be excessively repeated in the same article. Excessive linking is defined as linking the same term multiple times within a portion of text that can fit on a typical viewer's screen. Remember, the purpose of links is to direct the reader to a new spot at the point(s) where the reader is most likely to take a temporary detour due to needing more information.
- Duplicating an important link distant from a previous occurrence in an article may well be appropriate. If an important term appears many times in a long article, but is linked only once at the beginning of the article, it may actually be underlinked. Indeed, readers who jump directly to a subsection of interest must still be able to find a link. But take care in fixing such problems; the distance between duplicate links is an editor's preference; however, if in doubt, duplicate the term further down the article.
Sprite links
When listing in-game features such as blocks and items, it is common to use a sprite link template, which displays a small image before a link. Sprite links can be useful for illustrating subjects, but create clutter within text. Therefore:
- Use sprite links only in non-sentence lists. They should not be used in prose; instead, the regular link format should be used.
Items can be organized with the following actions:
- [Example of a sprite link]
- [Example of a sprite link]
- [Example of a sprite link]
- [Example of a sprite link]
- [Example of a sprite link]
| Column 1 | Column 2 | Column 3 |
|---|---|---|
| [Example of a sprite link] | [Example of a sprite link] | [Example of a sprite link] |
| [Example of a sprite link] | [Example of a sprite link] | [Example of a sprite link] |
| [Example of a sprite link] | [Example of a sprite link] | [Example of a sprite link] |
Article layout
For the sake of consistency, all articles of a specific type should follow a general layout.
- Hatnotes (i.e. notes that belong at the very top of an article page)
- Message Boxes
- Infoboxes
- Introduction with a general description
- Article body (multiple sections; see Specific layouts below)
- See also
- Notes<ref group="note">i.e. footnotes, like this.</ref>, then references<ref>[w:Wikipedia:Reference|Wikipedia: Reference] – This is a reference.</ref>
- External links, if applicable
- Applicable footer Navboxes
Be smart when adding a message box: too many boxes at the top of a page or a section are not useful, and they can clutter the page descriptions in search results. If there is already one, move the ones that are not necessary for the reader lower position on the page, for example, a relevant section or at the end. Similarly, any quote should not be placed at the top of the page, as it adds to visual clutter and distracts from the purpose of the introduction. Additionally, the introduction should be descriptive, informative, and long enough to prevent the article of templates like infoboxes from being picked up by search engines.
Specific layouts
If an article does not contain a layout currently, one can be proposed on the style guide's [User talk:CornerCactus/Guide|talk page]; otherwise, attempt to use a layout that follows a similar style to an existing layout. Current article layouts include:
- Example 1
- Example 2
- Example 3
Keeping articles concise and up to date
In short, articles should contain only information that is up to date, i.e., implemented in the latest full version of the game. Anything that is outdated should be moved to the History section of the article. When something changes, note the change in the History section and remove the outdated information from other sections of the article (except historical names from the intro lead section if they were used to name a feature for many months or years).
It is unnecessary to mention when a particular feature was implemented; this is once again reserved for the History section of the article. Sentences such as "[Trading], which was implemented in 1.3.1, is a feature that allows players to exchange [emerald]s (previously [Ruby|rubies]) for other items." should be written as "Trading is a feature that allows players to exchange emeralds for other items."
Here's an example of how to not write a good article (taken from the Mincraft Wiki). It uses a previous version of the Log article, which at the time was called Wood. This is the full introduction. Highlighted in yellow is the redundant information, and in pink the history information.
Wood (previously known as log) is a type of block first seen in Minecraft 0.0.14a. They have a skin resembling bark on the four side faces, and a crosscut face on top and bottom. Only the normal oak logs are available in chunks generated before the Beta 1.2 update and all previous versions, while pine and birch generate in newer chunks. Wood is greatly abundant in naturally generated maps, as it is used as the foundation for trees. Wood can be chopped by hand, but using an axe is faster. Wood is also flammable.
Of the current wood types, birch is the rarest type. They are often used to make plants, trees, and wooden cabins. In Survival Test, wood blocks drop 3–5 wooden planks when mined. In Indev, Infdev, Alpha, and Beta, mining a wood block drops a wood block instead. This allows the use of wood as a building material and is craftable into planks.
Wood's only crafting use is to be made into four wooden planks. In addition, wood can be burned in a furnace to make charcoal as a substitute for coal.
As of the Minecraft Beta 1.2 update on January 13, 2011, there are now four kinds of wood. One is the normal wood (oak), another resembles the wood of silver birch trees, yet another type resembles the normal wood, but it is darker and appears in pine/conifer trees that grow in colder biomes, the fourth type is similar to the oak wood, however there are some color differences and it is tilted to one side. Wood blocks produce 4 wooden planks when crafted. Wood from different types of trees does not stack in the inventory. Planks made from different kinds of trees used to be completely identical. Birch trees have slightly duller colored leaves than regular trees, pine trees have pine needles, and jungle leaves are leafy with fruit-like shapes on them.
The fourth type of wood was introduced in snapshot 12w03a, solely occurring in jungle biomes, and comprising trees exclusive to them. The tallest trees have this type of wood in 2x2 dimensions instead of the normal 1x1.The issue with this is that old information is scattered with new information. The introduction should state the current description of the block with the current release. Historical information is good, but for clarity, it should be described in chronological order in a single place: the History section of the article.
Files
Files, which are stored in the [Insert Page Name], should not have unintelligible names or generic names (e.g. "Screenshot.png", "2024-06-25_17.53.26.png", "IMG_5478.jpg", etc.). Instead, they should follow a consistent naming so they are easier to find.
Notes
Create Template
References
Create Template
