-- Leo's gemini proxy
-- Connecting to git.thebackupbox.net:1965...
-- Connected
-- Sending request
-- Meta line: 20 text/gemini
repo: gemini-site action: commit revision: path_from: revision_from: 3547e607aaa33b689dccb8931bdd1b1bc013c56a: path_to: revision_to:
commit 3547e607aaa33b689dccb8931bdd1b1bc013c56a
Author: Paulo Pinto <w3bk3rn3l@posteo.net>
Date: Thu Feb 25 17:45:00 2021 +0100
Portuguese translation of best practices and companion specifications
Signed-off-by: Solderpunk <solderpunk@posteo.net>
diff --git a/docs/pt-PT/boas-praticas.gmi b/docs/pt-PT/boas-praticas.gmi
new file mode 100644
index 0000000000000000000000000000000000000000..d80368166e2dc0b56f3c54505d11f07b3ba95f09
--- /dev/null
+++ b/docs/pt-PT/boas-praticas.gmi
@@ -0,0 +1,61 @@
+# Boas práticas para implementações Gemini
+
+# Introdução
+
+Este documento descreve várias convenções e pequenos conselhos para a implementação e uso do protocolo Gemini que, embora não sejam de caráter obrigatório à luz da especificação do protocolo, são geralmente considerados uma boa prática. Se está a escrever um software ou a construir um site para Gemini, deverá seguir os conselhos que aqui encontrará, a menos que tenha bons motivos para o não fazer.
+
+# Nomes de ficheiros
+
+Os servidores Gemini têm necessidade de informar os clientes sobre qual o tipo MIME dos ficheiros que estão a disponibilizar. A forma mais conveniente de o saberem é através da extensão do ficheiro. Trata-se de mapeamentos que, na sua maioria, estão bem padronizados (os sistemas unix geralmente guardam um ficheiro /etc/mime.types com todos esses mapeamento), mas subsiste uma questão, que é a de saber como é que os servidores reconhecem os ficheiros cujo tratamento deverá ser de tipo text/gemini, de acordo com o definido pela especificação do Gemini.
+
+Ao que tudo indica, os servidores Gemini atuais estão a usar as extensões .gmi ou .gemini para essa finalidade, motivo pelo qual se recomenda fortemente que os novos servidores ofereçam suporte a pelo menos uma dessas extensões, de preferência a ambas, em vez de preverem novas extensões, acrescentado, dessa forma, complexidade à equação.
+
+A exemplo do que acontece na lógica dos servidores web, se o pedido recebido pelo servidor referenciar um caminho para uma determinada pasta do sistema, e nessa pasta existir um ficheiro denominado index.gmi ou index.gemini, será esse o ficheiro que será exibido.
+
+# Tamanho dos ficheiros
+
+Os servidores Gemini não informam os clientes acerca do tamanho dos ficheiros que disponibilizam, o que pode ser um obstáculo à perceção de que o encerramento permaturo da conexão esteja relacionado com uma falha do servidor. O risco de isso acontecer aumenta com o tamanho do ficheiro.
+
+O Gemini também não tem suporte para compactação de ficheiros grandes ou suporte para somas de verificação que permitam detetar uma possível corrupção do ficheiro, cujo risco é proporcional ao tamanho do ficheiro.
+
+Por todos esses motivos, o Gemini não é adequado para a transferência de ficheiros "muito grandes". O conceito de "muito grande" depende, até certo ponto, da velocidade e da confiabilidade das conexões de internet envolvidas e da paciência dos utilizadores. Como regra geral, ficheiros com mais de 100 MBytes devem ser disponibilizados por outros meios.
+
+O facto do Gemini suportar um esquema de URL com a possibilidade de ligação a conteúdo online disponível noutros protocolos permite disponibilizar ficheiros de grande dimensão. Assim, o link dentro do documento Gemini fará referência a URLs de HTTPS, BitTorrent, IPFS ou qualquer outro modo de servir ficheiros.
+
+# Codificação do texto
+
+O Gemini suporta qualquer codificação de texto, usando para tal o parâmetro "charset" dos tipos text/* MIME. Isso permite disponibilizar conteúdo de texto "legacy" em esquemas de codificação regionais menos claros.
+
+Para novos conteúdos, por favor, mas por favor mesmo, use apenas UTF-8. A especificação do Gemini exige que aos clientes a capacidade de lidar com texto UTF-8. O suporte para qualquer outra codificação depende do cliente e não pode ser garantido. O facto do seu conteúdo ser disponibilizado como UTF-8 maximiza a sua acessibilidade e maximiza a utilidade dos clientes simples que suportam apenas UTF-8.
+
+# Redirecionamentos
+
+## Considerações gerais
+
+Os redirecionamentos foram incluídos no Gemini principalmente para permitir que a restruturação de sites, ou a migração de sites entre servidores, se efetue sem a quebra dos links existentes. Um espaço grande e interconectado de documentos, sem esse recurso, tornar-se-ia, inevitavelmente, "frágil".
+
+No entanto, os redirecionamentos são, de modo geral, situações desagradáveis. Eles reduzem a transparência de um protocolo e tornam mais difícil escolhas informadas acerca dos links a seguir (aumentando o risco de vazamento de informações sobre a atividade online para terceiros). No Gemini, esses problemas não são tão pronunciados como em HTTP (devido à falta de cookies, cabeçalhos de referência etc.), mas continuam a ser, na melhor das hipóteses, um mal necessário.
+
+Assim, evite usar redirecionamentos levianamente! Funcionalidades como encurtadores de URL são totalmente desnecessários. Evite o uso de redirecionamentos, a não ser quando essa for a única opção para evitar quebras de link.
+
+# Limites do redirecionamento
+
+Os clientes podem deixar na mão dos utilizadores a decisão de seguir, ou não seguir, um redirecionamento, ou podem redirecionar de forma automática. Se escreveu um cliente que segue redirecionamentos automaticamente, deve ter em conta os problemas que a seguir se descrevem.
+
+Os servidores Gemini mal configurados, ou mal-intencionados, podem efetuar redirecionamentos de forma a fazer com que um cliente, que os siga cegamente, fique preso num loop infinito, ou tenha que completar uma longa cadeia de redirecionamentos. Clientes robustos terão de ser suficientemente inteligentes para detetar essas condições e agir em conformidade. A implementação mais simples é fazer com que o cliente se recuse a seguir mais de N redirecionamentos consecutivos. Recomenda-se que N não seja superior a 5. Este procedimento está de acordo com a recomendação original para HTTP (consulte RFC-2068).
+
+# Redirecionamentos de protocolo cruzado
+
+Redirecionamentos de protocolo cruzado (ou seja, redirecionamentos do Gemini para outro protocolo, como o Gopher) são possíveis, mas são fortemente desencorajados. No entanto, os servidores mal-configurados ou mal-intencionados serão sempre capazes de atender a esses redirecionamentos. Contudo, se o cliente estiver bem escrito, ele deverá estar pronto a detetá-los e a responder adequadamente.
+
+É altamente recomendável, mesmo para os clientes que geralmente seguem redirecionamentos, que quando exista um redirecionamento para um protocolo não protegido por TLS, como o HTTP ou o Gopher, seja dado um alerta automático ao utilizador e seja pedida uma confirmação explícita para que o redirecionamento seja efetuado. Isto, claro está, assumindo que o cliente tenha implementado o suporte para esses protocolos. Dessa forma, evitar-se-ão transferências de texto simples não intencionais.
+
+# Conjuntos de cifras TLS
+
+O TLS 1.2 é permitido no Gemini, ainda que de forma relutante. Contudo, o TLS 1.3 é drasticamente mais simples e remove muitos criptográficos primitivos inseguros. Porque se permite então o TLS 1.2? Porque apenas o OpenSSL parece ter, atualmente, um bom suporte para TLS 1.3 e, assim sendo, exigir TLS 1.3 ou superior faria com que o uso de bibliotecas como LibreSSL ou BearSSL não fosse adequado.
+
+Os autores de clientes e servidores que optem por oferecer suporte ao TLS 1.2 devem, idealmente, permitir o uso de conjuntos de cifras que ofereçam segurança semelhante ao TLS 1.3. Em particular, o software deve:
+
+ Usar apenas Ephemeral Diffie-Hellman (DHE) Ephermeral Eliptic Curve Diffie-Hellman (ECDHE) para acordo de chave, a fim de fornecer sigilo de encaminhamento.
+ Usar AES ou ChaCha20 como cifras em massa
+ Usar as funções hash da família SHA2 ou SHA3 para autenticação de mensagens.
diff --git a/docs/pt-PT/complementar/index.gmi b/docs/pt-PT/complementar/index.gmi
new file mode 100644
index 0000000000000000000000000000000000000000..964d832617e6cb27688696dea38e90884c4c5189
--- /dev/null
+++ b/docs/pt-PT/complementar/index.gmi
@@ -0,0 +1,6 @@
+# Especificações complementares
+
+As "especificações complementares" que apresentamos nesta página descrevem práticas opcionais que não fazem parte da especificação principal do protocolo Gemini, mas que se destinam a estabelecer diretrizes claras para uma "boa cidadania" no Geminispace e aumentar, através de convenções amplamente adotadas, a interoperabilidade do software Gemini.
+
+=> robots.gmi robots.txt para Gemini
+=> subscricao.gmi Subscrição de páginas Gemini
diff --git a/docs/pt-PT/complementar/robots.gmi b/docs/pt-PT/complementar/robots.gmi
new file mode 100644
index 0000000000000000000000000000000000000000..35ff24bd00b3538edb5ad14ad428bd3de826d1fb
--- /dev/null
+++ b/docs/pt-PT/complementar/robots.gmi
@@ -0,0 +1,48 @@
+# robots.txt para Gemini
+
+# Introdução
+
+Descreve-se, em seguida, uma adaptação para o Gemini do mecanismo padrão da web robots.txt, que é usado para controlar o acesso aos recursos efetuado por clientes automatizados (doravante "bots").
+
+Os administradores de um servidor Gemini podem usar o robots.txt para anunciar a política de bot desejada, e devem fazê-lo num formato que seja legível por uma máquina.
+
+Os autores de clientes Gemini automatizados (como, por exemplo, rastreadores de motores de pesquisa, web proxies, etc.) são fortemente encorajados a verificar essas políticas e a cumpri-las, quando for aplicável.
+
+Os administradores de um servidor devem estar cientes que é impossível *obrigar* a que a política de robots.txt seja, de facto, cumprida, motivo pelo qual devem estar preparados para usar regras de firewall que bloqueiem o acesso de bots que manifestem um comportamento inadequado. O mesmo é válido para o Gemini e para a web.
+
+# Noções fundamentais
+
+Os administradores de um servidor Gemini devem disponibilizar a sua política de bots no URL relativo /robots.txt. Exemplo: o servidor example.net deve disponibilizar a sua política em gemini://example.net/robots.txt.
+
+O ficheiro robots.txt deve ser codificado com um tipo de media MIME de text/plain.
+
+O formato do ficheiro deverá obedecer à especificação original do robots.txt para a web, ou seja:
+
+ As linhas que começam por # são comentários
+ As linhas que começam por "User-agent:" indicam um agente de utilizador ao qual as linhas subsequentes se aplicam
+ Linhas que começam com "Disallow:" indicam prefixos de caminho de URL que os bots não devem solicitar
+ Todas as outras linhas devem ser ignoradas
+
+A única diferença significativa entre o robots.txt da web e o robots.txt do Gemini, e uma vez que os administradores do Gemini não conseguem saber facilmente que bots estão a aceder ao seu site e o motivo porque o fazem (porque os clientes Gemini não enviam um User-agent), é o facto dos bots no Gemini serem incentivados a obedecer às diretrizes de "virtual user agents", de acordo com a sua finalidade/função. As diretrizes em causa estão descritas neste documento, já a seguir.
+
+Apesar dessa diferença, os bots no Gemini devem respeitar as diretivas do robots.txt relativas a um User-agent de * e podem, igualmente, respeitar as diretivas destinadas ao seu próprio User-agent, anunciadas, em destaque, na página Gemini de quaisquer serviços públicos que providenciem.
+
+# Virtual User Agents (Agentes virtuais de utiizador)
+
+Descrever-se-ão agora as definições dos vários "virtual user agents", correspondendo cada um a uma categoria comum de bot. Os bots Gemini devem respeitar as diretivas destinadas ao virtual user agent específico que se adapte à sua natureza. Obviamente, é impossível chegar a definições perfeitas para os virtual user agents, que sejam capazes de categorizar inequivocamente os bots. Os autores de bots são encorajados, por precaução, a errar por excesso, seguindo o "espírito do sistema" em vez do "espírito da letra". Se um bot cumprir os critérios definidos em vários virtual user agents e não for capaz de adaptar o seu comportamento com parcimónia, ele deverá obedecer ao conjunto mais restritivo de diretivas que decorram da combinação de todos os virtual user agents aplicáveis.
+
+## Rastreadores de catalogação
+
+Os bots do Gemini que pesquisem conteúdo destinado à construção de catálogos públicos perenes do Geminispace, com o objetivo de continuar a disponibilizar esse conteúdo mesmo depois da fonte original ter mudado ou desaparecido (uma situação análoga ao que se passa com o "Wayback Machine" do archive.org), devem respeitar as diretivas mencionadas em robots.txt destinadas a um User-agent de "archiver".
+
+## Rastreadores de indexação
+
+Os bots do Gemini que pesquisem conteúdo destinado à construção de índices pesquisáveis do Geminispace devem respeitar as diretivas mencionadas em robots.txt destinadas a um User-agent de "indexer".
+
+## Rastreadores de pesquisa
+
+Os bots de Gemini que pesquisem conteúdo destinado ao estudo de dados estatísticos em larga escala (por exemplo, número de domínios/páginas, distribuição de tipos de media MIME, tamanhos de resposta, versões de TLS, frequência de links quebrados, etc.), que não façam rehosting, que não possuam links para outras páginas ou que não permitam a pesquisa de qualquer conteúdo pesquisado, devem respeitar as diretivas mencionadas em robots.txt destinadas a um User-agent de "researcher".
+
+## Web Proxies
+
+Os bots Gemini que pesquisem conteúdo destinado a ser convertido em HTML para ser disponibilizado por HTTP (S) (a fim de tornar o Geminispace acessível a partir de um navegador da web padrão) devem respeitar as diretivas mencionadas em robots.txt destinadas a um User-agent de "webproxy".
diff --git a/docs/pt-PT/complementar/subscricao.gmi b/docs/pt-PT/complementar/subscricao.gmi
new file mode 100644
index 0000000000000000000000000000000000000000..4e4cfc54407c105a2833a58d59e1e0cc166abe3b
--- /dev/null
+++ b/docs/pt-PT/complementar/subscricao.gmi
@@ -0,0 +1,96 @@
+# Subscrição de páginas do Gemini
+
+## Introdução
+
+Trataremos agora de dar conta de uma convenção através da qual os clientes Gemini podem "subscrever" uma página Gemini que seja atualizada regularmente (como, por exemplo, a página de índice de um gemlog), sem que seja necessária a utilização de uma tecnologia de distribuição complexa como Atom ou RSS. Este método pretende ser uma alternativa menos pesada a essas tecnologias, de forma a reduzir as barreiras para a publicação de conteúdo em série no Geminispace, conteúdo esse que pode ser facilmente seguido sem a entediante consulta regular dos favoritos. Em particular, um dos objetivos explícitos é fazer com que uma página de índice simples, atualizada manualmente e legível por humanos, um tipo de conteúdo que os autores muito provavelmente criarão, possa ser subscrita sem que nenhuma alteração especial seja necessária. Obviamente, tal convenção será menos poderosa do que tecnologias mais complexas, como o Atom, e não funcionará tão bem em todos os casos possíveis de uso. No entanto, espera-se que funcione adequadamente para uma ampla gama de casos. Nada nesta convenção impede que os autores de conteúdo publiquem simultaneamente um feed Atom, se o desejarem. Na verdade, esta convenção pode até facilitar a geração desses feeds.
+
+A informação que se segue descreve como interpretar um documento text/gemini como se de um feed Atom se tratasse, com todos os elementos necessários presentes. A convenção é descrita de forma a garantir que os clientes possam oferecer simultaneamente suporte a essa convenção e também à subscrição de feeds Atom. Para tal, usar-se-á uma base de código simplificada e uma interface de utilizador consistente, demonstrando-se como a geração automática simples de feeds Atom é possível. Os clientes mais simples, que suportem apenas a convenção de subscrição menos pesada, poderão ignorar os elementos Atom, se tal for adequado.
+
+## Elementos de Feed
+
+O URL a partir do qual o documento text/gemini é obtido serve como elemento "id" obrigatório do feed e como elemento "link" recomendado.
+
+O conteúdo da primeira linha do cabeçalho começada por um único # serve como o elemento "título" obrigatório do feed. Por esse motivo, os autores são encorajados a usar títulos que forneçam o seu próprio contexto, por ex. "Gemlog de Abelard Lindsay" em vez de "O meu gemlog" ou "Índice de Gemlog".
+
+Se imediatamente após a primeira linha começada por um único # for encontrada uma linha de cabeçalho começada por ##, o seu conteúdo pode servir como elemento opcional de "subtítulo" do feed.
+
+O elemento "atualizado" obrigatório de um feed deve conter o valor mais recente que for encontrado em todos os elementos "atualizados" obrigatórios da entrada associada. Se nenhuma entrada puder ser extraída do documento, então o feed ficará vazio (o que é permitido pelo padrão Atom) e o elemento "atualizado" do feed deve ser definido com a hora em que o documento foi obtido.
+
+## Elementos de entrada
+
+Os elementos de entrada de um feed derivam do subconjunto das suas linhas de link, se existir alguma.
+
+As linhas de link em que o URL é seguido por uma label cujos primeiros 10 carateres correspondam a uma data no formato ISO 8601 (ou seja, AAAA-MM-DD) representam uma única entrada. As linhas de link que não atendam a esses critérios são ignoradas.
+
+O elemento "id" obrigatório de uma entrada e o elemento "link" obrigatório com rel = "alternate" (geralmente, os elementos "link" são opcionais nas entradas Atom, mas esta convenção não assigna elementos "content" às entradas e, portanto, um link rel = alternate" torna-se obrigatório) são iguais ao URL da linha do link correspondente.
+
+O elemento "atualizado" obrigatório de uma entrada deve ter como hora o meio-dia UTC do dia indicado pelo carimbo de data de 10 carateres no início da label da linha do link correspondente.
+
+O elemento "título" obrigatório de uma entrada deriva do que resta da label da linha do link correspondente, após ser descartado o primeiro componente separado por espaços em branco (que necessariamente inclui o carimbo de data). Os clientes podem simplesmente considerar tudo o restante, mas uma higienização simples pode ser realizada para explicar o facto de que os utilizadores podem, por exemplo, usar labels com um separador entre a data e o título, como "23/03/1965 - lançamento do Gemini 3 bem-sucedido!".
+
+## Exemplo
+
+O seguinte documento Gemini, disponibilizado em gemini://gemini.jrandom.net/gemlog/:
+
+```
+# J. Random Geminaut's gemlog
+
+Welcome to my Gemlog, where you can read every Friday about my adventures in urban gardening and abstract algebra!
+
+## My posts
+
+=> bokashi.gmi 2020-11-20 - Early Bokashi composting experiments
+=> finite-simple-groups.gmi 2020-11-13 - Trying to get to grips with finite simple groups...
+=> balcony.gmi 2020-11-06 - I started a balcony garden!
+
+## Other gemlogs I enjoy
+
+=> gemini://example.com/foo/ Abelard Lindsay's gemlog
+=> gemini://example.net/bar/ Vladimir Harkonnen's gemlog
+=> gemini://example.org/baz/ Case Pollard's gemlog
+
+=> ../ Back to my homepage
+
+Thanks for stopping by!
+```
+
+pode ser interpretado como equivalente à estrutura do seguinte Atom feed:
+
+```
+<?xml version="1.0" encoding="utf-8"?>
+<feed xmlns="http://www.w3.org/2005/Atom">
+
+ <title>J. Random Geminaut's gemlog</title>
+ <link href="gemini://gemini.jrandom.net/gemlog/"/>
+ <updated>2020-11-20T12:00:00Z</updated>
+ <id>gemini://gemini.jrandom.net/gemlog/</id>
+
+ <entry>
+ <title>Early Bokashi composting experiments</title>
+ <link rel="alternate" href="gemini://gemini.jrandom.net/gemlog/bokashmi.gmi"/>
+ <id>gemini://gemini.jrandom.net/gemlog/bokashmi.gmi</id>
+ <updated>2020-11-20T12:00:00Z</updated>
+ </entry>
+
+ <entry>
+ <title>Trying to get to grips with finite simple groups...</title>
+ <link rel="alternate" href="gemini://gemini.jrandom.net/gemlog/finite-simple-groups.gmi"/>
+ <id>gemini://gemini.jrandom.net/gemlog/finite-simple-groups.gmi</id>
+ <updated>2020-11-13T12:00:00Z</updated>
+ </entry>
+
+ <entry>
+ <title>I started a balcony garden!</title>
+ <link rel="alternate" href="gemini://gemini.jrandom.net/gemlog/balcony.gmi"/>
+ <id>gemini://gemini.jrandom.net/gemlog/balcony.gmi</id>
+ <updated>2020-11-06T12:00:00Z</updated>
+ </entry>
+
+</feed>
+```
+
+## Fragilidades
+
+A principal lacuna desta convenção é o facto dela não indicar a hora do dia em que o post é escrito, nem o fuso horário do carimbo de data. Isso torna difícil que as aplicações façam um bom match quando estamos perante casos em que são esperadas várias atualizações num dia e em que a ordem relativa das atualizações (tanto dentro como fora da fontes do feed) é importante. Exemplos disso são os casos em que se pretende seguir as manchetes das últimas notícias, as atualizações meteorológicas, as informações do trânsito, etc. Nesses casos, essas aplicações são fortemente encorajadas a implementar tecnologias de subscrição mais robustas, como Atom ou RSS.
+
+Não é expectável que esta fragilidade tenha implicações sérias para uma ampla gama de atividades comuns e valiosas no Geminispace, que operam à "escala humana". Por exemplo, esta convenção é perfeitamente viável para que um leitor individual possa usar o seu cliente local para subscrever dez ou vinte gemlogs escolhidos a dedo, que atualizem, com uma frequência não muito grande, conteúdo que não seja de caráter urgente ou imprescindível, como por exemplo um diário sobre o dia a dia das pessoas, hobbies, opiniões sobre o estado geral do mundo, receitas, fotos, etc. Este tipo de conteúdo não é de uma grande urgência, pois saber-se que foi escrito pela Alice na manhã de quarta-feira, ou foi escrito pelo Bob na noite de quarta-feira, ou saber-se exatamente quando cada pessoa escreveu os seus posts, não é relevante. Se a hora do dia for relevante para o conteúdo do post, o autor certamente fará questão de o mencionar expressamente.
diff --git a/docs/pt-PT/index.gmi b/docs/pt-PT/index.gmi
--- a/docs/pt-PT/index.gmi +++ b/docs/pt-PT/index.gmi @@ -4,6 +4,8 @@ => faq.gmi Perguntas frequentes sobre o Gemini (FAQ) => especificacao.gmi Especificações do protocolo +=> boas-praticas.gmi Boas práticas para implementações Gemini +=> ./complementar/index.gmi Especificações complementares ## Traduções
-----END OF PAGE-----
-- Response ended
-- Page fetched on Sun Jun 2 17:31:45 2024