repo: gemini-site action: commit revision: path_from: revision_from: e485a1aaf41c8b69f4ddf40d91cc0fb2cade5478: path_to: revision_to:
commit e485a1aaf41c8b69f4ddf40d91cc0fb2cade5478 Author: Paulo PintoDate: Wed Feb 24 22:54:00 2021 +0100 normalization of some expressions in Portuguese translation of the FAQ document Signed-off-by: Solderpunk diff --git a/docs/pt-PT/faq.gmi b/docs/pt-PT/faq.gmi
--- a/docs/pt-PT/faq.gmi +++ b/docs/pt-PT/faq.gmi @@ -110,7 +110,7 @@ O Gemini exige a utilização de criptografia TLS. Atualmente, os hábitos de utilização na phlogosfera parecem sugerir que muitas pessoas consideram essa dicotomia um defeito. Um número crescente de utilizadores está a servir conteúdo, quase inteiramente constituído por texto, como item do tipo 1, de forma a inserir um número relativamente pequeno de links "em linha" para outro conteúdo gopher, fornecendo alguma aparência de hiperlink de HTML - algo perfeitamente razoável e inofensivo de se querer fazer. Sem recorrer a esta abordagem, o melhor que os autores de conteúdo do Gopher podem fazer é colar uma lista de URLs na parte inferior dos seus documentos, de forma a que os seus leitores possam copiar e colar manualmente nos seus clientes. Esta não é exatamente uma experiência agradável para o utilizador. Mas forçar hiperlinks no Gopher desta forma não é apenas um abuso da semântica do protocolo Gopher, é também uma maneira surpreendentemente ineficiente de servir texto, pois cada linha tem que ter um tipo de item i e um seletor não-padrão, o nome do host e a porta transmitida para que possa ser um menu Gopher válido. Todas e quaisquer reivindicações de simplicidade e beleza que o Gopher possa ter são destruídas por este facto. O Gemini adota a abordagem simples de permitir que as pessoas insiram quantos links quiserem no seu conteúdo de texto, com uma sobrecarga extremamente baixa, mas mantém a limitação de um link por linha, como no Gopher, o que resulta numa organização limpa e semelhante a uma lista de conteúdo. É difícil não ver esta realidade como algo que não seja uma melhoria. -Se você gostar mesmo do funcionamento do Gopher, não há nada no Gemini que impeça a sua replicação. Você pode servir o conteúdo do tipo 0 com um tipo MIME de texto/simples, e pode escrever documentos de texto/gemini, onde cada linha é uma linha de link, replicando a aparência de um menu Gopher RFC1436 sem o incómodo do tipo não-standard de item padrão i. +Se você gostar mesmo do funcionamento do Gopher, não há nada no Gemini que impeça a sua replicação. Você pode servir o conteúdo do tipo 0 com um tipo MIME de text/simples, e pode escrever documentos de text/gemini, onde cada linha é uma linha de link, replicando a aparência de um menu Gopher RFC1436 sem o incómodo do tipo não-standard de item padrão i. ## 2.4 Quais os defeitos da web que o Gemini se propõe superar? @@ -153,24 +153,24 @@ Certamente que o TLS tem os seus defeitos, contudo: * A maioria dos utilizadores já confia no TLS para proteger a sua navegação na web e o seu e-mail e, assim sendo, não precisa de decidir se quer confiar noutra tecnologia que não conhece para começar a usar o Gemini * TLS é um padrão da indústria profundamente enraizado, cuja definição e implementações continuarão a ser examinadas e aprimoradas por especialistas em segurança no futuro próximo, um trabalho que acontecerá por motivos que não estão relacionados com o Gemini - faz muito sentido para um pequeno projeto "ir à boleia" desta experiência. -## 2.9 Por que não utilizar Markdown em vez de texto/gemini? +## 2.9 Por que não utilizar Markdown em vez de text/gemini? -A sinalização feita através de texto/gemini baseia-se muito no Markdown, o que pode levar algumas pessoas a colocarem a seguinte questão: "Por que não usar o Markdown como o tipo de media padrão para o Gemini? Claro que é complicado de implementar, mas, a exemplo do que acontece com o TLS, há muitas bibliotecas disponíveis nas principais linguagens de programação". As razões para não seguir esse caminho são as seguintes: +A sinalização feita através de text/gemini baseia-se muito no Markdown, o que pode levar algumas pessoas a colocarem a seguinte questão: "Por que não usar o Markdown como o tipo de media padrão para o Gemini? Claro que é complicado de implementar, mas, a exemplo do que acontece com o TLS, há muitas bibliotecas disponíveis nas principais linguagens de programação". As razões para não seguir esse caminho são as seguintes: * Existem muitas variantes do Markdown, com diferenças subtis e incompatíveis. Ao contrário do TLS, não é garantido que todas as diferentes bibliotecas se comportem de maneira semelhante. * A grande maioria das bibliotecas Markdown não faz mais do que converter Markdown em HTML, o que, para um cliente Gemini, representa um formato intermediário desnecessário, que é mais pesado do que o original! * Muitas variantes do Markdown permitem recursos que não se coadunam com o Gemini, como, por exemplo, imagens embutidas. * Há o desejo de preservar a exigência de "um link por linha" do Gopher, de forma a incentivar um desenho de site claro e objetivo. -Claro que é possível servir Markdown em vez de Gemini. A inclusão de um tipo de media texto/markdown no cabeçalho da resposta permitirá que clientes mais avançados o suportem. +Claro que é possível servir Markdown em vez de Gemini. A inclusão de um tipo de media text/markdown no cabeçalho da resposta permitirá que clientes mais avançados o suportem. -## 2.10 Por que motivo o texto/gemini não tem suporte para links in-line? +## 2.10 Por que motivo o text/gemini não tem suporte para links in-line? -Como o texto/gemini é um formato totalmente novo, definido de raiz para o Gemini, os autores de clientes precisarão de escrever o seu próprio código para analisar e renderizar o formato a partir do zero, sem poder contar com uma implementação de biblioteca pré-existente e bem testada. Assim, é importante que o formato seja extremamente simples de manusear corretamente. O formato baseado numa filosofia de linha, em que as linhas de texto e as linhas de link são conceitos separados, permite essa simplicidade. Os clientes não necessitam de "varrer" cada uma das linhas, caratere por caratere, para testar a presença de alguma sintaxe de link especial. Mesmo a sintaxe de link especial mais simples introduz a possibilidade de sintaxe malformada, contra a qual seria necessária a robustez dos clientes. Casos extremos há cujo tratamento precisaria de ser explicitamente abordado na especificação do protocolo (levando a uma especificação mais longa e fastidiosa, menos divertida de ler e mais difícil de memorizar) ou ficar por definir (levando a um comportamento inconsistente em clientes diferentes). Embora os links in-line possam ser adequados para alguns tipos de conteúdo, eles simplesmente não compensam o aumento da complexidade e da fragilidade que seria introduzido no protocolo. +Como o text/gemini é um formato totalmente novo, definido de raiz para o Gemini, os autores de clientes precisarão de escrever o seu próprio código para analisar e renderizar o formato a partir do zero, sem poder contar com uma implementação de biblioteca pré-existente e bem testada. Assim, é importante que o formato seja extremamente simples de manusear corretamente. O formato baseado numa filosofia de linha, em que as linhas de texto e as linhas de link são conceitos separados, permite essa simplicidade. Os clientes não necessitam de "varrer" cada uma das linhas, caratere por caratere, para testar a presença de alguma sintaxe de link especial. Mesmo a sintaxe de link especial mais simples introduz a possibilidade de sintaxe malformada, contra a qual seria necessária a robustez dos clientes. Casos extremos há cujo tratamento precisaria de ser explicitamente abordado na especificação do protocolo (levando a uma especificação mais longa e fastidiosa, menos divertida de ler e mais difícil de memorizar) ou ficar por definir (levando a um comportamento inconsistente em clientes diferentes). Embora os links in-line possam ser adequados para alguns tipos de conteúdo, eles simplesmente não compensam o aumento da complexidade e da fragilidade que seria introduzido no protocolo. É verdade que é necessário mudar um pouco a forma de pensar para que nos acostumemos com o estilo de escrita de um link por linha, mas, com o tempo, isso traduzir-se-á num processo mais facilitado. O estilo também traz benefícios, pois incentiva a inclusão apenas dos links mais importantes ou relevantes, organizando links em listas relacionadas e dando a cada link uma descrição própria e autonomizada, sem que exista a preocupação dessa descrição se encaixar no fluxo do texto principal. -## 2.11 Por que motivo o texto/gemini não tem suporte para estilização? +## 2.11 Por que motivo o text/gemini não tem suporte para estilização? Algumas pessoas manifestaram o desejo de ter algo parecido com o CSS no Gemini. Embora algo muito mais simples e leve do que o CSS pudesse ser facilmente previsto, o Gemini advoga que o estilo visual do conteúdo deve ser controlado diretamente pelo leitor e não por quem produz o conteúdo. Nem todos têm o mesmo gosto quando se trata de cores e fontes, e não existe uma fórmula única de estilizar uma página de forma a torná-la ideal para todos os leitores, todos os dispositivos e todas as condições de iluminação. Há muito mais em jogo aqui do que a já clássica preferência entre texto escuro em fundo claro ou vice-versa. Pessoas com dificuldades de leitura, como a dislexia, podem beneficiar enormemente com o uso de, por exemplo, fontes especialmente desenhadas para um determinado fim. Um sistema de estilo simples, de "tamanho único", em que o conteúdo tem a mesma aparência em qualquer dispositivo, é garantidamente insatisfatório para muitas pessoas. Um sistema de estilização mais complicado, que pode prever diferentes estilos visuais para diferentes dispositivos e contextos, sobrecarregará os autores com a árdua tarefa de garantir que a sua cápsula (o nome que se dá aos sites em Gemini) possa ser visualizada em qualquer dispositivo. A experiência da web sugere que os problemas de acessibilidade serão, na melhor das hipóteses, uma reflexão a posteriori. É muito mais simples, e na verdade muito mais libertador para os autores de conteúdo, deixar o conteúdo ser apenas conteúdo e deixar o estilo para o cliente. Alguns clientes de Gemini podem parecer monótonos e aborrecidos, mas não há razão para que assim seja. Se houver procura por clientes com renderização de fontes de alta qualidade e bela tipografia, esses clientes, eventualmente, serão desenvolvidos - e quando assim acontecer, os utilizadores que valorizam esses aspetos poderão desfrutar dessa experiência de leitura em qualquer lugar no Geminispace, mesmo ao ler conteúdo escrito por autores que não tiveram preocupações com o estilo.
-----END OF PAGE-----