Minecraft Wiki
登録
Advertisement
このページは誰でも編集できます! 
このページは利用者のページではありますが、他の利用者も編集することができます。
編集フィルターにより編集ができない場合は、議論ページで変更を提案してください。
ショートカット

この記事では、Minecraft Wikiのすべての記事が従うべき包括的なスタイルガイドを提供することを目的としています。 どのようなスタイルルールや書式を使用するかについてはしばしば論争があります。そのため、公式のスタイルガイドはこれらの論争を解決し、コンセンサスを得るのに役立ちます。

ウィキペディアでは、既により一般的なスタイルガイドが提供されていますが、Minecraftに特化したガイドラインにはより具体的なものが必要です。そのため、ここではMinecraft Wikiとその書式ルールに関するガイドラインのみを掲載しています。

表記[]

ショートカット

記事は、以下の基準に合致する場合にのみ、メインの名前空間(以下、メインの名前空間には「Minecraft Dungeons」および「Minecraft Earth」名前空間も含みます)で作成することができます。基準に合わない記事は、予告なしに削除されることがあります。

全般
  1. 記事には、そのページを構成するために十分な情報が含まれていなければなりません。内容が不十分な場合、他の類似した記事と統合すべきです。
  2. 記事は、何らかの形でMinecraftに直接関係するものでなければなりません。
  3. 人物に関する記事は、当該の人物がMinecraftの開発者であるか、Mojang Studiosに何らかの形で関連している場合に許可されます。
  4. 現在ゲームにはない要素は、そのエディションの言及された要素の記事にのみ記載してください。
    1. ただし、削除された要素や、開発版の要素は除きます。それらの要素は、影響を受ける記事や関連するバージョンの記事に記載してください。
  5. Minecraftのバージョンに関する記事は、リリースバージョン用に作成することができますが、開発バージョン用にはそれぞれ個別の記事を作成する必要があります。
    1. リリースされていないバージョンの記事は、そのバージョンの存在を示す意味のある情報源がある場合に作成することができます。情報源には、開発バージョンや、次のアップデートの要素についての複数のソースが含まれます。未公開の開発バージョンの記事は作成することはできません。未リリースのバージョンは、計画中のバージョンのサブセクションとして追加してください。
    2. Legacy Console Editionのバージョンは、「Legacy Console Edition/更新履歴」に掲載するようにしてください。ただし、他のLegacy Console Editionが廃止された後のPlayStation 4 Edition(1.82より後のバージョン)は、個別に記事を作成してください。
    3. Minecraftのランチャーのバージョンは、「ランチャー/更新履歴」に掲載するようにしてください。変更履歴が長い場合、または開発ビルドが多い場合は、「ランチャー」から始まる名称でバージョンの記事を作成することができます。バージョンに複数の番号がある場合は、異なる番号を「x」に置き換えてください。
コミュニティ
  1. ゲームプレイにおける戦略、ガイド、ハウツーなどは、チュートリアルの下位の記事にしてください。
    1. ユーザーが作ることのできる雑多な建築物を一覧にしているようなページは、チュートリアルとはみなされません。そのようなページは「利用者」名前空間に格納すべきです。これには、利用者が作成したアクティビティやチャレンジの要素も含まれます。
  2. ミニゲームは、Mojangがプレイしたことがあるとした場合にのみ追加することができます。
  3. クライアントやサーバMod、サードパーティのプログラムやマップエディタに関する記事は、このウィキ上での作成は許可されていません。
    1. そのような記事は、Modなどの内容を解説するFeed the Beast Wikiを利用することが望ましいです。
    2. Modに関する多くのページは(ほとんどがModおよびツールとエディターの下位ページとして)現在もウィキ上に存在していますが、現在はより良い管理のためにFTB Wikiへの移植が行われています。
  4. カスタムサーバーに関する記事は作成してはなりません。
    1. そのような記事は、サーバーに関する情報を解説するMinecraft Servers Wikiを利用することが望ましいです。
ウィキの規則
 4.  読者や他の編集者に誤解を与えないようにしてください。記事への投稿は、検証可能であることを確認してください。憶測やパロディ、デマを記事に追加してはなりません。
 5.  ファンコミュニティやサーバーの宣伝をしてはなりません。記事には、引用された参照を除き、ファンコミュニティに関する情報や、ファンコミュニティへのリンクが含まれてはなりません。

なお、「利用者」名前空間の記事は、上記のガイドラインの適用対象外となります。その他のウィキの規則に従うものであれば、自由に使用することが可能です。ただし、メンテナンスカテゴリに分類されないよう、ページのメンテナンスを行うことが強く推奨されます。そのような利用者ページは、利用者が非活動の状態である際に、内容の消去やページの削除の対象となる場合があります。

転送ページ[]

転送ページ(リダイレクト)は通常の表記方法からは除外されますが、表記方法のガイドラインに適合する記事にリダイレクトしなければなりません。リダイレクトが他のウィキに接続される場合は、{{soft redirect}} を使用しなければなりません。転送ページは、以下のいずれかに当てはまる場合に作成することができます。

  1. タイトルの表記ゆれ(「かぼちゃ」を「カボチャ」へなど)
    1. 誤字や脱字、不正な書式は許可されていません。
  2. 一般的な用法の範囲内である代替名や短縮名(「」を「ニワトリ」へなど)、過去に使用されていたゲーム内の名称(「」を「」へなど)
    1. これには、Mojangの従業員の名前やハンドルネームも含まれます(「Nathan」や「Dinnerbone」を「Nathan Adams」へなど)。
    2. また、広く一般に知られている日本語の俗称も含まれます(「」を「クリーパー」へなど)。
  3. 以前の記事タイトルだったもの
    1. ただし、以前の記事タイトルが一般に使用されていないものは除きます。
  4. 英語名の大文字・小文字を入れ替えたもの、複数形にしたもの(「Iron Golem」や「Iron golems」を「アイアンゴーレム」へなど)
  5. ポーション言及された要素のような、複数の項目がまとめられたページへの転送ページ

「利用者」名前空間内での転送ページは、存在しないページや別の転送ページへのリダイレクトを除き、どのページへリダイレクトしても構いません(特別:迷子のリダイレクト特別:二重転送に記載されないようにしてください)。

記事名[]

記事名は、原則として正式リリースされたバージョンに登場する訳語を使用してください。

記事は、その種類に応じて一般的な命名形式に従わなければなりません。

  • ブロック、アイテム、エンティティに関する記事は、正式リリースされたバージョンで使用されている訳語を採用してください。
    • 正式リリースされていないバージョンで新たに登場する要素に関する記事は、英語(英語版の同内容の記事のタイトル)のままにしてください。
    • ゲーム内での名称が存在しない場合は、適切な日本語の名称を与えて記事名としてください(例:スパイダージョッキー)。
    • ゲーム内の複数の項目をまとめている記事の場合は、そのすべてに共通している語句を記事名としてください(例:木製のドアと鉄のドアをまとめた記事は「ドア」とする)
  • 人物に関する記事は、Minecraftの名前やTwitterのハンドルネームではなく、姓名を含めたものにしてください。また、日本語表記にはせず、英語版の表記に従ってください。
  • Java Editionのバージョンに関する記事は、「Java Edition」から始めてください(例:Java Edition 1.8)。
  • Pocket Editionのバージョンに関する記事は、「Pocket Edition」から始めてください(例:Alpha 0.9.0であれば「Pocket Edition Alpha 0.9.0」)。
    • Pocket Edition Alphaの開発ビルドに関する記事は、親バージョンのタイトルから始め、それに続けて「build」とビルド番号としてください(例:0.9.0の2番目のビルドであれば「Pocket Edition Alpha 0.9.0 build 2」)。
      • これらの記事名は、ゲーム内でのバージョン名称と完全に一致するものではないため、命名の規則は英語版ウィキで現在議論中です。
    • Pocket Editionの開発ビルドに関する記事は、「Pocket Edition」に続けて、メジャーバージョン、その後「build」とビルド番号としてください(例:1.1.0.1であれば「Pocket Edition 1.1 build 2」)。
  • Bedrock Editionのバージョンに関する記事は、「Bedrock Edition」から始めてください(例:1.2.1であれば「Bedrock Edition 1.2.1」)。
    • Bedrock Editionの開発ビルドに関する記事は、バージョンにより命名形式が異なります。
      • 1.2.10以前は、「Bedrock Edition」に続けて、メジャーバージョン・マイナーバージョン(マイナーバージョン番号が「0」の場合は「.0」を省略)、その後「build」とビルド番号としてください(例:1.2.0.9であれば「Bedrock Edition 1.2 build 3」)。
      • 1.2.13以降は、「Bedrock Edition」に続けて、「beta」とバージョン番号としてください(例:1.2.13.5であれば「Bedrock Edition beta 1.2.13.5」)。
  • その他のバージョンに関する記事は、そのエディションの名称から始めてください(例:Education Editionのバージョン1.0.27であれば「Education Edition 1.0.27」)。
  • 曖昧さ回避のための記事は、その単語が記事名として使われている場合にのみ「(曖昧さ回避)」を付与してください。
  • 上に記載のない記事の種類の場合は、可能な限りゲーム内で登場する語句で適切な記事名を構成してください。

記事の記述[]

このウィキの目的は事実を文書化することであるため、不確かな情報やソースのない情報は常に避けなければなりません。一般的に言えば、情報はゲーム内で直接見ることができるか、明らかなものであればソースを必要としません。しかし、その他の情報、例えばMojangの従業員からの引用や、広く知られていない情報については、適切なソースが必要です。ソースを必要とする情報の後には、{{要出典}} テンプレートを配置してください。適切なソースが見つからない場合は、記事にその内容を追加しないでください。

メインの名前空間の記事は、常に第三者の視点で、読者を指す用語を使わずに記述しなければなりません。チュートリアルページは例外ですが、ほとんどの場合、プレイヤーを参照する際には「プレイヤー」が最も適切な代名詞となります。単語の略語も使わないようにすべきです。例えば、「クリーパーは爆発してあなたを倒してくるので近寄るべきではない。」というような文章は、「クリーパーは爆発してプレイヤーを倒す可能性があるため近寄るべきではない。」のように記述すべきです。

強調箇所は太字ではなく、斜体、または「かぎ括弧」を使用して記述すべきです。

チュートリアル情報は、ブロックやテクスチャを案内する要素を含む、チュートリアル記事の中にのみ記述してください。関連があれば、チュートリアルの記事を他の記事からリンクしても構いません。

Modに関する記事ではない記事にModの情報を含めてはなりません。また、Modに関する記事ではない記事からModに関する記事へリンクしてはなりません。

記事を簡潔かつ最新の状態に保つ[]

ショートカット

要約すると、記事には最新の情報、つまり最新のリリースバージョンで実装された情報のみを掲載するようにすべきです。古い情報は、各記事の「歴史」節に移動してください。何らかの変更が行われた際は、「歴史」節にその変更を記載し、その他の節の古い情報は削除します。その要素がいつ実装されたかについては言及する必要はありません。「取引は1.3.1で実装された要素で、プレイヤーがエメラルド(以前はルビーと呼ばれていた)と他のアイテムとを交換することのできる機能である。」というような文章は、「取引は、プレイヤーがエメラルドと他のアイテムとを交換することができる機能である。」と記述すべきです。

ここでは、簡潔に書かれていない記事の例を紹介します。以下は、英語版での原木の記事の過去の版を日本語訳したもので、冒頭の文章の全文です。黄色で強調された箇所は冗長な情報で、桃色で強調された箇所は過去の情報です。

原木丸太としても知られている)は、Minecraft Creative mode 0.0.14aで追加されたブロックの一種である。4つの側面に樹皮のようなテクスチャがあり、上面と底面は切り株のようなテスクチャがある。Beta 1.2のアップデートとそれ以前のすべてのバージョンで生成されたチャンクでは、通常のオークのみが生成され、その後のバージョンのチャンクではマツとシラカバも生成される。原木は、自然生成されたマップ内に、樹木を構成するブロックとして非常に多く存在する。原木は素手で伐採することもできるが、斧を使うとより速く伐採できる。また、原木は燃えやすい性質を持つ。

現在の原木の種類の中では、シラカバが最も希少な種類である。これらは植物や樹木、木造の小屋によく使用されている。Survival Testでは原木を採掘すると木材が3–5個ドロップしていたが、Indev、Infdev、Alpha、Betaでは木材ではなく原木が1個ドロップする。これにより、原木を建築材料として使用したり、木材をクラフトしたりすることができるようになった。

原木の唯一のクラフトにおける用途は、4個の木材にすることである。また、木材はかまどで燃やすことで、石炭の代わりとなる木炭を作ることができる。

2011年1月13日のMinecraft Beta 1.2アップデートで、木材は4種類となった。通常の木(オーク)で、もう一つはシルバーバーチに似た木、もう一つは通常の木に似ているが色が濃く、より寒いバイオームに生育するマツの木や針葉樹のような木、4つ目はオークに似ているが色の違いがあり、一方に傾いている木である。これらの原木ブロックは、いずれも4個の木材へクラフトすることができる。インベントリ内では、異なる種類の原木はスタックできないが、それらの木材はスタックすることができる。異なる種類の原木からクラフトされた木材は、すべて同じ木材となる。シラカバの木は、葉の色が普通の木よりもややくすんでおり、マツの木には松葉があり、ジャングルの葉には実のようなものが付いており、葉が茂っている。

4つ目の原木は、スナップショット12w03aで追加されたもので、ジャングルバイオームにのみ生成され、ジャングルの樹木を構成している。最も高い木では、木の幹が通常の1×1ではなく2×2となっている。

この記事の問題点は、古い情報が新しい情報と一緒に記述されていることです。冒頭の文章では、現在のリリースのブロックの説明を記載すべきです。過去の情報を記載するのはよいことですが、分かりやすくするために記事の「歴史」節に、時系列でまとめて記載すべきです。

将来のアップデート[]

ショートカット

将来のアップデートで追加されるコンテンツは、{{upcoming}} を使用して示され、開発バージョンで登場した要素であれば、メインコンテンツの記事に追加することができます。アップデートにより記事への大きな変更を伴う場合は、その内容はメインセクションのサブセクションとして記述するか、「開発中」というような独自の節を設けて記述してください。また、将来のアップデートの要素は、適切な開発中ヘッダーを使用して歴史節に記載しなければなりません。

また、アップデートがリリースされた際には、古くなったコンテンツはすべて「歴史」節へ移動するか、削除しなければならず、使用されている {{upcoming}} もすべて除去しなければなりません。

本文の記述[]

メインの名前空間内のページでは、本文は「常体(である調)」を用いて記述します。ただし、チュートリアル以下の記事では「敬体(です・ます調)」を用いて記述します。また、メイン以外の名前空間では、原則として「敬体(です・ます調)」を用いて記述します。ただし、「利用者」名前空間はこの限りではありません。

語句の記述[]

ショートカット

ゲーム内のアイテム名などの語句は、正式リリースされたバージョンで使用されている日本語の翻訳文字列を採用してください。また、語句に含まれる空白文字は、除去して記述します(例:Bedrock Editionでの「レンガ ブロック」は「レンガブロック」と表記する)。

正式リリースされていないバージョンで新たに登場する要素

正式リリースされていないバージョンで新たに登場する要素は、そのバージョンが正式にリリースされるまでは英語表記のままとし、英語版クライアントで使用されている表記を採用します(英語版ウィキでは本文中では原則すべて小文字表記としており、表記方法が異なります)。また、要素が複数のエディションで登場する場合は、それらすべてのエディションのバージョンが正式リリースされるまで英語表記のままとします。

ゲーム内に登場しない語句

ゲーム内に登場しない語句(構造物やゲームの仕組みなどの名称)には、適切な日本語の名称を与えてください。ただし、その要素が正式リリースされていないバージョンで新たに登場するものである場合は、そのバージョンが正式にリリースされるまでは英語表記のままとし、語句に含まれる各単語の先頭を大文字にして表記をします(例:Basalt Pillar)。

エンチャント

エンチャントの最大レベルが2以上の場合、エンチャントのレベルをローマ数字(I、II、III、IV、V、…)で表記します。また、エンチャントの名称とレベルの間には半角スペースを記述します。

例:

シルクタッチ修繕効率強化 Vドロップ増加 III

セクションの見出し[]

ショートカット

記事のメインセクションは、レベル2ヘッダー(等号2個)で始め、サブセクションでは1レベル上げてください。レベル1ヘッダー(等号1個)は使用しないでください。

見出しにはリンクを含めないでください。リンクが必要な場合は、見出しの直後で {{main}} テンプレートを使用してください。

セクションとセクションの間は1行空け、等号とセクション名の間には半角スペースを記述します。{{main}} テンプレートやサムネイル画像を使用する場合は、セクションの見出しの直後にそれらを配置し、セクションの内容との間を1行空けてください。

空のセクションは記事に追加しないでください。

セクションの順序については、このスタイルガイドの記事のレイアウト節を参照してください。

斜体[]

Minecraft」と記述される箇所はすべて斜体にしなければなりません。また、コンピューターゲーム名などの著作物名は、日本語のタイトルは『』で、欧文のタイトルは '' で囲みます(例:Team Fortress 2)。

Java Edition」や「Education Edition」など、副題として使用されているMinecraftの公式のエディション名称は斜体にしなければなりません。それ以外の「Bedrock Edition」や「Legacy Console Edition」などのエディション名称は斜体にしてはなりません。

ただし、エディションの特定のバージョンを指す場合は斜体にしてはなりません。例えば、「Java Edition」が斜体であるのに対して、「Java Edition 1.16」は斜体にしません。

画像[]

ショートカット

記事にスクリーンショットを追加する際には、スクリーンショットがバニラのテクスチャとUIを使用していることを確認してください。カスタムテクスチャパックやUIの改変など、カスタムコンテンツを使用しているスクリーンショットは禁止されています。ただし、これはModに関する記事(これらは段階的に廃止されつつあります)には適用されません。

画像のキャプションには、文章が完全文でない限りは句点を付けてはなりません。

記事に追加する画像は、以下のガイドラインに沿ったものでなければなりません。

  • 画像は、その記事の主題の特性を示すものでなければなりません。
    • Mobが階段に「座っている」など、意図されていない奇妙な行動やユーモラスな振る舞いは避けてください。
    • バグの紹介をすることだけを目的として画像を使用しないでください。バグは公式トラッカーに報告してください。
    • プレイヤーの建造物の一部として特定の要素を使用している画像は避けてください。
  • 記事には、記事の内容の個々の特性を示す画像を1つだけ掲載するようにしてください。
  • 画像は、その要素が利用可能なMinecraftの最新のバージョンのものを示すものにしてください。
    • 古くなった画像は削除される場合があります。

リンク[]

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.

日付の書式[]

「12/10/11」のような日付の数字の省略形は、国や地域によって解釈の方法が異なり、例えばアジア諸国では「年/月/日」として、アメリカでは「月/日/年」として、それ他の多くの国や地域では「日/月/年」として解釈されます。こうした問題を避けるために、英語版では日付を「Month DD, YYYY」の形式で記述しています。日本語版では翻訳の際にこれらの日付を「YYYY年MM月DD日」の形式へ翻訳する必要があります。また、簡潔な書式での日付を(表などで)用いる場合は、表記の形式を「YYYY-MM-DD」とし、月と日の数字は常に2桁で表記します(例:2011-12-10、2012-05-04)。この形式はISO標準であり、ソートの際に適切に並べ替えが行われます。

コマンド[]

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.

  • 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.

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:

Advertisement