Help:Style

Related articles
/Formatting and punctuation
/White space
Help:Discussion
Help:Editing
Help:Reading
Help:Template
These style conventions encourage tidy, organized, and visually consistent articles. Follow them as closely as possible when editing the ArchWiki.
Article pages
Title
Titles should use
sentence case
, e.g. "Title for new page" is correct, while "Title for New Page" is not. Note that common words that are part of a proper name or an upper-case acronym must be capitalized, e.g. "Advanced Linux Sound Architecture", not "Advanced Linux sound architecture".
Namespaces are not considered part of titles, so "ArchWiki:Example article" is correct, while "ArchWiki:example article" is not. Subpage names should start with a capital letter, so "My page/My subpage" is correct, while "My page/my subpage" is not.
By default, the topic name in titles should be in the singular form; it should be in the plural form if it represents a group or class of something and is a countable noun or perceived as such.
Unless the subject of the article is primarily known by its 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, instead use a
redirect
on the acronym page that points to the page titled with the full name.
Titles of localized pages must follow
Help:i18n#Page titles
.
See the
Help:Article naming guidelines
article for more information.
Layout
Order elements in an article as follows:
Magic words
(optional)
Categories
Interlanguage links
(optional)
Article status templates
(optional)
Related articles box
(optional)
Preface or introduction
Table of contents (automatic)
Article-specific sections.
Magic words
Behavior switches—and in general, all of 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 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.
See the
Help:Category
article for more information.
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; for example
[[fi:Title]]
comes before
[[fr:Title]]
, even though "Suomi" would come after "Français".
See the
Help:i18n
and
Wikipedia:Help:Interlanguage links
articles for more information.
Article status templates
Status templates
that refer to the whole article must be included right below the categories (or interlanguage links, if present) and right above the introduction (or the
Related articles box
, if present).
Status templates that refer to a specific portion of an article must be placed as close as possible above such portion, while appropriately avoiding to break paragraphs, code blocks, or other pre-existing templates.
Always accompany an article status template with some words of explanation in the dedicated field (examples are provided in each template's page), possibly even opening a discussion in the talk page.
Related articles box
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.
Preface or introduction
Included right above the first section of the article.
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.
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
WireGuard
. You may also use the description from Wikipedia, as is the case with
ImageMagick
.
See
Help:Writing article introductions
for more information.
Standard sections
"Installation" section
The
Installation
section describes how to install the software, see
#Package management instructions
.
Use the standard title of
Installation
and order it early in the article.
"Known issues" section
Known issues
sections are used for known bugs or usage problems which do not have a solution yet (compare to
#"Troubleshooting" section
).
Use the standard title of
Known issues
and order it early in the article.
If a bug report exists for the known issue, it is very desirable that you provide a link to it. If it does not exist, you should report it yourself, thus increasing the chances that the bug will be fixed.
Refrain from mentioning dates or version numbers (for example, "Linux kernel 3.17 does not support device XYZ as of October 2014 yet.") whenever possible. Again, prefer to link references like bug reports for follow-up information instead.
"Tips and tricks" section
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" section
Troubleshooting
sections are used for frequently asked questions regarding the software or for solutions to common problems (compare to
#"Known issues" section
).
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; in this case, it is
mandatory
that you provide a link to the bug report (or similar appropriate sources, like a forum post containing a workaround). In case it has not been reported yet, you should report it yourself, thus increasing the chances that the bug will be properly fixed.
Refrain from mentioning dates or version numbers whenever possible. There are great benefits in linking to external references like bug reports 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 a 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.
"See also" section
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
and place the section last in the article. Other similar titles such as
External links
,
More resources
, etc. should be avoided.
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 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
.
See
Help:Effective use of headers
for more information.
Formatting
Code formatting
Use
Template:ic
for short lines of code, file names and paths, configuration parameters, variables and
other cases
to be represented inline; for example:
Run
sh ./hello_world.sh
in the console.
For single lines of code (command line input or output code and file content) to be represented in a proper frame, simply start them with a single space character; see also
Help:Editing#Code
. Example:
$ sh ./hello_world.sh
Hello World
Use
Template:bc
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
Template:hc
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
Template:hc
to show the file name in the heading; for example:
~/hello_world.sh
#!/bin/sh

# Demo
echo "Hello World"
For code block such as a configuration file, consider focusing the reader to the relevant lines and ellipsing (
...
) any surrounding, non-relevant content.
See the
Help:Template
article for more information and for troubleshooting problems with template-breaking characters like
=
or
|
.
Command line text
When using inline code (
Template:ic
), no prompt symbol is to be represented; any notes about permissions must be added explicitly to the surrounding text.
When using code block (
Template:bc
or lines starting with a space character), use
$
as a prompt for regular user commands; use
#
as a prompt for root commands.
Note
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
To show running a command
as another user
, prefix the prompt with the username in square brackets:
[archie]$
command
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
).
Keyboard keys
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
Up
(not
↑
or
Up Arrow
) – similarly for other arrow keys
PageUp
PageDown
Fn
(not
FN
or
fn
) – the
function key
present on many laptops
Home
(not
HOME
or
Beginning
)
End
(not
END
)
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 information that gives more in-depth knowledge on something 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 ignore-able.
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.
Tables
See
mw:Help:Tables
for the syntax.
Tables should generally have the
wikitable
class.
Comparison tables should additionally have the
sortable
class.
Use table headers and
table cell templates
when appropriate.
Table headers should be in sentence case.
Table legends should use definition lists and be placed before tables.
Footnotes or remarks should use
<sup>1</sup>
,
<sup>2</sup>
, etc. and an ordered list below the table instead of
Unicode characters
.
Instructions
File editing requests
Where it might be helpful, a link to
Help:Reading#Append, add, create, edit
can be added.
Do not assume a specific text editor—
nano
,
Vim
,
Emacs
, etc.—when requesting text file edits, except when necessary.
In general, do not use commands to implicitly request text file edits, for example:
echo -e "clear\nreset" >> ~/.bash_logout
should be:
Append the following lines to
~/.bash_logout
:
clear
reset
A common exception are commands which involve generating a complex, system-specific output—for example,
genfstab -U /mnt >> /mnt/etc/fstab
.
Package management instructions
All package management instructions should use a simple statement instead of example commands.
Using the
install
redirect or its variants (e.g.
[[install]]ed
) is recommended at least on the first occurrence of an installation request.
The package (or packages, or package groups) involved must be linked, preferably
without variants
(typically denoted by a suffix such as
-bin
,
-git
, or
-nightly
) unless they provide a meaningful difference.
Do not provide specific instructions for non-native package managers (e.g.
Flatpak
,
make install
); although a
Tip
linking to a meaningfully different packaging is acceptable, for example if upstream support is exclusive to them.
You are granted the flexibility to adapt the wording to your specific article, see the section on
#Official packages
for more examples.
Official packages
Avoid examples of
pacman
commands for the installation of official packages: 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 never-ending discussions such as 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:
Install
the
foobar
package.
Or, if for example the application name differs from the package name:
MyApplication
can be
installed
with the
my-app-pkg
package.
The instructions for the installation of a list of packages may appear as:
Install
the
foobar1
,
foobar2
and
foobar3
packages.
If referring to a package group you may use:
Install
the
foobar
group.
Use
Template:Pkg
; for example,
{{Pkg|foobar}}
.
When referring to package groups, use
Template:Grp
instead; for example,
{{Grp|foobar}}
.
If the package is hosted in the
core
or
extra
repositories, do not make reference to the repository: it increases maintenance because it is not uncommon for a package to be moved to a different repository. If the package is hosted in an official repository which is not enabled by default (
multilib
,
core-testing
, etc.), mentioning it is required, using a wording like:
Install
the
foobar
package from the official
multilib
repository.
AUR packages
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 their system.
Instead, just use a simple statement like:
Install the
foobar
AUR
package.
Use
Template:AUR
(e.g.
{{AUR|foobar}}
).
Unofficial repositories
When suggesting to use an unofficial repository for installing a pre-built package, do not provide instructions for enabling the repository, rather add the repository to
Unofficial user repositories
and link to the relevant repository section; for example
[[Unofficial user repositories#example|example]]
.
Just like with
official packages
, do not add examples of
pacman
commands; for example:
Install the
foobar
package from the
example
repository.
If the package is also available in the
AUR
:
Install the
foobar
AUR
package, also available in the
example
repository.
If the package is available in the
AUR
with a different name:
Install the
aurpkg
AUR
package, also available as
builtpackage
from the
example
repository.
systemd units operations
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:
To have GDM launched at boot time,
enable
gdm.service
.
Or, if for example the unit is a template that needs instantiation:
To enable automatic switching of
netctl
profiles on a wireless interface,
enable
an instance of
netctl-auto@.service
with the interface name; for example
netctl-auto@wlan0.service
.
You are granted the flexibility to adapt the wording to your specific article.
Make sure to link to
Help:Reading#Control of systemd units
through a dedicated redirect like
[[start]]
,
[[enable]]
or
[[stop]]
.
Coding style
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.
Scripts should be written to only do what is minimally necessary to perform the required task in the clearest possible way. They should not be designed for flexibility or expansion, prefer using
pseudo-variables
over actual variables. Do not add irrelevant functionality such as argument parsing or output formatting.
Scripts should be added mainly for educational purposes, when the verbose explanation in the article's text cannot be made sufficiently clear and concise. They can be useful for example to show how a complex command is intended to be used, or how related or interdependent commands are meant to work together.
If a script is deemed to add value to an article but does not meet the criteria above, it can be linked externally, possibly publishing it as a
gist
.
When representing the name or path of a directory, end it with a slash or explicitly add an appositive such as "directory" of "folder"; for example:
"Check if the
/sys/firmware/efi
directory has been created", not "Check if
/sys/firmware/efi
has been created".
"Place a
.conf
file in
/etc/modules-load.d/
", not "Place a
.conf
file in
/etc/modules-load.d
".
Arguments containing spaces should be quoted with double quotation marks, e.g.
cd "foo bar"
instead of
cd foo\ bar
.
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
See
Help:Editing#Links
for the syntax of internal, interwiki and external links.
Try to interlink your article with as many others as you can, using the words in the text.
Only link to existing articles. If you encounter a dead link, try to fix it. External links that appear to be dead should be marked with
Template:Dead link
.
Avoid implicit links whenever possible, prefer instructions like "See the
systemd
article for more information", instead of "See
here
for more information".
A link can be used in two ways:
As a
topic reference
, where the link is a term, part of the running text, and subject to regular grammar rules; use a link label if needed. Internal/interwiki links should point to a
redirect
if available.
As a
page/section reference
, do not use a link label, and spell the title according to
Template:Lowercase title
where used; in particular, do not hide the
#
symbol in same-page section links, e.g.
[[#Hypertext metaphor|Hypertext metaphor]]
.
See these examples:
Topic reference
Page/section reference
Use an
SSH agent
to speed up authentication.
Follow
SSH keys#SSH agents
to speed up authentication.
Subpixel rendering
is supported by most monitors.
Enable subpixel rendering as described in
Font configuration#Subpixel rendering
.
Include a
keyfile
in the
initramfs
.
Instructions can be found in
dm-crypt/Device encryption#Keyfiles
.
Be aware that
mouse keys
is disabled by default.
See
Wikipedia:Mouse keys
for details.
We have
style rules
for links.
The
#Hypertext metaphor
section has style rules for links.
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. Also:
For technical terms not covered by an article in the ArchWiki, link to the relevant Wikipedia page.
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.
For example: "
Kernel parameters
are used to issue
system calls
at boot; see the
Linux kernel documentation
for a complete list."
In general, maintain coherence with
Help:Reading#Organization
.
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).
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 link between different languages is 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 these kinds of links from
#Interlanguage links
, which do not have the colon at the beginning.
Prefer the "Wikipedia:" interwiki prefix over the shorter "w:" prefix.
Man pages
Man pages
should be referenced using
Template:man
.
Supported kernel versions
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
.
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.
Note that reporting the sources used to write an article is good practice: you can use the "See also" section for this purpose.
Uploading files is disabled for normal users, and including 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
and
Template:Text art
; 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.
Spelling
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. See also
Help:Style/Formatting and punctuation#Configuration parameters, variables, options, properties...
.
The names of projects, applications, executables etc. should be spelled, especially regarding capitalization, primarily according to their official documentation style. This includes the case where the documentation treats the name as a common noun, i.e. with an uppercase first letter when appearing at the beginning of a sentence, and lowercase otherwise. If the official documentation does not apply a consistent style, follow the style already used in the ArchWiki. If the name does not appear in the ArchWiki, or it still has inconsistent spelling, choose a style and conform to it throughout the article, also possibly updating the other pages that mention the name. Taking Git as an example you may choose to spell the name with the first letter uppercase ("Git") when talking about the project/software generally, and use all lowercase and italic ("
git
") when referring to the compiled program. When name capitalization can generate controversy, explicitly define a style in the article's talk page. See also
Help:Style/Formatting and punctuation#Executable/application names
ArchWiki prefers no national variety of English over any other, adopting the same guidelines outlined in
Wikipedia:Wikipedia:Manual of Style#National varieties of English
; in case of conflict with any of ArchWiki's other explicitly defined guidelines, ArchWiki's prevail. When writing new content within an existing article it is recommended to maintain the
spelling convention
already prevalent in it; if the article does not have a clear prevalent spelling, write accordingly to the variant used in the edited section. Harmonizing the spelling around the edited content is acceptable; refrain from performing edits whose main purpose is changing or harmonizing the spelling standard of articles or series thereof.
Language register
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.
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 their personal case.
Prefer neutral pronouns such as
they/them
when referring to the reader or people in general.
Category pages
Category
name must use
sentence case
.
Every category must be appropriately categorized under at least one parent category, except for root categories, which are:
Category:Archive
,
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, for example
Category:Simulation
); they should be in the plural form if the singular form can be used to describe
one
of its members ("set" categories, for example
Category:Boot loaders
).
Redirect pages
It is encouraged to create redirect pages for acronyms or grammatical variants of an existing article's title, or for a term or topic discussed in a subsection of a more generic article; for example
ALSA
,
daemon
or
AIGLX
. Redirects can simplify the source text by replacing labelled links, compare the previous examples with
[[Advanced Linux Sound Architecture|ALSA]]
,
[[daemons|daemon]]
or
[[Xorg#Composite|AIGLX]]
.
Redirect pages should contain only the redirect code and nothing else; the only exceptions are:
Archived
pages, which are in fact redirects; must be categorized under
Category:Archive
.
Renamed categories
can contain a
Template:Archive
flag.
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
.
See
Help:Editing#Redirects
for more information.
User pages
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.
Pages in the
User
namespace cannot be targets of
redirects
from other namespaces.
Generic rules
Edit summary
See
ArchWiki:Contributing#The 3 fundamental rules
.
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
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.
Tip
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.