From 361b6dd2b4be34a69a161c89f9dcf7ae532342dc Mon Sep 17 00:00:00 2001 From: Webysther Nunes Date: Fri, 13 Oct 2017 15:22:45 -0300 Subject: [PATCH] Suggestions of @brauliobz applied --- source/pt-BR/1.0.0/index.html.haml | 45 +++++++++++++++--------------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/source/pt-BR/1.0.0/index.html.haml b/source/pt-BR/1.0.0/index.html.haml index d150966..af25402 100644 --- a/source/pt-BR/1.0.0/index.html.haml +++ b/source/pt-BR/1.0.0/index.html.haml @@ -89,10 +89,10 @@ version: 1.0.0 para novos recursos. %li %code Changed/Modificado - for changes in existing functionality. + para alterações em recursos existentes. %li %code Deprecated/Obsoleto - para funcionalidades que serão removidas nas próximas versões. + para recursos que serão removidos nas próximas versões. %li %code Removed/Removido para recursos removidos nesta versão. @@ -134,7 +134,7 @@ version: 1.0.0 Usar um registro de alterações automático %p - Usar um registro de alterações automático é uma má idéia: eles estão + Usar um registro de alterações automático é uma má ideia: eles estão cheios de bagunça. Coisas como solicitação de mesclagem, envio com títulos estranhos, alterações de documentação, etc. @@ -152,14 +152,14 @@ version: 1.0.0 Ignorando depreciações %p - Quando pessoas atualizam de uma versão para outra, deve ser dolorosamente - claro quando algo vai quebrar. Deve ser possível atualizar para uma versão + Quando pessoas atualizam de uma versão para outra, deve ficar muitíssimo claro + quando algo vai quebrar. Deve ser possível atualizar para uma versão com depreciações listadas, remova o que é obsoleto, depois atualize para a versão onde as depreciações se tornam remoções. %p - Se você não fizer mais nada, liste as depreciações, remoções e quaisquer - mudanças de quebra no seu changelog. + Se você não fizer mais nada, liste no seu changelog as depreciações, + remoções e quaisquer mudanças que gerem falhas. %h4#confusing-dates %a.anchor{ href: "#confusing-dates", aria_hidden: "true" } @@ -170,10 +170,10 @@ version: 1.0.0 é difícil encontrar um formato de data amigável que seja intuitivo para todos. A vantagem das datas formatadas como 2017-07-17 é que elas seguem a ordem da maior para a menor unidade de tempo: ano, mês e dia. Este formato - também não se sobrepôem de maneira ambígua como em outros formatos de data, ao + também não se confunde de maneira ambígua com outros formatos de data, ao contrário de alguns formatos regionais que alteram a posição dos números do mês - e dia. Esses motivos, e o fato de ser um formato de data suportado pelo - #{link_to "ISO standard", iso} são as razões para ele ser o formato de data + e dia. Esses motivos, e o fato de ser um formato de data suportado pela + #{link_to "norma ISO", iso} são as razões para ele ser o formato de data recomendado para as entradas do changelog. %aside @@ -232,14 +232,14 @@ version: 1.0.0 GitHub Releases cria um changelog não portátil que só pode ser exibido para usuários no contexto do GitHub. É possível fazê-los parecer muito como o formato - Keep a Changelog, mas tende a estar um pouco mais envolvido. + Keep a Changelog, mas tende a ser um pouco mais complicado. %p - A versão atual do GitHub Releases não são facilmente + A versão atual do GitHub Releases não é facilmente descoberta por usuários finais, ao contrário dos arquivos maiúsculos típicos (README, CONTRIBUTING, etc.). Outro - problema menor é que a interface atualmente não oferece links para - confirmar alterações entre cada lançamento. + problema de menor magnitude é que a interface atualmente não oferece + links para confirmar alterações entre cada lançamento. %h4#automatic %a.anchor{ href: "#automatic", aria_hidden: "true" } @@ -268,22 +268,23 @@ version: 1.0.0 %p O marcador [REMOVIDO] está em caixa alta por uma razão. - É importante que as pessoas o percebam. Uma vez que está entre - colchetes é fácil de ser analisado programaticamente. + É importante que as pessoas o percebam. Já que está entre + colchetes, também fica mais fácil de ser analisado programaticamente. %h4#rewrite %a.anchor{ href: "#rewrite", aria_hidden: "true" } Você deve reescrever um changelog? %p - Claro. Sempre existe razão para melhorar um changelog. Eu - regularmente solicito uma alteração em projetos de código livre - para adicionar changelogs não mantidos. + Claro. Sempre existe razão para melhorar um changelog. + Eu regularmente solicito alterações em projetos de código livre que + possuem changelogs não mantidos para adicionar lançamentos + que não estão presentes nestes. %p Também é possível que você descubra que você esqueceu de abordar uma mudança abrupta nas notas para uma versão. - Obviamente é importante para você atualizar seu changelog neste caso. + Obviamente é importante que você atualize seu changelog neste caso. %h4#contribute %a.anchor{ href: "#contribute", aria_hidden: "true" } @@ -295,7 +296,7 @@ version: 1.0.0 exemplos que eu reuni. %p - Isso é porque eu quero que nossa comunidade chegue a um consenso. + Isso porque o que eu quero é que nossa comunidade chegue a um consenso. Eu acredito que a discussão é tão importante quanto o resultado final. %p @@ -304,7 +305,7 @@ version: 1.0.0 .press %h3 Discussões %p - Eu fui em #{link_to "The Changelog podcast", thechangelog} + Eu fui no #{link_to "The Changelog podcast", thechangelog} para falar sobre por que os mantenedores e contribuidores devem se preocupar com os changelogs, e também sobre as motivações por trás desse projeto.