A TUTTI GLI UTENTI, NON CREATE NUOVE PAGINE. PER ADESSO TRADUCETE LE PAGINE CONTENUTE NELLE CATEGORIE:
Traduzione in corso e Traduzione da completare

Minecraft Wiki:Guida di stile

Da Minecraft Wiki.
La traduzione di questo articolo è da completare.
Aiutaci a completare la traduzione di questo articolo.
Scorciatoia
MCW:STILE

Questo articolo ha come obiettivo di fornire una guida di stile globale per tutti gli articoli della Minecraft Wiki che seguono. Delle volte ci sono delle dispute su quale regola di stile o formattazione usare e fortunatamente l'inclusione di una guida di stile ufficiale aiuterà a risolvere queste dispute e raggiungere un consenso.

Anche se Wikipedia fornisce già una guida di stile generale, ne serve una più specifica per le linee guida specifiche di Minecraft. In quanto tale, solo delle linee guida relative allla Minecraft Wiki e le sue regole di formattazione di base dovrebbero essere incluse qui.

Notabilità

Scorciatoia
MCW:NOTABILITÀ

Gli articoli sono permessi nello spazio del nome prinipale solo se seguono questi criteri. Gli articoli che non rientrano in questi criteri possono essere cancellati senza nessun avviso.

Generale
  1. Gli articoli devono contenere abbastanza informazioni per essere considerati come una pagina intera. Se non hanno abbastanza contenuto, potrebbero essere uniti con articoli simili.
  2. Gli articoli devono essere pertinenti direttamente a Minecraft in qualche modo.
  3. Gli articoli riguardo le persone sono permessi solo se la persona in questione è parte, o è strettamente correlata, con la Mojang AB.
  4. Le funzioni che non sono attualmente nel gioco dovrebbero andare solamente nell'articolo delle funzioni menzionate per la versione.
    1. Questo esclude le funzioni che sono state rimosse o le funzioni dalle versioni di sviluppo, che possono essere notate su articoli che riguardano la funzioni e sull'articolo della versione.
  5. Gli articoli sulle versioni di Minecraft devono essere creati per le versioni rilasciate, con articoli separati per ogni versione di sviluppo.
    1. Possono essere creati articoli sulle versioni non rilasciate, a patto che venga fornita una fonte significativa per l'esistenza della versione. Le fonti includono le versioni di sviluppo o fonti multiple di funzioni per l'aggiornamento futuro. Articoli sulle versioni di sviluppo non rilasciate non devono essere creati.
    2. Le versioni della Console edition devono andare sulla Storia delle versioni della Console Edition. Le versioni non rilasciate devono essere aggiunte alla pagina delle versioni pianificate.
Comunità
  1. Le strategie per le partite, le guide, ecc., devono essere sottoarticoli della pagina delle guide.
    1. Pagine contenenti una lista delle varie costruzioni che un utente può fare non possono essere considerate una guida. Devono essere tenute nello spazio utente. Questo include sfide e attività create dall'utente.
  2. I minigiochi sono permessi solo se la Mojang AB afferma di averci giocato.
  3. Articoli sulle modifiche devono essere sottoarticoli della pagina sulle modifiche.
    1. Articoli riguardo modifiche per server personalizzati devono essere sottoarticoli dell'articolo principale.
    2. Articoli contenti informazioni riguardo modifiche al client sono permessi solo quando la modifica del client non contribuisce alla distruzione o ai trucchi nel multigiocatore.
  4. Articoli riguardo i server personalizzati sono permessi solamente quando il server è rilasciato al pubblico.
Regole della wiki
 4.  Articoli parodia, commedie, nosense, bufale e su speculazioni, o qualsiasi altro articolo che può sviare i giocatori non sono permessi.
 5.  Articoli creati con lo scopo di pubblicizzare server specifici o altri prodotti non sono permessi.
 6.  Articoli riguardo comunità di fan nono permessi a causa di problemi di pubblicità e altre cose come queste.

Articoli nello spazio del nome "Utente:" sono esenti dalle linee guida di notabilità. Possono essere usati per qualsiasi cosa, a patto che vengano seguite le altre regole della wiki.

Rinvii

I rinvii sono esenti dalla notabilità generale, ma devono rinviare ad un articolo che segue le linee guida sulla notabilità. Se un rinvio porta ad un altra wiki, deve usare il {{rinvio leggero}}.

  1. Compitazione alternativa del titolo, come "Pane" per "Pagnotta".
    1. La compitazione non corretta, gli errori di battitura, e formattazione non regolare non sono permessi.
  2. Nomi alternativi o accorciati, per i nomi che sono di uso comune, se il nome è di uso comune. I nomi precedenti presenti nel gioco sono permessi.
    1. Questo include i nomi o i soprannomi per gli impiegati Mojang, come "Nathan" o "Dinnerbone" per "Nathan Adams".
  3. Titoli precedenti di articoli, incluso se l'articolo è stato spostato in un'altra wiki.
    1. Esiste l'eccezione se il titolo non è comunemente usato.
  4. Capitalizzazione o forma alternativa, incluso il cambio del titolo al plurale.
  5. Parte di un articolo unito o di un articolo multi-argomento, come una pozione o una funzione menzionata.
  6. La versione madre per i pre-rilasci che diventato pre-rilasci di un'altra versione, come la "1.7" per la "1.7.2", siccome la "1.7-pre" è diventata un pre-rilascio della "1.7.2".

I rinvii negli spazi dei nomi degli utenti possono portare ovunque, a patto che l'articolo esista e non porti ad un altro rinvio.

Titoli degli articoli

I titoli degli articoli devono essere alla forma singolare per mantenere la consistenza.

Gli articoli seguono la formattazione generale dei nomi basata sul tipo.

  • Articoli riguardo i blocchi, gli oggetti e le entità nel gioco devono usare il nome così come appare nel gioco.
    • Se una funzione non ha un nome nel gioco, deve seguire lo stesso formato degli articoli dello stesso tipo. Ad esempio, la creatura del cavalcatore di ragni.
    • Se un articolo è su cose multiple nel gioco, il titolo dovrebbe rappresentare equamente tutti i titoli. Per esempio, un articolo riguardo le porte di legno e quella di ferro deve essere chiamata Porta.
  • Articoli riguardo le persone devono contenere il nome ed il cognome, più che il loro nome su Minecraft o di Twitter.
  • Le versioni per PC devono essere chiamate usando il nome della loro versione, come la 1.8 o la 14w02a.
    • I pre-rilasci devono essere formattati con una singola parola prima del nome della versione madre, ovvero con la parola "pre". Se un pre-rilascio contiene dei numeri alla fine, non dovrebbe essere messo niente in mezzo a "pre" ed il numero. Per esempio: 1.8-pre1.
  • Le versioni Pocket Edition devono essere nominate con le parole "Pocket Edition". Per esempio, l'aggiornamento "Alpha 0.9.0" deve essere chiamato "Pocket Edition Alpha 0.9.0"
    • Le build di sviluppo della Pocket Edition devono contenere prima il nome della versione madre, e poi il nome "build" seguito dal numero della build. Per esempio, la build 2 per la "Alpha 0.9.0" deve essere chiamata "Pocket Edition Alpha 0.9.0 build 2"
  • Gli articoli di disambiguazione devono contenere solamente "(disambiguazione)" se il titolo senza la parola è usato da un articolo.
  • Se il tipo di articolo non è nella lista, deve usare il titolo più rilevante in minuscolo, non in maiuscolo, a meno che non si tratti di nome proprio.

Scrittura

Vedi anche: Help:Official sources

As this wiki's purpose is to document facts, you should always avoid speculative and unsourced information. Generally speaking, information does not require sources if they can directly be seen in-game or are otherwise obvious. Other information however, such as quotes from Mojang employees and information that is not widely known, must be sourced with a proper reference. The {{citation needed}} template should be placed after any information that requires a source. Do not add content to an article if you cannot find a proper source. Articles in the main namespace should always be written in the third-person perspective and without terms referential to the reader. 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 "The player should not come close to creepers as they will explode, potentially killing the player.". To emphasis points, italics should be used, not bold or ALL CAPS. Tutorial information should only be within tutorial articles, which includes navigational features of blocks or textures. Tutorials may be linked from other articles if relevant though. Mod information should not be contained on articles not about mods. Mods should also not be linked from articles not about mods.

Keeping articles concise and up to date

Scorciatoia
MCW:UPTODATE

In short, articles should only contain 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. 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 emeralds (previously 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. It uses a previous version of the Wood article. 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 Creative mode 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, whilst pine and birch will 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 will drop 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 burnt 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. These wood blocks still produce 4 Wooden Planks when crafted. Wood from different types of trees will not stack in the inventory, but their planks will. Planks made from different kinds of trees are completely identical. Birch trees have slightly duller colored leaves than regular trees, pine trees have pine needles, and jungle leaves are leafy with fruit looking 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 scatted with new information. The introduction should state the current description of the block with the current release. History information is good, but for clarity, it should be described in the chronological order in a single place: the History section of the article.

Future

Scorciatoia
MCW:FUTURE

Content added in future updates may be added to the article in the main content, provided the features are marked using {{upcoming}} and have appeared in development versions. If the update contains major changes to the article, then the content may be noted as a subsection of a main section, or as its own section called Upcoming. Upcoming features must be noted as well in the history section using the proper upcoming header.

Upon the release of the update, all content that is now outdated must either be moved to the history section or removed, and any usage of {{upcoming}} may be removed.

Grammatica

Le pagine sulla wiki devono essere in Italiano e non usare italianizzazioni di termini inglesi o linguaggio sms. Ad esempio, “crafting” si traduce con “fabbricazione” non con “craftare”, e “enchanting” si traduce con “incantare” non con “enchantare”.

Capitalization

In-game items should be treated as common nouns and as such should not be capitalized. This includes fictional items, such as prismarine. Proper nouns however, such as the Nether or the Overworld should always be capitalized.

Structures

In-game structures should be lower case. Biome names should also be lower case. Examples:

Underground, there are randomly generated abandoned mine shafts.
A desert temple contains precious loot.
Blazes spawn in nether fortresses.
In deep ocean biomes, ocean monuments can generate.
A stronghold is home to an end portal.
Mobs

Any instance of a mob should be treated as a common noun, unless the mob is referred to as a proper noun. If the word "the" is used before the mob name, it should not be capitalized unless it is at the beginning of the sentence.

Examples:

One of the most feared mobs is the ghast.
A spider can poison its prey.
The player has been referred to as Steve.
Enchantments

Enchantment names should always be capitalized.

Example:

In order to have ice drop an item, you need a tool enchanted with Silk Touch.
Status effects

Status effects should be capitalized, unless used as an adjective.

Examples:

Magma cream is required for a potion of Fire Resistance.
Wither skeletons may inflict Wither on the player.
An invisible spider may rarely spawn.
Editions

Do not capitalize "snapshot" or "pre-release". Also, "pre-release" should be in this form, not as "prerelease" or "Pre-Release". Development phases should be capitalized. Editions should only be capitalized when used as nouns.

Examples:

Minecraft officially came out of Beta on November 18th, 2011
The cyan flower was introduced in Pocket Edition Alpha 0.1.
Of all the editions of Minecraft only the Pocket and Pi Editions have cyan flowers.
Game modes

The name of game mode types should also be capitalized.

Examples:

In Hardcore mode the game acts similar to Survival mode except the difficulty is permanently set to Hard.

Section headings

Article main sections should start with level 2 headers (two equal signs) and increase by one for subsections. Never use level 1 headers (one equal sign). Follow sentence style capitalization, not title style, so only the first letter of the heading and proper nouns are capitalized. There should be one space between sections as well as one space between the equal signs and the section name for ease of editing. If any "main article" links or thumb images are used, place them immediately under the section header, and then a space after those before the section content. For information on which sections should be in which order, see the Article layout section of this style guide.

Corsivo

Ogni presenza di "Minecraft" deve essere in corsivo. Ogni enfasi (nelle pagine di discussione, ecc.) deve essere in corsivo al posto che in grassetto o in maiuscolo. Ogni presenza di un altri videogiochi deve essere in corsivo. Ad esempio: Team Fortress 3.

Images

Scorciatoia
MCW:IMAGES

When adding screenshots to an article, make sure the screenshots use vanilla textures and UI. Screenshots that use custom texturepacks, UI mods and other custom content are not allowed. This does not apply to articles covering mods. Image captions should not have periods at the end, unless the phrase is a full sentence. Images added to articles should fit the following guidelines:

  • Images should showcase an attribute of the articles topic.
    • Images should not show unintended strange or humorous behavior, such as mobs "sitting" on stairs.
    • Images should not have the sole purpose of showcasing a bug, instead report the bug on the official tracker.
    • Images showcasing usage of specific features for decoration should be avoided.
  • Articles should only have one image showcasing an individual attribute of the articles content. For example, a zombie wearing armor.
  • Images should showcase the most up to date version of Minecraft available for the content.
    • Images that are outdated are subject to be removed.

Linking

For a complete guide to linking, please refer to Wikipedia's Manual of Style for links.

The use of links is a difficult balance between providing the reader enough useful links to allow them to "wander through" articles and excessive linking which 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 only be resolved 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 if the links are directing them to different articles or not. The guidelines for linking are:

  • No more than 10 percent of the words in an article are contained in links.
  • Unless it affects the sentence's wording and readability in a negative way, 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 multiple use of the same term, in a line or a paragraph, which will almost certainly appear needlessly on the 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 only linked once at the very 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.

Linking to a redirect is preferred over using a piped link except in templates and other pages that will be transcluded. When a piped link is unavoidable, it should not point to a redirect. If a redirect can be avoided using a suffix on the link, that is preferred. E.g. Using [[Creeper]]s instead of [[Creepers]] is desired.

Date formatting

The Minecraft 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, DD, YYYY" format, e.g. "December 10, 2011". 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 will naturally sort properly, say if the table column is later made sortable.

Redstone structures

Articolo principale: Minecraft Wiki:Style guide/Redstone

Write-ups for redstone circuits and mechanisms should follow a single convention on the wiki.

Article layout

Scorciatoia
MCW:LAYOUT

For the sake of consistency, all articles of a specific type should follow a general layout.

  • At the very top, applicable flags and templates, such as {{snapshot}} for anything not yet in the full release, {{Block}} for blocks, and so on.
  • Introduction with a general description.
  • Article body, starting with first header.

If an article does not contain a layout currently, one can be proposed on the talk page; otherwise, attempt to use a layout that follows a similar style to an existing layout. Current article layouts include: