Diretrizes do Site GNU

Nosso objetivo é levar informações às pessoas. Manter o design do site simples ajuda a cumprir isso.

Por favor, seja atencioso com todas as pessoas que acessam nossas páginas da web e acomode-as, incluindo aquelas que usam navegadores somente de texto ou navegadores antigos, bem como aquelas com conexões lentas. Desejamos evitar que os designs web tenham uma ótima aparência em uma versão de um navegador e que seja feio em muitos outros. Claro, por favor, não instale nenhum dos navegadores web privativos disponíveis se você já não os usa.

Diretrizes gerais

• O servidor web GNU tem apenas software livre disponível. Nós preferimos que apenas software livre seja usado para preparar páginas para o servidor web GNU.
• O site do GNU lista e vincula somente a software livre. O código-fonte e os executáveis do software precisam ser livremente redistribuídos e modificáveis para e por todas as pessoas e organizações. Em caso de dúvida, pergunte <[email protected]>.
• O site GNU dá prioridade a software coberto pela Licença Pública Geral GNU ou pela Licença Pública Geral Menor GNU.
• O uso de gráficos deve ser minimizado, de forma que as páginas sejam carregadas rapidamente em conexões lentas.
• Ofereça um documento em tantos formatos quanto o Projeto GNU. Por exemplo, veja a Licença de Documentação Livre GNU. Isso permite que usuários obtenham o documento no formato mais útil para eles.
• Além dos avisos de direitos autorais e de licença, todas as páginas devem ter informações de contato para a FSF (ou responsável) e o endereço para relatórios de erros (webmasters para páginas gerais, mas projetos endereços específicos de outra forma) na parte inferior de cada página. O motivo para anotar isso na parte inferior é para que o usuário sempre encontre essas informações no mesmo lugar em cada página.
• Antes de pegar qualquer gráfico ou texto de outro site, peça permissão para usá-lo. É educado fazê-lo. Também é essencial que evitemos a violação de direitos autorais.
• Antes de adicionar um link, verifique se ele segue nossos critérios de links.
• Não liste um endereço de alguém específico, incluindo o do mantenedor de um pacote GNU, a menos que seja explicitamente solicitado que seja listado. A maioria dos mantenedores do GNU não quer muitos e-mails extras e prefere receber relatórios de errors, etc., das listas de discussão de relatório de erros do GNU.
• Em páginas com entradas datadas (por exemplo, /philosophy/latest-articles.html), as entradas mais recentes devem ser as primeiras (ou seja, ordem cronológica inversa).
• As páginas não devem carregar CSS de servidores que não sejam aqueles executados pela FSF.
• Geralmente, o uso de JavaScript não é permitido. Exceções a isso precisam ser revisadas e aprovadas pelo Cheif GNUisance, caso a caso.

Diretrizes de direitos autorais

• Cada página deve ter um aviso de direitos autorais. Veja o boilerplate, referido abaixo.
• Cada página deve ter um aviso dando permissão a todos para distribuí-la. Se você não puder obter essa permissão do autor, discuta o problema com os webmasters antes de publicá-la. Isso se aplica ao CSS e ao HTML.
• Normalmente você não deve publicar uma página que não seja de direito autoral da FSF, a menos que tenhamos permissão para modificar a versão que publicamos. Se você não puder obter tal permissão do autor, por favor, discuta o assunto com a FSF antes de publicá-la. Isso se aplica ao CSS e ao HTML.
• Se, em última análise, decidirmos publicar uma nova página que não temos permissão para modificar, coloque o texto “Posted in 20XX without FSF permission to modify” dentro de um comentário HTML, logo após o aviso de direitos autorais.
• O usuário de nossas páginas deve sempre encontrar as informações de direitos autorais no mesmo lugar em cada página. Se a página for protegida por direitos autorais por outra pessoa ou entidade, use seu aviso de direitos autorais em vez do aviso de direitos autorais da FSF. Use o resto do material de rodapé normal da FSF, exceto quando houver uma razão específica para alterar algo nele.
• Todas as páginas que explicam como fazer algo, como usar determinados programas, são documentação. Isso inclui todas as páginas em /software/ que descrevem programas específicos. Pelos nossos princípios, a documentação deve ser livre. Portanto, essas páginas devem ter uma licença livre. Se essa página não tiver uma licença livre, relate o problema para <[email protected]>.
• Para outras páginas, use a mesma licença que outra página que serve a um propósito semelhante.

Escrita e pontuação

• As páginas em inglês devem seguir as convenções padrão norte-americano de ortografia, hifenização e pontuação.
• Como essas convenções nem sempre são muito específicas, especialmente no que diz respeito a hifenização e citações, o gnu.org acrescenta suas próprias regras para manter a consistência:
  • O termo “nonfree” é preferido a “non-free”; da mesma forma, “noncommercial” a “non-commercial”.
  • Em um texto comum, as entidades HTML ““…”” e “‘…’” são preferidas às aspas retas ("..." e '...'). Isso não se aplica a documentos gerados por script.
  • Onde eles existem, os espaços duplos após as quebras de sentença devem ser preservados. Eles permitem que os comandos de sentença do Emacs façam a coisa certa.

Nomes de arquivos

• Para facilitar a edição simultânea de vários arquivos, tente dar a cada arquivo HTML um nome único e descritivo; o nome do arquivo index.html deve ser usado apenas como um link simbólico, como explicado a seguir.
• Cada diretório na árvore do servidor da web deve ter um link simbólico chamado index.html para o arquivo HTML de nível superior desse diretório. Use o arquivo .symlinks para lidar com isso.
• Se você traduzir sua página web em diferentes idiomas, por favor, nomeie o arquivo em inglês artigo.html e suas traduções artigo.idioma.html – idioma deve conter o código de idioma de duas letras da ISO 639 e, opcionalmente, um hífen seguido o código de país de duas letras dado na ISO 3166 (minúsculas). Por exemplo, a tradução em alemão de not-ipr.html deve ser nomeada not-ipr.de.html; a tradução em português brasileiro deve ser nomeada não-ipr.pt-br.html.

URLs

• URLs escritas à mão que se referem a outros arquivos em www.gnu.org devem ser absolutas, a partir da página raiz. Ou seja, os caminhos devem começar com / (por exemplo, /gnu/about-gnu.html; não http://www.gnu.org/gnu/about-gnu.html e não about-gnu.html). Isso facilita copiar e colar links de outras páginas. Além disso, links como http://www.gnu.org/ estarão errados quando o visitante usar HTTPS.
• Verifique se o host vinculado oferece suporte a HTTPS e HTTP e use URLs relativos a protocolos (por exemplo, //www.example.org), se for o caso.
• Coleções de arquivos produzidos automaticamente a partir da fonte Texinfo contêm links com nomes de arquivos relativos. Eles sempre se referem a outro arquivo no mesmo diretório. Esses links relativos devem ser tolerados.
• Não use apenas um nome de diretório em um URL; sempre inclua o nome do arquivo específico. Por exemplo, use /gnu/gnu.html, não apenas /gnu/. Nunca use index.html em uma URL. Ambas são gentilezas para o usuário, pois os navegadores alteram o realce em um link após ele ter sido visitado. Se os links para um determinado arquivo usarem várias URLs diferentes, as URLs que não foram explicitamente mencionadas não serão destacadas como visitadas. Assim, o usuário acessa as páginas que ele já viu, o que é irritante. Além disso, isso facilita a manutenção do site à medida que as coisas são movidas.
• Certifique-se de omitir completamente o nome do arquivo ao vincular a uma âncora no mesmo arquivo e tenha certeza de que a âncora realmente funciona.
• Considere outros links para sua página ao remover um atributo de âncora ou id.
• Encorajamos os sites FTP a usarem um diretório para cada pacote e apenas colocarem os arquivos de um pacote em cada diretório, de forma que usuários possam ver quais versões do pacote e informações relacionadas podem ser baixadas (por exemplo, um arquivo README, informações de quais versões estão disponíveis, documentações, fontes, etc.). Além disso, significa que as URLs de localização de FTP não precisam ser alteradas, neste e em outros sites, à medida que novas versões são lançadas nesse diretório.

• Cite pessoas com endereços de e-mail assim:

  <a href="//www.stallman.org/">Richard Stallman</a> <a href="mailto:[email protected]">&lt;[email protected]&gt;</a>

  o que navegadores exibem dessa maneira:

  Richard Stallman <[email protected]>

  Assim é menos confuso para quem lê, porque está claro o que é um link para outra página web e o que é uma âncora mailto: que abrirá um formulário de correio para preencher e enviar, se houver suporte a isso pelo cliente. Além disso, se os usuários salvarem uma cópia da página, eles terão uma cópia do endereço de e-mail que podem usar sem voltar ao navegador web. Se a pessoa não tiver uma página web, deixe o nome sem a âncora.

• Ao incorporar recursos estáticos, como vídeos que não estão no repositório CVS www, juntamente com o restante das páginas www.gnu.org, é importante que a URL usada para incorporar o ativo seja um subdomínio do gnu.org, para que o complemento Third-party Request Blocker enviado com o GNU IceCat não o considere um ativo de terceiros que impediria de ser carregado. Por exemplo, ao incorporar vídeos das campanhas da FSF em www.gnu.org, use static.gnu.org em vez de static.fsf.org. Ambos os endereços foram configurados para apontar para a mesma máquina, para que possam ser usados de forma intercambiável.

Diretrizes de HTML

• HTML no servidor web GNU deve ser estritamente compatível com os padrões do W3C.
• Por favor, siga os padrões da web mencionados acima estritamente. Não negligencie os elementos necessários como <html> <head> <title> <body>, etc. ao usar o (X)HTML e sempre inclua a referência de DTD ou Schema apropriada. Isso apazígua navegadores excessivamente pedantes.
• Não adicione comentários na parte superior de um documento. Os navegadores da Web esperam que o doctype, a declaração XML ou o Schema estejam no topo. Comentários os confundirão e, com frequência, farão com que eles interpretem incorretamente sua marcação.
• O elemento <head> deve conter esta linha:

  <link rel="author" href="mailto:[email protected]">

  Alguns navegadores usam essas informações para permitir que as pessoas relatem facilmente problemas encontrados em uma página.
• A primeira tag de cabeçalho, <h[n]>, deve ter seu texto duplicado no início da tag <title>. A tag <title> é usada por muitos navegadores em menus como o histórico e as listas de favoritos, como um link para essa página. Repetir o cabeçalho principal na tag <title> garante que, quando os usuários clicam em um item nesses menus, eles recebam uma página com o cabeçalho esperado. Por favor, use corretamente seus cabeçalhos em ordem numérica: 1, 2, etc. Estes não são usados para aparência, mas para a organização do documento.
• A tag <title> deve incluir as frases “GNU Project” e “Free Software Foundation” Assim, as páginas serão encontradas quando os mecanismos de pesquisa da web forem usados. O padrão é adicionar isso no final: - GNU Project - Free Software Foundation.
• Acrônimos/abreviações:
  • Nunca use <acronym>: o HTML 5 o tornou obsoleto em favor do <abbr>.
  • Não use <abbr> a menos que seja por um motivo realmente convincente. Os navegadores o processam de maneira feia.
  • Quando uma abreviação pode não ser familiar para um leitor, forneça sua expansão na primeira vez em que for usada em um documento, como: <abbr title="Abreviação Expandida">AE</abbr> ou AE(Abreviação Expandida).
  • Outras ocorrências, em qualquer caso, devem ser escritas sem qualquer marcação: apenas AE.
  • Para inicialismos comuns, como GNU, FSF, BSD, RAM, HTML, DVD e assim por diante, nenhuma marcação é necessária. Use seu julgamento.

Tabelas e menus

• Por favor, use tabelas para organizar dados, não a apresentação da página web.
• Softwares de leitura de tela usados pela maioria das pessoas com deficiência visuais lê o texto da esquerda para a direita, ignorando qualquer tabela que você faça. Se você usa tabelas, você deve se certificar que ler uma página inteira da esquerda para a direita não confunda tal software. Siga as diretrizes de acessibilidade na web do W3C para garantir que as tabelas sejam marcadas adequadamente para fins de acessibilidade.
• Algumas pessoas gostam de organizar links como um menu à esquerda ou à direita do texto principal ao usar navegadores gráficos. Isso não funciona muito bem com os navegadores de texto, pois eles farão com que o menu apareça no topo da página ou na parte inferior. Se você tiver um menu com mais de 30 linhas, é muito provável que um usuário que esteja visualizando a página nunca se importe em ler o texto, pois ele estará muito baixo. Você deve fazer um esforço para manter esses menus com menos de 20 linhas, para que o início do artigo seja visível na primeira página ao visualizá-lo com um navegador de texto. Uma barra de menu de uma ou duas linhas horizontais também pode realizar seu propósito. Fornecer um “skip link” para o texto principal é outra opção.

Usando nosso modelo de página

• Para ajudar as pessoas a seguir as diretrizes acima, um modelo de página (ou “boilerplate”) é fornecido tanto para a parte principal do website GNU quanto para os projetos de software. Seu uso é obrigatório para novas páginas em www.gnu.org e altamente recomendado para páginas de software. Por favor, não comece com uma página existente para criar uma nova; use a fonte original do boilerplate e siga as instruções nele contidas.
• As páginas modeladas em XHTML devem seguir as diretrizes do XHTML-1.0.
• Nosso lado do servidor inclui declarar UTF-8 como a codificação de caracteres, portanto, usar qualquer outra codificação é problemático.

Estilo

Estilo de páginas modeladas

• O estilo genérico para desktops e smartphones é fornecido por /layout.css ; ele cobre a maioria dos nossos casos de uso.
• Dispositivos móveis com recursos muito limitados usam /mini.css. Esta folha de estilo é apenas as folhas de estilo reset e base da Yahoo User Interface (versão 2), pois esses dispositivos normalmente têm uma necessidade mínima de várias fontes e não precisam de layouts sofisticados.
• Impressoras usam /print.css. Observe que o cabeçalho, barras de navegação e rodapé (exceto direitos autorais e licença) não são imprimíveis.
• Além de /layout.css, algumas páginas têm folhas de estilo especializadas: /graphics/graphics.css para a seção de Arte do GNU e /side-menu.css para as seções Malware e Educação.
• Se algum estilo especial for necessário para uma página específica, ele deve ser adicionado à própria página em um elemento <style>, entre as diretivas SSI que incluem header.html e banner.html. Se o estilo se aplicar a um único elemento, normalmente ele deve ser adicionado como um atributo.
• Se você especificar qualquer atributo de cor no HTML, deverá especificar todos os que são permitidos para essa tag. Isso ocorre porque alguns navegadores permitem que os usuários especifiquem padrões para os atributos de cores, e as escolhas do usuário podem entrar em conflito com suas escolhas, já que suas escolhas substituem as escolhas do usuário. No pior dos casos, o primeiro plano e o fundo podem terminar do mesmo jeito. Por favor, use uma folha de estilo para isso, e não marcação obsoleta do HTML 3.2 (HTML 4 Transitional).

Outras folhas de estilos

• Páginas históricas (traduções sem manutenção em sua maior parte) referem-se a /gnu.css, que por sua vez carrega o /mini.css, já que essas páginas são geralmente muito básicas, simples páginas com pouca ou nenhuma formatação.
• Existem folhas de estilo dedicadas para manuais de software. As principais são:
  • /style.css;
  • gnulib.css, que importa /style.css e adiciona mais algumas definições; é usada por gendocs.sh para gerar novamente os manuais Texinfo.
• Tradutores mantêm folhas de estilos (/style.idioma.css) que modificam layout.css de acordo com suas próprias necessidades. Os idiomas RTL (árabe, persa e hebraico) usam /style.rtl.css.

Uso de imagens

• O uso de gráficos deve ser minimizado, de forma que as páginas sejam carregadas rapidamente em conexões lentas, especialmente animações.
• Nós não usamos imagens de fundo em nossas páginas, pois elas tornam o texto significativamente mais difícil de ler.
• No passado, os GIFs tiveram problemas de patentes. No entanto, agora que as patentes da IBM e da Unisys (e outras patentes em todo o mundo que são relevantes para a compactação LZW) expiraram, os GIFs baseados no padrão 87a ou 89a são aceitáveis. Por favor, tenha cuidado com os aplicativos privativos que podem incluir tecnologias patenteadas não padrão (preferimos que você use aplicativos de software livre ao criar nossos sites). Em geral, os formatos PNG ou JPEG ainda são seguros e provavelmente são melhores do ponto de vista técnico. Para obter detalhes sobre o antigo problema de GIF, consulte https://www.gnu.org/philosophy/gif.html. Outros formatos também são permitidos, embora o JPEG seja o mais amplamente reconhecido pelos navegadores da Web (evite JPEG 2000 e tenha cuidado com os canais alfa do PNG; o primeiro não é amplamente suportado e os últimos não são totalmente suportados por alguns navegadores mais antigos).
• Antes de usar uma imagem de outro site, peça permissão para usá-la.
• Tenha sempre uma alternativa textual para imagens em linha, para garantir indexabilidade por mecanismos de pesquisas e acessibilidade. Por exemplo:

  <img src="/graphics/*.jpg" alt="&nbsp;[TEXTO DESCRITIVO]&nbsp;">

  Adicionamos os espaços não separáveis (&nbsp;) e colchetes para separar o TEXTO DESCRITIVO do texto adjacente e ajudamos o usuário a perceber que este é um substituto para uma imagem. O ponto de usar espaços sem quebra em vez dos normais é garantir que eles encontrem o caminho para as mensagens traduzíveis que são extraídas pelas ferramentas PO4A/Gettext.
• Verifique se a imagem não parece muito grande ou muito pequena quando exibida no tamanho original, usando o tamanho de fonte padrão do navegador.

• Ajuste a largura ou a altura da imagem em um atributo style, usando unidades escaláveis como em ou %; por exemplo:

  <img src="/graphics/*.jpg" alt="&nbsp;[TEXTO DESCRITIVO]&nbsp;" style="width: 10em; height: auto;" />

  Dessa forma, a página terá a mesma aparência se o leitor aumentar ou diminuir o tamanho da fonte.

• Se você estiver adicionando uma pequena imagem flutuante a uma página que usa layout.css (a folha de estilo para páginas modeladas), você pode querer usar a classe imgright ou imgleft (definida na seção IMAGES da folha de estilo). Isso garantirá que a direção flutuante seja invertida se a página for traduzida para um idioma RTL.
• Se a imagem que você está adicionando tiver 12 ou mais de largura e a página tiver um modelo, talvez seja conveniente usar uma das classes pict responsivas definidas na seção IMAGES do layout .css (você pode ajustar a largura em um atributo de estilo se nenhum dos pré-definidos atender às suas necessidades); por exemplo:

  <div class="pict wide" style="width: 25em"><img src="/graphics/*.jpg" alt="&nbsp;[TEXTO DESCRITIVO]&nbsp;" /></div>

  Observe que o contêiner div é necessário porque alguns navegadores (por exemplo, NetSurf) não sabem como aplicar max-width às imagens.

• Faça um link para todas as imagens exibidas em todo o site à página relevante, geralmente em /graphics/. Isso pode ser feito com código semelhante a este, que corresponde à imagem à esquerda:

  

  <p class="imgleft">
  <a href="/graphics/agnuhead.html">
  <img src="/graphics/gnu-head-sm.jpg"
       alt=" [Image of the Head of a GNU] "
       style="width: 8em" /></a>
  </p>
  

  Isso permitirá que os usuários acessem rapidamente as páginas relacionadas às fotos nas quais estão interessados.

Apêndice 1 - Políticas de links

Um dos aspectos mais complexos da manutenção de páginas web é seguir as diretrizes de links; no entanto, também é um aspecto crucial do trabalho.

Nós nos esforçamos para garantir que todas as páginas que promovemos – todas as páginas que recebem links em nosso site – sejam amigáveis ao movimento software livre. Algumas páginas obviamente não atenderão a esses padrões; se o site critica a Free Software Foundation, ou não tem relação aparente com o software livre e questões relacionadas, não deve-se acrescentar um link para ele. Além disso, no entanto, existem critérios usados para determinar se é ou não apropriado fornecer um link para uma página da nossa. Eles estão listados abaixo, em ordem decrescente de importância geral.

Qual é o contexto do link?

O propósito do link em nosso site terá um papel na determinação de quão fortemente ele deve ser julgado em relação aos outros critérios. Páginas hospedando projetos GNU serão julgadas com os mais altos padrões. Páginas sobre outros softwares livres e grandes promoções – por exemplo, incluídas em um feed de notícias na página principal – estão em segundo lugar. Os links na página de filosofia podem ter mais margem de manobra ao falar sobre software privativo; As páginas do grupo de usuários GNU/Linux devem chamar o sistema quase sempre de GNU/Linux, mas dificilmente são verificadas em outros critérios. Tenha sempre isso em mente ao decidir como pesar cada aspecto dessas políticas.

A página promove software privativo?

A grande questão levantada pelo movimento software livre é que o software privativo apresenta um dilema ético: você não pode concordar com termos não-livres e tratar os que estão à sua volta como gostaria de ser tratado. Quando softwares privativos são promovidos, as pessoas ficam com a impressão de que não há problema em usá-los, enquanto tentamos convencê-las do contrário. Como tal, evitamos oferecer publicidade gratuita, seja diretamente em nosso site ou indiretamente por meio de links.

O que é complicado nesse critério é o ponto de “promoção”: há uma diferença entre mencionar software privativo e fazer um discurso de vendas para ele. De fato, o site do Projeto GNU faz menção a software privativo por toda parte, mas nunca dá às pessoas a impressão de que seu uso não apresenta problemas éticos.

Há duas coisas a ter em mente ao determinar se uma referência a um software privativo o promove ou simplesmente o menciona. Em primeiro lugar, quanta informação é oferecida sobre o software? Segundo, quanta informação é provável que o leitor realmente ganhe com essa página?

Páginas diferentes fornecem diferentes quantidades de informações sobre software privativo; quanto mais elas fornecem, mais problema elas representam para nós. Por exemplo, algumas páginas podem ser vinculadas ao site principal de um programa de software privativo. Outros podem descrever sua funcionalidade em detalhes. Até mesmo o nome do produto é dado; há uma diferença entre “Windows” e “Microsoft Windows XP Home Edition”.

Se a página exigir JavaScript não livre e não trivial e houver falhas graves com o JavaScript desativado, o link não deverá ser criado. Da mesma forma, se a página incorporar o Flash que desempenha um papel importante, de modo que uma pessoa perderia algo importante se os vídeos não forem reproduzidos, o link não deverá ser criado.

O assunto da referência também terá um papel na determinação de quão problemática é uma referência. Se o software já é muito popular, é improvável que uma menção básica seja novidade para o leitor. Alguns exemplos de software privativo que são comuns o suficiente para serem considerados “conhecidos” são os principais sistemas operacionais (Windows, Mac OS, SO Sun, HP-UX) e aplicativos comuns principais, como Office, Internet Explorer, Photoshop, Acrobat Reader e Flash.

As páginas de projeto dos softwares GNU sentem a força total desta política. O software privativo deve ser mencionado apenas quando o software GNU fornece suporte a ele ou para compará-lo com os recursos de software privativo bem conhecido. Por exemplo, o texto a seguir – e não muito mais – seria aceitável:

w3 is a web browser for GNU Emacs, similar to Internet Explorer. It can run on all platforms GNU Emacs runs on, including GNU/Linux, proprietary Unix systems, and Windows. ¹

Links que aparecem em outras áreas, como os depoimentos ou páginas de filosofia, bem como links para grupos de usuários podem discutir esse software em maior detalhe, mas links e outros métodos de incentivo para “aprender mais”. ainda devem ser evitados.

Como a página compara software livre ao código aberto?

Quase todas as páginas que possuem links em nosso site devem, no mínimo, tratar software livre e código aberto igualmente. Não fazer isso – seja omitindo o software livre ou sugerindo que o código aberto é superior – geralmente é inaceitável. As páginas de projeto dos softwares GNU devem ter pouca menção a código aberto. A página do GNOME é usada para fornecer um bom exemplo de uma maneira diplomática de fazer isso:

GNOME is part of the GNU Project, and is free software (sometimes referred to as open source software). ²

Qualquer exceção a esta regra deve ser aparente no contexto. Por exemplo, as páginas dos grupos de usuários podem falar mais detalhadamente sobre código aberto; nós declaramos na página de grupos de usuários, “As with our links page, the FSF is not responsible for the contents of other websites, or how up-to-date their information is.” ³

Como a página trata o Projeto GNU?

As páginas para as quais acrescentamos link devem tratar bem o Projeto GNU. O principal aspecto a ser observado a esse respeito é se a página chama o sistema GNU/Linux ou apenas “Linux”. As páginas do projeto de software GNU e do grupo de usuários quase nunca, ou nunca, deixarão de fazer isso. Novamente, as exceções para outras páginas devem ser aparentes no contexto.

Isto posto, certas partes de uma página não devem ser consideradas contra esses critérios. Por exemplo, suponha que fôssemos fazer um link para uma página em um site de notícias de software livre. Quaisquer anúncios ou comentários de leitores anexados ao artigo não serão considerados ao determinar se ele atendeu ou vinculou as diretrizes, uma vez que elas são entendidas como a opinião de seus autores individuais. Da mesma forma, em páginas de grupos de usuários, o conteúdo de fóruns e páginas wiki não deve ter peso nesses aspectos.

Por fim, alguns sites são sempre considerados exceção com a maioria dessas diretrizes. Esses sites são geralmente sobre questões que são importantes, mas um tanto periféricas, para o movimento do software livre. Várias vezes acrescentamos link para o site da Electronic Frontier Foundation, embora eles incentivem o uso do Flash e falem exclusivamente sobre software livre. É geralmente entendido que, uma vez que estas páginas não são primariamente sobre software livre, as políticas não possuem força total para elas.

Como uma explicação final (vinda do RMS): Mesmo para fazer links a partir do www.gnu.org, nós não exigimos que as pessoas chamem o sistema GNU/Linux ou usem o termo “software livre” em vez de “open source”. No entanto, exigimos que eles não promovam nenhum software não-livre.

Se tudo isso parece complicado, é porque, infelizmente, é. Não se preocupe; um talento para isso vem com o tempo e a experiência. Você pode avaliar erroneamente algumas páginas enquanto aprende a ter uma ideia do que é aceitável e do que não é; Por favor, não hesite em receber uma segunda opinião de um webmaster mais experiente, ou alguém como o Chief Webmaster ou o RMS. Novas exceções sempre surgirão; mantenha uma mente aberta para essa possibilidade e esteja preparado para lidar com eles adequadamente.

Apêndice 2 - Trabalhando com repositórios CVS Web

Comandos básicos de CVS

• Para um manual de referência, execute info cvs.
• Antes do checkout inicial, defina a variável de ambiente CVS_RSH=ssh.

• Se você tem acesso de escrita a www, confira o principal repositório www com seu login em Savannah:

  cvs -z3 -d:ext:nome-de-usuário@cvs.savannah.gnu.org:/web/www co www
  

  Você receberá um diretório de trabalho, www, com a mesma estrutura do nosso site principal.

• Se você não tiver acesso de escrita a www, ainda poderá fazer um checkout anônimo de www:

  cvs -z3 -d:pserver:[email protected]:/web/www co www
  

• Faça o checkout do repositório web do projetofoo:

  cvs -z3 -d:ext:username@cvs.savannah.gnu.org:/web/projetofoo \
           co projetofoo
  

  Você obterá um diretório de trabalho, projetofoo, com a mesma estrutura que o subdiretório www/software/projetofoo. Note, no entanto, que os repositórios projetofoo e www são independentes. Os diretórios de trabalho podem estar em qualquer lugar no seu sistema de arquivos.

  Webmasters, por favor leiam as Páginas web para software GNU oficial antes de enviar qualquer coisa para o repositório web de um projeto de software.

• Adicione um arquivo ou diretório:

  cvs add foo
  

• Atualize antes de editar um arquivo:

  cvs update -P foo
  

• Verifique as alterações que você vai enviar:

  cvs diff -U2 foo
  

• Execute o commit (sem necessidade de cvs add se o arquivo já estiver no repositório):

  cvs commit foo
  

  Isso abrirá um editor de texto no qual você deverá inserir uma mensagem de log. A confirmação ocorrerá ao salvar a mensagem.

  Sem serem excessivamente detalhados, as mensagens de log devem descrever com a maior clareza possível a natureza do commit, incluindo quaisquer números de tickets relacionados do RT, para permitir que futuros historiadores entendam por que suas alterações foram feitas.

  Sempre que possível, as alterações em vários arquivos que compartilham a mesma mensagem de log devem ser agrupadas em uma confirmação. Não agrupe várias alterações não relacionadas em um commit.

  As alterações (exceto para arquivos .symlinks) devem estar visíveis em www.gnu.org em poucos minutos.

Para mais detalhes sobre o CVS, como reverter para uma versão anterior, ou olhar para a saída diff de uma mudança particular, veja a Documentação do CVS.

Links simbólicos

Como o CVS não é capaz de manipular links simbólicos diretamente, um mecanismo separado foi implementado para permitir que os webmasters mantenham links simbólicos, como segue. (Os links simbólicos reais não são mais criados no www.gnu.org; em vez disso, são usadas as regras do mod_rewrite. Mas manteremos essa discussão falando sobre links simbólicos, já que é mais fácil entender isso.)

Ser um link simbólico significa que os links relativos da página vinculada podem ser interrompidos quando o link simbólico pula para um diretório diferente.

Arquivos especiais, chamados .symlinks, ao fazer commit para a árvore CVS, são interpretados como especificações para construir links simbólicos. Cada especificação de link simbólico do arquivo .symlinks é honrada, ou seja, o link simbólico é criado se ainda não existir. Se um link simbólico for encontrado no diretório e não estiver listado no arquivo .symlinks, ele será removido.

Os arquivos .symlinks obedecem ao formato ln -s, conforme descrito abaixo:

• Linhas que começam com um sinal de cerquilha (“#”) são ignoradas.
• Linhas que não contêm duas strings separadas por espaço em branco são silenciosamente ignoradas.

Aqui está um exemplo de um arquivo .symlinks:

# Cria um link chamado l.html para um alvo t.html.
# É estritamente equivalente a ln -s t.html l.html:
t.html l.html

Em cada linha, o primeiro nome de arquivo deve ser um nome de caminho relativo para um arquivo existente. O segundo nome de arquivo não pode conter nenhuma barra; é o nome do link simbólico a ser criado no diretório atual. Por exemplo, se uma página chamada dir.html existir no diretório /dir, e index.html não existir, /dir/.symlinks deve conter uma linha como esta:

dir.html index.html

A analogia de ln -s representa apenas parte da história. O método atual realmente aproveita a flexibilidade da regravação de URL. Assim, uma única entrada HTML no arquivo .symlinks define links para todas as possíveis traduções que seguem nossas convenções de nomenclatura. Isso torna impossível usar links simbólicos para redirecionar para e de arquivos HTML cujos nomes se parecem com traduções, ou seja, página.ll.html ou page.ll-cc.html, onde ll and cc são códigos de duas letras. Quando você precisar desses redirecionamentos, use o mecanismo htaccess.

Hoje em dia, o tratamento de .symlinks acontece em www.gnu.org por meio de uma tarefa de cron que é executada duas vezes por hora. Os webmasters não têm acesso a ele.

.htaccess e redirecionamentos

Para os navegadores, os links simbólicos na seção anterior são indistinguíveis do arquivo real. Você pode querer um redirecionamento real em alguns casos. Você pode fazer isso no arquivo de controle de nível superior .htaccess, ou usando algo parecido com isto como o arquivo a ser redirecionado:

<meta http-equiv="refresh" content="0; url=https://www.gnu.org/alvo">

Scripts do lado do servidor

Uma descrição de scripts e software usados no www.gnu.org está disponível. Por favor, leia-a antes de escrever qualquer script, e também atualize-a conforme necessário, se você tiver acesso de escrita a www.

Administradores de sistema

Os administradores de sistema do GNU mudam de tempos em tempos. Por favor, envie um e-mail para a lista de sysadmin <[email protected]> em vez de uma pessoa específica, a menos que você tenha uma razão específica para isso.

Recursos úteis

• Fora do gnu.org:
  • Seguimos as diretrizes da campanha Otimizado para Qualquer Navegador.
  • Informações básicas sobre a web e suas especificações técnicas podem ser encontradas no The World Wide Web Consortium.
  • O servidor web GNU segue o guia de estilo do w3.org.
  • O uso de WCAG 2.1 ajuda a garantir a acessibilidade para uma ampla gama de pessoas com deficiência.
• No gnu.org:
  • As Diretrizes do Site GNU (esta página);
  • Diretrizes para Diretrizes para Escrever Páginas Web no www.gnu.org;
  • Appendix B Tips and Hints e outras dicas de estilo no Manual do Texinfo;
  • Declaração de Acessibilidade do GNU;
  • Diretrizes de Webmaster GNU;
  • Guia para traduzir páginas web do GNU para outros idiomas;
  • Dicas para webmasters para facilitar o trabalho dos tradutores;
  • Documentação do Savannah, o clone do SourceForge dedicado para o Projeto GNU;
  • README para o diretório /prep/gnumaint/ (aqueles arquivos são usados principalmente por administradores mantenedores do GNU, e ocasionalmente por webmasters do GNU, para atualizar os arquivos /*/allgnupkgs.html no www);
  • Como ajudar com nosso servidor web.