These ArchWiki style conventions encourage tidy, organized, and visually consistent articles. Follow them as closely as possible when editing the wiki.

+

These style conventions encourage tidy, organized, and visually consistent articles. Follow them as closely as possible when editing the ArchWiki.

==Article pages==

==Article pages==

===Title===

===Title===

−

*Prefer using a full name (as opposed to an acronym) in the title of an article. If both are commonly used, use a [[Wikipedia:Help:Redirect|redirect]] on the acronym page. Do not include both the full name and the acronym (e.g. in parentheses) in the title.

+

*If the subject of the article is commonly known both with the full name and the acronym, prefer using the full name in the title of the article. Do not include both the full name and the acronym (e.g. in parentheses) in the title, but rather use a [[Help:Editing#Redirects|redirect]] on the acronym page that points to the page titled with the full name.

*See also [[Article Naming Guidelines]].

*See also [[Article Naming Guidelines]].

===Layout===

===Layout===

*Order elements in an article as follows:

*Order elements in an article as follows:

−

#[[#Categories|Categories]]

+

#[[#Magic words]] (optional)

−

#[[#i18n template|i18n template]]

+

#[[#Categories]]

−

#[[#Interlanguage links|Interlanguage links]] (optional)

+

#[[#Interlanguage links]]

−

#[[#Article status templates|Article status templates]] (optional)

+

#[[#Article status templates]] (optional)

−

#[[#Article summary|Article summary]] (optional)

+

#[[#Article summary]] (optional)

−

#[[#Preface or introduction|Preface or introduction]]

+

#[[#Preface or introduction]]

#Table of contents (automatic)

#Table of contents (automatic)

#Article-specific sections

#Article-specific sections

+

+

===Magic words===

+

*Behavior switches, and in general all the [[mw:Help:Magic words|magic words]] that change how an article is displayed or behaves but do not add content by themselves, should all go at the very top of the articles. <br> This rule applies in particular to {{ic|<nowiki>{{DISPLAYTITLE:title}}</nowiki>}} and [[Template:Lowercase title]], which makes use of the former.

===Categories===

===Categories===

*Every article must be categorized under at least one existing category.

*Every article must be categorized under at least one existing category.

*An article can belong to more than one category, provided one is not ancestor of the others.

*An article can belong to more than one category, provided one is not ancestor of the others.

−

*Categories must be included at the top of every article. {{Note|This is different from some other MediaWiki projects such as Wikipedia, which include categories at the bottom.}}

+

*Categories must be included at the top of every article, right below any magic words. {{Note|This is different from some other MediaWiki projects such as Wikipedia, which include categories at the bottom.}}

−

*There should be no blank lines between categories and the i18n bar, because this introduces extra space at the top of the article.

+

*There should be no blank lines between categories and the first line of text (or interlanguage links, if present), because this introduces extra space at the top of the article.

*See also [[Recategorizing Pages]].

*See also [[Recategorizing Pages]].

−

−

===i18n template===

−

*[[Template:i18n]] should be put on every article, right below the categories.

−

*See also [[Help:i18n]].

===Interlanguage links===

===Interlanguage links===

−

*If the article has a corresponding page in an Arch Linux wiki for another language, interlanguage links can be included right below the i18n template. <br> Note that they will actually appear in the appropriate column to the left side of the page.

+

*If the article has translations in the local or an external Arch Linux wiki, interlanguage links must be included right below the categories and above the first line of text. <br> Note that they will actually appear in the appropriate column to the left side of the page.

−

*When adding or editing interlanguage links you should take care of repeating your action for all the translations of the article which are accessible in the i18n bar.

+

*There should be no blank lines between interlanguage links and the first line of text, because this introduces extra space at the top of the article.

−

*See also [[Wikipedia:Help:Interlanguage links]].

+

*When adding or editing interlanguage links you should take care of repeating your action for all the already existing translations.

+

*Do not add more than one interlanguage link for each language to an article.

+

*Do not add interlanguage links for the same language of the article.

+

*The interlanguage links must be sorted alphabetically based on the language tag, not the local name, so for example {{ic|<nowiki>[[fi:Title]]</nowiki>}} comes before {{ic|<nowiki>[[fr:Title]]</nowiki>}} even though "Suomi" would come after "Français".

+

*See also [[Help:i18n]] and [[Wikipedia:Help:Interlanguage links]].

===Article status templates===

===Article status templates===

−

*[[:Category:Template#Article_status_templates|Article status templates]] can be included right below [[Template:i18n]] and right above the Article Summary.

+

*[[:Category:Template#Article_status_templates|Article status templates]] can be included right below the categories (or interlanguage links, if present) and right above the Article Summary.

*Article status templates can also be used inside article sections, when appropriate.

*Article status templates can also be used inside article sections, when appropriate.

*Article status templates should always be accompanied by at least some words of explanation in the talk page.

*Article status templates should always be accompanied by at least some words of explanation in the talk page.

Line 50:

Line 55:

===Article summary===

===Article summary===

*Describes the structure and scope of the article.

*Describes the structure and scope of the article.

−

*Optionally included right below [[Template:i18n]] or Article status templates, if present.

*Use {{ic|<nowiki>{{ic|code}}</nowiki>}} for short lines of code, file names, command names, variable names and the like to be represented inline, for example: <br> foo {{ic|code}} bar.

+

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

*Use {{ic|<nowiki>{{bc|code}}</nowiki>}} for single or multiple lines of code (command line input or output code and file content) to be represented in a proper frame, for example:

*Use {{ic|<nowiki>{{bc|code}}</nowiki>}} for single or multiple lines of code (command line input or output code and file content) to be represented in a proper frame, for example:

−

{{bc|# iwconfig}}

+

{{bc|$ sh ./hello_world.sh}}

−

{{bc|1=lo no wireless extensions.

+

{{bc|Hello World}}

−

eth0 no wireless extensions.

−

wlan0 unassociated ESSID:""

−

Mode:Managed Channel=0 Access Point: Not-Associated

−

Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0

−

Retry limit:7 RTS thr:off Fragment thr:off

−

Power Management:off

−

Link Quality:0 Signal level:0 Noise level:0

−

Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0

−

Tx excessive retries:0 Invalid misc:0 Missed beacon:0}}

{{bc|#!/bin/sh

{{bc|#!/bin/sh

# Demo

# Demo

echo "Hello World"}}

echo "Hello World"}}

−

*For short lines of code, you can just start them with a space instead of using {{ic|<nowiki>{{bc|code}}</nowiki>}} (see [[Help:Editing]]), but note that the resulting code block will not add a horizontal scrollbar if code overflows from the screen: keep in mind that some readers may use a narrower screen than yours, or just keep the browser in a non-maximized window, so they could see the code overflowing even if you do not.

+

:For short lines of code, you can just start them with a space instead of using {{ic|<nowiki>{{bc|code}}</nowiki>}} (see [[Help:Editing]]).

*Use {{ic|<nowiki>{{hc|input|output}}</nowiki>}} when in the need of representing both command line input and output, for example:

*Use {{ic|<nowiki>{{hc|input|output}}</nowiki>}} when in the need of representing both command line input and output, for example:

−

{{hc|# iwconfig|<nowiki>lo no wireless extensions.

+

{{hc|$ sh ./hello_world.sh|Hello World}}

−

eth0 no wireless extensions.

−

wlan0 unassociated ESSID:""

−

Mode:Managed Channel=0 Access Point: Not-Associated

−

Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0

−

Retry limit:7 RTS thr:off Fragment thr:off

−

Power Management:off

−

Link Quality:0 Signal level:0 Noise level:0

−

Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0

−

Tx excessive retries:0 Invalid misc:0 Missed beacon:0</nowiki>}}

*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 {{ic|<nowiki>{{hc|filename|content}}</nowiki>}} to show the file name in the heading, for example:

*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 {{ic|<nowiki>{{hc|filename|content}}</nowiki>}} to show the file name in the heading, for example:

*{{Ic|# sudo command}} is redundant and must be avoided. The only exception is when {{Ic|sudo}} is used with the {{Ic|-u}} flag: in this case the prompt can match the others of the same code block, or default to {{Ic|$}}.

*Do not add comments in the same box of a command (e.g. {{Ic|# pacman -S foo #Install package foo}})

*Do not add comments in the same box of a command (e.g. {{Ic|# pacman -S foo #Install package foo}})

*Avoid writing excessively long lines of code: use line-breaking techniques when possible.

*Avoid writing excessively long lines of code: use line-breaking techniques when possible.

Line 144:

Line 131:

===Package management instructions===

===Package management instructions===

====Official packages====

====Official packages====

−

*For installation instructions of official packages, use a wording like this: <br> <span style="margin:0 1em;"></span>[[pacman|Install]] {{Pkg|package}}, available in the [[Official Repositories]]. <br> The wiki code for this is {{Ic|<nowiki>[[pacman|Install]] {{Pkg|package}}, available in the [[Official Repositories]].</nowiki>}} <br> The instructions for the installation of a list of packages should appear as: <br> <span style="margin:0 1em;"></span>[[pacman|Install]] {{Pkg|package1}}, {{Pkg|package2}} and {{Pkg|package3}}, available in the [[Official Repositories]]. <br> More basic phrasing examples may be: <br> <span style="margin:0 1em;"></span>''MyApplication'' can be [[pacman|installed]] with the package {{Pkg|my-appplication}}, available in the [[Official Repositories]]. <br> <span style="margin:0 1em;"></span>You can [[pacman|install]] ''MyApplication'' with the package {{Pkg|my-appplication}}, available in the [[Official Repositories]]. <br> You are granted the flexibility to adapt the wording to your specific article.

+

*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 {{Ic|pacman -Sy package}} or possibly never-ending discussions like the choice between {{Ic|pacman -S package}} and {{Ic|pacman -Syu package}}. All the more reason you should not suggest the use of pacman frontends or wrappers. <br> Instead, just use a simple statement like: <br> <span style="margin:0 1em;"></span> [[pacman|Install]] {{Pkg|package}} from the [[official repositories]].<br> Or, if for example the application name differs from the package name: <br> <span style="margin:0 1em;"></span>''MyApplication'' can be [[pacman|installed]] with the package {{Pkg|my-app-pkg}}, available in the [[official repositories]]. <br> The instructions for the installation of a list of packages may appear as: <br> <span style="margin:0 1em;"></span> [[pacman|Install]] {{Pkg|package1}}, {{Pkg|package2}} and {{Pkg|package3}} from the [[official repositories]]. <br> You are granted the flexibility to adapt the wording to your specific article.

−

*If the package is hosted in [core], [extra] or [community], do not make reference to the repository, thus facilitating maintenance since 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 this: <br> <span style="margin:0 1em;">[[pacman|Install]] {{Pkg|package}}, available in the [[Official Repositories]]. You must enable [[multilib|&#91;multilib&#93;]].

+

*Links to the referenced packages are mandatory and should be created using [[Template:Pkg]], for example {{Ic|<nowiki>{{Pkg|package}}</nowiki>}}.

−

*Giving an example of the pacman command needed for the installation is deprecated (except in the [[Beginners' Guide]] and its subpages), both for simplicity's sake (every Arch user should know [[pacman]]'s article by memory) and to avoid errors such as {{Ic|pacman -Sy package}} or possibly never-ending discussions like the choice between {{Ic|pacman -S package}} and {{Ic|pacman -Syu package}}. <br> All the more reason you should not suggest the use of pacman frontends or wrappers to install official packages.

+

*The above examples also make use of an implicit link to the [[pacman]] article (e.g. {{ic|<nowiki>[[pacman|Install]]</nowiki> ...}}) and one to [[official repositories]] ({{ic|<nowiki>[[official repositories]]</nowiki>}}): these are recommended to be used at least on the first occurrence of an installation request, especially in articles that are more likely to be visited by Arch novices.

+

*Examples of pacman commands are nonetheless accepted and even recommended in the [[Beginners' Guide]] and its subpages.

+

*If the package is hosted in [core], [extra] or [community], do not make reference to the repository, thus facilitating maintenance since 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: <br> <span style="margin:0 1em;"></span>[[pacman|Install]] {{Pkg|package}} from the official [[multilib|&#91;multilib&#93;]] repository.

====AUR packages====

====AUR packages====

−

*For installation instructions of AUR packages use a wording like this: <br> <span style="margin:0 1em;"></span> Install {{AUR|package}}, available in the [[Arch User Repository]]. <br> The wiki code for this is {{Ic|<nowiki>Install {{AUR|package}}, available in the [[Arch User Repository]].</nowiki>}} <br> You are granted the flexibility to adapt the wording to your specific article, although you should always make clear that the package is unofficial.

+

*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. <br> Instead, just use a simple statement like: <br> <span style="margin:0 1em;"></span> Install {{AUR|package}} from the [[Arch User Repository]]. <br> You are granted the flexibility to adapt the wording to your specific article, see the section on [[#Official packages]] for more examples.

−

*Do not give examples on 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.

+

*Links to the referenced packages are mandatory and should be created using [[Template:AUR]], for example {{Ic|<nowiki>{{AUR|package}}</nowiki>}}.

+

*You should always make clear that the package is unofficial, also linking to the [[Arch User Repository]] article or one of its redirects, e.g. [[AUR]].

===Kernel module operations===

===Kernel module operations===

−

*Giving examples of how to add modules to the {{Ic|MODULES}} array in {{ic|/etc/rc.conf}} is deprecated: the standard phrasing is a simple list of the modules involved, possibly remarking dependencies or conflicts with other modules, and a link to [[Kernel modules]].

+

*Giving examples of how to load, remove, blacklist or perform any other basic operation with modules is deprecated: the standard phrasing is a list of the modules involved, possibly remarking dependencies or conflicts with other modules, a description of the actions to be performed, and a link to [[Kernel modules]].

−

*Giving examples of how to load, remove, blacklist or perform any other basic operation with modules is deprecated: the standard phrasing is a description of the actions to be performed, and a link to [[Kernel modules]].

+

*The [[Beginners' Guide]] and its subpages are the only exceptions to the rule above.

−

*The [[Beginners' Guide]] and its subpages are the only exceptions to the rules above.

===Daemon operations===

===Daemon operations===

−

*Giving examples of how to add daemons to the {{Ic|DAEMONS}} array in {{ic|/etc/rc.conf}} is deprecated: the standard phrasing is a simple list of the daemons involved, possibly remarking dependencies or conflicts with other daemons, and a link to [[Daemon]].

+

*Giving examples of how to enable, start or perform any other basic operations with daemons is deprecated: the standard phrasing is a list of the daemons involved, possibly remarking dependencies or conflicts with other daemons, a description of the actions to be performed, and a link to [[systemd]].

−

*Giving examples of how to ''start'', ''restart'' or ''stop'' daemons is deprecated: the standard phrasing is a description of the actions to be performed, and a link to [[Daemon]]. <br> Nevertheless, if the requested action is not one of those, an example is acceptable, and it should make use of the {{ic|rc.d}} command instead of using the full {{ic|/etc/rc.d/daemon}} command path.

+

*The [[Beginners' Guide]] and its subpages are the only exceptions to the rule above.

−

*The [[Beginners' Guide]] and its subpages are the only exceptions to the rules above.

===Notes, Warnings, Tips===

===Notes, Warnings, Tips===

Line 182:

Line 170:

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

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

*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 local pages of the same language of the article being edited, since they will not be shown in [[Special:WhatLinksHere]] pages. For example using {{ic|<nowiki>[[:hu:Main Page]]</nowiki>}} in a Hungarian article is wrong, while {{ic|<nowiki>[[Main Page (Magyar)]]</nowiki>}} is correct. <br> Using this kind of links between different languages is instead acceptable, since this would make it easier to move the articles to a separate wiki in case it is set up. <br> Finally, note the difference of this kind of links from [[#Interlanguage links]], which do not have the colon at the beginning.

==="Tips and tricks" sections===

==="Tips and tricks" sections===

Line 207:

Line 196:

===Non-pertinent content===

===Non-pertinent content===

*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. <br> Reporting the sources used to write an article, though, is good practice: you can use the "See also" section for this purpose.

*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. <br> 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 [http://www.asciiflow.com/ Asciiflow].

+

*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 [http://www.asciiflow.com/ 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.

===Language register===

===Language register===

−

*Articles should be written using a formal language register.

+

*Articles should be written using formal, professional and concise language.

+

*Remember not only to answer ''how'', but also ''why.'' Explanatory information always goes further toward imparting knowledge than does instruction alone.

*Do not include personal comments on articles; use discussion pages for this purpose. In general, do not write in first person.

+

*Write objectively: do not include personal comments on articles, use discussion pages for this purpose. In general, do not write in first person.

==Discussion pages==

==Discussion pages==

*Add new discussions at the bottom of discussion pages and with a proper heading. You can also make use of the {{ic|+}} tag at the top of each discussion page.

*Add new discussions at the bottom of discussion pages and with a proper heading. You can also make use of the {{ic|+}} tag at the top of each discussion page.

*Indent your answers using colons at the beginning of new lines.

*Indent your answers using colons at the beginning of new lines.

+

*Do not edit your posts if somebody has already replied, otherwise you will break the flow of the discussion and make it difficult for others to further respond. Only striking (using {{Ic|<nowiki><s></nowiki>}} tags) words or sentences is allowed, but the related explanation should be given in a regular reply.

*Every category must be categorized under at least one parent category, except for root categories. <br> Root categories are language categories, like [[:Category:English]] and some other special categories: [[:Category:DeveloperWiki]], [[:Category:Sandbox]] and [[:Category:Template]].

+

*Every category must be appropriately categorized under at least one parent category, except for root categories. <br> Root categories are [[:Category:DeveloperWiki]], [[:Category:Languages]], [[:Category:Sandbox]] and [[:Category:Template]].

*A category can be categorized under more than one category, provided one is not ancestor of the others.

*A category can be categorized under more than one category, provided one is not ancestor of the others.

*Do not categorize a category under itself (self-categorized category).

*Categories must be included at the top of the category page.

*Categories must be included at the top of the category page.

*Categories should not redirect.

*Categories should not redirect.

Line 232:

Line 230:

==Redirect pages==

==Redirect pages==

*Redirect pages should contain only the redirect code, nothing more.

*Redirect pages should contain only the redirect code, nothing more.

+

*Redirect only to internal articles; do not use interwiki redirections.

==Template pages==

==Template pages==

−

*See [[Template:Template]].

+

*See [[Help:Template]].

==User pages==

==User pages==

−

*User pages cannot be categorized (this rule can be infringed in very rare, admin-approved cases).

+

*User pages cannot be categorized.

==Generic rules==

==Generic rules==

===Edit summary===

===Edit summary===

−

*The changes made daily to the articles are bravely checked by dedicated and voluntary patrollers, whom you must help by making sure that all your edits are accompanied by some explanation words in the "Summary" field of the editor page.

+

*The changes made daily to the articles are bravely checked by dedicated and voluntary [[ArchWiki:Maintenance Team|patrols]], whom you must help by making sure that all your edits are accompanied by some explanation words in the "Summary" field of the editor page.

**If the edit is [[Wikipedia:Help:Minor edit|minor]], e.g. grammar or orthography corrections or the simple rewording of a sentence, a simple description of your edit is perfectly enough.

**If the edit is [[Wikipedia:Help:Minor edit|minor]], e.g. grammar or orthography corrections or the simple rewording of a sentence, a simple description of your edit is perfectly enough.

**If you are performing a major change, e.g. adding, moving, modifying or removing content, besides summarizing your edit, you should make sure to explain the reason ''why'' you edited the article, even linking to a discussion on the wiki or the forums, if one exists at all.

**If you are performing a major change, e.g. adding, moving, modifying or removing content, besides summarizing your edit, you should make sure to explain the reason ''why'' you edited the article, even linking to a discussion on the wiki or the forums, if one exists at all.

Article pages

Title

If the subject of the article is commonly known both with the full name and the acronym, prefer using the full name in the title of the article. Do not include both the full name and the acronym (e.g. in parentheses) in the title, but rather use a redirect on the acronym page that points to the page titled with the full name.

Magic words

Behavior switches, and in general all the magic words that change how an article is displayed or behaves but do not add content by themselves, should all go at the very top of the articles. This rule applies in particular to {{DISPLAYTITLE:title}} and Template:Lowercase title, which makes use of the former.

Categories

Every article must be categorized under at least one existing category.

An article can belong to more than one category, provided one is not ancestor of the others.

Categories must be included at the top of every article, right below any magic words.

Note: This is different from some other MediaWiki projects such as Wikipedia, which include categories at the bottom.

There should be no blank lines between categories and the first line of text (or interlanguage links, if present), because this introduces extra space at the top of the article.

Interlanguage links

If the article has translations in the local or an external Arch Linux wiki, interlanguage links must be included right below the categories and above the first line of text. Note that they will actually appear in the appropriate column to the left side of the page.

There should be no blank lines between interlanguage links and the first line of text, because this introduces extra space at the top of the article.

When adding or editing interlanguage links you should take care of repeating your action for all the already existing translations.

Do not add more than one interlanguage link for each language to an article.

Do not add interlanguage links for the same language of the article.

The interlanguage links must be sorted alphabetically based on the language tag, not the local name, so for example [[fi:Title]] comes before [[fr:Title]] even though "Suomi" would come after "Français".

Article summary

Preface or introduction

Describes the topic of the article. Rather than paraphrasing or writing your own (possibly biased) description of a piece of software, you can use the upstream author's description, which can usually be found on the project's home page or about page, if it exists. An example is MediaTomb.

Included right below the Article summary.

Do not explicitly make an ==Introduction== or ==Preface== section: let it appear above the first section heading. A table of contents is shown automatically between the preface and first section when there are sufficient sections in the article.

Section headings

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, since 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 also My New Page. For the same reason, also avoid using any kind of html or wiki markup code, including code formatting templates.

Blank lines

Code formatting templates

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.

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

$ sh ./hello_world.sh

Hello World

#!/bin/sh
# Demo
echo "Hello World"

For short lines of code, you can just start them with a space instead of using {{bc|code}} (see Help:Editing).

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:

Package management instructions

Official packages

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. Instead, just use a simple statement like: Installpackage from the official repositories. Or, if for example the application name differs from the package name: MyApplication can be installed with the package my-app-pkg, available in the official repositories. The instructions for the installation of a list of packages may appear as: Installpackage1, package2 and package3 from the official repositories. 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|package}}.

The above examples also make use of an implicit link to the pacman article (e.g. [[pacman|Install]] ...) and one to official repositories ([[official repositories]]): these are recommended to be used at least on the first occurrence of an installation request, especially in articles that are more likely to be visited by Arch novices.

Examples of pacman commands are nonetheless accepted and even recommended in the Beginners' Guide and its subpages.

If the package is hosted in [core], [extra] or [community], do not make reference to the repository, thus facilitating maintenance since 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: Installpackage from the official [multilib] repository.

AUR packages

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 packageAUR from the Arch User Repository. 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|package}}.

You should always make clear that the package is unofficial, also linking to the Arch User Repository article or one of its redirects, e.g. AUR.

Kernel module operations

Giving examples of how to load, remove, blacklist or perform any other basic operation with modules is deprecated: the standard phrasing is a list of the modules involved, possibly remarking dependencies or conflicts with other modules, a description of the actions to be performed, and a link to Kernel modules.

The Beginners' Guide and its subpages are the only exceptions to the rule above.

Daemon operations

Giving examples of how to enable, start or perform any other basic operations with daemons is deprecated: the standard phrasing is a list of the daemons involved, possibly remarking dependencies or conflicts with other daemons, a description of the actions to be performed, and a link to systemd.

The Beginners' Guide and its subpages are the only exceptions to the rule above.

Notes, Warnings, Tips

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.

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:

Tip example #1.

Tip example #2.

Shells

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.

Hypertext metaphor

Try to interlink your article with as many others as you can, using the various keywords in the text.

For technical terms like system call not covered by an article in the ArchWiki, link to the relevant Wikipedia page.

When linking to other articles of the wiki do not use full URLs, but take advantage of the special syntax for interwiki links: [[Wiki Article]]. This will also let the wiki engine keep track of the internal links hence facilitating maintenance. See Help:Editing#Links for in-depth information and more advanced uses of interwiki links syntax.

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 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 local pages of the same language of the article being edited, since 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, since this would make it easier to move the articles to a separate wiki in case it is set up. Finally, note the difference of this kind of links from #Interlanguage links, which do not have the colon at the beginning.

"Tips and tricks" sections

Advanced tips or examples of using the software.

Standard title is Tips and tricks.

The various tips and tricks should be organized in subsections.

"Troubleshooting" sections

Frequently asked questions regarding the software, or solutions to common problems (compare to #"Known issues" sections).

Standard title is Troubleshooting; Trouble shooting, Trouble-shooting, TroubleShooting are common mistake examples.

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, and 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 clean up 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

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

A list of links to references and sources of additional information.

This should be a list where each entry is started with *.

The standard title is See also, other similar titles like External links, More resources etc. should be avoided.

Non-pertinent content

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.

Language register

Articles should be written using formal, professional and concise language.

Remember not only to answer how, but also why. Explanatory information always goes further toward imparting knowledge than does instruction alone.

Write objectively: do not include personal comments on articles, use discussion pages for this purpose. In general, do not write in first person.

Discussion pages

Add new discussions at the bottom of discussion pages and with a proper heading. You can also make use of the + tag at the top of each discussion page.

Indent your answers using colons at the beginning of new lines.

Do not edit your posts if somebody has already replied, otherwise you will break the flow of the discussion and make it difficult for others to further respond. Only striking (using <s> tags) words or sentences is allowed, but the related explanation should be given in a regular reply.

Always append a signature (~~~~) to your edits.

Discussion pages should not be categorized.

You should take care to strike the header of exhausted discussions using <s> tags. Exhausted discussions will be deleted a while after striking.

Redirect pages

Template pages

User pages

User pages cannot be categorized.

Generic rules

Edit summary

The changes made daily to the articles are bravely checked by dedicated and voluntary patrols, whom you must help by making sure that all your edits are accompanied by some explanation words in the "Summary" field of the editor page.

If the edit is minor, e.g. grammar or orthography corrections or the simple rewording of a sentence, a simple description of your edit is perfectly enough.

If you are performing a major change, e.g. adding, moving, modifying or removing content, besides summarizing your edit, you should make sure to explain the reason why you edited the article, even linking to a discussion on the wiki or the forums, if one exists at all.

An explanation is not mandatory in talk pages, where the why should be already evident. When deleting exhausted discussions, however, some explanation words are required (e.g. "closed discussion," "fixed," etc.) and including also the title of the discussion could help retrieving it in the history in case it needs to be reopened.

Tip: Take a look at the edit summaries in the Recent Changes to get an idea of what you should write in your summary, but be warned that unfortunately not all users respect these guidelines.

When performing major changes to articles, you should better try to split your work in multiple edits, based on the logical steps needed to complete the change. Especially when moving sections (both within the same article or between two articles), you should avoid also modifying their content in the same edit, otherwise it will be more difficult to check the consequent diff.

HTML tags

Usage of HTML tags is generally discouraged: always prefer using wiki markup or templates when possible, see Help:Editing and related.

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

Especially avoid HTML comments (<!-- comment -->): it is likely that a note added in a HTML comment can be explicitly shown in the article's discussion page. You can add an appropriate Article status template in place of the comment.

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.