Help:Style (Português)

Status de tradução: Esse artigo é uma tradução de Help:Style. Data da última tradução: 2022-08-04. Você pode ajudar a sincronizar a tradução, se houver alterações na versão em inglês.

Artigos relacionados

• Help:Estilo/Formatação e pontuação
• Help:Estilo/Espaço em branco
• Help:Edição
• Help:Leitura
• Help:Discussão
• Help:Modelo

Essas convenções de estilo encorajam artigos arrumados, organizados e visualmente consistentes. Siga-os o mais próximo possível ao editar o ArchWiki.

Páginas de artigo

Título

• Títulos devem ter letras maiúsculas apenas no início da primeira palavra, o que, em inglês, é chamado de sentence case (ex.: "Título para nova página" está correto, enquanto "Título para Nova Página" está errado). Note que palavras comuns que são parte de um nome próprio ou um acrônimo em maiúsculo devem estar em maiúsculo (ex.: "Advanced Linux Sound Architecture", e não "Advanced Linux sound architecture".
  Espaços de nome (namescapes) não são considerados parte de títulos, então "ArchWiki:Artigo exemplo" está correto, enquanto "ArchWiki:artigo exemplo" está errado. Nomes de subpáginas devem iniciar com uma letra maiúscula, de forma que "Minha página/Minha subpágina" está correto, enquanto "Minha página/minha subpágina" está errado.
• Por padrão, o nome do tópico em títulos deve estar na forma singular; ele deve estar na forma plural se ele representa um grupo ou classe de alguma coisa e é um nome contável ou percebido como tal.
• A menos que o assunto do artigo seja conhecido principalmente por seu acrônimo, prefira usar o nome completo do título do artigo. Não inclua os dois (ex.: acrônimo entre parenteses) no título, e sim use um redirecionamento na página do acrônimo que aponte para a página intitulada com o nome completo.
• Títulos de páginas localizadas (traduzidas) devem seguir Help:i18n (Português)#Títulos de páginas.
• Veja o artigo Help:Diretrizes para nomenclatura de artigos para mais informações.

Layout

• Ordene elementos em um artigo conforme esta lista:

1. #Palavras mágicas (opcional)
2. #Categorias
3. #Links interlínguas (opcional)
4. #Modelos de status de artigo (opcional)
5. #Caixa de artigos relacionados (opcional)
6. #Prefácio ou introdução
7. Tabela de conteúdos (automático)
8. Seções específicas do artigo

Palavras mágicas

• Alternadores de comportamento  –  e, em geral, todas as palavras mágicas que alteram como um artigo é exibido ou se comporta, mas que não adicionam conteúdo por si só  –  devem todos aparecerem bem no começo de artigos.
  Essa regra se aplica em especial para {{DISPLAYTITLE:título}} e Template:Lowercase title, que faz uso do anterior.

Categorias

• Todo artigo deve ser categorizado sob pelo menos uma categoria existente.
• Um artigo pode pertencer a mais de uma categoria, desde que uma não seja "pai" de outras listadas.
• Categorias devem ser incluídas no topo de todo artigo, logo abaixo de quaisquer palavras mágicas.
  Nota: Isso é diferente de alguns outros projetos MediaWiki tal como Wikipédia, o qual inclui categorias ao final.
• Não deve haver linha em branco entre categorias e a primeira linha de texto (ou links interlínguas, se houver), porque isso introduz um espaço extra no topo do artigo.
• Veja o artigo Help:Categoria para mais informações.

Links interlínguas

• Se o artigo possui traduções no wiki local ou externo de Arch Linux, links interlínguas devem ser incluídos logo abaixo de categorias e acima da primeira linha do texto.
  Note que eles na verdade aparecerão na coluna apropriada no lado esquerdo da página.
• Não deve haver linha em branco entre links interlínguas e a primeira linha de texto, porque isso introduz um espaço extra no topo do artigo.
• Ao adicionar ou editar links interlínguas, você deve ter cuidado para repetir sua ação para todas as traduções já existentes.
• Não adicione mais de um link interlíngua para cada idioma a um artigo.
• Não adicione links interlínguas para o mesmo idioma do artigo.
• Os links interlíngua devem ser ordenados alfabeticamente baseado na tag de idioma, não o nome local; então, por exemplo [[fi:Título]] vem antes de [[fr:Título]] ainda que "Suomi" venha após "Français".
• Veja os artigos Help:i18n (Português) e Wikipedia:pt:Help:Interlanguage links para mais informações.

Modelos de status de artigo

• Modelos de status de artigo, ou Article status templates, que se referem a todo o artigo deve ser incluídos logo abaixo das categorias (ou links interlínguas, se houver) e logo acima da introdução (ou a Caixa de artigos relacionados, se houver).
• Modelos de status de artigo que se referem a uma parte específica de um artigo devem ser colocados o mais próximo possível acima dessa parte, mas evitando apropriadamente quebrar parágrafos, blocos de código ou outros modelos pré-existentes.
• Sempre acompanhe o modelo de status de artigo com algumas palavras de explicação no campo dedicado (exemplos são fornecidos em cada página de modelo), possivelmente até abra uma discussão na página de discussão.

Caixa de artigos relacionados

• Fornece uma lista simples de artigos internos relacionados.
• Opcionalmente, incluído logo abaixo das categorias (links interlínguas, ou Modelos de status de artigo, se houver).
• Só pode ser feito de Template:Related articles start, Template:Related e Template:Related articles end. Para artigos traduzidos, utilize Template:Related articles start (Português) em vez da sua versão original em inglês. Veja também as diretrizes naquelas páginas.
• Artigos em outros idiomas podem fazer uso de Template:Related2 para traduzir o texto âncora.
• Use a #Seção de "See also" ("Veja também") para uma lista mais completa e detalhada que também inclui descrições de link e links interwiki e externos.

Prefácio ou introdução

• Descreve o tópico do artigo.
  Em vez de parafrasear ou escrever sua própria (provavelmente imparcial) descrição de um pedaço de software, você pode usar a descrição do autor upstream, que geralmente pode ser encontrado na página do projeto ou página sobre, se ela existir. Um exemplo é WireGuard. Você também pode usar a descrição do Wikipédia, como é o caso do ImageMagick.
• Incluído logo acima da primeira seção do artigo.
• Não crie explicitamente uma seção == Introduction == ou == Preface ==: Deixe-a aparecer acima do título da primeira seção. A tabela de conteúdo será mostrada automaticamente entre o prefácio e a primeira seção quando houver seções suficientes no artigo.
• Veja Help:Escrevendo introduções de artigos para mais informações.

Seções padrão

Seção de "Installation"

Nota: Em artigos traduzidos, use Instalação.

• A seção Installation descreve como instalar o software, veja #Instruções de gerenciamento de pacote.
• Use o título padrão de Installation (ou sua versão traduzida em artigos traduzidos) e posicione-o no início do artigo.

Seção de "Known issues"

Nota: Em artigos traduzidos, use Problemas conhecidos.

• Seções de Known issues são usadas para bugs conhecidos ou problemas de uso que ainda não têm solução (comparar com #Seção de "Troubleshooting").
• Use o título padrão de Known issues (ou sua versão traduzida em artigos traduzidos) e ordene-o no começo do artigo.
• Se um relatório de bug existir para o problema conhecido, é muito desejável que você forneça o link para ele. Se ele não existir, você deveria relatá-lo, de forma a aumentar as chances de que o bug seja corrigido.
• Evite mencionar datas ou números de versões (por exemplo, "Linux kernel 3.17 does not support device XYZ as of October 2014 yet.") quando possível. Novamente, prefira vincular referências como relatórios de bug para informação de acompanhamento.

Seção de "Tips and tricks"

Nota: Em artigos traduzidos, use Dicas e truques.

• Seções de Tips and tricks fornecem dicas e exemplos avançados de usar o software.
• Use o título padrão de Tips and tricks (ou sua versão traduzida em artigos traduzidos).
• As várias dicas e truques devem ser organizados por subseções.

Seção de "Troubleshooting"

Nota: Em artigos traduzidos, use Solução de problemas.

• Seções de Troubleshooting são usadas para perguntas frequentes sobre o software ou para soluções para problemas comuns (compare com #Seção de "Known issues").
• Use o título padrão de Troubleshooting (ou sua versão traduzida em artigos traduzidos). Erros de escrita comuns que devem ser evitados são Trouble shooting, Trouble-shooting e TroubleShooting.
• Você também pode relatar soluções de contorno para bugs conhecidos, mas, neste caso, é obrigatório que você forneça um link para o relatório de bug (ou fontes apropriadas similares, como uma publicação em fórum contendo uma solução de contorno). No caso dele ainda não ter sido relatado, você mesmo deve relatá-lo, de forma a aumentar as chances de que o bug seja corrigido.
  Evite de mencionar as datas ou números de versão quando possível. Há muitos benefícios em vincular referências externas como relatórios de bug para leitores e editores:
  • Para leitores, o Wiki não se torna um ponto de parada: eles podem localizar mais informações próximas à fonte que, do contrário, seria perdida por seus esforços de pesquisa.
  • Para editores do Wiki, ele facilita a limpeza reduzindo o esforço envolvido em pesquisar se um bug relacionado ainda é um problema; isso pode ainda levar a uma autonomia maior se o leitor localiza novas informações e volta para editar o wiki.

Seção de "See also"

Nota: Em artigos traduzidos, use Veja também.

• Seções See also contêm uma lista de links para referências e fontes de informações adicionais.
• Este deve ser uma lista na qual cada entrada é iniciada com *, que cria uma lista de marcadores do MediaWiki.
• Use o título padrão de See also (ou sua versão traduzida em artigos traduzidos) e coloque a seção como última no artigo. Outros títulos similares, tais como External links ("links externos"), More resources ("Mais recursos"), etc. devem ser evitados.

Títulos de seção

• Títulos devem iniciar a partir do nível 2 (==), porque o nível 1 está reservado para títulos do artigo.
• Não pule níveis quando estiver fazendo subseções, de forma que a subseção de um nível 2 precisa de um título de nível 3 e por aí vai.
• Títulos devem ter maiúsculo apenas na primeira letra da primeira palavra (em inglês, chamado de sentence case); e não maiúsculo para cada palavra: Meu novo título; e não Meu Novo Título.
• Evite usar links em títulos porque eles quebram a consistência do estilo e não ficam muito bem. Geralmente, o texto âncora também é encontrado no conteúdo da seção, do contrário você pode usar uma sentença simples como:

Veja Alguns artigos relacionados para mais informação.

Pelo mesmo motivo, também evite usar qualquer tipo de HTML ou código de marcação wiki, incluindo modelos de #Formatação de código. Veja também Help:Estilo/Formatação e pontuação.

• Veja Help:Uso efetivo de cabeçalhos para mais informações.

Formatação

Formatação de código

• Use Template:ic para linhas curtas de código, nomes e caminhos de arquivos, parâmetros de configuração, variáveis e outros casos de representações em linha, como:
  Execute sh ./ola_mundo.sh no console.

• Para linhas singulares de código (entrada de linha de comando ou código de saída ou conteúdo de arquivo) para ser representado em um quadro apropriado, basta iniciá-los com um único caractere de espaço, veja também Help:Edição#Código. Por exemplo:

$ sh ./ola_mundo.sh

Olá Mundo

• Use Template:bc para múltiplas linhas de código (entrada de linha de comando ou saída de código e conteúdo de arquivo) serem representadas em um quadro apropriado. Por exemplo:

#!/bin/sh

# Demo
echo "Olá Mundo"

• Use Template:hc quando houver necessidade de representar ambos entrada e saída da linha de comando, por exemplo:

$ sh ./ola_mundo.sh

Olá Mundo

• Quando você precisa para representar o conteúdo de arquivo e você sente que pode ser difícil para leitores entenderem a qual arquivo que o código se refere, você pode usar Template:hc para mostrar o nome do arquivo no cabeçalho. Por exemplo:

~/ola_mundo.sh

#!/bin/sh

# Demo
echo "Olá Mundo"

• Para blocos de código como um arquivo de configuração, considere focar o leitor nas linhas relevantes e inserir reticências (...) em volta, para os conteúdos irrelevantes.

• Veja o artigo Help:Modelo para mais informações e para solução de problemas com caracteres que quebram os templates, como = ou |.

Texto de linha de comando

• Ao usar código em-linha (Template:ic), nenhum símbolo de prompt será representado, mas quaisquer notas sobre permissões deve ser adicionadas explicitamente ao texto contido.
• Ao usar um código de bloco (Template:bc ou linhas iniciando com um caractere de espaço), use $ como um prompt para comandos de usuário comum; use # como um prompt para comandos como root.
  Nota: Pois # também é usado para denotar comentários em arquivos texto, você deve sempre ter certeza de evitar ambiguidades, geralmente escrevendo explicitamente para executar o comando ou editar um arquivo texto.
  • A sentença introduzindo um bloco de comando geralmente deve finalizar com :.
  • A menos que seja realmente necessário, prefira usar:

    # comando

    a escrever:

    $ sudo comando

  • Não use o prompt de root e comando sudo juntos, como em:

    # sudo comando

    A única exceção é quando sudo é usado com a opção -u: neste caso, o prompt pode corresponder a outros no mesmo bloco de código, ou voltar para $.
  • Não adicione comentários na mesma caixa de um comando, por exemplo:

    # pacman -S foo  #Instala o pacote foo

  • Evite escrever linhas de código excessivamente longas: use técnicas de quebra de linha quando possível.
• Não presuma que o usuário usa sudo ou outros utilitários de elevação de privilégios (ex.: gksu, kdesu).

Teclas de teclado

• A forma padrão para representar teclas do teclado em artigos é usando instâncias de Template:ic.
• Teclas de letras devem ser representadas em minúsculo: a. Para representar letras maiúsculas, use Shift+a em vez de Shift+A ou A.
• A forma correta de representar combinações faz uso do símbolo + para juntar teclas, com nenhum espaço adicional em envolta dele, em uma única instância do template: Ctrl+c.
  Ctrl + c, Ctrl+c, Ctrl-c são formas em desconformidade, e deve ser evitado.
• A forma correta de representar sequências de teclas é tanto verbosa, ex.: "pressione g seguido por Shift+t", ou concisa, separando as teclas com um único espaço em diferentes instâncias do template: g Shift+t.
• A seguir estão formas padrões de representar algumas teclas especiais:
  • Shift (não SHIFT)
  • Ctrl (não CTRL ou Control)
  • Alt (não ALT)
  • Super (não Windows ou Mod)
  • Enter (não ENTER ou Return)
  • Esc (não ESC ou Escape)
  • Space (não SPACE)
  • Backspace
  • Tab
  • Ins (não INS ou Insert)
  • Del (não DEL ou Delete)
  • PrintScreen
  • Up (não ↑ ou Up Arrow) – de forma similar para outras teclas de setas
  • PageUp
  • PageDown
  • Fn (não FN ou fn) – a tecla de função presente em muitos laptops
  • Home (não HOME ou Beginning)
  • End (não END)

Notes, Warnings, Tips

• Uma Note (para artigos traduzidos, Nota) deve ser usada para informações que de alguma forma se divergem do que naturalmente se espera em algum ponto no artigo. Isso também inclui informações que fornecem mais conhecimento aprofundado sobre alguma coisa em particular que, do contrário, seria considerada fora do escopo do artigo. Um outro exemplo é quando é necessário apontar um anúncio temporário, como uma alteração no nome de um pacote.

Uma Note também pode ser usada para realçar informações que são importantes, mas facilmente negligenciados por alguém novo neste assunto.

• Uma Warning (para artigos traduzidos, Atenção) deve ser usada quando o procedimento descrito poderia causar consequências severas tais como ser razoavelmente difícil de desfazer ou resultar em dano para o sistema. Warnings devem indicar ambos os piores cenários assim como as condições que poderiam levar ou que poderiam evitar tais piores casos.

Em geral, não abuse de Warnings: se você está em dúvida, provavelmente você deve usar uma Note.

• Uma Tip (para artigos traduzidos, Dica) deve indicar um método ou procedimento que pode ser útil e trazer benefícios para alguém, apesar de não ser necessário para completar a operação com a qual está sendo lidada e, portanto, pode ser ignorada sem perigo.
• Quando duas ou mais notas, atenções ou dicas tiverem que aparecer uma após a outra no mesmo lugar em um artigo, prefira agrupar seus textos em uma lista dentro de um único template, evitando empilhamento de templates a menos que elas sejam completamente desrelacionadas. Por exemplo:

Dica:

• Exemplo de dica #1.
• Exemplo de dica #2.

Tabelas

Veja mw:Help:Tables/pt-br para a sintaxe.

• As tabelas geralmente devem ter a classe wikitable.
• Tabelas comparativas devem ter, adicionalmente, a classe sortable.
• Use cabeçalhos de tabelas e modelos de células de tabela quando apropriado.
• Cabeçalhos de tabela devem estar em maiúsculo somente na primeira letra da primeira palavra (em inglês, sentence case).
• Legendas de tabelas devem usar listas de definição e serem substituídas antes das tabelas.

Instruções

Requisições de edição de arquivo

• Não presuma um editor de texto específico (nano, vim, emacs, etc.) ao requisitar edições de arquivo de texto, exceto quando necessário.
• Em geral, não use comandos para implicitamente requisitar edições de arquivos texto. Por exemplo, $ echo -e "clear\nreset" >> ~/.bash_logout deve ser:

Adicione as seguintes linhas a ~/.bash_logout:

clear
reset

Uma exceção comum são comandos que envolvem gerar uma saída complexa e específica de sistema, como genfstab -U /mnt >> /mnt/etc/fstab.

Onde for útil, um link para Help:Leitura#Acrescentar, adicionar, criar, editar pode ser adicionado.

Instruções de gerenciamento de pacote

Pacotes oficiais

• Por favor, evite usar exemplos de comandos do pacman para fornecer instruções para instalação de pacotes oficiais: isso foi estabelecido tanto para a simplicidade (todo usuário Arch deve conhecer o artigo do pacman de memória) e para evitar erros como pacman -Sy pacote ou possivelmente discussões intermináveis como a escolha entre pacman -S pacote e pacman -Syu pacote. Outro motivo é que você não deve sugerir o uso de frontends ou wrappers do pacman.

Em vez disso, basta usar uma afirmação como:

Install the foobar package.

Ou se, por exemplo, o nome de aplicativo for diferente do nome do pacote:

MeuAplicativo can be installed with the pkg-meu-app package.

As instruções para instalação de uma lista de pacotes pode aparecer como:

Install the foobar1, foobar2 and foobar3 packages.

Se estiver se referindo a um grupo de pacotes, você pode usar:

Install the foobar group.

Você tem a flexibilidade para adaptar as palavras a seu artigo específico.

• Links para pacotes referenciados são obrigatórios e devem ser criados usando o Template:Pkg; por exemplo {{Pkg|foobar}}.

Ao se referir a grupos de pacotes, Template:Grp deve ser usado; por exemplo: {{Grp|foobar}}.

• Os exemplos acima também fazem uso de um link para install (ex.: [[install]]), podendo-se usar, no caso de artigos traduzidos, a versão em português instalar ou instale (ex.: [[instalar]]): seu uso é recomendado pelo menos na primeira ocorrência de uma requisição de instalação, especialmente em artigos que provavelmente serão visitados por novatos do Arch.
• Se o pacote é hospedado nos repositórios core, extra ou community, não faça referência ao repositório, facilitando manutenção porque não é incomum para um pacote ser movido para um repositório diferente. Porém, se o pacote é hospedado em um repositório oficial que não esteja habilitado por padrão (multilib, testing etc.), mencionando que é necessário, usando um palavras como:

Install the foobar package from the official multilib repository.

Pacotes do AUR

• Por favor, evite usar exemplos de como instalar pacotes do AUR, seja com o método oficial ou mencionando auxiliares do AUR. Todo usuário que instala pacotes extraoficiais deve ter lido o artigo do Arch User Repository e estar ciente de todas as consequências possíveis em seu sistema.

Em vez disso, basta usar uma declaração simples como:

Install the foobar^AUR package.

Você tem a flexibilidade para adaptar as palavras a seu artigo específico. Veja a seção em #Pacotes oficiais para mais exemplos.

• Links para pacotes referenciados são obrigatórios e devem ser criados usando Template:AUR (ex.: {{AUR|foobar}}).

Repositórios extraoficiais

• Ao sugerir o uso de um repositório extraoficial para instalar um pacote pré-compilado, não forneça instruções para habilitar o repositório, mas certifique-se que tal repositório esteja incluído em Repositórios não oficiais de usuário e então basta fazer link para ele. Também, assim como com pacotes oficiais, não adicione exemplos de comandos do pacman. Por exemplo:

Install the foobar package from the example repository.

Se o pacote também estiver disponível no AUR:

Install the foobar^AUR package, also available in the example repository.

Se o pacote estiver disponível no AUR com um nome diferente:

Install the aurpkg^AUR package, also available as builtpackage from the example repository.

Você tem a flexibilidade para adaptar as palavras para seu artigo específico.

• O link para Repositórios não oficiais de usuário é obrigatório e deve apontar para a seção de repositório relevante; por exemplo [[Unofficial user repositories#example|exemplo]].

Operações de units de systemd

• Não dê exemplos de como habilitar, iniciar ou realizar uma outra operação básica com systemctl em units de systemd. Em vez disso, use uma sentença simples para listar as units envolvidas, possivelmente comentando sobre dependências e conflitos com outras units, e uma descrição das ações a serem realizadas. Por exemplo:

To have GDM launched at boot time, enable gdm.service.

Ou, se por exemplo a unit for um modelo que precisar instanciação:

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.

Você tem a flexibilidade para adotar as palavras a seu artigo específico.

• Certifique-se de fazer link para a seção de artigo systemd#Using units (ou, para um artigo traduzido, systemd (Português)#Usando units), seja diretamente ou por meio de um redirecionamento dedicado, como [[start]], [[enable]] or [[stop]] (ou, para artigos traduzidos, as respectivas versões traduzidas, como [[inicie]], [[habilite]] or [[pare]]).

Shells

• Não presuma um shell específico como o shell do usuário (ex.: Bash), exceto quando realmente necessário: no que tange a shell, tente ser o mais neutro possível ao escrever ou editar artigos.

Metáfora de hipertexto

Veja Help:Edição#Links para a sintaxe dos links internos, interwiki e externos.

• Tente interligar o seu artigo com tantos outros quanto possível, usando as palavras no texto.
• Vincule apenas a artigos existentes. Se você encontrar um link quebrado, tente consertá-lo. Links externos que parecem estar quebrados devem ser marcados com Template:Dead link. (Em páginas traduzidas, use Template:Dead link (Português))
• Evite links implícitos sempre que possível. Por exemplo, prefira instruções como "See the systemd article for more information" em vez de "See here for more information".

Um link pode ser usado em duas formas:

• Como uma referência a tópico, na qual o link é um termo, parte da sentença ou sujeito a regras de gramática comum: use um rótulo de link se necessário; links internos/interwiki devem apontar para um redirecionamento se disponível.
• Como uma referência de página/seção: não use um rótulo de link e escreva o título também de acordo com Template:Lowercase title onde usado; em particular, não oculte o símbolo # nos links da seção de mesma página, por exemplo, [[#Metáfora de hipertexto|Metáfora de hipertexto]].

Veja esses exemplos:

Referência a tópico	Referência a página/seção
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
style rules]] for links	The #Metáfora de hipertexto section has style rules for links

• Antes de escrever um procedimento específico em um artigo ou descrever algumas coisa em particular, sempre verifique se já há algum artigo que trata daquela parte em detalhes: naquele caso, vincule aquele artigo em vez de duplicar seu conteúdo. Também:
  • Para termos técnicos não cobertos por um artigo no ArchWiki, vincule à página Wikipédia relevante.
  • Se a documentação upstream do assunto de seu artigo estiver bem escrita e mantida, prefiram escrever adaptações específicas do Arch e vincular a documentação oficial para informações gerais.

Por exemplo: "Kernel parameters are used to issue system calls at boot; see the Linux kernel documentation for a complete list."

Em geral, mantenha coerência com Help:Leitura#Organização.

• Exceto em casos raros, você não deve deixar um artigo como uma página sem saída (um artigo que não faz vínculo a qualquer outro) ou uma página órfã (um artigo que não está vinculado a partir de outra página).
• Não use links interwiki para links a páginas localizadas do mesmo idiomado artigo sendo editado porque eles não serão mostradas nas páginas Special:WhatLinksHere. Por exemplo, usar [[:hu:Main page]] em um artigo húngaro é errado, enquanto [[Main page (Magyar)]] está correto.
  Usar esse tipo de links entre idiomas diferentes é aceitável porque isso facilitaria mover os artigos para um wiki separado no caso de um wiki separado ser criado no futuro.
  Finalmente, note a diferença deste tipo de links para #Links interlínguas, que não possuem o caractere de dois pontos no começo.
• Prefira o prefixo interwiki "Wikipedia:" ao prefixo abreviado "w:".

Páginas man

• Referências a página man devem ser adicionados usando Template:man.

Estilo de código

• Ao adicionar comandos ou scripts, use um estilo de codificação consistente por todo o artigo, possivelmente algo fazendo referência a outros artigos, especialmente se houver algum relacionado. Se disponível, respeito as diretrizes de estilo de codificação mais comum para o idioma.
• Evite recursos obsoletos da linguagem de programação/scripting que você está usando: por exemplo, use a sintaxe $() para substituição de comandos shell em vez da sintaxe acento grave (``).
• Scripts devem ser escritos para fazer o que é minimamente necessário para realizar a tarefa na forma mais clara possível. Eles não devem ser projetados para flexibilidade ou expansão: prefira usar pseudo-variáveis em vez das reais variáveis. Não adicione funcionalidade irrelevante, tal como interpretação de argumentos ou formatação de saída.
• Scripts devem ser adicionados principalmente para propósitos educacionais, quando a explicação verbosa no texto do artigo não puder ser feita com suficiente clareza e concisão. Eles podem ser úteis para, por exemplo, mostrar como um comando complexo deve ser usado, ou como os comandos relacionados ou interdependentes devem funcionar juntos.
• Se um script deveria adicionar valor a um artigo, mas não atende aos critérios acima, ele pode ser vinculado externamente, possivelmente publicando-o como um gist.
• Ao representar o nome ou caminho de um diretório, termine-o com um caractere de barra ou adicione explicitamente um apóstrofo como um "diretório" de "pasta". Por exemplo:

• "Check if the /sys/firmware/efi directory has been created", e não "Check if /sys/firmware/efi has been created".
• "Place a .conf file in /etc/modules-load.d/", e não "Place a .conf file in /etc/modules-load.d".

• Argumentos contendo espaços devem ser envolvidos por caracteres de aspas duplas, ex.: cd "foo bar" em vez de cd foo\ bar.

Versões de kernel com suporte

• Não remova quaisquer anotações ou adaptações sobre versões do kernel maiores ou iguais à versão mínima entre o pacote atual linux-lts no repositório core e o kernel na mídia de instalação mais recente.

Conteúdo não pertinente

• Por favor, não assine artigos nem credite autores de artigo: o ArchWiki é uma obra da comunidade e a história de cada artigo é o suficiente para creditar seus contribuidores.
  Relatar os fontes usado para escrever um artigo, porém, é uma boa prática: você pode usar a seção "See also" (Veja também) para esse propósito.
• O envio de arquivos está desabilitado para usuários normais, e incluir imagens nos artigos não é permitida. Como uma alternativa, você pode incluir links para imagens externas ou galerias, e se você precisar desenhar diagramas simples, você pode usar um editor ASCII, como Asciiflow e Template:Text art. Justificativa:
  • Manutenção: Arch segue lançamento contínuo (rolling release), e imagens tornariam atualização de artigos muito mais difícil.
  • Necessidade: Arch não desenvolve nem mantém qualquer tipo de aplicativo de GUI, de forma que nós não precisamos exibir qualquer captura de tela.
  • Moderação: envio de imagem livre exigiria gastar tempo para remover imagens inapropriadas ou grandes demais.
  • Acessibilidade: nós apoiamos usuários com conexões lentas, navegadores só de texto, leitores de tela e similares.
  • Eficiência: imagens gastam largura de banda e espaço de armazenamento de servidor.
  • Simplicidade: artigos de somente texto parecem mais simples e arrumados.

Ortografia

• Evite contrações: "don't", "isn't", "you've", etc. devem ser "do not", "is not" e "you have", por exemplo.
• Evite abreviação desnecessária de palavras: por exemplo, em vez de "repo", "distro" e "config", prefira "repository", "distribution" e "configuration".
  No mesmo estilo, prefira usar a forma longa de opções de comandos incomuns em vez de suas formas de um caractere. Veja também Help:Estilo/Formatação e pontuação#Parâmetros de configuração, variáveis, opções, propriedades....
• Os nomes de projetos, aplicativos, executáveis etc. devem ser escritos, especialmente no que se refere a maiusculização, principalmente em conformidade com o estilo da sua documentação oficial. Isso inclui o caso no qual a documentação trata o nome como um substantivo comum, i.e. com a primeira letra maiúscula quando aparece no início de uma sentença e, do contrário, minúsculo. Se a documentação oficial não define um estilo consistente, siga o estilo que já é usado no ArchWiki. Se o nome não aparece no ArchWiki, ou ele ainda possui escrita inconsistente, escolha um estilo e utilize-o ao longo do artigo, também possivelmente atualizando outras páginas que mencionam o nome. Pegando o Git como um exemplo, você pode escolher escrever o nome com a primeira letra maiúscula ("Git") quando estiver falando sobre o projeto/software em geral, e usar todas letras minúsculas e em itálico ("git") ao se referir ao programa compilado. Quando nome maiúsculo puder gerar controvérsia, defina explicitamente um estilo na página talk do artigo. Veja também Help:Estilo/Formatação e pontuação#Nomes de executável/aplicativo
• ArchWiki não prefere nenhuma variedade nacional de inglês sobre qualquer outra, adotando as mesmas diretrizes descritas em Wikipedia:Wikipedia:Manual of Style#National varieties of English; em caso de conflito com qualquer outra diretriz explicitamente definida do ArchWiki, prevalece a do ArchWiki. Ao escrever um novo conteúdo dentro de um artigo existente, é recomendado manter a convenção ortográfica já prevalecente nele (para páginas traduzidas, siga Ortografia portuguesa); se o artigo não tiver uma ortografia predominante clara, escreva de acordo com a variante usada na seção editada. A harmonização da ortografia em torno do conteúdo editado é aceitável, porém abstenha-se de realizar edições cujo objetivo principal seja alterar ou harmonizar o padrão ortográfico de artigos ou séries dos mesmos.

Registro de linguajar

• Os artigos devem ser escritos usando linguajar formal, profissional e conciso. Deve-se ter o cuidado de remover erros gramaticais e ortográficos por meio de previsão de edição e revisão.
• Lembre-se de não apenas responder o como, mas também o por que. As informações explicativas sempre vão além de transmitir conhecimento do que apenas a instrução.
• Não omita termos que são necessários para fornecer um significado exato e não ambíguo a uma sentença. Por exemplo, sempre adicione a palavra "repository" ao mencionar o nome de um repositório.
• Não use referências em tempo indefinido, tal como "currently" ("atualmente"), "at the time of writing" ("quando da escrita") ou "soon" ("em breve"); substitua por expressões definitivas tal como "as of May 2015" ("a partir de Maio de 2015") etc.
• Escreva objetivamente: não inclua comentários pessoais em artigos; use páginas de discussão para esse propósito. Em geral, não escreva na primeira pessoa.
• Ao editar conteúdo, seja consistente com o estilo usado no resto do artigo. Por exemplo, se o leitor é sempre mencionado na segunda pessoa, esse estilo deve ser adotado pelo conteúdo adicionado; o mesmo vale se terceira pessoa ou voz passiva são claramente dominante ao longo do artigo.
• Ao oferecer uma escolha entre diferentes opções (pedaços de software, métodos para fazer alguma coisa, etc.) não recomende explicitamente uma sobre as outras, mas descreva objetivamente as vantagens e desvantagens de cada uma, assim ajudando o leitor a tomar a melhor decisão para seu caso pessoal.
• Dê preferência para pronomes neutros, como they/them ao se referir ao leitor ou pessoas em geral.

Páginas de categoria

• Toda categoria deve ser apropriadamente categorizada sob pelo menos uma categoria pai, exceto para as categorias raízes, que são Category:Archive, Category:DeveloperWiki, Category:Languages, Category:Maintenance e Category:Sandbox.
• Uma categoria pode ser categorizada sob mais de uma categoria, desde que um não seja antecessora das outras.
• Evite relações circulares: duas categorias não podem ser reciprocamente antecessoras.
• Não categorize uma categoria sob si própria (categoria autocategorizada).
• Categorias devem ser incluídas no topo da página da categoria.
• Categorias não devem redirecionar, exceto temporariamente enquanto renomeia.
• Por padrão, nomes de categorias devem estar na forma singular (categorias "tópicas", como Category:Simulation); elas devem estar na forma plural se a forma singular puder ser usada para descrever um de seus membros (categorias "conjunto", como Category:Boot loaders).

Páginas de redirecionamento

• É encorajado criar páginas de redirecionamento para acrônimos ou variantes gramaticais do título de um artigo existente, ou para um termo ou tópico discutido em uma subseção de um artigo mais genérico, por exemplo ALSA, daemon ou AIGLX. Redirecionamentos podem simplificar o texto fonte substituindo os links rotulados, comparando os exemplos anteriores com [[Advanced Linux Sound Architecture|ALSA]], [[daemons|daemon]] ou [[Xorg#Composite|AIGLX]].
• Páginas de redirecionamento devem conter apenas o código de redirecionamento e nada mais. As únicas exceções são:
  • Páginas arquivadas, que na verdade são redirecionamentos, devem ser categorizados sob Category:Archive.
  • Categorias renomeadas podem conter uma marcação Template:Archive.
• Redirecione apenas para artigos internos; não use redirecionamentos interwiki.

Redirecionamentos usando links interlínguas são excepcionalmente permitidos em conformidade com Help:i18n (Português) e mediante autorização da Equipe de Manutenção.

• Veja Help:Edição#Redirecionamentos para mais informações.

Páginas de usuário

• Páginas no espaço de nome User não podem ser categorizadas.
• Páginas no espaço de nome User só podem ser vinculados a partir de outras páginas nos espaços de nome User ou talk, a menos que autorização para fazer o contrário seja concedida pelos Administradores.
• Páginas no espaço de nome User não podem ser alvos de redirecionamentos de outros espaços de nomes.

Regras gerais

Resumo de edição

Veja ArchWiki:Contribuindo#As 3 regras fundamentais.

Tags HTML

• O uso de tags HTML é geralmente desencorajado: sempre prefira usar marcação wiki ou templates quando possível, veja Help:Edição e relacionados.
• Quando está tentando usar <pre>código</pre>, sempre use {{bc|código}}. Quando tentado usar <tt>texto</tt> ou <code>texto</code>, sempre use {{ic|texto}}.
• Especialmente, evite comentários HTML (<!-- comentário -->): é provável que uma nota adicionada em um comentário HTML possa ser mostrada explicitamente na página de discussão do artigo.
  Você pode adicionar um Template de status de artigo no lugar do comentário.
• Use apenas <br> quando necessário: para iniciar um novo parágrafo ou quebrar uma linha, coloque uma linha em branco abaixo.
  Exceções comuns a essa regra são quando é necessário quebrar uma linha em um item de lista e você não puder usar um subitem ou dentro de um template e você não puder usar uma lista.