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:
#Palavras mágicas
(opcional)
#Categorias
#Links interlínguas
(opcional)
#Modelos de status de artigo
(opcional)
#Caixa de artigos relacionados
(opcional)
#Prefácio ou introdução
Tabela de conteúdos (automático)
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.