Minecraft Wiki:Manual de escritura

Plantilla:Traducción en proceso

Este artículo busca proveer una guía de estilo comprensiva para que la sigan todos los artículos de Minecraft Wiki. Hay siempre disputas sobre cual regla de estilo o formato usar, por lo que una quía oficial ayuda a resolver esos problemas y a alcanzar un consenso.

Aunque Wikipedia ya proporciona una guía de estilo más general, se necesita una más especial para pautas específicas para Minecraft. Por lo tanto, solo pautas pertinentes a la Minecraft Wiki y sus reglas de formato básico se incluyen aquí. Si alguna contradicción aparece, esta página siempre toma precedencia sobre sus subpáginas y la guía de estilo de Wikipedia.

Notabilidad

Los artículos solo se permiten en un espacio principal se encajan en los siguientes criterios. Los que no encajen en ellos pueden ser eliminados sin avisar.

General

1. Los artículos deben contener suficiente información para merecer una página completa. Si no tienen la suficiente, deberían fusionarse con otros artículos similares.
2. Los artículos deben pertenecer directamente a Minecraft de alguna forma.
3. Los artículos sobre gente solo se permiten si la persona en cuestión es un desarrollador de Minecraft y/o parte de o cercanamente relacionado a Mojang Studios.
4. Usualmente las características que aún no estén en el juego deberían estar solo en el artículo de las características mencionadas de esa versión.
   1. Esto excluye características que fueron removidas o características en versiones de desarrollo, lo que puede ser mencionado en los artículos afectados por la característica y en los artículos de versión relevantes.
5. Los artículos sobre versiones de Minecraft pueden ser creados para versiones publicadas, de lo cual deberían crearse artículos separados para cada versión de desarrollo.
   1. Se pueden crear artículos de versiones futuras, mas no de versiones de desarrollo futuras. Estos deben crearse si hay información y una fuente segura de la existencia de aquella versión aún no publicada. Las fuentes incluyen versiones de desarrollo o múltiples fuentes de características para la siguiente actualización. Además, las versiones futuras deberían añadirse como subsección de Versiones planeadas.

Comunidad

1. Las estrategias para jugar, guías, "cómo-hacer-algo"s, etc., deberían ser subpáginas de Tutoriales.
   1. Las páginas que contienen una lista de construcciones misceláneas que un usuario puede hacer no son consideradas tutoriales. Deben mantenerse en el espacio de usuario. Esto incluye actividades creadas por los usuarios y retos.
2. Sobre añadir minijuegos solo están permitidos si Mojang Studios afirma haberlos jugado.
3. Los artículos sobre modificaciones de clientes o servidores, o programas de terceros y editores de mapas, no están permitidos en la wiki.
   1. Es mejor dejarlos en la Feed the Beast Wiki (y su versión en español), una wiki enfocada en documentar contenido modificado.
4. Los artículos sobre servidores personalizados no deberían ser creados.
   1. Esos artículos encajan mejor en la Minecraft Servers wiki, debido a que esta diseñada para documentar esa información.

Normas

 4.  No está permitido crear artículos sobre para parodia, comedia, cosas sin sentido, falsedades, y especulación, o cualquier otro artículo que pueda confundir a los jugadores.

 5.  No están permitidos los artículos creados para publicitar servidores específicos u otros productos.

 6.  Los artículos sobre comunidades no están permitidos debido a problemas de publicidad.

Los artículos en el espacio de nombres "Usuario:" están exentos de las pautas de notabilidad. Pueden ser usados para lo que sea, mientras que sigan las otras normas. Sin embargo, se recomienda que se mantengan libres y limpios para no obstruir las categorías de mantenimiento, dado a que esas páginas de usuario pueden ser elegibles para una limpieza y blanqueado por inactividad del usuario.

Redirecciones

Las redirecciones están exentas de la notabilidad normal, pero deben redirigir a un artículo que encaje en las pautas de notabilidad. Si una redirección lleva a otra wiki, debe usar {{soft redirect}}. Se pueden crear redirecciones si encajan en algo de lo siguiente.

• Formas dialectales o alternas de títulos, como "Papa" para "Patata".
  • No están permitidos mala escritura/errores ortográficos, mal lenguaje, ni formatos irregulares.
• Nombres alternos o recortados, siempre y cuando sean de uso común, como "Pato" o "Pollo" para "Gallina". También se permiten nombres antiguos en el juego, como "Mesa de fabricación" para "Mesa de trabajo".
  • Esto incluye los primeros nombres, identificadores, y apodos para los empleados de Mojang Studios, como "Nathan" o "Dinnerbone" para "Nathan Adams".
• Nombres en inglés como "Pig" para "Cerdo". Sin embargo, no todos los nombres en inglés deben ser redirecciones si no son de uso común.
• El título anterior de un artículo, incluso si el artículo fue movido a otra wiki.
  • Una excepción es cuando el título anterior no era muy usado.
• Uso alterno de mayúsculas o formas, incluso cambiar el título a plural.
  • Sobre el plural, solo debe usarse si es irregular, dado a que de otro modo se debe en lazar en el artículo correspondiente con "[[Algo en singular]]s/es".
• Una parte de un artículo fusionado o multi-tópico, como una poción o una característica mencionada.
• Las redirecciones del espacio principal hacia los espacios principales de Minecraft Earth y Minecraft Dungeons.

Las redirecciones en el espacio de nombres pueden llevar a donde sea, excepto a un artículo que no exista u otra redirección.

Títulos de artículo

Los títulos de artículo deberían generalmente estar en singular, salvo características en el juego con nombres en plural (por ejemplo "Botas").

Los artículos deberían seguir un formato de nombre general basado en su tipo.

• Los artículos sobre bloques, objetos, y entidades en el juego deben usar el nombre tal cual como está escrito en el juego.
  • Si la característica no posee un nombre en el juego, debe seguir el mismo formato como otros artículos del mismo tipo. Por ejemplo, la criatura Jinete arácnido.
  • Si el artículo trata de múltiples elementos en el juego, el título debe igualmente representar a todos los títulos. Por ejemplo, un artículo sobre puertas de madera y hierro se llamaría Puerta.
• Los artículos sobre personas deben contener su primer nombre y apellido, en lugar de su apodo/nombre de Minecraft o Twitter.
• Las versiones de la Edición Java deben ir precedidas por las palabras "Edición Java" (por ejemplo "Edición Java 1.8").
• Las versiones de la Edición Pocket deben ir precedidas por las palabras "Edición Pocket". Por ejemplo, la actualización "Alpha 0.9.0" se titularía "Edición Pocket Alpha 0.9.0"
  • Las etapas de desarrollo de la Edición Pocket Alpha deben contener primero el nombre de su versión, y luego la palabra "build" (etapa) en minúscula seguida por el número de etapa. Por ejemplo, la etapa 2 para "0.9.0" se titularía "Edición Pocket Alpha 0.9.0 build 2"
    • Como esos títulos de página no son completamente fieles a la versión de los nombres en el juego, esta especificación de nombrado está actualmente en discusión.
  • Las etapas de desarrollo de la Edición Pocket deben contener primero la palabra "alpha" en minúscula seguida por el número de la versión. Por ejemplo, "1.1.0.1" se titularía "Edición Pocket alpha 1.1.0.1"
• Las versiones de la Edición Bedrock deben ir precedidas por las palabras "Edición Bedrock". Por ejemplo, la actualización "1.2.1" se titularía "Edición Bedrock 1.2.1"
  • Las etapas de desarrollo de la Edición Bedrock deben contener primero la palabra "beta" en minúsculas seguida del número de versión. Por ejemplo, "1.2.0.9" se titularía "Edición Bedrock beta 1.2.0.9"
• Otras versiones deben ir precedidas por la edición. Por ejemplo, la actualización "1.0.27" para la Edición Education se titularía "Edición Education 1.0.27"
• Si el tipo del artículo no está en la lista, debe usar el título más relevante en el caso de oración, no el caso del título, a menos que sea un nombre propio.

Writing

Véase también: Ayuda:Fuentes oficiales

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 Studios 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. 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 "The player should not come close to creepers as they will explode, potentially killing them."

To emphasize 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

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 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 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. Wood blocks produce 4 wooden planks when crafted. Wood from different types of trees do 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 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 scattered 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

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.

Quotes

All quotes should be copied verbatim. Any additional content added within the quotation marks must be enclosed in square brackets. Terminal punctuation must only go inside the quote if it is in the original; otherwise, it must go outside. If the quote contains an error that was present in the original, add {{sic}} after that text to show readers that it is not a transcription mistake.

Spelling

Pages on the wiki should use American English unless the in-game name is British English. For instance, "colour" should be "color" and "centre" should be "center".

Capitalization

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

Structures and biomes

In-game structures and biome names should not be capitalized. Examples:

Underground, there are randomly generated mineshafts.

A desert pyramid contains some rare loot.

Blazes spawn in nether fortresses.

In deep ocean biomes, monuments can generate.

A stronghold is home to an end portal.

Mobs

Any instance of a mob should be treated as a common noun, except where the mob is referred to using 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 cave 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, a tool enchanted with Silk Touch should be used.

Status effects

Status effect names should be capitalized, except where they are 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

"Snapshot" and "pre-release" should not be capitalized, except in cases where they are capitalized in the game itself, in which case they should only be capitalized within the context of the name itself. "Pre-release" should always be hyphenated. Development phases should be capitalized.

Editions should only be capitalized when used as nouns.

Examples:

Minecraft: Java Edition officially came out of Beta on November 18, 2011

The rose, with an exclusive texture, was introduced in Pocket Edition v0.1.0 alpha.

Of all the editions of Minecraft only the Pocket and Pi Editions have blue roses.

Game modes

The name of game modes should 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 headings (==Heading==) and increase by one for subsections. Never use level 1 headings (=Heading=), which are used 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 Plantilla:Tl template.

Although not required, having one space between sections and one space between the equal signs and the section name makes for ease of editing.

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 {{empty section}} to request prompt expansion.

For information on which sections should be in which order, see the Article layout section of this style guide.

Italics

Any instance of "Minecraft " should be in italics. Any instance of the name of a videogame should also be in italics. For instance: "Team Fortress 2".

Official Minecraft edition names used as subtitles, such as "Java Edition" and "Education Edition" should be in italics; other edition names, such as "Bedrock Edition" and "Legacy Console Edition", should not.

Additionally, if an edition name is also referring to a specific version, it should not be in italics. For instance: "Java Edition 1.16" should not be in italics, whereas "Java Edition" should.

Images

Véase también: Minecraft Wiki:Vistas estandarizadas

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, which are currently being phased out.

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 article's 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 as part of player builds 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, although do note that some of the policies about linking listed there are different than many here.

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 23^rd" 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.

Commands

Plantilla:Needs update In-game commands should be in a specific format for ease of understanding. Literal keywords that must be typed in chat do not have any brackets for formatting applied (e.g., /data merge). Variables must be inside angle brackets and should be italic (e.g., <target>). Optional content must be inside square brackets, but these brackets should not replace any angle brackets (e.g., [<scale>] is an optional variable whereas [scale] is an optional keyword). A list of valid keywords should be placed in parentheses with each option separated by a pipe (e.g., (eyes|feet). In the example /advancement (grant|revoke) <targets> only <advancement> [<criterion>], /advancement and only are literals to be typed exactly as-is in chat, (grant|revoke) is a list of choices for literal text where either grant or revoke must be typed in chat, <targets> and <advancement> are compulsary variables which must be replaced with valid values, and [<criterion>] is an optional variable which must be replaced with a valid value.

Files

File names should be consistent so they are easier to find. Files used in the infobox of articles should be titled with the exact name of the subject as seen ingame using en-US (when possible), and must be an isometric render. Old revisions of files should take the format of "Subject JEX BEY", where X and Y are the revision numbers for Java Edition and Bedrock Edition, respectively. This number is incremented each time the texture is updated in game (e.g., not in teaser images). "Subject" should redirect to the most recent revision. If the current textures for Java Edition and Bedrock Edition differ, "Subject" will redirect to the Java Edition texture, while "Subject BE" will redirect to the Bedrock Edition texture. Textures added in snapshots should follow this naming convention, though "Subject" should not redirect to the texture until it is included in a full release.

For example, the texture files for cobblestone would go as follows:

• "Cobblestone JE1.png"
• "Cobblestone JE2.png"
• "Cobblestone JE3 BE1.png"
• "Cobblestone JE4 BE2.png"
• "Cobblestone JE5.png"
• "Cobblestone JE6 BE3.png"
  • "Cobblestone.png" redirects here.

The "Subject JEX BEY" files should be used in places where the texture shouldn't change if the texture is updated, such as history sections and version guides. The "Subject" files should be used in places where the texture should always be up to date, such as infoboxes.

Article layout

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

1. Hatnotes
2. Message boxes
3. Infoboxes
4. Introduction with a general description
5. Article body
6. See also
7. Notes and references
8. Applicable footer navboxes
9. DEFAULTSORT
10. Categories
11. Interwikis

Be smart when adding a message box: too many boxes at the top of a page or a section is not useful. If there is already one, move the ones that are not necessary for the reader lower on the page, for example in a relevant section or at the very end.

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:

• Características
• Redstone
• Versiones

Manual de escritura
Más tutoriales