fix regressions

Author: corwintines

public/content/translations/pt-br/developers/docs/smart-contracts/composability/index.md

@@ -7,7 +7,7 @@ incomplete: true
 
 ## Uma breve introdução {#a-brief-introduction}
 
-Os contratos inteligentes são públicos na Ethereum e podem ser considerados como APIs abertas. Você não precisa escrever o seu próprio contrato inteligente para se tornar um desenvolvedor dapp, você só precisa saber como interagir com eles. Por exemplo, você pode usar os contratos inteligentes existentes do [Uniswap](https://uniswap.exchange/swap), uma troca descentralizada, para lidar com toda a lógica de troca de token em seu aplicativo - você não precisa começar do zero. Confira alguns de seus contratos [v2](https://github. com/Uniswap/uniswap-v2-core/tree/master/contracts) e [v3](https://github. com/Uniswap/uniswap-v3-core/tree/main/contracts).
+Os contratos inteligentes são públicos na Ethereum e podem ser considerados como APIs abertas. Você não precisa escrever o seu próprio contrato inteligente para se tornar um desenvolvedor dapp, você só precisa saber como interagir com eles. Por exemplo, você pode usar os contratos inteligentes existentes do [Uniswap](https://uniswap.exchange/swap), uma troca descentralizada, para lidar com toda a lógica de troca de token em seu aplicativo - você não precisa começar do zero. Confira alguns de seus contratos [v2](https://github.com/Uniswap/uniswap-v2-core/tree/master/contracts) e [v3](https://github.com/Uniswap/uniswap-v3-core/tree/main/contracts).
 
 ## O que é composabilidade? {#what-is-composability}
 

public/content/translations/pt-br/developers/docs/smart-contracts/formal-verification/index.md

@@ -58,7 +58,7 @@ Especificações de alto nível geralmente capturam duas propriedades temporais
 
 Veja, por exemplo, este requisito de segurança que cobre condições para usar `transfer()` ou `transferFrom()` em contratos de token ERC-20: _ “O saldo de um remetente nunca é inferior à quantidade solicitada de tokens a serem enviados.”_. Essa descrição em linguagem natural de uma invariável de contrato pode ser traduzida em uma especificação formal (matemática), que pode então ser rigorosamente verificada para validade.
 
-Propriedades de vivacidade afirmam que “algo eventualmente bom acontece” e se refere à capacidade do contrato progredir por diferentes estados. Um exemplo de uma propriedade de vivacidade é a “liquidez”, que se refere à capacidade do contrato transferir seus saldos aos usuários por solicitação. Se essa propriedade for violada, os usuários não poderiam retirar os ativos armazenados no contrato, como aconteceu com o [incidente de carteira do Parity](https://www.cnbc.com/2017/11/08/accidental-bug-may- have-frozen-280-worth-of-ether-on-parity-wallet.html).
+Propriedades de vivacidade afirmam que “algo eventualmente bom acontece” e se refere à capacidade do contrato progredir por diferentes estados. Um exemplo de uma propriedade de vivacidade é a “liquidez”, que se refere à capacidade do contrato transferir seus saldos aos usuários por solicitação. Se essa propriedade for violada, os usuários não poderiam retirar os ativos armazenados no contrato, como aconteceu com o [incidente de carteira do Parity](https://www.cnbc.com/2017/11/08/accidental-bug-may-have-frozen-280-worth-of-ether-on-parity-wallet.html).
 
 ### Especificações de baixo nível {#low-level-specifications}
 
@@ -70,7 +70,7 @@ Especificações formais de baixo nível podem ser fornecidas como propriedades
 
 ### Propriedades do estilo Hoare {#hoare-style-properties}
 
-[Hore Logic](https://en.wikipedia.org/wiki/Hoare_logic) fornece um conjunto de regras formais para raciocinar sobre a correção de programas, incluindo contratos inteligentes. Uma propriedade de estilo Hoare é representada por um triplo Hoare \{_P_}_c_\{_Q_}, em que _c_ é um programa e _P_ e _Q_ são predicados no estado do _c_ (ou seja, o programa), formalmente descritos como _precondições_ e _pós-condições_, respectivamente.
+[Hore Logic](https://en.wikipedia.org/wiki/Hoare_logic) fornece um conjunto de regras formais para raciocinar sobre a correção de programas, incluindo contratos inteligentes. Uma propriedade de estilo Hoare é representada por um triplo Hoare `{P}c{Q}`, onde `c` é um programa e `P` e `Q` são predicados no estado do `c` (ou seja, o programa), formalmente descritos como _precondições_ e _pós-condições_, respectivamente.
 
 Uma precondição é um predicado que descreve as condições necessárias para a execução correta de uma função; os usuários que chamam um contrato devem satisfazer este requisito. Uma pós-condição é um predicado que descreve a condição que uma função estabelece se executada corretamente; os usuários podem esperar que essa condição seja verdadeira após chamar a função. Uma _invariável_ na lógica Hoare é um predicado que é preservado pela execução de uma função (ou seja, não muda).
 

public/content/translations/pt-br/developers/docs/smart-contracts/testing/index.md

@@ -54,7 +54,7 @@ Os testes unitários são úteis para verificar se as funções retornam os valo
 
 ##### 1. Entenda a lógica de negócios e o fluxo de trabalho de seus contratos
 
-Antes de escrever testes unitários, é bom saber quais funcionalidades um contrato inteligente oferece e como os usuários acessarão e usarão essas funções. Isso é particularmente útil para executar [testes de caminho feliz](https://en.m.wikipedia.org/wiki/Happy_path) que determinam se as funções em um contrato retornam a saída correta para entradas válidas do usuário. Explicaremos esse conceito usando este exemplo (resumido) de [um contrato de leilão](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple- open-auction)
+Antes de escrever testes unitários, é bom saber quais funcionalidades um contrato inteligente oferece e como os usuários acessarão e usarão essas funções. Isso é particularmente útil para executar [testes de caminho feliz](https://en.m.wikipedia.org/wiki/Happy_path) que determinam se as funções em um contrato retornam a saída correta para entradas válidas do usuário. Explicaremos esse conceito usando este exemplo (resumido) de [um contrato de leilão](https://docs.soliditylang.org/en/v0.8.17/solidity-by-example.html?highlight=Auction%20contract#simple-open-auction)
 
 ```
 constructor(

public/content/translations/pt-br/developers/docs/smart-contracts/verifying/index.md

@@ -84,7 +84,7 @@ Etherscan é a ferramenta mais usada para verificação de contratos. No entanto
 
 [Sourcify](https://sourcify.dev/#/verifier) é outra ferramenta para verificação de contratos que é de código aberto e descentralizada. Não é um observador de blocos e apenas verifica contratos em [diferentes redes baseadas em EVM](https://docs.sourcify.dev/docs/chains). Ele atua como uma infraestrutura pública para que outras ferramentas construam sobre ele, e tem como objetivo permitir interações de contrato mais amigáveis a humanos usando o [ABI](/developers/docs/smart-contracts/compiling/#web-applications) e [NatSpec](https://docs.soliditylang.org/en/v0.8.15/natspec-format.html) encontrados no arquivo de metadados.
 
-Ao contrário do Etherscan, o Sourcify suporta correspondências completas com o hash de metadados. Os contratos verificados são servidos em seu [repositório público](https://docs.sourcify.dev/docs/repository/) HTTP e [IPFS](https://docs.ipfs. io/concepts/what-is-ipfs/#what-is-ipfs), que é um [armazenamento descentralizado](https://web3.storage/docs/concepts/content-addressing/) endereçado ao conteúdo. Isso permite buscar o arquivo de metadados de um contrato sobre IPFS, pois o hash de metadados incluído é um hash IPFS.
+Ao contrário do Etherscan, o Sourcify suporta correspondências completas com o hash de metadados. Os contratos verificados são servidos em seu [repositório público](https://docs.sourcify.dev/docs/repository/) HTTP e [IPFS](https://docs.ipfs.io/concepts/what-is-ipfs/#what-is-ipfs), que é um [armazenamento descentralizado](https://web3.storage/docs/concepts/content-addressing/) endereçado ao conteúdo. Isso permite buscar o arquivo de metadados de um contrato sobre IPFS, pois o hash de metadados incluído é um hash IPFS.
 
 Adicionalmente, também é possível recuperar os arquivos de código-fonte por IPFS, pois os hashes IPFS desses arquivos também são encontrados nos metadados. Um contrato pode ser verificado fornecendo o arquivo de metadados e os arquivos da origem por meio de sua API ou [UI](https://sourcify.dev/#/verifier) ou usando os plugins. A ferramenta de monitoramento Sourcify também escuta as criações de contratos em novos blocos e tenta verificar os contratos se os seus metadados e arquivos de origem são publicados no IPFS.
 
@@ -96,7 +96,7 @@ A [plataforma Tenderly](https://tenderly.co/) permite desenvolvedores Web3 criem
 
 É possível verificar um contrato de forma privada ou pública. Se verificado privadamente, o contrato inteligente ficará visível apenas para você (e outros membros do seu projeto). A verificação de um contrato publicamente o torna visível para todos que usam a plataforma Tenderly.
 
-Você pode verificar seus contratos usando o [Painel](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract), [Plugin Tenderly da Hardhat](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin) ou [CLI](https:/ /docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli).
+Você pode verificar seus contratos usando o [Painel](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-a-smart-contract), [Plugin Tenderly da Hardhat](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-the-tenderly-hardhat-plugin) ou [CLI](https://docs.tenderly.co/monitoring/smart-contract-verification/verifying-contracts-using-cli).
 
 Ao verificar contratos através do Painel, você precisa importar o arquivo de origem ou o arquivo de metadados gerado pelo compilador Solidity, o endereço/rede e as configurações do compilador.
 

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

@@ -94,7 +94,7 @@ As melhorias normalmente não afetam os usuários finais, exceto ao proporcionar
 
 [Vitalik Buterin propôs uma visão para o planejamento do Ethereum](https://twitter.com/VitalikButerin/status/1741190491578810445) que foi organizada em diversas categorias vinculadas pelos efeitos na arquitetura do Ethereum. Ela inclui:
 
-- <**A Fusão**: melhorias relacionadas à mudança de [prova de trabalho](/glossary/#pow) para [prova de participação](/glossary/#pos)
+- **A Fusão**: melhorias relacionadas à mudança de [prova de trabalho](/glossary/#pow) para [prova de participação](/glossary/#pos)
 - **The Surge**: melhorias relacionadas ao dimensionamento por meio de [rollups](/glossary/#rollups) e fragmentação de dados
 - **The Scourge**: melhorias relacionadas à resistência à censura, à descentralização e a riscos de protocolo do [MEV](/glossary/#mev)
 - **The Verge**: melhorias relacionadas à verificação de [blocos](/glossary/#block) com mais facilidade

src/intl/pt-br/page-learn.json

@@ -121,4 +121,4 @@
   "unchained-description": "Analisa em profundidade as pessoas que constroem a Internet descentralizada, os detalhes dessa tecnologia que poderá sustentar nosso futuro e alguns dos tópicos mais espinhosos da criptografia, como regulamentação, segurança e privacidade",
   "the-daily-gwei-title": "The Daily Gwei",
   "the-daily-gwei-description": "Recapitula notícias, atualizações e análises sobre o Ethereum"
-}
+}