ヘルプ:スタイル

関連記事

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

以下のスタイルの取り決めは記事を引き締めて、まとめて、見た目を統一することが狙いです。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" は誤っています。
• 通常は、タイトルのトピックは単数形にしますが、何かのグループやクラスなどを表していて可算名詞の場合は複数形にします。
• 記事の主題がフルネームでも、省略形でもどちらの名前でも知られている場合、記事のタイトルにはフルネームの法を使うほうが適しています。フルネームと省略形の両方を (括弧を使って) タイトルに入れるのは止めて下さい。代わりに省略形のページからフルネームのページに転送するようにします。
• 詳しくはヘルプ:記事命名ガイドラインを見て下さい。

レイアウト

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

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

マジックワード

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

カテゴリ

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

言語間リンク

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

記事の状態テンプレート

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

関連記事ボックス

• Provides a simple list of related internal articles.
• Optionally included right below categories (or interlanguage links, or Article status templates, if present).
• It can only be made of Template:Related articles start, Template:Related and Template:Related articles end. See also the guidelines in those pages.
• Non-English articles can make use of Template:Related2 for translating the anchor text.
• Use the "See also" section for a more complete and detailed list that also includes link descriptions and interwiki or external links.

前書きや導入

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

セクションの見出し

• Headings should start from level 2 (==), because level 1 is reserved for article titles.
• Do not skip levels when making subsections, so a subsection of a level 2 needs a level 3 heading and so on.
• Headings use sentence case; not title case: My new heading; not My New Heading.
• Avoid using links in headings because they break style consistency and do not stand out well enough. Usually the anchor text is also found in the section content, otherwise you can use a simple sentence like:

See Some related article for more information.

For the same reason, also avoid using any kind of HTML or wiki markup code, including #Code formatting templates. See also Help:Style/Formatting and punctuation.

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

コードのフォーマット

• Use {{ic|code}} for short lines of code, file names, command names, variable names and the like to be represented inline, for example:
  Run sh ./hello_world.sh in the console.

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

$ sh ./hello_world.sh

Hello World

• Use {{bc|code}} for multiple lines of code (command line input or output code and file content) to be represented in a proper frame, for example:

#!/bin/sh

# Demo
echo "Hello World"

• Use {{hc|input|output}} when in the need of representing both command line input and output, for example:

$ sh ./hello_world.sh

Hello World

• When you need to represent file content and you feel it may be difficult for readers to understand which file that code refers to, you can also use {{hc|filename|content}} to show the file name in the heading, for example:

~/hello_world.sh

#!/bin/sh

# Demo
echo "Hello World"

• For blocks of code such as a configuration file, consider focusing the reader to the relevant lines and ellipsing (...) any surrounding, non-relevant content.

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

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

• When using inline code (Template:ic), no prompt symbol is to be represented, but any notes about permissions must be added explicitly to the surrounding text.
• When using block code (Template:bc or lines starting with a space character), use $ as a prompt for regular user commands; use # as a prompt for root commands.
  ノート: Because # is also used to denote comments in text files, you should always make sure to avoid ambiguities, usually by explicitly writing to run the command or edit a text file.
  • The sentence introducing a command block should usually end with :.
  • Unless really necessary, prefer using:

    # command

    instead of writing:

    $ sudo command

  • Do not use the root prompt and the sudo command together, like in:

    # sudo command

    The only exception is when sudo is used with the -u flag: in this case the prompt can match the others of the same code block, or default to $.
  • Do not add comments in the same box of a command, for example:

    # pacman -S foo  #Install package foo

  • Avoid writing excessively long lines of code: use line-breaking techniques when possible.
• Do not assume the user uses sudo or other privilege escalation utilities (e.g. gksu, kdesu).

ファイル編集の記述

• Do not assume a specific text editor (nano, vim, emacs, etc.) when requesting text file edits, except when necessary.
• Do not use implicit commands to request text file edits, unless strictly necessary. For example, $ echo -e "clear\nreset" >> ~/.bash_logout should be:

Append the following lines to ~/.bash_logout:

clear
reset

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

キーボードキー

• The standard way to represent keyboard keys in articles is using instances of Template:ic.
• Letter keys should be represented in lower case: a. To represent upper-case letters, use Shift+a instead of Shift+A or A.
• The correct way to represent key combinations makes use of the + symbol to join keys, with no additional spaces around it, in a single instance of the template: Ctrl+c.
  Ctrl + c, Ctrl+c, Ctrl-c are non-compliant forms, and should be avoided.
• The correct way to represent key sequences is either verbose, e.g. "press g followed by Shift+t", or concise, separating the keys with a single space in different instances of the template: g Shift+t.
• The following are the standard ways of representing some special keys:
  • Shift (not SHIFT)
  • Ctrl (not CTRL or Control)
  • Alt (not ALT)
  • Super (not Windows or Mod)
  • Enter (not ENTER or Return)
  • Esc (not ESC or Escape)
  • Space (not SPACE)
  • Backspace
  • Tab
  • Ins (not INS or Insert)
  • Del (not DEL or Delete)
  • PrintScreen
  • PageUp
  • PageDown

パッケージ管理の記述

公式パッケージ

• Please avoid using examples of pacman commands in order to give instructions for the installation of official packages: this has been established both for simplicity's sake (every Arch user should know pacman's article by memory) and to avoid errors such as pacman -Sy package or possibly never-ending discussions like the choice between pacman -S package and pacman -Syu package. All the more reason you should not suggest the use of pacman frontends or wrappers.

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

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

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

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

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

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

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

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

You are granted the flexibility to adapt the wording to your specific article.

• Links to the referenced packages are mandatory and should be created using Template:Pkg, for example {{Pkg|foobar}}.

When referring to package groups, Template:Grp should be used instead, for example {{Grp|foobar}}.

• 上記の例ではインストールのリンクを利用しています (例: [[install]]): インストールの指示が初めて出てくるところでは必ずリンクを使うことを推奨します。特に、Arch 初心者がアクセスするようなページのときはリンクを絶対に付けて下さい。
• pacman コマンドの例を書くことは推奨されていませんが、ビギナーズガイドでは例外的に推奨されています。
• If the package is hosted in the core, extra, or community repositories, do not make reference to the repository, thus facilitating maintenance because it is not uncommon for a package to be moved to a different repository. If however the package is hosted in an official repository which is not enabled by default (multilib, testing, etc.), mentioning it is required, using a wording like:

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

AUR パッケージ

• Please avoid using examples of how to install AUR packages, neither with the official method nor mentioning AUR helpers: every user who installs unofficial packages should have read the Arch User Repository article, and be aware of all the possible consequences on his system.

Instead, just use a simple statement like:

Install the foobar^AUR package.

You are granted the flexibility to adapt the wording to your specific article, see the section on #Official packages for more examples.

• Links to the referenced packages are mandatory and should be created using Template:AUR, for example {{AUR|foobar}}.

非公式リポジトリ

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

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

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

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

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

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

You are granted the flexibility to adapt the wording to your specific article.

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

systemd ユニットの操作

• Do not give examples of how to enable, start, or perform any other basic operations with systemctl on systemd units. Instead, use a simple sentence listing the units involved, possibly remarking dependencies or conflicts with other units, and a description of the actions to be performed. For example:

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

Or, if for example the unit is a template that needs instantiation:

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

You are granted the flexibility to adapt the wording to your specific article.

• Make sure to link to the systemd#Using units article section, either directly or through a dedicated redirect like [[start]], [[enable]] or [[stop]].
• systemctl コマンドの例は記述する必要ありませんがビギナーズガイドでは例外的に記述してください。

ノート・警告・ヒント

• A Note should be used for information that somehow diverges from what the user would naturally expect at some point in the article. This includes also information that gives more in-depth knowledge on something in particular that otherwise would be considered a bit extraneous to the article. Another example is when needing to point out a temporary announcement like a change in the name of a package.

A Note can also be used to highlight information that is important but easily overlooked by someone new to the subject area.

• A Warning should be used where the described procedure could carry severe consequences such as being reasonably difficult to undo or resulting in damage to the system. Warnings should generally indicate both the worst case scenarios as well as the conditions that could lead to or avoid such worst cases.

In general, do not abuse Warnings: if you are undecided, chances are high that you should use a Note.

• A Tip should indicate a method or procedure that could be useful and bring benefits to somebody, albeit not needed to complete the operation being dealt with, and therefore safely ignorable.
• When two or more notes, warnings or tips have to appear one after each other at the same point of an article, prefer grouping their texts in a list inside a single template, avoiding stacking the templates unless they are completely unrelated. For example:

ヒント:

• Tip example #1.
• Tip example #2.

シェル

• Do not assume a particular shell as the user's shell (e.g. Bash), except when really needed: try to be as shell-neutral as possible when writing or editing articles.

ハイパーテキスト

• Try to interlink your article with as many others as you can, using the various keywords in the text.
• Only link to a new article after creating it. In general, do not create links to non-existent articles.
• For technical terms, such as system call, not covered by an article in the ArchWiki, link to the relevant Wikipedia page.
• wiki の他の記事にリンクするときは、URL を使ってはいけません。内部リンクを利用するようにしてください: [[Wiki Article]]。wiki エンジンが内部リンクを追跡できるようにすることで、メンテナンスが楽になります。
  内部リンクの使用法に関する詳細はヘルプ:編集#リンクを見て下さい。
• Avoid implicit links whenever possible. For example, prefer instructions like "See the systemd article for more information" instead of "See here for more information".
• Except in rare cases, you should not leave an article as a dead-end page (an article that does not link to any other) or an orphan page (an article that is not linked to from any other).
• Before writing a specific procedure in an article or describing something in particular, always check if there is already an article that treats that part in detail: in that case, link that article instead of duplicating its content.
• If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information.
• Do not use interwiki links for links to localized pages of the same language of the article being edited because they will not be shown in Special:WhatLinksHere pages. For example, using [[:hu:Main page]] in a Hungarian article is wrong, while [[Main page (Magyar)]] is correct.
  Using this kind of links between different languages is instead acceptable because this would make it easier to move the articles to a separate wiki in case a separate wiki is created in the future.
  Finally, note the difference of this kind of links from #Interlanguage links, which do not have the colon at the beginning.

コーディングスタイル

• When adding commands or scripts, use a consistent coding style throughout the article, possibly also referring to the other articles, especially if there are any related ones. If available, respect the official or most common coding style guidelines for the language.
• Avoid deprecated features of the programming/scripting language you are using: for example, use the $() syntax for shell command substitution instead of the backticks/grave (``) syntax.

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

• Do not remove any notes or adaptations regarding kernel versions greater than or equal to the minimum version between the current linux-lts package in the core repository and the kernel on the latest installation media.

"Tips and tricks" セクション

• Tips and tricks sections provide advanced tips or examples of using the software.
• Use the standard title of Tips and tricks.
• The various tips and tricks should be organized in subsections.

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

• Troubleshooting sections are used for frequently asked questions regarding the software or for solutions to common problems (compare to #"Known issues" sections).
• Use the standard title of Troubleshooting. Common misspellings that should be avoided are Trouble shooting, Trouble-shooting, and TroubleShooting.
• You can also report temporary workarounds for known bugs, but in this case, it is very desirable that you provide a link to the bug report. In case it has not been reported yet, you should report it yourself, thus increasing the chances that the bug will be properly fixed.
  There are great benefits in linking to a bug report both for readers and editors:
  • For readers, the Wiki does not become a stopping point: they can find more information close to the source that may have otherwise been missed by their search efforts.
  • For Wiki editors, it makes cleanup easier by reducing the effort involved in researching whether the reported bug is still an issue; this can even lead to greater autonomy if the reader finds new information and comes back to edit the wiki.

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

• Known issues sections are used for known bugs or usage problems which do not have a solution yet (compare to #"Troubleshooting" sections).
• Use the standard title of Known issues.
• If a bug report exists for the known issue, it is very desirable that you provide a link to it; otherwise, if it does not exist, you should report it yourself, thus increasing the chances that the bug will be fixed.

"参照" セクション

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

カテゴリのページ

• Every category must be appropriately categorized under at least one parent category, except for root categories, which are :Category:DeveloperWiki, :Category:Languages, :Category:Maintenance and :Category:Sandbox.
• 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).

リダイレクトのページ

• Redirect pages should contain only the redirect code and nothing else. In rare cases, they can also contain a flag such as Template:Deletion.
• Redirect only to internal articles; do not use interwiki redirections.

Redirects using interlanguage links are exceptionally allowed in accordance with Help:I18n and upon authorization from the ArchWiki:Maintenance Team.

ユーザーのページ

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