Help:Style (Português)

From ArchWiki
Jump to: navigation, search

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.
  • Se o assunto do artigo é comumente conhecido pelo nome completo e pelo 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:Article naming guidelines (Português) para mais informações.

Layout

  • Ordene elementos em um artigo conforme esta lista:
  1. #Palavras mágicas (opcional)
  2. #Categorias
  3. #Links interlínguas
  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:Category (Português) 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, podem 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 também podem ser usados dentro de seções de artigos, quando apropriado.
  • 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

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 é MediaTomb.
  • 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:Writing article introductions para mais informações.

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; 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 tamém Help:Style/Formatting and punctuation.

Formatação de código

  • Use {{ic|code}} para linhas curtas de código, nomes de arquivos, nomes de comandos, nomes de variáveis e 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:Editing (Português)#Código. Por exemplo:
$ sh ./ola_mundo.sh
Olá Mundo
  • Use {{bc|code}} 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 {{hc|entrada|saída}} 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 {{hc|nome do arquivo|conteúdo}} 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:Template (Português) 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).

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:Reading (Português)#Acrescentar, adicionar, criar, editar pode ser adicionado.

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
    • PageUp
    • PageDown

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 foobarAUR 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 extraoficiais 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 foobarAUR package, also available in the example repository.
Se o pacote estiver disponível no AUR com um nome diferente:
Install the aurpkgAUR package, also available as builtpackage from the example repository.
Você tem a flexibilidade para adaptar as palavras para seu artigo específico.

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 (Português). 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]]).

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:
Tip:
  • Exemplo de dica #1.
  • Exemplo de dica #2.

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

  • Tente interligar seu artigo com o máximo de artigos que você puder, usando as várias palavras-chave no texto. Porém, apenas vincule um artigo a um novo artigo após criá-lo. Em geral, não crie vínculos para artigos inexistentes.
  • Ao vincular a outros artigos do wiki, não use URLs completas; aproveite a sintaxe especial para links internos: [[Artigo wiki]]. Isso também permitirá que o motor wiki mantenha rastro de links internos, facilitando a manutenção.
    Veja Help:Editing (Português)#Links para informação aprofundada e usos mais avançados da sintaxe de links interwiki.
  • Se um link faz referência ao termo ou tópico descrito na página ou seção alvo, possivelmente aponte-o para um redirecionamento para o termo ou nome do tópico, ou use um rótulo de link. Regras normais de gramática se aplicam, i.e. substantivos comuns devem estar em minúsculo, a menos que o início de uma sentença, e substantivos próprios devem ser escritos como exigido.
Por exemplo: "Use an SSH agent to speed up authentication" ou "Subpixel rendering is supported by most monitors" ou "Include a keyfile in the initramfs" ou "Be aware that mouse keys is disabled by default" ou "We have style rules for links".
  • Se um link interno/interwiki faz referência à página ou seção alvo em si, em vez de um tópico por ela descrito, basta mostrar o link simples sem um rótulo, também em conformidade ao Template:Lowercase title onde usado.
Por exemplo: "Follow SSH keys#SSH agents to speed up authentication" ou "Enable subpixel rendering as described in Font configuration#Subpixel rendering" ou "Instructions can be found in dm-crypt/Device encryption#Keyfiles" ou "See w:Mouse keys for details" ou "The #Hypertext metaphor section has style rules for links".
  • Não oculte o símbolo # nos links de seção de mesma página, ex.: [[#Metáfora de hipertexto|Metáfora de hipertexto]]. Além da reformatação desnecessária, a âncora de seção fornece uma indicação clara de que o link aponta para uma outra seção, e não para outro artigo.
  • 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:Reading (Português)#Organização.
  • Evite vincular implicitamente 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".
  • 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.

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.

Páginas man

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.

Seções de "Known issues"

  • Seções de Known issues (em artigos traduzidos, Problemas conhecidos) são usadas para bugs conhecidos ou problemas de uso que ainda não têm solução (comparar com as #Seções 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ções de "Tips and tricks"

  • Seções de Tips and tricks (em artigos traduzidos, Dicas e truques) 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ções de "Troubleshooting"

  • Seções de Troubleshooting (em artigos traduzidos, Solução de problemas) são usadas para perguntas frequentes sobre o software ou para soluções para problemas comuns (compare com #Seções 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, é muito desejado que você forneça um link para o relatório de bug. 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ções de "See also"

  • Seções See also (em artigos traduzidos, Veja também) 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). Outros títulos similares, tais como External links ("links externos"), More resources ("Mais recursos"), etc. devem ser evitados.

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 as imagens existentes 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. 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.
  • 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 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.

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.

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"); elas devem estar na forma plural se a forma singular puder ser usada para descrever um de seus membros (categorias "conjunto").

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

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.

Regras gerais

Resumo de edição

Veja ArchWiki:Contributing (Português)#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:Editing (Português) 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.