Minecraft Wiki:Guía de estilo

De Minecraft Wiki
Saltar a: navegación, buscar
Guía de estilo de la Minecraft Wiki

Esta guía busca proveer una guía de estilo razonable para que la sigan todos los artículos de Minecraft Wiki.

Hay siempre disputas sobre qué estilo o formato usar, por lo que una guí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 si 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. Véase la sección de futuro abajo para más especificaciones.
    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 si se han publicado, pero no si no lo están. 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.
  6. Cuando se edite una página, añada la plantilla {{En construcción}} para agregarla a una categoría de páginas a editar, pero solo si no ha terminado la página. Si no desea que otros editores editen dicha página, utilice la plantilla {{En proceso de edición}} para mencionarlo. En caso de que dicha plantilla se encuentre en una página, pero no haya sido modificada en más de una semana, retire la plantilla o reemplácela con {{En construcción}}.

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. No se permiten artículos sobre minijuegos, a menos que hayan tenido un gran impacto en el desarrollo de Minecraft. Dicha información es más adecuada para la Minecraft Servers Wiki, que está diseñada para documentar dicha información. La única excepción a esta regla es el artículo sobre Minijuegos en la Edición de Consolas Legacy, debido a su oficialidad.
    1. Además, los artículos de minijuegos deben ser primero discutidos en el portal de la comunidad si es que se considera que fueron o no una parte importante del desarrollo de Minecraft.
  3. Los artículos sobre modificaciones de clientes o servidores (mods), 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 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 {{redirección suave}}. 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 deben estar en singular cuando hablan de una característica específica. Van en plural si la página contiene y habla de alguno de estos temas:

  • Valores de datos, estados de bloque/objeto/entidad, y similares.
  • Características mencionadas/removidas/no usadas.
  • Nombres en plural en el juego (ejemplo: Botas).
  • Conceptos generales (ejemplo: Mecánicas de encantamiento).
  • Características iguales o similares.
    • No incluye páginas que documenten características del mismo tipo pero que varían en valores, como Espada.

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.
    • Si la característica tiene nombres distintos en las ediciones Java y Bedrock, el nombre de la Edición Java debe usarse.
    • Si la característica no tiene un nombre mostrado en ninguna edición, debe ser la traducción de su ID.
      • Si no tiene nombre mostrado en Java ni en Bedrock, la ID de la Edición Java debe ser el título del artículo.
      • Si no tiene nombre mostrado en una de las dos versiones, el nombre mostrado en la edición que lo muestra debe ser el título del artículo.
  • 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"
    • 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 coherente, a menos que sea un nombre propio.

Escritura

Véase también: Ayuda:Fuentes oficiales

Como el propósito de esta wiki es documentar datos, uno debería evitar siempre información especulativa y sin fundamentos o fuentes. Generalmente, la información no requiere fuentes si pueden ser vistas directamente en el juego o simplemente son obvias. Sin embargo sobre otra información, como citas de empleados de Mojang Studios e/o información que no es muy conocida, debe tener una fuente con una referencia apropiada. La plantilla {{cita requerida}} debería y debe ser colocada después de cualquier información que requiera una fuente. No añada contenido a un artículo si no puede hallar una fuente apropiada.

Los artículos en el espacio principal deben siempre estar escritos en tercera persona (usualmente con las conjugaciones del pronombre "usted" para el imperativo y otras, sin mencionar este pronombre), y sin términos que hagan referencia al lector. La excepción a esto son las páginas de tutoriales, donde en la mayoría de casos "tú" es el pronombre más apropiado al referirse a un jugador (o también el pronombre "uno"). Intente no usar abreviaciones de palabras. En cambio, oraciones como "Tú no deberías acercarte a los creepers porque explotarán y te matarán." deberían reemplazarse con "El jugador no debería acercarse a los creepers debido a que explotarán, probablemente matándolos."

Para enfatizar puntos, se debería usar cursivas, no negritas o SOLO MAYÚSCULAS.

La información de tutorial debe estar únicamente en artículos de tutorial, lo que incluye características de navegación de bloques o texturas. Sin embargo, los tutoriales pueden ser enlazados desde otros artículos si son relevantes.

Mantener artículos concisos y actualizados

En resumen, los artículos deberían contener solo información que esté al día y actualizada, es decir, implementada en la última versión completa del juego. Todo lo que esté desactualizado debe ser trasladado a la sección de Historial del artículo. Cuando algo cambie, informe el cambio en la sección de Historial y remueva la información desactualizada de otras secciones del artículo. Es innecesario mencionar cuando una característica en particular fue añadida; esto es una vez más reservado a la sección de Historial. Oraciones como "El Comercio, el cual fue implementado en la 1.3.1, es una característica que le permite a los jugadores intercambiar esmeraldas (antiguamente rubíes) por otros objetos." deberían ser escritas como ""El comercio es una característica que le permite a los jugadores intercambiar esmeraldas por otros objetos."

Aquí hay un ejemplo de cómo no escribir un buen artículo. Se trata de una versión anterior del artículo Tronco en el artículo de la wiki inglesa en Log, que se llamaba Madera (Wood) en ese entonces, traducida al español. Esta es su introducción. Lo resaltado en amarillo es la información redundante, y en rosado la información histórica.

La madera (anteriormente conocida como tronco) es un tipo de bloque visto por primera vez en Minecraft 0.0.14a Tienen una textura similar a la corteza en sus cuatro caras de lado, y una cara cortada tanto arriba como abajo. Solo hay troncos de roble normales disponibles en chunks generados antes de la actualización Beta 1.2 y todas las versiones anteriores, mientras que los de pino y abedul se generan en nuevos chunks. La madera es muy abundante en mapas naturalmente generados, dado a que es usada para la creación de árboles. La madera puede ser talada a mano, pero usar un hacha es más rápido. La madera también es inflamable.

De los tipos actuales de madera, el más raro es el de abedul. Usualmente se utilizan para fabricar tablones, árboles y cabañas de madera. En la Survival Test (Prueba de supervivencia), los bloques de madera sueltan 3-5 tablones de madera al minarse. En cambio, en Indev, Infdev, Alpha, y Beta, minar un bloque de madera suelta un bloque de madera. Esto permite usar la madera como un material de construcción y se puede fabricar en tablones.

El único uso de la madera en la fabricación es para hacer cuatro tablones de madera. Además, la madera puede quemarse en un horno para hacer carbón vegetal como sustituto para el carbón.

Por la actualización de Minecraft Beta 1.2 el 13 de enero del 2011, ahora hay cuatro tipos de madera. Una es la madera normal (roble), otra se asemeja a la madera de árboles plateados de abedul, otro tipo se asemeja a la madera normal, pero es más oscuro y aparece en árboles de pino/coníferos que crecen en biomas más fríos, el cuarto tipo es similar a la madera de roble, sin embargo hay algunas diferencias en el color y está inclinada hacia un lado. Los bloques de madera producen 4 tablones de madera al usarse para fabricarlos. La madera de diferentes tipos de árboles no se apila en el inventario. Los tablones hechos de diferentes tipos de árboles antes eran completamente idénticos. Los árboles de abedul tienen hojas de colores ligeramente más apagados que los árboles normales, los árboles de pino tienen agujas de pino y las hojas de la jungla son frondosas con formas parecidas a frutas.

El cuarto tipo de madera fue introducido en la snapshot 12w03a, apareciendo únicamente en biomas de jungla, y conformando árboles exclusivos a ellos. Los árboles más altos tienen este tipo de madera en dimensiones de 2x2 en lugar de la normal de 1x1.

El problema con esto es que la información antigua está combinada con información nueva. La introducción debe indicar la descripción actual del bloque con la versión actual. La información histórica es buena, pero por claridad, debe describirse en orden cronológico en un solo lugar: la sección Historial del artículo.

Futuro

El contenido añadido en actualizaciones futuras puede ser añadido al artículo en el contenido principal, siempre y cuando las características estén marcadas usando {{próximamente}} y hayan aparecido en versiones de desarrollo. Si la actualización contiene cambios mayores para el artículo, entonces el contenido puede ser mencionado como una subsección de una sección principal, o como su propia sección llamada "Próximamente". Las características próximas deben ser mencionadas también en la sección de historial utilizando el encabezado de proximidad adecuado.

Tras la salida de la actualización, todo el contenido desactualizado debe o ser movido a la sección de historial o ser removido, y todo uso de {{próximamente}} puede ser removido.

Para elementos planeados que no han aparecido en versiones de desarrollo, se permite colocarlos únicamente en las secciones de "Características planeadas" en artículos de versiones o en artículos que engloben características generales, en el artículo de Características mencionadas, y en la sección de historial como cambio planeado.

Citas

Todas las citas deben ser copiadas tal cual se observen, traducidas al español si es necesario. Cualquier contenido adicional entre las marcas citación debe ser encerrado en corchetes. Los puntos finales deben ir solo adentro de la cita si están en la original; de otro modo, debe ir afuera. Si la cita contiene un error presente en la original, añada {{sic}} después de ese texto para indicarle a los lectores que no es un error de transcripción.

Lenguaje

Escritura

Las páginas en la wiki deberían utilizar el nombre en español de España para los títulos de artículos, si está disponible. Para su escritura general, se recomienda utilizar el español latino debido a su uso más extendido.

Formas dialectales

Se debe mantener concordancia con el uso general de las palabras. Por ejemplo, se puede usar "vos" en lugar de "tú" en los tutoriales, o se puede usar una forma verbal de "vos" o "vosotros" en lugar de las de "tú" y "ustedes" (como ejemplos, comprás, contais, mirad, etc.), pero no se pueden usar en los artículos normales, dadas las restricciones.

Traducciones

Para las traducciones, uno debe fijarse en las palabras que se encuentren en el texto original. Por ejemplo, una frase como "mobs will spawn on generated chunks" se debe traducir como "las criaturas se generan en chunks generados" (y fíjese el lector en "se generan", que no se debe traducir como "generarán", lo que pareciera obvio, mas no lo es).

Mayúsculas y minúsculas

Los nombres en el juego deben ser tratados como sustantivos comunes y por lo tanto no deberían estar en mayúsculas, a menos que inicien una nueva oración. Esto incluye objetos ficticios, como la prismarina. Los sustantivos propios, sin embargo, como el Nether o la Superficie siempre deberían ir en mayúsculas.

Estructuras y biomas

Los nombres de estructuras y biomas en el juego no deben ir en mayúsculas. Ejemplos:

Bajo tierra, hay minas abandonadas generadas aleatoriamente.
Un templo del desierto contiene algunos botines raros.
Los blazes aparecen en las fortalezas del Nether.
En los biomas de océano profundo, se pueden generar monumentos.
Una fortaleza es hogar de un portal del End.
Criaturas

Cualquier instancia de una criatura debe tratarse como un sustantivo común, excepto cuando se hace referencia a la criatura con un nombre propio. Si la palabra "el" o "la" se usa antes del nombre de la criatura, no debe escribirse tampoco en mayúscula a menos que esté al principio de la oración.

Ejemplos:

Una de las criaturas más temidas es el ghast.
Una araña de cueva puede envenenar a su presa.
El jugador ha sido conocido y referido como Steve.
Encantamientos

Los nombres de encantamiento deben ir siempre en mayúsculas. Esto se aplica solo al primero en caso de nombres compuestos.

Ejemplo:

Para hacer que el hielo se suelte como objeto, se debe usar una herramienta encantada con Toque de seda.
Efectos de estado

Los nombres de efectos de estado deben ir siempre en mayúsculas, salvo cuando se usen como parte de otro elemento (o se use un adjetivo que sea igual o referente al efecto). Esto se aplica solo al primero en caso de nombres compuestos.

Ejemplos:

Se requiere crema de magma para una poción de cuerpo ignífugo.
Los esqueletos wither pueden infligir Descomposición al jugador.
Una araña invisible puede aparecer raramente.
Ediciones

"Snapshot" y "pre-release" no deberían ir en mayúsculas, salvo en casos en donde el juego las muestre en mayúsculas, para el cual solo deberían ir en mayúsculas en el contexto del nombre en sí. "Pre-release" siempre debe tener un guion. Las fases de desarrollo deben ir en mayúsculas.

Las ediciones solo deben ir en mayúsculas al usarse como sustantivos.

Ejemplos:

Minecraft: Java Edition (Edición Java) salió oficialmente de la Beta el 18 de noviembre del 2011
La rosa, con una textura exclusiva, fue introducida en la Edición Pocket v0.1.0 alpha.
De todas las ediciones de Minecraft solo las ediciones Pocket y Pi tienen rosas azules.
Modos de juego

los nombres de los modos de juego deben ir en mayúsculas si van solos salvo se usen como adjetivos. De otro modo si acompañan a la palabra "modo" u otra van en minúsculas.

Ejemplos:

En el modo extremo el juego actúa similar al modo supervivencia excepto que la dificultad está colocada permanentemente en "Difícil".

Encabezados de sección

Las secciones principales del artículo deben iniciar con encabezados de nivel 2 (==Encabezado==) e incrementar por uno para las subsecciones. Nunca use encabezados de nivel 1 (=Encabezado=), ya que están reservados para el título del artículo.

Siga las mayúsculas del estilo de la oración, no del estilo del título, por lo que solo la primera letra del encabezado y los nombres propios se escriben en mayúscula.

Los encabezados no deben tener enlaces o plantillas en ellos; los enlaces deben ser colocados debajo, como en una plantilla de {{Artículo principal}}.

Aunque no es obligatorio, tener un espacio entre las secciones y un espacio entre los signos de igualdad y el nombre de la sección facilita la edición.

Coloque las hatnotes (notas) y las imágenes inmediatamente debajo del encabezado de la sección, y luego un espacio después de esas antes del contenido de la sección.

No añada secciones en blanco a menos que estén marcadas con {{sección vacía}} para solicitar una expansión pronta.

Para información sobre el orden en el que deben ir las secciones, véase la sección Orden del artículo de esta guía de estilo.

Cursiva

Cualquier uso de "Minecraft " debe ir en cursiva. Cualquier uso del nombre de un videojuego debe ir también en cursiva. Por ejemplo: "Team Fortress 2".

Los nombres oficiales de ediciones de Minecraft usados como subtítulos, como "Java Edition" y "Education Edition" deben ir en cursiva; los nombres de otras ediciones, como "Bedrock Edition" y "Legacy Console Edition", lo tienen opcional, mientras sigan una escritura consistente.

Las traducciones al español de estos, como "Edición Java" o "Edición Bedrock", no van en cursiva.

Además, si el nombre de la edición también se refiere a una versión específica, no debería ir en mayúsculas, dependiendo del caso. Por ejemplo: "Edición Java 1.16" no debe ir en cursiva, cuando "Java Edition" sí. Es importante remarcar que depende del uso en la oración, dado a que puede haber casos en los que se necesite resaltar una versión, o sea un caso especial.

Imágenes

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

Split-arrows.svg
Se ha sugerido que esta sección sea dividida en su propia página en Minecraft Wiki:Guía de estilo/Imágenes. [discusión]
Por favor no dividir la sección hasta que se alcance un concenso.

Al agregar capturas de pantalla a un artículo, asegúrese de que usen texturas e interfaces vanilla. No se permiten capturas de pantalla que utilicen paquetes de texturas personalizados, modificaciones de interfaces y otro contenido personalizado.

Los títulos de las imágenes no deben tener puntos al final, a menos que la frase sea una oración completa.

Las imágenes agregadas a los artículos deben ajustarse a las siguientes pautas:

  • Las imágenes deben mostrar un atributo del tema del artículo.
    • Las imágenes no deben mostrar comportamientos extraños o graciosos no intencionales, como criaturas "sentadas" en escaleras.
    • Las imágenes no deben tener el único propósito de mostrar un error, sino informe el error en el buscador oficial.
    • Deben evitarse las imágenes que muestren el uso de funciones específicas como parte de construcciones del jugador.
  • Los artículos solo deben tener una imagen que muestre un atributo individual del contenido de los artículos. Por ejemplo, un zombi con armadura.
  • Las imágenes deben mostrar la versión más actualizada de Minecraft disponible para el contenido.
    • Las imágenes obsoletas están sujetas a ser eliminadas.

Enlaces

Para una guía completa sobre enlaces, refiérase al Manual de estilo para enlaces de Wikipedia, aunque nótese que algunas de las políticas sobre enlaces listadas allí son diferentes a muchas de las presentes aquí.

El uso de enlaces es un balance complicado entre proveerle al lector suficientes enlaces para permitirles "navegar entre" artículos y demasiados enlaces que pueden distraerlos de su flujo de lectura.

Usar pocos enlaces puede provocar que el lector se sienta frustrado porque pueden surgir preguntas sobre el contenido del artículo que solo se pueden responder usando la opción de búsqueda u otras fuentes para aclaraciones, interrumpiendo y distrayendo al lector.

Usar demasiados enlaces puede distraer al lector porque los enlaces están coloreados de manera diferente provocando que sus ojos alternen constantemente un foco de atención. Además, si la misma palabra está enlazada varias veces en el mismo párrafo puede provocar que el lector se pregunte si llevan al mismo artículo o no.

Las pautas para enlaces son:

  • No más del 10 por ciento de las palabras de un artículo están contenidas en enlaces.
  • A menos que afecte la redacción y la legibilidad de la oración de manera negativa, dos enlaces no deben estar uno al lado del otro en el texto para que parezca un solo enlace.
  • Los enlaces para un solo término no deben repetirse excesivamente en el mismo artículo. El enlazado excesivo se define como el uso múltiple del mismo término, en una línea o un párrafo, que casi con certeza aparecerá innecesariamente en la pantalla del espectador. Recuerde, el propósito de los enlaces es dirigir al lector a un nuevo lugar en el(los) punto(s) donde es más probable que el lector tome un desvío temporal debido a que necesita más información.
  • Puede ser apropiado duplicar un enlace importante distante de una ocurrencia anterior en un artículo. Si un término importante aparece muchas veces en un artículo extenso, pero solo está vinculado una vez al principio del artículo, es posible que no esté muy enlazado. De hecho, los lectores que van directamente a una subsección de interés deberían poder encontrar un enlace. Pero tenga cuidado al solucionar estos problemas, la distancia entre los enlaces duplicados es la preferencia del editor; sin embargo, si tiene dudas, duplique el término más adelante en el artículo.

Se prefiere vincular a una redirección a usar un enlace canalizado, excepto en plantillas y otras páginas que serán transcluidas. Cuando un enlace canalizado es inevitable, no debe apuntar a una redirección. Si se puede evitar una redirección usando un sufijo en el enlace, es preferible. Por ejemplo, se prefiere usar [[Creeper]]s en lugar de [[Creepers]].

Formato de fechas

La Minecraft Wiki es una comunidad internacional. En sí es bueno, aunque puede generar problemas con abreviaciones numéricas, como "12/10/11": aunque la mayoría de países abrevia las fechas como día/mes/año, algunos países usan año/mes/día, y otros mes/día/año. Esto implica que la fecha numérica puede representar cualquiera de estos casos.

Para evitar este problema, la mayoría de fechas debería escribirse con el formato "Día del Mes del Año", o sea "DD del MM del AAAA" (o en cambio "Mes Día, Año", o sea "MM&nsbp;DD, AAAA"), por ejemplo "Diciembre 10, 2011" o "10 de diciembre del 2011".

No utilice superíndices ni sufijos como "23°/avo día de abril " o "4°/to de mayo". Si se necesita una fecha numérica o concisa (como en una tabla), utilice AAAA-MM-DD, siempre con 2 dígitos para el mes y el día ("por ejemplo", 2011-12-10 o 2012-05-04 ). Además de ser el ISO estándar, las fechas en este formato naturalmente se ordenarán correctamente, digamos si la columna de la tabla se vuelve después ordenable.

Coordenadas

Las coordenadas individuales del juego deben estar en mayúsculas y sin espacios ("Y=1" en lugar de "y=1" o "y = 1"). Deben encontrarse en el orden X, Y, Z, con cada elemento separado por un signo de multiplicación ("×"; ×); "4×3×2" es un área de 4 bloques de ancho a lo largo del eje X, 3 a lo largo del eje Y (vertical) y 2 a lo largo del eje Z.

Comandos

Los comandos en el juego deben estar en un formato específico para mayor comprensión. Las claves literales que se deben escribir en el chat no tienen corchetes aplicados para formato (por ejemplo, /data merge). Las variables deben estar dentro de corchetes angulares y deben estar en cursiva (por ejemplo, <target>). El contenido opcional debe estar dentro de corchete, pero estos no deben reemplazar ningún corchete angular (por ejemplo, [<scale>] es una variable opcional donde sea que [scale] es una clave opcional).

Se debe colocar en paréntesis una lista de claves válidas para cada opción separadas por una barra vertical (por ejemplo, (eyes|feet)). En el ejemplo /advancement (grant|revoke) <targets> solo <advancement> [<criterion>], /advancement y only son literales para copiarse tal cual en el chat, (grant|revoke) es una lista de elecciones para texto literal donde o grant o revoke deben colocarse en el chat, <targets> y <advancement> variables obligatorias que deben ser reemplazadas por valores válidos, y [<criterion>] es una variable opcional que debe ser reemplazada por valores válidos.

Archivos

Los nombres de archivo deben ser consistentes para que sean fáciles de encontrar. Los archivos usados en las infoboxes (cajas de información) de los artículos deben estar tituladas con el nombre exacto del tema como se ve en el juego usando es-ES (cuando sea posible), y debe ser un renderizado isométrico. La revisiones antiguas de archivos deberían tomar el formato de "Elemento/Tema EJX EBY", donde X y Y son los números de revisión para la Edición Java y la Edición Bedrock, respectivamente. Este número se incrementa cada vez que la textura se actualiza en el juego (por ejemplo, no en imágenes de adelanto). "Elemento/Tema" debe redirigir a la revisión más reciente. Si las texturas actuales para la Edición Java y la Edición Bedrock difieren, "Elemento/Tema" redirigirá a la textura de la Edición Java, mientras que "Elemento/Tema BE" redirigirá a la textura de la Edición Bedrock. Las texturas añadidas en snapshots deben seguir esta convención de nombrado, aunque " Elemento/Tema" no debe redirigir a la textura hasta que se incluya en una versión completa.

Por ejemplo, los archivos de textura para la roca serían así:

  • "Roca EJ1.png"
  • "Roca EJ2.png"
  • "Roca EJ3 EB1.png"
  • "Roca EJ4 EB2.png"
  • "Roca EJ5.png"
  • "Roca EJ6 EB3.png"
    • "Roca.png" redirige aquí.

los archivos del "Elemento/Tema EJX EBY" deben usarse en lugares donde la textura no debería cambiar si se actualiza la textura, como las secciones del historial y las guías de versión. Los archivos " Elemento/Tema" deben usarse en lugares donde la textura siempre debe estar actualizada, como las cajas de información (infoboxes).

Orden del artículo

Para mantener la consistencia, todos los artículos de un tipo específico deben seguir un diseño general.

  1. Antes del contenido del artículo
    1. Hatnotes (Notas al inicio del artículo)
    2. Etiquetas de eliminación / protección
    3. Etiquetas/Plantillas de mantenimiento
    4. Message boxes (Cajas de mensaje)
    5. Infoboxes (Cajas de información)
    6. Plantillas de encabezado de navegación
  2. Contenido del artículo
    1. Sección de encabezado; introducción con descripción general
    2. Tabla de contenido (generalmente se incluye automáticamente)
    3. Cuerpo del artículo
  3. Apéndices y pies de página
    1. Logros
    2. Progresos
    3. Sonidos
    4. Valores de datos (si son aplicables)
      1. ID
      2. Metadatos
      3. Estados de bloque
      4. Datos de objeto
      5. Datos de bloque / Datos de entidad
    5. Video (si está presente para la ilustración)
    6. Historial
    7. Errores
    8. Véase también
    9. Curiosidades (minimizar si es posible)
    10. Galería
    11. Notas y/o referencias (recopilando todas las citas de las secciones anteriores; esto puede ser dos secciones)
    12. Enlaces externos
  4. Final del artículo
    1. Plantillas de pie de página / cuadros de navegación aplicables
    2. DEFAULTSORT
    3. Categorías
    4. Interwikis

Sea inteligente al agregar una caja de mensaje: demasiadas cajas en la parte superior de una página o sección no son útiles. Si ya hay una, mueva las que no sean necesarias para el lector más abajo en la página, por ejemplo en una sección relevante o al final.

Si un artículo no posee un orden actualmente, uno puede proponerse en la página de discusión; de otro modo, trate de usar un orden que siga un estilo similar a uno existente. Los órdenes de archivos actuales incluyen: