Merge pull request #15307 from hotequil/fix/translations-pt-br

fix: improve some translations in pt-BR [Fixes #15306]

Author: corwintines

.all-contributorsrc

@@ -12725,6 +12725,13 @@
         "bug"
       ]
     },
+    {
+      "login": "hotequil",
+      "name": "João Paulo Hotequil",
+      "avatar_url": "https://avatars.githubusercontent.com/u/46814712?v=4",
+      "profile": "https://github.com/hotequil",
+      "contributions": ["code", "translation"]
+    },
     {
       "login": "microHoffman",
       "name": "microHoffman",

public/content/translations/pt-br/whitepaper/index.md

@@ -405,7 +405,7 @@ Conforme descrito na seção de transição de estado, nossa solução funciona
 - Um invasor vê um contrato com um código como `send(A,contract.storage[A]); contract.storage[A] = 0`, e envia uma transação com gas o suficiente para executar a primeira etapa, mas não a segunda (ou seja, fazendo uma retirada mas sem deixar diminuir o saldo). O autor do contrato não precisa se preocupar em se proteger contra ataques assim porque, se a execução parar no meio do caminho, as mudanças são revertidas.
 - Um contrato financeiro funciona tomando a mediana de nove feeds de dados proprietários para minimizar o risco. Um invasor controla um dos feed de dados, que é projetado para ser modificável por meio do mecanismo de chamada por endereço-variável descrito na seção sobre DAOs, e o converte para rodar um loop infinito, forçando assim qualquer tentativa de reivindicar fundos do contrato financeiro a ficar sem gas. Porém, o contrato financeiro pode definir um limite de gas na mensagem para prevenir este problema.
 
-A alternativa para completude de Turing é a incompletude de Turing, em que `JUMP` e `JUMPI` não existem e apenas uma cópia de cada contrato pode existir no stack de chamadas em dado momento. Com esse sistema, o sistema de taxas descrito e as incertezas em torno da eficácia de nossa solução podem não ser necessárias, pois o custo de executar um contrato seria limitado por seu tamanho. Alpem disso, a incompletude deTuring não é uma limitação tão grande. De todos os exemplos de contrato que concebemos internamente, até agora apenas um precisou de um loop, e mesmo esse loop poderia ser removido fazendo 26 repetições de um pedaço de linha de código. Dadas as sérias implicações da completude de Turing e o benefício limitado, por que não simplesmente ter uma linguagem Turing incompleta? Na verdade, porém, a incompletude de Turing está longe de ser uma solução perfeita para o problema. Para entender o porquê, considere os seguintes contratos:
+A alternativa para completude de Turing é a incompletude de Turing, em que `JUMP` e `JUMPI` não existem e apenas uma cópia de cada contrato pode existir no stack de chamadas em dado momento. Com esse sistema, o sistema de taxas descrito e as incertezas em torno da eficácia de nossa solução podem não ser necessárias, pois o custo de executar um contrato seria limitado por seu tamanho. Além disso, a incompletude de Turing não é uma limitação tão grande. De todos os exemplos de contrato que concebemos internamente, até agora apenas um precisou de um loop, e mesmo esse loop poderia ser removido fazendo 26 repetições de um pedaço de linha de código. Dadas as sérias implicações da completude de Turing e o benefício limitado, por que não simplesmente ter uma linguagem Turing incompleta? Na verdade, porém, a incompletude de Turing está longe de ser uma solução perfeita para o problema. Para entender o porquê, considere os seguintes contratos:
 
 ```sh
 C0: call(C1); call(C1);
@@ -450,7 +450,7 @@ O modelo de emissão será o seguinte:
 
 _Apesar da emissão linear da moeda, assim como com o Bitcoin, ao longo do tempo a taxa de crescimento da oferta tende a zero._
 
-As duas principais opções no modelo acima são (1) a existência e o tamanho de um pool de doações e (2) a existência de uma oferta de crescimento linear permanente, em vez de uma oferta limitada como no Bitcoin. A justificativa do pool de doações é a seguinte. se o pool de doações não existisse e a emissão linear fosse reduzida a 0,217x para fornecer a mesma taxa de inflação, então a quantidade total de ether seria 16,5% menor e então cada unidade seria 19,8% mais valiosa. Assim, no equilíbrio de 19,8%, mais ether seria comprado na venda, então cada unidade voltaria a ter exatamente o mesmo valor de antes. A organização teria então também 1,198% mais BTC, que provavelmente será dividido em duas fatias: o BTC original e o adicional de 0,198x. Assim, a situação equivale _exatamente_ à doação, mas com uma importante diferença: a organização possui apenas BTC, e portanto, não é incentivada a apoiar o valor da unidade ether.
+As duas principais opções no modelo acima são (1) a existência e o tamanho de um pool de doações e (2) a existência de uma oferta de crescimento linear permanente, em vez de uma oferta limitada como no Bitcoin. A justificativa do pool de doações é a seguinte. Se o pool de doações não existisse e a emissão linear fosse reduzida a 0,217x para fornecer a mesma taxa de inflação, então a quantidade total de ether seria 16,5% menor e então cada unidade seria 19,8% mais valiosa. Assim, no equilíbrio de 19,8%, mais ether seria comprado na venda, então cada unidade voltaria a ter exatamente o mesmo valor de antes. A organização teria então também 1,198% mais BTC, que provavelmente será dividido em duas fatias: o BTC original e o adicional de 0,198x. Assim, a situação equivale _exatamente_ à doação, mas com uma importante diferença: a organização possui apenas BTC, e portanto, não é incentivada a apoiar o valor da unidade ether.
 
 O modelo linear permanente de crescimento da oferta (de moeda) reduz o risco do que alguns veem como uma excessiva concentração de riqueza em Bitcoin, e dá aos indivíduos, agora e no futuro, uma chance justa de adquirir unidades da moeda, enquanto mantém um forte incentivo para obter e manter ether, porque a "taxa de crescimento da oferta" como porcentagem ainda tende a zero ao longo do tempo. Também teorizamos isso porque as moedas sempre se perdem ao longo do tempo devido a descuidos, morte etc, e a perda de moedas pode ser modelada como uma porcentagem da oferta total por ano, que a oferta total de moedas em circulação acabará por estabilizar num valor igual à emissão anual dividida pela taxa de perda (por exemplo, a uma taxa de perda de 1%, quando a oferta atingir 26x então 0,26x será minerado e 0,26x perdido todo ano, criando um equilíbrio).
 

src/components/LanguagePicker/MenuItem.tsx

@@ -73,7 +73,10 @@ const MenuItem = ({ displayInfo, ...props }: ItemProps) => {
           <p className="text-xs uppercase text-body">{sourceName}</p>
         </div>
         {isCurrent && (
-          <BsCheck className="text-2xl text-primary-high-contrast" />
+          <BsCheck
+            aria-hidden={true}
+            className="text-2xl text-primary-high-contrast"
+          />
         )}
       </div>
       <p className="max-w-full text-xs lowercase text-body-medium">