Merge pull request #280 from jlozovei/feat/pt-br

Improve pt-br translation

LICENSE

@@ -1,4 +1,4 @@
-Copyright (c) Dave Kerr 2019
+Copyright (c) Dave Kerr 2020
 
 # Attribution-ShareAlike 4.0 International
 

translations/pt-BR.md

@@ -2,7 +2,7 @@
 
 Leis, teorias, princípios e padrões que desenvolvedores acharão úteis.
 
-[Traduções](#traduções): 🇧🇷 [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./de.md) [🇫🇷](./fr.md) [🇬🇷](./el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr)
+[Traduções](#translations): [🇮🇩](./translations/pt-BR.md) [🇧🇷](./translations/pt-BR.md) [🇨🇳](https://github.com/nusr/hacker-laws-zh) [🇩🇪](./translations/de.md) [🇫🇷](./translations/fr.md) [🇬🇷](./translations/el.md) [🇮🇹](https://github.com/csparpa/hacker-laws-it) [🇱🇻](./translations/lv.md) [🇰🇷](https://github.com/codeanddonuts/hacker-laws-kr) [🇷🇺](https://github.com/solarrust/hacker-laws) [🇪🇸](./translations/es-ES.md) [🇹🇷](https://github.com/umutphp/hacker-laws-tr) [🇯🇵](./translations/jp.md)
 
 Gostou deste projeto? Por favor, considere [me apoiar](https://github.com/sponsors/dwmkerr) e [apoiar os tradutores](#traduções).
 
@@ -12,51 +12,51 @@ Gostou deste projeto? Por favor, considere [me apoiar](https://github.com/sponso
 
 * [Introdução](#introdução)
 * [Leis](#leis)
-	* [Princípio 90-9-1 (Regra do 1%)](#princípio-90-9-1-regra-do-1)
-    * [Lei de Amdahl](#lei-de-amdahl)
-    * [Teoria das Janelas Quebradas](#teoria-das-janelas-quebradas)
-    * [Lei de Brook](#lei-de-brook)
-    * [Lei de Conway](#lei-de-conway)
-    * [Lei de Cunningham](#lei-de-cunningham)
-    * [Número de Dunbar](#número-de-dunbar)
-    * [Lei de Gall](#lei-de-gall)
-    * [Lei de Goodhart](#lei-de-goodhart)
-    * [Navalha de Hanlon](#navalha-de-hanlon)
-    * [Lei de Hofstadter](#lei-de-hofstadter)
-    * [Lei de Hutber](#lei-de-hutber)
-    * [O Ciclo Hype e Lei de Amara](#o-ciclo-hype-e-lei-de-amara)
-    * [Lei de Hyrum (Lei das Interfaces Implícitas)](#lei-de-hyrum-lei-das-interfaces-implícitas)
-    * [Lei de Kernighan](#lei-de-kernighan)
-    * [Lei de Metcalfe](#lei-de-metcalfe)
-    * [Lei de Moore](#lei-de-moore)
-    * [Lei de Murphy / Lei de Sod](#lei-de-murphy--lei-de-sod)
-    * [Navalha de Occam](#navalha-de-occam)
-    * [Lei de Parkinson](#lei-de-parkinson)
-    * [Efeito de Otimização Prematura](#efeito-de-otimização-prematura)
-    * [Lei de Putt](#lei-de-putt)
-    * [Lei de Reed](#lei-de-reed)
-    * [A Lei da Conservação da Complexidade (Lei de Tesler)](#a-lei-da-conservação-da-complexidade-lei-de-tesler)
-    * [A Lei das Abstrações Gotejantes](#a-lei-das-abstrações-gotejantes)
-    * [A Lei da Trivialidade](#a-lei-da-trivialidade)
-    * [A Filosofia Unix](#a-filosofia-unix)
-    * [O Modelo Spotify](#o-modelo-spotify)
-    * [Lei de Wadler](#lei-de-wadler)
-    * [Lei de Wheaton](#lei-de-wheaton)
+  * [Princípio 90-9-1 (Regra do 1%)](#princípio-90-9-1-regra-do-1)
+  * [Lei de Amdahl](#lei-de-amdahl)
+  * [Teoria das Janelas Quebradas](#teoria-das-janelas-quebradas)
+  * [Lei de Brook](#lei-de-brook)
+  * [Lei de Conway](#lei-de-conway)
+  * [Lei de Cunningham](#lei-de-cunningham)
+  * [Número de Dunbar](#número-de-dunbar)
+  * [Lei de Gall](#lei-de-gall)
+  * [Lei de Goodhart](#lei-de-goodhart)
+  * [Navalha de Hanlon](#navalha-de-hanlon)
+  * [Lei de Hofstadter](#lei-de-hofstadter)
+  * [Lei de Hutber](#lei-de-hutber)
+  * [O Ciclo Hype e Lei de Amara](#o-ciclo-hype-e-lei-de-amara)
+  * [Lei de Hyrum (Lei das Interfaces Implícitas)](#lei-de-hyrum-lei-das-interfaces-implícitas)
+  * [Lei de Kernighan](#lei-de-kernighan)
+  * [Lei de Metcalfe](#lei-de-metcalfe)
+  * [Lei de Moore](#lei-de-moore)
+  * [Lei de Murphy / Lei de Sod](#lei-de-murphy--lei-de-sod)
+  * [Navalha de Occam](#navalha-de-occam)
+  * [Lei de Parkinson](#lei-de-parkinson)
+  * [Efeito de Otimização Prematura](#efeito-de-otimização-prematura)
+  * [Lei de Putt](#lei-de-putt)
+  * [Lei de Reed](#lei-de-reed)
+  * [A Lei da Conservação da Complexidade (Lei de Tesler)](#a-lei-da-conservação-da-complexidade-lei-de-tesler)
+  * [A Lei das Abstrações Gotejantes](#a-lei-das-abstrações-gotejantes)
+  * [A Lei da Trivialidade](#a-lei-da-trivialidade)
+  * [A Filosofia Unix](#a-filosofia-unix)
+  * [O Modelo Spotify](#o-modelo-spotify)
+  * [Lei de Wadler](#lei-de-wadler)
+  * [Lei de Wheaton](#lei-de-wheaton)
 * [Princípios](#princípios)
-	* [O Princípio Dilbert](#o-princípio-dilbert)
-    * [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020)
-    * [O Princípio de Peter](#o-princípio-de-peter)
-    * [O Princípio da Robustez (Lei de Postel)](#o-princípio-da-robustez-lei-de-postel)
-    * [SOLID](#solid)
-    * [O Princípio da Responsabilidade Única](#o-princípio-da-responsabilidade-única)
-    * [O Princípio do Aberto/Fechado](#o-princípio-do-abertofechado)
-    * [O Princípio da Substituição de Liskov](#o-princípio-da-substituição-de-liskov)
-    * [O Princípio da Segregação de Interface](#o-princípio-da-segregação-de-interface)
-    * [O Princípio da Inversão de Dependência](#o-princípio-da-inversão-de-dependência)
-    * [O Princípio DRY](#o-princípio-dry)
-    * [O Princípio KISS](#o-princípio-kiss)
-    * [YAGNI](#yagni)
-    * [As Falácias da Computação Distribuída](#as-falácias-da-computação-distribuída)
+  * [O Princípio Dilbert](#o-princípio-dilbert)
+  * [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020)
+  * [O Princípio de Peter](#o-princípio-de-peter)
+  * [O Princípio da Robustez (Lei de Postel)](#o-princípio-da-robustez-lei-de-postel)
+  * [SOLID](#solid)
+  * [O Princípio da Responsabilidade Única](#o-princípio-da-responsabilidade-única)
+  * [O Princípio do Aberto/Fechado](#o-princípio-do-abertofechado)
+  * [O Princípio da Substituição de Liskov](#o-princípio-da-substituição-de-liskov)
+  * [O Princípio da Segregação de Interface](#o-princípio-da-segregação-de-interface)
+  * [O Princípio da Inversão de Dependência](#o-princípio-da-inversão-de-dependência)
+  * [O Princípio DRY](#o-princípio-dry)
+  * [O Princípio KISS](#o-princípio-kiss)
+  * [YAGNI](#yagni)
+  * [As Falácias da Computação Distribuída](#as-falácias-da-computação-distribuída)
 * [Lista de leitura](#lista-de-leitura)
 * [Traduções](#traduções)
 * [Projetos relacionados](#projetos-relacionados)
@@ -73,21 +73,21 @@ Existem muitas leis sobre as quais as pessoas discutem quando falam sobre desenv
 
 ## Leis
 
-E lá vamos nos!
+E lá vamos nós!
 
 ### Princípio 90-9-1 (Regra do 1%)
 
 [1% Rule on Wikipedia](https://en.wikipedia.org/wiki/1%25_rule_(Internet_culture))
 
-The 90-9-1 principle suggests that within an internet community such as a wiki, 90% of participants only consume content, 9% edit or modify content and 1% of participants add content.
+O Princípio 90-9-1 sugere que em uma comunidade da internet, como uma wiki, 90% dos participantes apenas consomem o conteúdo, 9% editam ou modificam o conteúdo e 1% dos participantes adicionam novos conteúdos.
 
-Real-world examples:
+Exemplos do mundo real:
 
-- A 2014 study of four digital health social networks found the top 1% created 73% of posts, the next 9% accounted for an average of ~25% and the remaining 90% accounted for an average of 2% ([Reference](https://www.jmir.org/2014/2/e33/))
+- Um estudo de 2014 de quatro redes sociais de saúde digital concluíram que 1% dos usuários criaram 73% das publicações, os próximos 9% foram responsáveis por cerca de ~25% e os 90% restantes por uma média de 2% ([Referência](https://www.jmir.org/2014/2/e33/))
 
-See Also:
+Veja também:
 
-- [Pareto principle](#the-pareto-principle-the-8020-rule)
+- [O Princípio de Pareto (Regra do 80/20)](#o-princípio-de-pareto-regra-do-8020)
 
 ### Lei de Amdahl
 
@@ -109,15 +109,15 @@ Como pode-se perceber, mesmo um programa que teve metade da sua implementação
 
 [The Broken Windows Theory on Wikipedia](https://en.wikipedia.org/wiki/Broken_windows_theory)
 
-The Broken Windows Theory suggests that visible signs of crime (or lack of care of an environment) lead to further and more serious crimes (or further deterioration of the environment).
+A Teoria das Janelas Quebradas sugere que sinais visíveis de crimes (ou a falta de cuidado por um ambiente) leva a crimes mais sérios (ou mais deterioração do ambiente).
 
-This theory has been applied to software development, suggesting that poor quality code (or [Technical Debt](#TODO)) can lead to a perception that efforts to improve quality may be ignored or undervalued, thus leading to further poor quality code. This effect cascades leading to a great decrease in quality over time.
+Essa teoria tem sido aplicada no desenvolvimento de software, sugerindo que a baixa qualidade do código (ou o [Débito Técnico](#TODO)) podem levar a percepção de que esforços para melhorar a qualidade talvez sejam ignorados ou desvalorizados, mantendo a baixa qualidade. Esse efeito de cascata leva a uma grande diminuição na qualidade através do tempo.
 
-See also:
+Veja também:
 
-- [Technical Debt](#TODO)
+- [Débito Técnico](#TODO)
 
-Examples:
+Exemplos:
 
 - [The Pragmatic Programming: Software Entropy](https://pragprog.com/the-pragmatic-programmer/extracts/software-entropy)
 - [Coding Horror: The Broken Window Theory](https://blog.codinghorror.com/the-broken-window-theory/)
@@ -135,7 +135,7 @@ Essa lei sugere que em muitos casos, na tentativa de acelerar uma entrega, que j
 "Nove mulheres não podem parir uma criança em um mês" e "Dois pilotos não fazem o carro ir mais rápido" são frases relacionadas a Lei de Brooke, principalmente porque algumas tarefas nao podem ser divididas.
 
 
-Esse é um tema central do livro'[The Mythical Man Month](#lista-de-livros)'.
+Esse é um tema central do livro '[The Mythical Man Month](#lista-de-livros)'.
 
 Veja também:
 
@@ -156,11 +156,11 @@ Veja também:
 
 [Cunningham's Law on Wikipedia](https://en.wikipedia.org/wiki/Ward_Cunningham#Cunningham's_Law)
 
-> The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.
+> A melhor forma de obter a resposta correta na Internet não é fazer a pergunta, mas postar a resposta errada.
 
-According to Steven McGeady, Ward Cunningham advised him in the early 1980s: "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." McGeady dubbed this Cunningham's law, though Cunningham denies ownership calling it a "misquote." Although originally referring to interactions on Usenet, the law has been used to describe how other online communities work (e.g., Wikipedia, Reddit, Twitter, Facebook).
+De acordo com Steven McGeady, Ward Cunningham o aconselhou no início dos anos 80: "A melhor forma de ter a resposta correta na Internet não é fazer a pergunta, mas postar a resposta errada." McGeady apelidou essa lei de "Lei de Cunningham", mesmo que Cunningham negue sua propriedade chamando-a de "citação". Mesmo originalmente se referindo a interações na Usenet, a lei tem sido utilizada para descrever como comunidades online funcionam (e.x.: Wikipedia, Reddit, Twitter, Facebook).
 
-See also:
+Veja também:
 
 - [XKCD 386: "Duty Calls"](https://xkcd.com/386/)
 
@@ -168,7 +168,7 @@ See also:
 
 [Número de Dunbar na Wikipedia](https://en.wikipedia.org/wiki/Dunbar%27s_number)
 
-[Dumbar] propós que humanos só conseguem manter de forma confortável, 150 relacionamentos estáveis. Esse número está mais em um contexto social, "o número de pessoas que você não se sentiria sem graça para se juntar em uma bebiba se esbarrase com ela em um bar". Esse número geralmente está entra 100 e 250.
+Dunbar propós que humanos só conseguem manter de forma confortável, 150 relacionamentos estáveis. Esse número está mais em um contexto social, "o número de pessoas que você não se sentiria sem graça para se juntar em uma bebiba se esbarrase com ela em um bar". Esse número geralmente está entra 100 e 250.
 
 Esse número é uma sugestão cognitiva limite para o número de pessoass para qual consegue-se manter uma relação social estável.
 
@@ -176,45 +176,44 @@ Como uma relação entre pessoas, manter uma relação entre desenvolvedor e cod
 
 Veja também:
 
-- [Lei de Conwy](#lei-de-conway)
+- [Lei de Conway](#lei-de-conway)
 
 ### Lei de Gall
 
 [Gall's Law on Wikipedia](https://en.wikipedia.org/wiki/John_Gall_(author)#Gall's_law)
 
-> A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
->
-> ([John Gall](https://en.wikipedia.org/wiki/John_Gall_(author)))
+> Um sistema complexo que funciona é invariavelmente encontrado para ter evoluído a partir de um sistema simples que trabalhou. Um sistema complexo projetado a partir do zero nunca funciona e não pode ser remendado para fazê-lo funcionar.
 
-Gall's Law implies that attempts to _design_ highly complex systems are likely to fail. Highly complex systems are rarely built in one go, but evolve instead from more simple systems.
+A Lei de Gall afirma que tentativas de projetar sistemas altamente complexos provavelmente falharão. Sistemas altamente complexos raramente são construídos em uma vez só, mas evoluem a partir de sistemas mais simples.
 
-The classic example is the world-wide-web. In its current state, it is a highly complex system. However, it was defined initially as a simple way to share content between academic institutions. It was very successful in meeting these goals and evolved to become more complex over time.
+Um exemplo clássico é a world-wide-web. Em seu estado atual, ela é um sistema altamente complexo. Contudo, ela foi definida inicialmente como uma forma simples de compartilhar conteúdo entre instituições acadêmicas. Ela foi tão bem-sucedida em atingir esses objetivos que evoluiu para se tornar algo mais complexo ao longo do tempo.
 
-See also:
+Veja também:
 
-- [KISS (Keep It Simple, Stupid)](#the-kiss-principle)
+- [KISS (Keep It Simple, Stupid)](#o-princípio-kiss)
 
 ### Lei de Goodhart
 
 [The Goodhart's Law on Wikipedia](https://en.wikipedia.org/wiki/Goodhart's_law)
 
-> Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes.
+> Qualquer regularidade estatística observada tende a entrar em colapso quando a pressão é aplicada para fins de controle.
 >
 > _Charles Goodhart_
 
-Also commonly referenced as:
 
-> When a measure becomes a target, it ceases to be a good measure.
+Também referenciada como:
+
+> Quando uma medida torna-se uma meta (ou alvo), ela deixa de ser uma boa medida.
 >
 > _Marilyn Strathern_
 
-The law states that the measure-driven optimizations could lead to devaluation of the measurement outcome itself. Overly selective set of measures ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) blindly applied to a process results in distorted effect. People tend to optimize locally by "gaming" the system in order to satisfy particular metrics instead of paying attention to holistic outcome of their actions.
+A lei diz que otimizações orientadas por medidas podem levar à uma desvalorização do próprio resultado da medição. O conjunto de medidas excessivamente seletivo ([KPIs](https://en.wikipedia.org/wiki/Performance_indicator)) aplicado cegamenta a um processo resulta em um efeito distorcido. As pessoas tentem a otimizar localmente "jogando com" o sistema para satisfazer métricas específicas ao invés de prestar atenção ao resultado holístico de suas ações.
 
-Real-world examples:
-- Assert-free tests satisfy the code coverage expectation, despite the fact that the metric intent was to create well-tested software.
-- Developer performance score indicated by the number of lines committed leads to unjustifiably bloated codebase.
+Exemplos do mundo real:
+- Testes sem `assertions` atendem à cobertura de código esperada, apesar do objetivo da métrica era criar software bem testado
+- A pontuação do desempenho de desenvolvedores é indicada pelo número de linhas `commitadas` leva a uma base de código injustificadamente inchada.
 
-See also:
+Veja também:
 - [Goodhart’s Law: How Measuring The Wrong Things Drive Immoral Behaviour](https://coffeeandjunk.com/goodharts-campbells-law/)
 - [Dilbert on bug-free software](https://dilbert.com/strip/1995-11-13)
 
@@ -245,20 +244,20 @@ This is from the book '[Gödel, Escher, Bach: An Eternal Golden Braid](#lista-de
 
 [Hutber's Law on Wikipedia](https://en.wikipedia.org/wiki/Hutber%27s_law)
 
-> Improvement means deterioration.
+> Melhoria significa deterioração.
 >
-> ([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))
+> _([Patrick Hutber](https://en.wikipedia.org/wiki/Patrick_Hutber))_
 
-This law suggests that improvements to a system will lead to deterioration in other parts, or it will hide other deterioration, leading overall to a degradation from the current state of the system.
+Essa lei sugere que melhorias em um sistema irão levar à deterioração em outras partes, ou ela ocultarão outras deteriorações, levando a uma degradação do estado atual do sistema.
+
+Por exemplo, a diminuição na latência da resposta para um `end-point` particular pode causar um aumento na taxa de transferência e na capacidade ao longo de um fluxo de solicitação, afetando um subsistema totalmente diferente.
 
-For example, a decrease in response latency for a particular end-point could cause increased throughput and capacity issues further along in a request flow, affecting an entirely different sub-system.
 
 ### O Ciclo Hype e Lei de Amara
 
-
 [The ciclo Hype on Wikipedia](https://en.wikipedia.org/wiki/Hype_cycle)
 
->Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo.
+> Nós tendemos a superestimar os efeitos da tecnologia em curto prazo e subestimar os efeitos a longo prazo.
 >
 > Roy Amara
 
@@ -274,13 +273,12 @@ Em curto prazo, o ciclo sugere que acontece uma explosão de empolgação a cerc
 
 [Lei de Hyrum site](http://www.hyrumslaw.com/)
 
-
->Com um número suficientes de clientes de uma API,
->não importa a sua pré-condição no contato:
->todos os comportamentos observáveis do seu sistema
->serão dependentes de alguém.
+> Com um número suficientes de clientes de uma API,
+> não importa a sua pré-condição no contato:
+> todos os comportamentos observáveis do seu sistema
+> serão dependentes de alguém.
 >
-> (Hyrum Wright)
+> Hyrum Wright
 
 A lei de Hyrum sugere que quando você tem um número muito grande de consumidores de uma API, todos os comportamentos dessa API (mesmo aqueles que não estão definidos como parte de um contrato público) eventualmente irão dependender de outra parte do sistema, ou outra API. Um exemplo trivial pode ser elementos não funcionais, como o tempo de resposta de uma API. Um exemplo mais sutil pode ser os consumidores que estão confiando em aplicar um regex a uma mensagem de erro para determinar o _tipo_ de erro de uma API. Mesmo que o contrato público da API não especifique nada sobre o conteúdo da mensagem, indicando que os usuários devem usar um código de erro associado, alguns usuários podem usar a mensagem e alterar a mensagem essencialmente interrompe a API para esses usuários.
 
@@ -288,35 +286,37 @@ Veja Também:
 
 - [XKCD 1172](https://xkcd.com/1172/)
 
+
 ### Lei de Kernighan
 
-> Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.
+> A depuração é duplamente mais difícil do que escrever o código em primeiro lugar. Portanto, se você escrever o código da maneira mais inteligente possível, por definição, você não é inteligente o sufiencte para depurá-lo.
 >
-> (Brian Kernighan)
+> Brian Kernighan
 
-Kernighan's Law is named for [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) and derived from a quote from Kernighan and Plauger's book [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
+A Lei de Kerningham é nomeada por [Brian Kernighan](https://en.wikipedia.org/wiki/Brian_Kernighan) e devivada de uma citação de Kerningham no livro [The Elements of Programming Style](https://en.wikipedia.org/wiki/The_Elements_of_Programming_Style):
 
-> Everyone knows that debugging is twice as hard as writing a program in the first place. So if you're as clever as you can be when you write it, how will you ever debug it?
+> Todo mundo sabe que depurar é duplamente mais difícil do que programar em primeiro lugar. Então, se você é o mais inteligente possível quando escreve, como você conseguirá depurar o código?
 
-While hyperbolic, Kernighan's Law makes the argument that simple code is to be preferred over complex code, because debugging any issues that arise in complex code may be costly or even infeasible.
+Enquanto hiperbólica, a Lei de Kerningham faz a argumentação de que código simples deve ser preferido ao invés de código complexo, porque depurar qualquer problema que poderá surgir em um código complexo pode ser custoso ou até mesmo inviável.
 
-See also:
+Veja também:
+
+- [Princípio KISS](#o-princípio-kiss)
+- [Filosofia Unix](#a-filosofia-unix)
+- [Navalha de Occam](#navalha-de-occam)
 
-- [The KISS Principle](#the-kiss-principle)
-- [The Unix Philosophy](#the-unix-philosophy)
-- [Occam's Razor](#occams-razor)
 
 ### Lei de Metcalfe
 
 [Metcalfe's Law on Wikipedia](https://en.wikipedia.org/wiki/Metcalfe's_law)
 
-> In network theory, the value of a system grows as approximately the square of the number of users of the system.
+> Na teoria das redes, o valor de um sistema cresce aproximadamente o quadrado do número de usuários daquele sistema.
 
-This law is based on the number of possible pairwise connections within a system and is closely related to [Reed's Law](#reeds-law). Odlyzko and others have argued that both Reed's Law and Metcalfe's Law overstate the value of the system by not accounting for the limits of human cognition on network effects; see [Dunbar's Number](#dunbars-number).
+Esta lei é baseada no número de possíveis conexões pareadas dentro de um sistema e é relacionada com a [Lei de Reed](#lei-de-reed). Odlyzko e outros argumentaram que tanto a Lei de Reed e a Lei de Metcalfe exageram o valor do sistema, não levando em consideração os limites da cognição humana sobre os efeitos da rede; veja [Número de Dunbar](#número-de-dunbar).
 
-See also:
-- [Reed's Law](#reeds-law)
-- [Dunbar's Number](#dunbars-number)
+Veja também:
+- [Lei de Reed](#lei-de-reed)
+- [Número de Dunbar](#número-de-dunbar)
 
 ### Lei de Moore
 
@@ -335,37 +335,37 @@ Esse padrão continuou a se manter, e não se espera que pare até, no mínimo,
 
 [Murphy's Law on Wikipedia](https://en.wikipedia.org/wiki/Murphy%27s_law)
 
-> Anything that can go wrong will go wrong.
+> Tudo que poderá dar errado, irá dar errado.
 
-Related to [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.) _Murphy's Law_ states that if a thing can go wrong, it will go wrong.
+Relacionada com [Edward A. Murphy, Jr](https://en.wikipedia.org/wiki/Edward_A._Murphy_Jr.), a _Lei de Murphy_ diz que se algo pode dar errado, isso dará errado.
 
-This is a common adage among developers. Sometimes the unexpected happens when developing, testing or even in production. This can also be related to the (more common in British English) _Sod's Law_:
+Isso é um ditado comum entre desenvolvedores. Muitas vezes o inesperado ocorre durante o desenvolvimento, testes ou até mesmo em produção. Essa lei também pode ser relacionada a Lei de Sod (mais comum no inglês britânico):
 
-> If something can go wrong, it will, at the worst possible time.
+> Se algo pode dar errado, dará errado, no pior momento possível.
 
-These 'laws' are generally used in a comic sense. However, phenomena such as [_Confirmation Bias_](#TODO) and [_Selection Bias_](#TODO) can lead people to perhaps over-emphasise these laws (the majority of times when things work, they go unnoticed, failures however are more noticeable and draw more discussion).
+Essas 'leis' são geralmente utilizadas em um sentido cômico. Contudo, fenômenos como [_Confirmation Bias_](#TODO) e [_Selection Bias_](#TODO) podem pevar as pessoas a enfatizarem demais essas leis (na maioria das vezes quando as coisas funcionam, elas passam desapercebidas, as falhas são mais perceptíveis e atraem mais discussões).
 
-See Also:
+Veja também:
 
 - [Confirmation Bias](#TODO)
 - [Selection Bias](#TODO)
 
 ### Navalha de Occam
 
-[Occam's Razor on Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor)
+[Navalha de Occam on Wikipedia](https://en.wikipedia.org/wiki/Occam's_razor)
 
-> Entities should not be multiplied without necessity.
+> Entidades não devem ser multiplicadas sem necessidade.
 >
 > William of Ockham
 
-Occam's razor says that among several possible solutions, the most likely solution is the one with the least number of concepts and assumptions. This solution is the simplest and solves only the given problem, without introducing accidental complexity and possible negative consequences.
+A Navalha de Occam diz que em meio a várias possíveis soluções, a solução mais provável é aquela com menor número de conceitos e suposições. Essa solução é a mais simples e envolve apenas o problema em questão, sem introduzir complexidades acidentais e possíveis consequências negativas.
 
-See also:
+Veja também:
 
 - [YAGNI](#yagni)
 - [No Silver Bullet: Accidental Complexity and Essential Complexity](https://en.wikipedia.org/wiki/No_Silver_Bullet)
 
-Example:
+Exemplo:
 
 - [Lean Software Development: Eliminate Waste](https://en.wikipedia.org/wiki/Lean_software_development#Eliminate_waste)
 
@@ -381,13 +381,13 @@ A lei de Parkinson foi publicada por Cyril Northcote Parkinson num artigo na rev
 
 [Premature Optimization on WikiWikiWeb](http://wiki.c2.com/?PrematureOptimization)
 
-> Premature optimization is the root of all evil.
+> Otimização prematura é a raiz de todo o mal.
 >
 > [(Donald Knuth)](https://twitter.com/realdonaldknuth?lang=en)
 
-In Donald Knuth's paper [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), he wrote: "Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: **premature optimization is the root of all evil**. Yet we should not pass up our opportunities in that critical 3%."
+No artigo de Donald Knuth, [Structured Programming With Go To Statements](http://wiki.c2.com/?StructuredProgrammingWithGoToStatements), ele escreve: "Programadores perdem grandes quantidades de tempo pensando ou se preocupando com a velocidade de partes não críticas de seus programas, e essas tentativas de eficiência possuem um forte impacto negativo quando depuração e manutenção são consideradas. Nós devemos esquecer essas pequenas eficiências, cerca de 97% das vezes: **otimização prematura é a raiz de todo o mal.** No entando, não devemos perder a oportunidade nesses 3% críticos".
 
-However, _Premature Optimization_ can be defined (in less loaded terms) as optimizing before we know that we need to.
+Contudo, _Otimização Prematura_ pode ser definida (em termos menos carregados) como otimizar antes de saber o que precisamos.
 
 ### Lei de Putt
 
@@ -403,20 +403,20 @@ Estas declarações sugerem que devido a vários critérios de seleção e tend
 
 Veja também:
 
-- [O Principio de Peter](#em-progresso)
-- [Lei de Dilbert](#em-progresso).
+- [Principio de Peter](#o-princípio-de-peter)
+- [Princípio de Dilbert](#o-princípio-dilbert)
 
 ### Lei de Reed
 
 [Reed's Law on Wikipedia](https://en.wikipedia.org/wiki/Reed's_law)
 
-> The utility of large networks, particularly social networks, scales exponentially with the size of the network.
+> A utilidade de grandes redes, particularmente redes sociais, escalam exponencialmente com o tamanho da própria rede.
 
-This law is based on graph theory, where the utility scales as the number of possible sub-groups, which is faster than the number of participants or the number of possible pairwise connections. Odlyzko and others have argued that Reed's Law overstates the utility of the system by not accounting for the limits of human cognition on network effects; see [Dunbar's Number](#dunbars-number).
+Essa lei é baseada na teoria dos grafos, onde a utilidade é escalonada com o número de possíveis subgrupos, que é mais rápido que o número de participantes ou o número de possíveis conexões pareadas. Odlyzko e outros argumentam que a Lei de Reed exagera a utilidade de um sistema por não levar em conta os limites da cognição humana sobre os efeitos da rede; veja [Número de Dunbar](#número-de-dunbar).
 
-See also:
-- [Metcalfe's Law](#metcalfes-law)
-- [Dunbar's Number](#dunbars-number)
+Veja também:
+- [Lei de Metcalfe](##lei-de-metcalfe)
+- [Número de Dunbar](#número-de-dunbar)
 
 ### A Lei da Conservação da Complexidade (Lei de Tesler)
 
@@ -434,64 +434,63 @@ Um elemento interessante para essa lei é a sugestão de que, mesmo simplificand
 
 >Todas as abstrações não triviais, até certo ponto, são vazadas
 
-This law states that abstractions, which are generally used in computing to simplify working with complicated systems, will in certain situations 'leak' elements of the underlying system, this making the abstraction behave in an unexpected way.
+Essa lei afirma que abstrações, as quais são geralmente utilizadas na computação para simplificar um trabalho com sistemas complexos, em certas situações irão 'vazar' elementos do sistema subjacente, fazendo com que a abstração se comporte de maneira inesperada.
 
-An example might be loading a file and reading its contents. The file system APIs are an _abstraction_ of the lower level kernel systems, which are themselves an abstraction over the physical processes relating to changing data on a magnetic platter (or flash memory for an SSD). In most cases, the abstraction of treating a file like a stream of binary data will work. However, for a magnetic drive, reading data sequentially will be *significantly* faster than random access (due to increased overhead of page faults), but for an SSD drive, this overhead will not be present. Underlying details will need to be understood to deal with this case (for example, database index files are structured to reduce the overhead of random access), the abstraction 'leaks' implementation details the developer may need to be aware of.
+Um exemplo disso pode ser carregar um arquivo e ler o seu conteúdo. As APIs do sistema de arquivo são abstrações do kernel de nível inferior, que são uma abstração dos processadores físicos relacionados à alteração de dados no disco rígido (ou na memória flash em SSD). Na maioria dos casos, a abstração de tratar um arquivo como um fluxo de dados binários funcionará. Contudo, para um disco rígido, a leitura sequencial dos dados será significamente mais rápida que o acesso aleatório (devido ao aumento da sobrecarga de falhas na página), mas para um disco SSD, essa sobrecarga não estará presente. Os detalhes subjacentes precisarão ser entendidos para lidar com esse caso (por exemplo, os arquivos índices de uma base de dados são estruturados para reduzir a sobrecarga do acesso aleatório), a abstração 'vaza' detalhes de implementação os quais o desenvolvedor precisa estar ciente.
 
-The example above can become more complex when _more_ abstractions are introduced. The Linux operating system allows files to be accessed over a network but represented locally as 'normal' files. This abstraction will 'leak' if there are network failures. If a developer treats these files as 'normal' files, without considering the fact that they may be subject to network latency and failures, the solutions will be buggy.
+O exemplo acima pode se tormar mais complexo quando _mais_ abstrações são introduzidas. O sistema operacional Linux permite que os arquivos sejam acessados por rede mas representados localmente como arquivos 'normais'. Essa abstração será 'vazada' se houverem falhas de rede. Se um desenvolvedor tratar esses arquivos como 'normais', sem considerar o fato de que eles podem estar sujeitos à latência e falhas na rede, as soluções serão incorretas.
 
-The article describing the law suggests that an over-reliance on abstractions, combined with a poor understanding of the underlying processes, actually makes dealing with the problem at hand _more_ complex in some cases.
+Veja também:
 
-See also:
+- [Lei de Hyrum](#lei-de-hyrum-lei-das-interfaces-implícitas)
 
-- [Hyrum's Law](#hyrums-law-the-law-of-implicit-interfaces)
+Exemplos do mundo real:
 
-Real-world examples:
-
-- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - an issue I encountered in the past. Photoshop would be slow to startup, sometimes taking minutes. It seems the issue was that on startup it reads some information about the current default printer. However, if that printer is actually a network printer, this could take an extremely long time. The _abstraction_ of a network printer being presented to the system similar to a local printer caused an issue for users in poor connectivity situations.
+- [Photoshop Slow Startup](https://forums.adobe.com/thread/376152) - um problema que eu encontrei no passado. O Photoshop demorava para abrir, às vezes levando alguns minutos. Parecia que o problema era que, ao iniciar, o programa lia algumas informações sobre a impressora padrão. No entando, se essa impressora fosse uma impressora de rede, isso demoraria tempo extremamente longo. A _abstração_ de uma impressora de rede ser mostrada ao sistema como uma impressora local causou um problema para usuários em situação de baixa conectividade. 
 
 ### A Lei da Trivialidade
 
 [The Law of Triviality on Wikipedia](https://en.wikipedia.org/wiki/Law_of_triviality)
 
-This law suggests that groups will give far more time and attention to trivial or cosmetic issues rather than serious and substantial ones.
+Essa lei sugere que grupos irão dar maior atenção para problemas triviais ou cosméticos, do que para os problemas sérios e substanciais.
 
-The common fictional example used is that of a committee approving plans for nuclear power plant, who spend the majority of their time discussing the structure of the bike shed, rather than the far more important design for the power plant itself. It can be difficult to give valuable input on discussions about very large, complex topics without a high degree of subject matter expertise or preparation. However, people want to be seen to be contributing valuable input. Hence a tendency to focus too much time on small details, which can be reasoned about easily, but are not necessarily of particular importance.
+O exemplo fictício comum utilizado é o de um comitê aprovando planos para uma usina nuclear, que passam maior tempo discutindo a estrutura do bicicletário ao invés do design da própria usina que é muito mais importante. Pode ser difícil fornecer informações valiosas em discussões sobre tópicos muito grandes e complexos sem um alto grau de conhecimento ou preparação no assunto. No entando, as pessoas querem ser vistas contribuindo com informações importantes. Daí uma tendência de concentrar muito tempo em pequenos detalhes, que podem ser facilmente explicados, mas necessariamente não são de importância particular.
+
+O exemplo fictício acima levou ao uso do termo _'Bike Shedding'_ como uma expressão por gastar tempo em detalhes triviais.
 
-The fictional example above led to the usage of the term 'Bike Shedding' as an expression for wasting time on trivial details.
 
 ### A Filosofia Unix
 
 [The Unix Philosophy on Wikipedia](https://en.wikipedia.org/wiki/Unix_philosophy)
 
-The Unix Philosophy is that software components should be small, and focused on doing one specific thing well. This can make it easier to build systems by composing together small, simple, well-defined units, rather than using large, complex, multi-purpose programs.
+A Filosofia Unix prega que componentes de um software devem ser pequenos, e focados em fazer muito bem uma coisa específica. Isso torna mais fácil a construção de sistemas compondo unidades pequenas, simples e bem definidas, em vez de usar programas grandes, complexos e multiuso.
 
-Modern practices like 'Microservice Architecture' can be thought of as an application of this law, where services are small, focused and do one specific thing, allowing complex behaviour to be composed of simple building blocks.
+Práticas modernas como a 'Arquitetura de Microsserviços' podem ser pensadas como uma aplicação dessa lei, onde os serviços são pequenos, focados em uma tarefa específica, permitindo que um comportamento complexo seja composto de blocos de construção simples.
 
 ### O Modelo Spotify
 
 [The Spotify Model on Spotify Labs](https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/)
 
-The Spotify Model is an approach to team and organisation structure which has been popularised by 'Spotify'. In this model, teams are organised around features, rather than technologies.
+O Modelo Spotify é uma abordagem para a organização de equipes que foi popularizado pelo 'Spotify'. Neste modelo, times são organizados por funcionalidades, não por tecnologias.
 
-The Spotify Model also popularises the concepts of Tribes, Guilds, Chapters, which are other components of their organisation structure.
+O Modelo Spotify também popularizou o conteido de Tribos, Guildas, Capítulos, que são outros componentes de sua estrutura organizacional.
 
 ### Lei de Wadler
 
 [Wadler's Law on wiki.haskell.org](https://wiki.haskell.org/Wadler's_Law)
 
-> In any language design, the total time spent discussing a feature in this list is proportional to two raised to the power of its position.
+> Em qualquer design de linguagem, o tempo total gasto discutindo a uma funcionalidade nessa lista é proporcional a dois elevados à potência de sua posição.
 > 
-> 0. Semantics
-> 1. Syntax
-> 2. Lexical syntax
-> 3. Lexical syntax of comments
-> 
-> (In short, for every hour spent on semantics, 8 hours will be spent on the syntax of comments).
+> 0. Semântica
+> 1. Sintaxe
+> 2. Sintaxe léxica
+> 3. Sintaxe léxica de comentários
+>
+> (Em resumo, para cada hora gasta em semântica, 8 horas serão gastas na sintaxe de comentários)
 
-Similar to [The Law of Triviality](#the-law-of-triviality), Wadler's Law states what when designing a language, the amount of time spent on language structures is disproportionately high in comparison to the importance of those features.
+Semelhante à [Lei da Trivialidade](#a-lei-da-trivialidade), a Lei de Wadler afirma que quando projetamos uma linguagem, o tempo gasto em estruturas é desproporcionalmente maior do que a imporância dessas funcionalidades.
 
-See also:
+Veja também:
 
 - [The Law of Triviality](#the-law-of-triviality)
 
@@ -501,11 +500,11 @@ See also:
 
 [The Official Day](https://dontbeadickday.com/)
 
-> Don't be a dick.
+> Não seja um babaca
 >
 > _Wil Wheaton_
 
-Coined by Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), this simple, concise, and powerful law aims for an increase in harmony and respect within a professional organization. It can be applied when speaking with coworkers, performing code reviews, countering other points of view, critiquing, and in general, most professional interactions humans have with each other.
+Cunhada por Wil Wheaton (Star Trek: The Next Generation, The Big Bang Theory), esta lei simples, concisa e poderosa visa aumentar a harmonia e o respeito dentro de uma organização profissional. Ela pode ser aplicada ao conversar com colegas de trabalho, ao efetuar code reviews, contrariar outros ponto de vista, criticar, e, em linhas gerais, na maioria das interações que os humanos mantém entre si.
 
 ## Princípios
 
@@ -515,52 +514,52 @@ Os princípios são como diretrizes relacionadas à design.
 
 [The Dilbert Principle on Wikipedia](https://en.wikipedia.org/wiki/Dilbert_principle)
 
-> Companies tend to systematically promote incompetent employees to management to get them out of the workflow.
+> Empresas tendem a promover sistematicamente funcionários incompetentes para a gerência para tirá-los do fluxo de trabalho.
 >
 > _Scott Adams_
 
-A management concept developed by Scott Adams (creator of the Dilbert comic strip), the Dilbert Principle is inspired by [The Peter Principle](#the-peter-principle). Under the Dilbert Principle, employees who were never competent are promoted to management in order to limit the damage they can do. Adams first explained the principle in a 1995 Wall Street Journal article, and expanded upon it in his 1996 business book, [The Dilbert Principle](#reading-list).
+Um conceito de gerência desenvolvido por Scott Adams (criador da tirinha Dilbert), o Princípio de Dilbert é inspirado pelo [Princípio de Peter](#o-princípio-de-peter). Sob o Princípio de Dilbert, funcionários que nunca foram competentes são promovidos para a gerência, para limitar o estrago que eles podem causar. Adams explicou esse princípio pela primeira vez um artigo no Wall Street Journal, em 1995, e o expandiu para seu livro de negócios em 1996, o [The Dilbert Principle](#lista-de-leitura).
 
-See Also:
+Veja também:
 
-- [The Peter Principle](#the-peter-principle)
-- [Putt's Law](#putts-law)
+- [Princípio de Peter](#o-princípio-de-peter)
+- [Lei de Putt](#lei-de-putt)
 
 ### O Princípio de Pareto (Regra do 80/20)
 
 [The Pareto Principle on Wikipedia](https://en.wikipedia.org/wiki/Pareto_principle)
 
-> Most things in life are not distributed evenly.
+> A maioria das coisas na vida não são distribuídas de maneira uniforme.
 
-The Pareto Principle suggests that in some cases, the majority of results come from a minority of inputs:
+O Princípio de Pareto sugere que em alguns casos, a maioria dos resultados vem de uma minoria de insumos:
 
-- 80% of a certain piece of software can be written in 20% of the total allocated time (conversely, the hardest 20% of the code takes 80% of the time)
-- 20% of the effort produces 80% of the result
-- 20% of the work creates 80% of the revenue
-- 20% of the bugs cause 80% of the crashes
-- 20% of the features cause 80% of the usage
+- 80% de um certo pedaço de software pode ser escrito em 20% do tempo total alocado (inversamente, os 20% mais difíceis do código levam 80% do tempo)
+- 20% do esforço produz 80% do resultado
+- 20% do trabalho cria 80% da receita
+- 20% dos bugs causam 80% das quebras
+- 20% das funcionalidades causam 80% da utilização
 
-In the 1940s American-Romanian engineer Dr. Joseph Juran, who is widely credited with being the father of quality control, [began to apply the Pareto principle to quality issues](https://en.wikipedia.org/wiki/Joseph_M._Juran).
+Nos anos 40 o engenheiro americano-romeno Dr. Joseph Juran, reconhecido como pai do controle de qualidade, [começou a aplicar o Princípio de Pareto a questões de qualidade]((https://en.wikipedia.org/wiki/Joseph_M._Juran)).
 
-This principle is also known as: The 80/20 Rule, The Law of the Vital Few and The Principle of Factor Sparsity.
+Este princípio é também conhecido como: A Regra do 80/20, A Lei dos Poucos Vitais e O Princípio de Escassez do Fator.
 
-Real-world examples:
+Exemplos do mundo real:
 
-- In 2002 Microsoft reported that by fixing the top 20% of the most-reported bugs, 80% of the related errors and crashes in windows and office would become eliminated ([Reference](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
+- Em 2002 a Microsoft reportou que corrigindo 20% dos erros mais reportados, 80% dos erros e quebras relacionadas no Windows e no Office foram eliminados ([Referência](https://www.crn.com/news/security/18821726/microsofts-ceo-80-20-rule-applies-to-bugs-not-just-features.htm)).
 
 ### O Princípio de Peter
 
 [The Peter Principle on Wikipedia](https://en.wikipedia.org/wiki/Peter_principle)
 
-> People in a hierarchy tend to rise to their "level of incompetence".
+> Pessoas em uma hierarquia tentem a subir ao seu "nível de incompetência".
 >
 > _Laurence J. Peter_
 
-A management concept developed by Laurence J. Peter, the Peter Principle observes that people who are good at their jobs are promoted, until they reach a level where they are no longer successful (their "level of incompetence"). At this point, as they are more senior, they are less likely to be removed from the organisation (unless they perform spectacularly badly) and will continue to reside in a role which they have few intrinsic skills at, as their original skills which made them successful are not necessarily the skills required for their new jobs.
+Um conceito de gerenciamento desenvolvido por Laurence J. Peter, o Princípio de Peter observa que as pessoas que são boas em seu emprego são promovidas até um nível onde elas não são mais bem-sucedidas (o "nível de incompetência"). Neste ponto, à medida em que são mais seniores, é menos provável que elas sejam removidas da organização (a não ser que elas performem de maneira horrível) e irão continuar a permanecer em uma função na qual possuem poucas habilidades intrínsecas, pois as habilidades originais que as fizeram bem-sucedidas não são necessariamente as mesmas que o novo cargo exige.  
 
-This is of particular interest to engineers - who initially start out in deeply technical roles, but often have a career path which leads to _managing_ other engineers - which requires a fundamentally different skills-set.
+Isso é de interesse particular para engenheiros - que inicialmente começam em funções técnicas mas tem uma carreira que leva ao _gerenciamento_ de outros engenheiros - o que requer um conjunto de habilidades fundamentalmente diferente.
 
-See Also:
+Veja também:
 
 - [The Dilbert Principle](#the-dilbert-principle)
 - [Putt's Law](#putts-law)
@@ -569,11 +568,11 @@ See Also:
 
 [The Robustness Principle on Wikipedia](https://en.wikipedia.org/wiki/Robustness_principle)
 
-> Be conservative in what you do, be liberal in what you accept from others.
+> Seja conservador naquilo que você faz, seja liberal naquilo que você aceita dos outros.
 
-Often applied in server application development, this principle states that what you send to others should be as minimal and conformant as possible, but you should be aim to allow non-conformant input if it can be processed.
+Geralmente aplicado no desenvolvimento de aplicativos para servidor, esse princípio afirma que o que você envia para outras pessoas deve ser o mínimo compatível possível, mas que você deve ter como objetivo permitir entradas fora de conformidade, se puderem ser processadas.
 
-The goal of this principle is to build systems which are robust, as they can handle poorly formed input if the intent can still be understood. However, there are potentially security implications of accepting malformed input, particularly if the processing of such input is not well tested.
+O objetivo desse princípio é construir sistemas que são robustos, pois eles conseguem lidar com dados mal formatados se a intenção ainda puder ser entendida. No entanto, há potenciais implicações de segurança na aceitação de entradas mal formatadas, principalmente se o processamento dessas entradas não for bem testado.
 
 ### SOLID
 
@@ -585,19 +584,19 @@ The goal of this principle is to build systems which are robust, as they can han
 * I: [The Interface Segregation Principle](#the-interface-segregation-principle)
 * D: [The Dependency Inversion Principle](#the-dependency-inversion-principle)
 
-These are key principles in [Object-Oriented Programming](#todo). Design principles such as these should be able to aid developers build more maintainable systems.
+Esses são os princípios-chave da [Programação Orientada a Objetos](#todo). Os princípios de design como esses devem ajudar os desenvolvedores a criarem sistemas mais sustentáveis.
 
 ### O Princípio da Responsabilidade Única
 
 [The Single Responsibility Principle on Wikipedia](https://en.wikipedia.org/wiki/Single_responsibility_principle)
 
-> Every module or class should have a single responsibility only.
+> Cada módulo ou classe deve possuir apenas uma única responsabilidade.
 
-The first of the '[SOLID](#solid)' principles. This principle suggests that modules or classes should do one thing and one thing only. In more practical terms, this means that a single, small change to a feature of a program should require a change in one component only. For example, changing how a password is validated for complexity should require a change in only one part of the program.
+O primeiro dos princípios '[SOLID](#solid)'. Esse princípio sugere que módulos ou classes devem fazer apenas uma única coisa. Em termos mais práticos, isso significa que uma mudança simples a uma funcionalidade de um programa deve exigir uma mudança em apenas um componente. Por exemplo, mudar como uma senha é validada por complexidade deve exigir uma mudança em apenas uma parte do programa.
 
-Theoretically, this should make the code more robust, and easier to change. Knowing that a component which is being changed has a single responsibility only means that _testing_ that change should be easier. Using the earlier example, changing the password complexity component should only be able to affect the features which relate to password complexity. It can be much more difficult to reason about the impact of a change to a component which has many responsibilities.
+Teoricamente, isso deve tornar o código mais robusto, e fácil de ser mudado. Sabendo que um componente que está sendo alterado possui apenas uma responsabilidade siginfica que o _teste_ deverá ser mais fácil. Usando o exemplo anterior, trocar a complexidade do componente de senha deve afetar apenas as funcionalidades que são relacionadas com a complexidade de senha. Pode ser muito mais difícil argumentar sobre o impacto de uma alteração em um componente que tem muitas responsabilidades.
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
@@ -606,15 +605,15 @@ See also:
 
 [The Open/Closed Principle on Wikipedia](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle)
 
-> Entities should be open for extension and closed for modification.
+> Entidades devem estar aberta para extensão e fechadas para modificação
 
-The second of the '[SOLID](#solid)' principles. This principle states that entities (which could be classes, modules, functions and so on) should be able to have their behaviour _extended_, but that their _existing_ behaviour should not be able to be modified.
+O segundo princípio do '[SOLID](#solid)'. Esse princípio afirma que entidades (que podem ser classes, módulos, funções e afins) poderão ter seu comportamento _extendido_, mas que o comportamento já existente não poderá ser alterado.
 
-As a hypothetical example, imagine a module which is able to turn a Markdown document into HTML. If the module could be extended to handle a newly proposed markdown feature, without modifying the module internals, then it would be open for extension. If the module could _not_ be modified by a consumer so that how existing Markdown features are handled, then it would be _closed_ for modification.
+Em um exemplo hipotético, imagine um módulo que converte um documento Markdown para HTML. Se o módulo pode ser extendido para aceitar uma nova funcionalidade do markdown, sem modificar a parte interna desse módulo, quer dizer que ele está aberto para extensões. Se o módulo _não_ pode ser modificado por um consumidor, de modo que as funcionalidades existentes do markdown sejam tratadas, então ele estará _fechado_ para modificações.
 
-This principle has particular relevance for object-oriented programming, where we may design objects to be easily extended, but would avoid designing objects which can have their existing behaviour changed in unexpected ways.
+Esse princípio tem uma relevância particular na orientação a objetos, onde nós projetamos objetos para serem facilmente extendidos, mas evitamos projetar objetos onde o comportamento existente pode ser alterado de maneiras inesperadas.
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
@@ -623,15 +622,15 @@ See also:
 
 [The Liskov Substitution Principle on Wikipedia](https://en.wikipedia.org/wiki/Liskov_substitution_principle)
 
-> It should be possible to replace a type with a subtype, without breaking the system.
+> Deve ser possível trocar um tipo por um subtipo, sem o sistema apresentar quebras.
 
-The third of the '[SOLID](#solid)' principles. This principle states that if a component relies on a type, then it should be able to use subtypes of that type, without the system failing or having to know the details of what that subtype is.
+O terceiro princípio '[SOLID](#solid)'. O princípio afirma que se um componente confia em um tipo, então ele deverá estar apto para utilizar subtipos daquele tipo, sem que o sistema falhe ou que ele conheça os detalhes daquele subtipo.
 
-As an example, imagine we have a method which reads an XML document from a structure which represents a file. If the method uses a base type 'file', then anything which derives from 'file' should be able to be used in the function. If 'file' supports seeking in reverse, and the XML parser uses that function, but the derived type 'network file' fails when reverse seeking is attempted, then the 'network file' would be violating the principle.
+Como um exemplo, imagine que temos um método que lê um documento XML de uma estrutura que representa um arquivo. Se o método utiliza a base de um tipo 'arquivo', então qualquer coisa que seja derivada de 'arquivo' poderá ser utilizada na função. Se 'arquivo' suporta busca recursiva, e o interpretador de XML utiliza essa função, mas o tipo derivado 'arquivo de rede' falha quando tenta uma busca recursiva, então o tipo 'arquivo de rede' estaria violando o princípio.
 
-This principle has particular relevance for object-oriented programming, where type hierarchies must be modeled carefully to avoid confusing users of a system.
+Esse princípio tem uma relevância particular na orientação a objetos, onde as hierarquias de tipos precisam ser modeladas com cautela para envitar confusão entre usuaríos do sistema.
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
@@ -640,15 +639,15 @@ See also:
 
 [The Interface Segregation Principle on Wikipedia](https://en.wikipedia.org/wiki/Interface_segregation_principle)
 
-> No client should be forced to depend on methods it does not use.
+> Nenhum cliente deverá ser forçado a depender de métodos que ele não utilize.
 
-The fourth of the '[SOLID](#solid)' principles. This principle states that consumers of a component should not depend on functions of that component which it doesn't actually use.
+O quarto princípio do '[SOLID](#solid)'. Esse princípio afirma que os consumidores de um componente não devem depender de funções daquele componente, as quais eles atualmente não usem.
 
-As an example, imagine we have a method which reads an XML document from a structure which represents a file. It only needs to read bytes, move forwards or move backwards in the file. If this method needs to be updated because an unrelated feature of the file structure changes (such as an update to the permissions model used to represent file security), then the principle has been invalidated. It would be better for the file to implement a 'seekable-stream' interface, and for the XML reader to use that.
+Como um exemplo, imagine que um método lê um documento XML de uma estutura que representa um arquivo. O método apenas precisa ler os bytes, ir para frente ou para trás no arquivo. Se esse método precisar ser atualizado porque um recurso não relacionado da estrutura do arquivo é alterado (como uma atualização no modelo de permissões utilizado para representar a segurança do arquivo), o princípio foi invalidado. 
 
-This principle has particular relevance for object-oriented programming, where interfaces, hierarchies and abstract types are used to [minimise the coupling](#todo) between different components. [Duck typing](#todo) is a methodology which enforces this principle by eliminating explicit interfaces.
+Esse princípio tem uma relevância particular na orientação a objetos, onde interfaces, hierarquias e tipos abstratos são utilizados para [minimizar o acomplamento](#todo) entre componentes diferentes. [Duck typing]() é uma metodologia que enforça esse princípio, eliminando interfaces explícitas.
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
@@ -659,15 +658,15 @@ See also:
 
 [The Dependency Inversion Principle on Wikipedia](https://en.wikipedia.org/wiki/Dependency_inversion_principle)
 
-> High-level modules should not be dependent on low-level implementations.
+> Módulos de alto nível não devem ser dependentes de implementações de baixo nível.
 
-The fifth of the '[SOLID](#solid)' principles. This principle states that higher level orchestrating components should not have to know the details of their dependencies.
+O quinto conceito do '[SOLID](#solid)'. Esse princípio afirma que componentes 
 
-As an example, imagine we have a program which read metadata from a website. We would assume that the main component would have to know about a component to download the webpage content, then a component which can read the metadata. If we were to take dependency inversion into account, the main component would depend only on an abstract component which can fetch byte data, and then an abstract component which would be able to read metadata from a byte stream. The main component would not know about TCP/IP, HTTP, HTML, etc.
+Como um exemplo, imagine que temos um programa que lê os metadados de um website. Nós devemos assumir que o componente principal precisa conhecer um componente que irá baixar a página, depois um outro componente que irá ler os metadados. Se fôssemos levar a inversão de dependências em conta, o componente principal deveria depender apenas de um componente abstrato que pode buscar pelos bytes, e depois outro componente abstrato que irá ler os metadados de um fluxo de bytes. O componente principal não sabe nada sobre TCP/IP, HTTP, HTML, etc.
 
-This principle is complex, as it can seem to 'invert' the expected dependencies of a system (hence the name). In practice, it also means that a separate orchestrating component must ensure the correct implementations of abstract types are used (e.g. in the previous example, _something_ must still provide the metadata reader component a HTTP file downloader and HTML meta tag reader). This then touches on patterns such as [Inversion of Control](#todo) and [Dependency Injection](#todo).
+Esse princípio é complexo, pois pode "inverter" as dependências esperadas de um sistema (daí o nome). Na prática, isso também significa que um componente de orquestração separado deve garantir que as implementações corretas dos tipos abstratos sejam usadas (por exemplo, no caso anterior, _algo_ ainda deve fornecer ao componente de leitura dos de metadados um downloader de arquivos HTTP e um leitor de metatags HTML). Isso toca em padrões como [Inversão de controle](#todo) e [Injeção de dependência](#todo).
 
-See also:
+Veja também:
 
 - [Object-Oriented Programming](#todo)
 - [SOLID](#solid)
@@ -678,15 +677,15 @@ See also:
 
 [The DRY Principle on Wikipedia](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself)
 
-> Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
+> Cada pedaço de código deve possuir uma representação única, inequívoca e autoritária dentro de um sistema.
 
-DRY is an acronym for _Don't Repeat Yourself_. This principle aims to help developers reducing the repetition of code and keep the information in a single place and was cited in 1999 by Andrew Hunt and Dave Thomas in the book [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
+DRY é um acrônimo para _**D**on't **R**epeat **Y**ourself_ (Não repita você mesmo). Esse princípio ajuda os desenvolvedores a reduzir a repetição de código e manter a informação em um único lugar. Foi citado em 1999 por Andrew Hunt e Dave Thomas no livro [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer).
 
-> The opposite of DRY would be _WET_ (Write Everything Twice or We Enjoy Typing).
+> O oposto de DRY seria WET (Write Everything Twice or We Enjoy Typing) - (Escreva tudo duas vezes ou Nós gostamos de digitar).
 
-In practice, if you have the same piece of information in two (or more) different places, you can use DRY to merge them into a single one and reuse it wherever you want/need.
+Na prática, se você tem o mesmo pedaço de informação em dois (ou mais) lugares diferentes, você pode utilizar o DRY para centralizá-los em um único lugar, e reutilizar a informação onde necessário.
 
-See also:
+Veja também:
 
 - [The Pragmatic Developer](https://en.wikipedia.org/wiki/The_Pragmatic_Programmer)
 
@@ -694,56 +693,56 @@ See also:
 
 [KISS on Wikipedia](https://en.wikipedia.org/wiki/KISS_principle)
 
-> Keep it simple, stupid
+> Mantenha simples, idiota
 
-The KISS principle states that most systems work best if they are kept simple rather than made complicated; therefore, simplicity should be a key goal in design, and unnecessary complexity should be avoided.  Originating in the U.S. Navy in 1960, the phrase has been associated with aircraft engineer Kelly Johnson.
+KISS é um acrônimo para _**K**eep **i**t **s**imple, **s**tupid_. O princípio afirma que a maioria dos sistemas trabalham melhor se eles são mantidos simples ao invés de complicados. Portanto, simplicidade deve ser um objetivo no design, e complexidades desnecessárias devem ser evitadas. Originada na Marinha Americana em 1960, a frase foi associada com o engenheiro de aeronaves Kelly Johnson.
 
-The principle is best exemplified by the story of Johnson handing a team of design engineers a handful of tools, with the challenge that the jet aircraft they were designing must be repairable by an average mechanic in the field under combat conditions with only these tools. Hence, the "stupid" refers to the relationship between the way things break and the sophistication of the tools available to repair them, not the capabilities of the engineers themselves. 
+O princípio é melhor exemplificado pela história de Johnson entregando a uma equipe de engenheiros de projeto algumas ferramentas, com o desafio de que as aeronaves a jato que estavam projetando deveriam ser reparadas por um mecânico comum em campo sob condições de combate apenas com essas ferramentas. Portanto, o "estúpido" refere-se à relação entre a maneira como as coisas quebram e a sofisticação das ferramentas disponíveis para repará-las, e não as capacidades dos próprios engenheiros.
 
-See also:
+Veja também:
 
-- [Gall's Law](#galls-law)
+- [Lei de Gall](#lei-de-gall)
 
 ### YAGNI
 
 [YAGNI on Wikipedia](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it)
 
-This is an acronym for _**Y**ou **A**ren't **G**onna **N**eed **I**t_.
+É um acrônimo para _**Y**ou **A**ren't **G**onna **N**eed **I**t_ - Você não vai precisar disto.
 
-> Always implement things when you actually need them, never when you just foresee that you need them.
+> Sempre implemente as coisas quando você de fato precisar delas, nunca quando você prevê que precisará delas.
 >
-> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder and author of the book "Extreme Programming Installed")
+> ([Ron Jeffries](https://twitter.com/RonJeffries)) (XP co-founder e autor do livro "Extreme Programming Installed")
 
-This _Extreme Programming_ (XP) principle suggests developers should only implement functionality that is needed for the immediate requirements, and avoid attempts to predict the future by implementing functionality that might be needed later.
+Este princípio da _Extreme Programming_ (XP) sugere que os desenvolvedores apenas devem implementar funcionalidades quando elas forem necessárias, e evitar tentativas de prever o futuro e implementar uma funcionalidade que talvez seja necessária.
 
-Adhering to this principle should reduce the amount of unused code in the codebase, and avoid time and effort being wasted on functionality that brings no value.
+Aderir a esse princípio deve reduzir a quantidade de código não utilizado em um projeto, e evitar tempo e esforço sendo disperdiçados em funcionalidades que não agregam valor.
 
-See also:
+Veja também:
 
-- [Reading List: Extreme Programming Installed](#reading-list)
+- [Reading List: Extreme Programming Installed](#lista-de-leitura)
 
 ### As Falácias da Computação Distribuída
 
 [The Fallacies of Distributed Computing on Wikipedia](https://en.wikipedia.org/wiki/Fallacies_of_distributed_computing)
 
-Also known as _Fallacies of Networked Computing_, the Fallacies are a list of conjectures (or beliefs) about distributed computing, which can lead to failures in software development. The assumptions are:
+Também conhecidas como as _Falácias da Computação em rede_, as Falácias são uma lista de conjecturas (ou crenças) sobre a computação distribuídas, que podem levar a falhas no desenvolvimento de software. As suposições são:
 
-- The network is reliable
-- Latency is zero
-- Bandwidth is infinite
-- The network is secure
-- Topology doesn't change
-- There is one administrator
-- Transport cost is zero
-- The network is homogeneous
+- A rede é confiável
+- A latência é zero
+- A largura de banda é infinita
+- A rede é segura
+- A topologia não muda
+- Existe apenas um administrador
+- Custo de transporte é zero
+- A rede é homogênea
 
-The first four items were listed by [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) and [Tom Lyon](https://twitter.com/aka_pugs) around 1991 and first classified by [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) as the "Fallacies of Networked Computing". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) added the 5th, 6th and 7th fallacies. In the late 90's Gosling added the 8th fallacy.
+Os primeiro quatro itens foram listados por [Bill Joy](https://en.wikipedia.org/wiki/Bill_Joy) e [Tom Lyon](https://twitter.com/aka_pugs) por volta de 1991, e foram classificados por [James Gosling](https://en.wikipedia.org/wiki/James_Gosling) como as "Falácias da Computação de rede". [L. Peter Deutsch](https://en.wikipedia.org/wiki/L._Peter_Deutsch) adicionou os itens 5, 6 e 7. No final dos anos 90, Gosling adicionou o item 8.
 
-The group were inspired by what was happening at the time inside [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
+O grupo foi inspirado pela situação que corria na época dentro da [Sun Microsystems](https://en.wikipedia.org/wiki/Sun_Microsystems).
 
-These fallacies should be considered carefully when designing code which is resilient; assuming any of these fallacies can lead to flawed logic which fails to deal with the realities and complexities of distributed systems.
+Essas falácias devem ser consideradas com cuidado ao projetar um código que seja resiliente; supondo que qualquer uma dessas falácias possa levar a uma lógica defeituosa que falha em lidar com as realidades e complexidades dos sistemas distribuídos
 
-See also:
+Veja também:
 
 - [Foraging for the Fallacies of Distributed Computing (Part 1) - Vaidehi Joshi
  on Medium](https://medium.com/baseds/foraging-for-the-fallacies-of-distributed-computing-part-1-1b35c3b85b53)
@@ -752,38 +751,40 @@ See also:
 ## Lista de leitura
 
 
-If you have found these concepts interesting, you may enjoy the following books.
+Se você achou esses conceitos interessantes, você provavelmente vai gostar dos seguintes livros.
 
-- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Covers the core principles of Extreme Programming.
-- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - A classic volume on software engineering. [Brooks' Law](#brooks-law) is a central theme of the book.
-- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - This book is difficult to classify. [Hofstadter's Law](#hofstadters-law) is from the book.
-- [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - A comic look at corporate America, from the author who created the [Dilbert Principle](#the-dilbert-principle).
-- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Another comic look at the challenges of larger organisations and people management, the source of [The Peter Principle](#the-peter-principle).
+- [Extreme Programming Installed - Ron Jeffries, Ann Anderson, Chet Hendrikson](https://www.goodreads.com/en/book/show/67834) - Cobre os principais princípios do Extreme Programming.
+- [The Mythical Man Month - Frederick P. Brooks Jr.](https://www.goodreads.com/book/show/13629.The_Mythical_Man_Month) - Um volume clássico na engenharia de software. A [Lei de Brook](#brooks-law) é o tema central desse livro.
+- [Gödel, Escher, Bach: An Eternal Golden Braid - Douglas R. Hofstadter.](https://www.goodreads.com/book/show/24113.G_del_Escher_Bach) - Esse livre é difícil de classificar. A [Lei de Hofstadter](#hofstadters-law) é desse livro.
+- [The Dilbert Principle - Scott Adams](https://www.goodreads.com/book/show/85574.The_Dilbert_Principle) - Um olhar cômico sobre a América corporativa, do autor que criou o [Princípio Dilbert](#the-dilbert-principle).
+- [The Peter Principle - Lawrence J. Peter](https://www.goodreads.com/book/show/890728.The_Peter_Principle) - Outro olhar cômico sobre os desafios de grandes organizações e sobre a gestão de pessoas, a fonte do [Princípio de Peter](#the-peter-principle).
 
 ## Traduções
 
-Thanks to a number of wonderful contributors, Hacker Laws is available in a number of languages. Please consider sponsoring moderators!
+Graças a contribuidores maravilhosos, Hacker Laws está disponível em vários idiomas. Por favor, considere em patrocinar os moderadores!
 
-| Language | Moderator | Status |
+| Idioma   | Moderador | Status |
 |----------|-----------|--------|
-| [🇧🇷 Brasileiro / Brazilian](./translations/pt-BR.md) | [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge) |
-| [🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Partially complete |
+| [🇮🇩 Bahasa Indonesia / Indonesian](./translations/pt-BR.md) | [arywidiantara](https://github.com/arywidiantara) | [![gitlocalized ](https://gitlocalize.com/repo/2513/id/badge.svg)](https://gitlocalize.com/repo/2513/id?utm_source=badge) |
+| [🇧🇷 Português Brasileiro / Brazilian Portuguese](./translations/pt-BR.md) | [Eugênio Moreira](https://github.com/eugenioamn), [Leonardo Costa](https://github.com/leofc97) | [![gitlocalized ](https://gitlocalize.com/repo/2513/pt-BR/badge.svg)](https://gitlocalize.com/repo/2513/pt-BR?utm_source=badge) |
+| [🇨🇳 中文 / Chinese](https://github.com/nusr/hacker-laws-zh) | [Steve Xu](https://github.com/nusr) | Parcialmente completa |
 | [🇩🇪 Deutsch / German](./translations/de.md) | [Vikto](https://github.com/viktodergunov) | [![gitlocalized ](https://gitlocalize.com/repo/2513/de/badge.svg)](https://gitlocalize.com/repo/2513/de?utm_source=badge) |
 | [🇫🇷 Français / French](./translations/fr.md) | [Kevin Bockelandt](https://github.com/KevinBockelandt) | [![gitlocalized ](https://gitlocalize.com/repo/2513/fr/badge.svg)](https://gitlocalize.com/repo/2513/fr?utm_source=badge) |
 | [🇬🇷 ελληνικά / Greek](./translations/el.md) | [Panagiotis Gourgaris](https://github.com/0gap) | [![gitlocalized ](https://gitlocalize.com/repo/2513/el/badge.svg)](https://gitlocalize.com/repo/2513/el?utm_source=badge) |
-| [🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Partially complete |
-| [🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Partially complete |
+| [🇮🇹 Italiano / Italian](https://github.com/csparpa/hacker-laws-it) | [Claudio Sparpaglione](https://github.com/csparpa) | Parcialmente completa |
+| [🇯🇵 JP 日本語 / Japanese](./translations/jp.md) | [Fumikazu Fujiwara](https://github.com/freddiefujiwara)| [![gitlocalized ](https://gitlocalize.com/repo/2513/ja/badge.svg)](https://gitlocalize.com/repo/2513/ja?utm_source=badge) |
+| [🇰🇷 한국어 / Korean](https://github.com/codeanddonuts/hacker-laws-kr) | [Doughnut](https://github.com/codeanddonuts) | Parcialmente completa |
 | [🇱🇻 Latviešu Valoda / Latvian](./translations/lv.md) | [Arturs Jansons](https://github.com/iegik) | [![gitlocalized ](https://gitlocalize.com/repo/2513/lv/badge.svg)](https://gitlocalize.com/repo/2513/lv?utm_source=badge) |
-| [🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Partially complete |
-| [🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Partially complete |
+| [🇷🇺 Русская версия / Russian](https://github.com/solarrust/hacker-laws) | [Alena Batitskaya](https://github.com/solarrust) | Parcialmente completa |
+| [🇪🇸 Castellano / Spanish](./translations/es-ES.md) | [Manuel Rubio](https://github.com/manuel-rubio) ([Sponsor](https://github.com/sponsors/manuel-rubio)) | Parcialmente completa |
 | [🇹🇷 Türkçe / Turkish](https://github.com/umutphp/hacker-laws-tr) | [Umut Işık](https://github.com/umutphp) | [![gitlocalized ](https://gitlocalize.com/repo/2513/tr/badge.svg)](https://gitlocalize.com/repo/2513/tr?utm_source=badge) |
 
-If you would like to update a translation, just [open a pull request](https://github.com/dwmkerr/hacker-laws/pulls). If you want to add a new language, log onto [GitLocalize](https://gitlocalize.com/) to create an account, then open an issue asking to administer the language and I will add you to the project! It would also be super helpful if you can open a pull request which updates the table above and link at the top of the file.
+Se você quer atualizar uma tradução, [abra uma pull request](https://github.com/dwmkerr/hacker-laws/compare). Se você quer adicionar um novo idioma, crie uma conta no [GitLocalize](https://gitlocalize.com/), depois abra uma issue pedindo ao administrador o idioma eu irei adicionar você no projeto! Seria muito útil se você conseguir abrir uma pull request que atualiza a tabela acima, adicionando link ao topo do arquivo.
 
 ## Projetos relacionados
 
-- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receive a daily hacker law/principle.
-- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - List, view and see random laws from the terminal!
+- [Tip of the Day](https://tips.darekkay.com/html/hacker-laws-en.html) - Receba diaramente uma lei ou princípio hacker.
+- [Hacker Laws CLI](https://github.com/umutphp/hacker-laws-cli) - Liste e visualize as leis de maneira aleatória no seu terminal!
 
 ## Contribuindo