ヘルプ:スタイル

関連記事

• ヘルプ:スタイル/書式と句読点
• ヘルプ:スタイル/空白
• ヘルプ:編集
• ヘルプ:読み方
• ヘルプ:議論
• ヘルプ:テンプレート

以下のスタイルの取り決めは記事を引き締めて、まとめて、見た目を統一することが狙いです。ArchWiki を編集するときはできるかぎり守るようにしてください。

記事のページ

タイトル

• タイトルは先頭だけを大文字にしてください。例: "Title for new page" は正しいですが、"Title for New Page" は誤っています。正式名称や大文字の頭字語に含まれている常用語は大文字にしてください。例えば "Advanced Linux Sound Architecture" が正しく、"Advanced Linux sound architecture" は誤っています。
  名前空間はタイトルの一部として考えません。したがって "ArchWiki:Example article" が正しく、"ArchWiki:example article" は誤っています。サブページの名前の先頭は大文字にします。したがって "My page/My subpage" が正しく、"My page/my subpage" は誤っています。
• 通常は、タイトルのトピックは単数形にしますが、何かのグループやクラスなどを表していて可算名詞の場合は複数形にします。
• 記事の主題がフルネームでも、省略形でもどちらの名前でも知られている場合、記事のタイトルにはフルネームの方を使うほうが適しています。フルネームと省略形の両方を (括弧を使って) タイトルに入れるのは止めてください。代わりに省略形のページからフルネームのページに転送するようにします。
• 翻訳されたページのタイトルは必ずヘルプ:i18n#記事のタイトルに従ってください。
• 詳しくはヘルプ:記事命名ガイドラインを見てください。

レイアウト

• 記事の構成は以下の順番とします:

1. #マジックワード (任意)
2. #カテゴリ
3. #言語間リンク
4. #記事の状態テンプレート (任意)
5. #関連記事ボックス (任意)
6. #前書きや導入
7. 目次 (自動)
8. 記事のセクション

マジックワード

• 挙動スイッチ — そして一般に、記事に内容を追加するためには使用せず、その表示のされ方や挙動を変えるために使用するすべてのマジックワード — はすべて記事の最上部に配置してください。
  このルールは特に {{DISPLAYTITLE:title}} と テンプレート:Lowercase title に適用され、これらは前者を使用します。

カテゴリ

• どの記事も必ず最低1つ以上の現存しているカテゴリに分類してください。
• 1つの記事は複数のカテゴリに分類することができます。ただし、そのカテゴリ同士が親子関係であってはいけません。
• カテゴリは必ず記事の最上部 (何らかのマジックワードがあればそのすぐ下) に配置してください。
  ノート: これは、カテゴリを記事の最下部に配置する Wikipedia などの他の MediaWiki プロジェクトとは異なっています。
• カテゴリと本文の最初の行 (もしくは言語間リンクがある場合はそれ) の間に空行を含めないでください。記事の上部に余分な空白が挿入されてしまいます。
• 詳しくはヘルプ:カテゴリを見てください。

言語間リンク

• 記事が内部または外部の Arch Linux wiki で翻訳されていたら、必ず言語間リンクをカテゴリのすぐ下、本文の最初の行のすぐ上に配置してください。
  なお、言語間リンクは、実際にはページ左側の適切なカラムに表示されます。
• 言語間リンクと本文の最初の行の間に空行を含めないでください。記事の上部に余分な空白が挿入されてしまいます。
• 言語間リンクの追加、編集は、既に存在しているすべての翻訳記事に対して行ってください。
• 1つの言語に対して2つ以上の言語間リンクを記事に追加しないでください。
• 記事には、その記事の言語と同じ言語間リンクを追加しないでください。
• 言語間リンクは、言語の現地名ではなく、必ず言語タグ名に基づいてアルファベット順に並べてください。例えば、現地名では "Suomi" (フィンランド語) は "Français" (フランス語) の後に来ますが、言語タグ名では [[fi:Title]] (フィンランド語) は [[fr:Title]] (フランス語) の先に来ます。
• 詳しくは ヘルプ:i18n や Wikipedia:Help:言語間リンク の記事を見てください。

記事の状態テンプレート

• 記事の状態テンプレートはカテゴリ (もしくは言語間リンクがある場合はそれ) のすぐ下、イントロダクション (もしくは関連記事ボックスがある場合はそれ) のすぐ上に配置します。
• 記事の状態テンプレートは、その使用法が適切であれば、記事のセクションの中でも使用することができます。
• 記事の状態テンプレートを使用する際は必ず専用の欄に短い説明を加えてください (例はそれぞれのテンプレートページにあります)。必要であればトークページで議論を始めます。

関連記事ボックス

• ArchWiki 内部にある関連記事のシンプルなリストを提供します。
• 使用する場合は、カテゴリ (もしくは言語間リンクや記事の状態テンプレートがあればそれ) のすぐ下に配置してください。
• 関連記事ボックスは テンプレート:Related articles start と テンプレート:Related と テンプレート:Related articles end のみで構成されています。各ページのガイドラインを参照してください。
• 英語以外の言語で書かれた記事は、そのリンクの文字列を翻訳するために テンプレート:Related2 を使うことができます。
• もっと完全で詳しいリストがほしいときは "参照" セクション を使ってください。リンクの説明と wiki 間または外部サイトへリンクを含めることができます。

前書きや導入

• 記事の主題を記述します。
  ソフトウェアの説明は、(偏った見方になる可能性があるので) 自分の言葉で言い換えたり書いたりするより、アップストリームの著者が書いたものを使うとよいでしょう。これは (もし存在すれば) 大抵プロジェクトのホームページや about ページにあります。例として MediaTomb が挙げられます。
• 記事の最初のセクションのすぐ上に配置してください。
• 明示的に ==Introduction== や ==Preface== セクションを作らずに、最初のセクションの見出しの上に配置してください。目次は、十分な数のセクションが記事にあれば、自動的に前書きと最初のセクションの間に表示されます。
• 詳しくはヘルプ:記事の書き方を見てください。

セクションの見出し

• 見出しは2段階目から使ってください (==)。1段目は記事のタイトルに予約されています。
• サブセクションを作成するときは段階を飛ばさないでください。2段目のサブセクションは3段と続いていきます。
• 見出しは先頭だけ大文字にしてください。例: "My new heading" は正しいですが、"My New Heading" は誤っています。
• 見出しにリンクは使わないでください。スタイルが崩れます。普通は見出しではなくセクションの中身にアンカーテキストを記述します。以下のような文章を使って下さい:

詳しくは関連記事を参照してください。

同じく、HTML や wiki のマークアップコード、あるいはコードをフォーマットするテンプレートを見出しに使わないで下さい。ヘルプ:スタイル/書式と句読点も参照。

• 詳しくはヘルプ:効果的な見出しを見てください。

コードのフォーマット

• 短いコードやファイル名、コマンド名、変数などのインラインで表示したいものは {{ic|code}} を使います。例:
  コンソールで sh ./hello_world.sh を実行してください。

• (コマンドラインの入出力するコードやファイルの中身など) コードが一行で適切なフレームを付ける場合、半角スペースを前に付けます。ヘルプ:編集#コードを見てください。例:

$ sh ./hello_world.sh

Hello World

• 複数行のコード (コマンドラインの入出力やファイルの中身) に適切なフレームを付ける場合、{{bc|code}} を使います。例:

#!/bin/sh

# Demo
echo "Hello World"

• コマンドラインの入力と出力を両方表示する必要がある場合は、{{hc|input|output}} を使います。例:

$ sh ./hello_world.sh

Hello World

• ファイルの中身を表示する必要があり、そのコードがどのファイルを指しているか読者に伝わらないかもしれないときは、{{hc|filename|content}} を使うことで、見出しにファイル名を表示することもできます。例:

~/hello_world.sh

#!/bin/sh

# Demo
echo "Hello World"

• 設定ファイルのようなコードブロックについては、読者を関連のある行に集中させ、それ以外の周囲の無関連な内容を省略する (...) ことを考えてください。

• 詳しくはヘルプ:テンプレートを見てください。= や | などテンプレートを破壊する文字の対処法についても載っています。

コマンドラインのテキスト

• インラインコード (テンプレート:ic) 使う場合、プロンプト記号を表示する必要はありませんが、テキストの周囲に必ずパーミッションの注意書きを、はっきりとわかるように追加してください。
• ブロックコード (テンプレート:bc や空白文字で始まる行) を使う場合、一般ユーザのコマンドのプロンプトとして $ を、root のコマンドのプロンプトとして # を使います。
  ノート: # はテキストファイル内のコメントを示すのにも使われるため、通常はコマンドを実行するのかテキストファイルのコメントを示すのかを明確に説明し、曖昧な表現は必ず避けるようにしてください。
  • コマンドブロックの前置きとなる文の最後は、通常 : にしたほうがよいです。
  • 特別な事情がない限り、次を使います:

    # command

    次は使いません:

    $ sudo command

  • root プロンプトと sudo コマンドを次のように一緒に使わないでください:

    # sudo command

    唯一の例外は、sudo が -u フラグと一緒に使われる場合です: この場合、プロンプトを同じコードブロックの他のプロンプトに合わせることができます。それ以外では、デフォルトの $ を使ってください。
  • コマンドを含む同じ囲みにコメントを付け足さないでください。例:

    # pacman -S foo  #パッケージ foo をインストール

  • 極端に長いコードを書くのは避けてください。可能であれば改行をうまく使ってください。
• ユーザーの sudo や他の権限昇格ユーティリティ (例: gksu, kdesu) の使用を前提としないでください。

ファイル編集の記述

• テキストファイルの編集する必要がある場合、原則、特定のテキストエディタ (nano, vim, emacs など) の使用を前提としないでください。
• テキストファイルを編集する必要がある場合、厳密な理由がない限り、間接的なコマンドを使わないでください。例えば $ echo -e "clear\nreset" >> ~/.bash_logout は次のようにします:

~/.bash_logout に以下の行を付け加えます:

clear
reset

適切な場所に ヘルプ:読み方#追加, 作成, 編集 そして source へのリンクを追加するのも良いでしょう。

キーボードキー

• 記事内でのキーボードキーの表示は、通常、テンプレート:ic のインスタンスを使います。
• 文字キーは小文字で表示します: a。大文字を表示するには Shift+a を使います。Shift+A や A は使いません。
• キーの 組み合わせ は、+ 記号を用い、その両端に空白文字を付けずにそれぞれのキーを結合するのが正しい表示の仕方です: Ctrl+c。
  Ctrl + c, Ctrl+c, Ctrl-c は準拠していない書式なので、使用は避けてください。
• キー入力の 流れ は、冗長に説明 (例: Shift+t に続けて g を押します) するか、それぞれのキーにテンプレートの別々のインスタンスを用いて、それらを1個の半角スペースで区切って簡潔に説明するのが正しい表示の仕方です: g Shift+t。
• 特別なキーの組み合わせの標準的な表示方法を以下にいくつか示します:
  • Shift (SHIFT ではありません)
  • Ctrl (CTRL や Control ではありません)
  • Alt (ALT でありません)
  • Super (Windows や Mod ではありません)
  • Enter (ENTER や Return ではありません)
  • Esc (ESC や Escape ではありません)
  • Space (SPACE ではありません)
  • Backspace
  • Tab
  • Ins (INS や Insert ではありません)
  • Del (DEL や Delete ではありません)
  • PrintScreen
  • PageUp
  • PageDown

パッケージ管理の記述

公式パッケージ

• 公式パッケージのインストールの説明に、pacman のコマンド例を挙げないでください: この規則は、シンプルであるために (すべての Arch ユーザは、pacman の記事内容を知っておくべきです)、そして pacman -Sy package のようなコマンドで起こりうるエラーや、pacman -S package か pacman -Syu package のどちらを選ぶかのような、起こるかもしれない終わりのない議論を避けるために作られました。そのため、pacman のフロントエンドやラッパーの使用を提案してはいけません。

代わりに、以下のような記述を使ってください:

foobar パッケージをインストールしてください。

もしくは、アプリケーションの名前がパッケージの名前と異なっている場合:

MyApplication は my-app-pkg パッケージでインストールできます。

複数のパッケージをインストールするように書きたいときは以下のようになります:

foobar1, foobar2, foobar3 パッケージをインストールしてください。

パッケージグループを参照するときは以下を使用:

foobar グループをインストールしてください。

記事に合わせて言い回しを変えても構いません。

• 言及したパッケージのリンクは必ず貼り、テンプレート:Pkg を使ってください。例: {{Pkg|foobar}}。
• パッケージグループの参照する場合は、代わりに テンプレート:Grp を使ってください。例: {{Grp|foobar}}。
• 上記の例ではインストールのリンクを利用しています (例: [[install]]): インストールの指示が初めて出てくるところでは必ずリンクを使うことを推奨します。特に、Arch 初心者がアクセスするようなページのときはリンクを絶対に付けてください。
• メンテナンスを容易にするために、パッケージが core、extra、または community リポジトリでホストされている場合は、そのリポジトリを参照しないでください。パッケージが別のリポジトリに移されるのはよくあることです。ただし、そのパッケージがデフォルトでは有効化されていない公式リポジトリ (multilib、testing など) でホストされている場合は、以下のようにして言及する必要があります:

foobar パッケージを公式の multilib リポジトリからインストールしてください。

AUR パッケージ

• AUR パッケージのインストール手順の例は挙げないでください。公式の手順を説明したり、AUR ヘルパーについて述べたりしないでください。非公式パッケージをインストールしようとする全てのユーザーは、事前に Arch User Repository に目を通しておき、システムで起こりうるあらゆる結果を把握しておいてください。

代わりに、以下のように簡潔に述べてください:

foobar^AUR パッケージをインストールします。

記事に合わせて言い回しを変えても構いません。より多くの例については#公式パッケージを見てください。

• 言及したパッケージのリンクは必ず貼り、テンプレート:AUR を使ってください。例: {{AUR|foobar}}。

非公式リポジトリ

• ビルド済みのパッケージをインストールするために、非公式リポジトリの使用を提案するときは、リポジトリを有効化する方法は書かないでください。そのリポジトリが非公式ユーザーリポジトリにかかれていることを確認して、ページヘのリンクを張ってください。また、公式パッケージと同様に、pacman コマンドの例は不要です。例:

example リポジトリから foobar パッケージをインストールしてください。

パッケージが AUR からもインストールできる場合:

foobar^AUR パッケージをインストールしてください。このパッケージは example リポジトリからインストールすることもできます。

パッケージが AUR とは違う名前で存在している場合:

aurpkg^AUR パッケージをインストールしてください。example リポジトリの builtpackage でもインストールできます。

記事に合わせて言い回しを変えても構いません。

• 非公式ユーザーリポジトリへのリンクは絶対で、適切なリポジトリセクションにリンクしてください。例: [[Unofficial user repositories#example|example]]。

systemd ユニットの操作

• systemctl を用いた systemd ユニットの有効化、起動、またはその他の基本的操作の例は挙げないでください。代わりに、関連するユニットを挙げて簡潔に説明してください。他のユニットとの依存関係または競合、そして行うべき操作についての説明が必要な場合は述べてください。

ブート時に GDM を起動させるには、gdm.service を有効化してください。例:

または、ユニットがインスタンス化する必要があるテンプレートである場合:

無線インターフェイスの netctl プロファイルを自動的に切り替えるようにするには、インターフェイスの名前を指定して netctl-auto@.service のインスタンスを有効化してください。例: netctl-auto@wlan0.service。

記事に合わせて言い回しを変えても構いません。

systemd#ユニットを使う の記事セクションへのリンクを、直接、または [[start]] や [[enable]]、 [[stop]] のような専用のリダイレクト を通して必ず貼ってください。

ノート・警告・ヒント

• ノートは、当然のこととして期待するようなことが、ユーザー毎に異なる恐れがある記事中の箇所で情報を示すのに使います。これは、特に、使わなければ記事の本筋から少々外れてしまうと考えられるものに関する詳細な情報を示すのにも使います。もう1つの例として、パッケージ名の変更のような一時的なアナウンスを告知する必要がある場合が挙げられます。

ノートは、重要であるけれど、主題の領域に関してよく知らない場合に見落としやすい情報を目立たせるのに使うこともできます。

• 警告は、説明された手順によって元に戻すことがかなり難しくなったり、システムにダメージを与えてしまうような深刻な結果をもたらしてしまう可能性がある箇所で使用します。通常、警告は、起こりうる最悪のケースが発生するような、またはそれを避けるような状態だけではなく、そのようなケースのシナリオの両方を示します。

基本的には警告を多用しないでください: 警告を使用するべきかわからないときは、多くの場合ノートを使ったほうがよいです。

• ヒントは、役に立ち、誰かのメリットになるような方法や手順を示すときに使います。これは、扱っている操作を完了させるには必要がないため、無視しても問題ありません。
• 2つ以上のノートや警告、ヒントを記事の同じ箇所に連続して表示する必要がある場合、1つのテンプレート中のリストにテキストをまとめてください。それらの内容に関連性が全くない限りは、テンプレートを積み重ねないでください。例:

ヒント:

• ヒント例 #1.
• ヒント例 #2.

シェル

• 本当に必要でない限りは、ユーザーのシェルとして特定のシェル (例: Bash) の使用を前提としないでください: 記事を書いたり編集する場合は、可能な限りどのシェルでも実行できるようにしてください。

ハイパーテキスト

• 書いた記事を、テキスト中に様々なキーワードを用いて、可能な限り多くの他の記事に内部リンクしてください。
• 新しい記事へのリンクは記事作成後にしてください。基本的に存在しない記事へのリンクは作成しないでください。
• システムコールなどの専門用語で、ArchWiki の記事でカバーされていないものは、Wikipedia の関連するページにリンクしてください。
• wiki の他の記事にリンクするときは、URL を使ってはいけません。内部リンクを利用するようにしてください: [[Wiki の記事]]。wiki エンジンが内部リンクを追跡できるようにすることで、メンテナンスが楽になります。
  内部リンクの使用法に関する詳細はヘルプ:編集#リンクを見てください。
  • 同じページのセクションにリンクするときは、アンカー記号を隠さないでください (例: [[#ドキュメントのセクションへのリンク|ドキュメントのセクションへのリンク]])。書式の再設定が不要になるのに加え、アンカーによってリンク先が完全な1つの記事ではなく、記事のセクションへのものであることを明確に示せます。
• できる限り間接的なリンクはしないでください。例えば、"詳しくはここを見てください" ではなく "詳しくは systemd の記事を見てください" のように指示します。
• 稀なケースを除いて、記事を行き止まりページ (他のどの記事にもリンクしていない記事) や孤児ページ (他のどの記事からもリンクされていない記事) のままにしないでください。
• 記事に具体的な処理を書いたり、特別なことを述べる前に、それらを詳細に扱った記事が既に存在していないか常に確認してください: 存在する場合は、内容を重複させずにその記事にリンクしてください。
• 記事の主題がアップストリームのドキュメントによく書かれ維持されている場合は、Arch 特有の対応だけを記述し、一般的な情報については公式ドキュメントにリンクしてください。
• 編集中の記事と同じ言語でローカライズされたページヘのリンクには、特別:リンク元ページに表示されなくなってしまうので、wiki 間リンクを使わないでください。例えば、ハンガリー語の記事では [[Main page (Magyar)]] を使うのが正しく、 [[:hu:Main page]] を使うのは誤っています。
  分離された wiki が将来作られたときに、記事をその wiki に移動させやすくするため、代わりにこの種のリンクを他言語間に使うのは容認されています。
  最後に、この種のリンクと #言語間リンク との違いについて言及しますが、言語間リンクには最初にコロンが付きません。

コーディングスタイル

• コマンドやスクリプトを追加するときは、記事全体を通して一貫したコーディングスタイルを用いてください。特に、他に関連のある記事がある場合は、その記事にもこれが当てはまります。使用する言語の公式または最も一般的なコーディングスタイルのガイドラインが利用可能であれば、それを順守してください。
• 使用するプログラミング/スクリプト言語の非推奨な機能は使わないでください。例: シェルのコマンド置換には、バックティック/グレイヴ (``) 構文は使わず、$() 構文を使ってください。

サポートするカーネルのバージョン

• core リポジトリにある最新の linux-lts パッケージと最新のインストールメディアのうち、低いほうのバージョン以上のカーネルバージョンに関わるあらゆるノートや対応は削除してはいけません。

"Tips and tricks" セクション

• Tips and tricks セクションでは、高度なヒントやソフトウェアの使用例を提供します。
• タイトルは Tips and tricks で統一してください。
• Tips and tricks の内容が多岐にわたる場合、サブセクションにしてまとめてください。

"トラブルシューティング" セクション

• トラブルシューティングセクションは、ソフトウェアやよくある問題の解決策に関する、頻繁に尋ねられる質問のために使います (#"既知の問題" セクション と比べてみてください)。
• タイトルはトラブルシューティング (訳註: 英語版は Troubleshooting) で統一してださい。(訳注: 英語版では) Trouble shooting、Trouble-shooting、そして TroubleShooting は、よくあるスペルミスなので使わないでください。
• 既知のバクに対する一時的な応急処置を報告することもできますが、その場合、そのバグ報告へのリンクを提供することが強く望まれます。まだ報告されていない場合は、自分で報告してください。そうすることで、そのバグが適切に修正される可能性が増します。
  バグ報告をリンクすることは、読者と編集者の双方にとって大きなメリットがあります:
  • 読者にとって、この Wiki が停止点ではなくなります: リンクしなければ頑張って検索しても見逃してしまったかもしれない、ソースに近い情報を見つけられるようになります。
  • Wiki の編集者にとって、報告されたバグが依然として問題になっているかどうかを確認する手間が省け、整理が楽になります: これは、読者が新しい情報を見つけ、wiki を編集しに戻って来るようになった場合、自律性の向上さえももたらすかもしれません。

"既知の問題" セクション

• 既知の問題 セクションは、既知のバグやまだ解決策が存在しない利用上の問題のために使います (#"トラブルシューティング" セクション と比べてみてください)。
• タイトルは既知の問題で統一してください。
• バグが既知の問題として報告されている場合、その報告へのリンクを提供することが強く望まれます; 報告されていない場合は、自分で報告してください。そうすることで、バグが修正される可能性が増します。

"参照" セクション

• See also sections contain a list of links to references and sources of additional information.
• This should be a list where each entry is started with *, which creates a MediaWiki bulleted list.
• Use the standard title of See also. Other similar titles such as External links, More resources, etc. should be avoided.

適切ではない記述

• Please do not sign articles, nor credit article authors: the ArchWiki is a work of the community, and the history of each article is enough for crediting its contributors.
  Reporting the sources used to write an article, though, is good practice: you can use the "See also" section for this purpose.
• Uploading files is disabled for normal users, and including the existing images in articles is not allowed. As an alternative you can include links to external images or galleries, and if you need to draw simple diagrams you may use an ASCII editor like Asciiflow. Rationale:
  • Maintenance: Arch is rolling release, and images would make updating articles much more difficult.
  • Necessity: Arch does not develop nor maintain any sort of GUI application, so we do not need to display any screenshot.
  • Moderation: free image upload would require time to be spent removing oversized or inappropriate images.
  • Accessibility: we support users with slow connections, text-only browsers, screen readers and the like.
  • Efficiency: images waste server bandwidth and storage space.
  • Simplicity: text-only articles just look simpler and tidier.

言語使用域

• Articles should be written using formal, professional, and concise language. Care should be taken to remove grammar and orthography errors through edit previews and proofreading.
• Remember not only to answer how, but also why. Explanatory information always goes further toward imparting knowledge than does instruction alone.
• Avoid contractions: "don't", "isn't", "you've", etc. should be "do not", "is not", and "you have", for example.
• Avoid unnecessary shortening of words: for example, instead of "repo", "distro", and "config", prefer "repository", "distribution", and "configuration".
  In the same fashion, prefer using the long form of uncommon command options instead of their single-character counterpart.
• Do not omit terms that are necessary to give an exact, unambiguous meaning to a sentence. For example, always add the word "repository" when mentioning the name of a repository.
• Do not use indefinite time references such as "currently", "at the time of writing" or "soon"; replace them with definite expressions such as "as of May 2015" etc.
• Write objectively: do not include personal comments on articles; use discussion pages for this purpose. In general, do not write in first person.
• When editing content, be consistent with the style used in the rest of the article. For example, if the reader is always addressed using the second person, this style should be adopted by the added content; the same goes if third person or passive voice are clearly dominant throughout the article.
• When offering a choice among different options (pieces of software, methods to do something, etc.) do not explicitly recommend one over the others, but objectively describe the advantages and disadvantages of each, thus helping the reader to make the best decision for his personal case.

カテゴリのページ

• 全てのカテゴリは最低でも一つの親カテゴリの下にカテゴライズされなければなりません。ただし、ルートカテゴリ (カテゴリ:アーカイブ, カテゴリ:目次, カテゴリ:メンテナンス) は例外です。
• A category can be categorized under more than one category, provided one is not ancestor of the others.
• Avoid circular relationships: two categories cannot be reciprocal ancestors.
• Do not categorize a category under itself (self-categorized category).
• Categories must be included at the top of the category page.
• Categories should not redirect, except temporarily during renaming.
• By default, category names should be in the singular form ("topic" categories); they should be in the plural form if the singular form can be used to describe one of its members ("set" categories).

リダイレクトのページ

• 転送ページにはリダイレクトのコード以外は含めてはいけません。唯一の例外:
  • アーカイブページはリダイレクトですが、カテゴリ:アーカイブにカテゴライズされます。
• リダイレクトは内部の記事に限ります。wiki 間のリダイレクトは作成してはいけません。

言語間リンクを使用するリダイレクトはヘルプ:i18n の決まりにしたがってArchWiki:管理者からの許可が得られた場合にのみ例外的に可能となります。

ユーザーのページ

• Pages in the User namespace cannot be categorized.
• Pages in the User namespace can only be linked from other pages in the User or talk namespaces, unless authorization to do otherwise is given by Administrators.

共通ルール

編集内容の要約

ヘルプ:編集を見てください。

HTML タグ

• HTML タグの利用は基本的に推奨されません。できるかぎり wiki のマークアップとテンプレートを使うようにしてください。ヘルプ:編集を参照。
• When tempted to use <pre>code</pre>, always resort to {{bc|code}}. When tempted to use <tt>text</tt> or <code>text</code>, always resort to {{ic|text}}.
• 特に HTML コメントは使わないようにしてください (<!-- comment -->): HTML コメントで追加するようなノートは記事の議論ページに投稿してください。
  コメントを書くところには適当な記事の状態テンプレートを追加してください。
• Use <br> only when necessary: to start a new paragraph or break a line, put a blank line below it.
  Common exceptions to this rule are when it is necessary to break a line in a list item and you cannot use a sub-item, or inside a template and you cannot use a list.