From 90368b88332145378f8cfaee64a82db75fe92c6f Mon Sep 17 00:00:00 2001
From: Steven Wang <steven.guan.wang@gmail.com>
Date: Sun, 25 Jun 2017 11:48:26 +1000
Subject: [PATCH 1/6] Create index.html.haml

---
 source/zh-CN/1.0.0/index.html.haml | 300 +++++++++++++++++++++++++++++
 1 file changed, 300 insertions(+)
 create mode 100644 source/zh-CN/1.0.0/index.html.haml

diff --git a/source/zh-CN/1.0.0/index.html.haml b/source/zh-CN/1.0.0/index.html.haml
new file mode 100644
index 0000000..5bd7ce5
--- /dev/null
+++ b/source/zh-CN/1.0.0/index.html.haml
@@ -0,0 +1,300 @@
+---
+description: Keep a Changelog
+title: Keep a Changelog
+language: en
+version: 1.0.0
+---
+
+- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md"
+- gemnasium = "https://gemnasium.com/"
+- gh = "https://github.com/olivierlacan/keep-a-changelog"
+- issues = "https://github.com/olivierlacan/keep-a-changelog/issues"
+- semver = "http://semver.org/"
+- shields = "http://shields.io/"
+- thechangelog = "http://5by5.tv/changelog/127"
+- vandamme = "https://github.com/tech-angels/vandamme/"
+- iso = "http://www.iso.org/iso/home/standards/iso8601.htm"
+- ghr = "https://help.github.com/articles/creating-releases/"
+
+.header
+  .title
+    %h1 Keep a Changelog
+    %h2 Don’t let your friends dump git logs into changelogs.
+
+  = link_to changelog do
+    Version
+    %strong= current_page.metadata[:page][:version]
+
+  %pre.changelog= File.read("CHANGELOG.md")
+
+.answers
+  %h3#what
+    %a.anchor{ href: "#what", aria_hidden: "true" }
+    What is a changelog?
+
+  %p
+    A changelog is a file which contains a curated, chronologically
+    ordered list of notable changes for each version of a project.
+
+  %h3#why
+    %a.anchor{ href: "#why", aria_hidden: "true" }
+    Why keep a changelog?
+
+  %p
+    To make it easier for users and contributors to see precisely what
+    notable changes have been made between each release (or version) of
+    the project.
+
+  %h3#who
+    %a.anchor{ href: "#who", aria_hidden: "true" }
+    Who needs a changelog?
+
+  %p
+    People do. Whether consumers or developers, the end users of
+    software are human beings who care about what's in the software. When
+    the software changes, people want to know why and how.
+
+.good-practices
+  %h3#how
+    %a.anchor{ href: "#how", aria_hidden: "true" }
+    How do I make a good changelog?
+
+  %h4#principles
+    %a.anchor{ href: "#principles", aria_hidden: "true" }
+    Guiding Principles
+
+  %ul
+    %li
+      Changelogs are <em>for humans</em>, not machines.
+    %li
+      There should be an entry for every single version.
+    %li
+      The same types of changes should be grouped.
+    %li
+      Versions and sections should be linkable.
+    %li
+      The latest version comes first.
+    %li
+      The release date of each versions is displayed.
+    %li
+      Mention whether you follow #{link_to "Semantic Versioning", semver}.
+
+  %a.anchor{ href: "#types", aria_hidden: "true" }
+  %h4#types Types of changes
+
+  %ul
+    %li
+      %code Added
+      for new features.
+    %li
+      %code Changed
+      for changes in existing functionality.
+    %li
+      %code Deprecated
+      for soon-to-be removed features.
+    %li
+      %code Removed
+      for now removed features.
+    %li
+      %code Fixed
+      for any bug fixes.
+    %li
+      %code Security
+      in case of vulnerabilities.
+
+.effort
+
+  %h3#effort
+    %a.anchor{ href: "#effort", aria_hidden: "true" }
+    How can I reduce the effort required to maintain a changelog?
+
+  %p
+    Keep an <code>Unreleased</code> section at the top to track upcoming
+    changes.
+
+  %p This serves two purposes:
+
+  %ul
+    %li
+      People can see what changes they might expect in upcoming releases
+    %li
+      At release time, you can move the <code>Unreleased</code> section
+      changes into a new release version section.
+
+.bad-practices
+  %h3#bad-practices
+    %a.anchor{ href: "#bad-practices", aria_hidden: "true" }
+    Can changelogs be bad?
+  %p Yes. Here are a few ways they can be less than useful.
+  %h4#log-diffs
+    %a.anchor{ href: "#log-diffs", aria_hidden: "true" }
+    Commit log diffs
+
+  %p
+    Using commit log diffs as changelogs is a bad idea: they're full of
+    noise. Things like merge commits, commits with obscure titles,
+    documentation changes, etc.
+
+  %p
+    The purpose of a commit is to document a step in the evolution of
+    the source code. Some projects clean up commits, some don't.
+
+  %p
+    The purpose of a changelog entry is to document the noteworthy
+    difference, often across multiple commits, to communicate them
+    clearly to end users.
+
+  %h4#ignoring-deprecations
+    %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
+    Ignoring Deprecations
+  %p
+    When people upgrade from one version to another, it should be
+    painfully clear when something will break. It should be possible to
+    upgrade to a version that lists deprecations, remove what's
+    deprecated, then upgrade to the version where the deprecations
+    become removals.
+  %p
+    If you do nothing else, list deprecations, removals, and any
+    breaking changes in your changelog.
+  %h4#confusing-dates
+    %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
+    Confusing Dates
+
+  %p
+    In the U.S., people put the month first (<code>06-02-2012</code> for
+    June 2nd, 2012), while many people in the rest of the world write a
+    robotic-looking <code>2 June 2012</code>, yet pronounce it
+    differently. <code>2012-06-02</code> works logically from largest to
+    smallest, doesn't overlap in ambiguous ways with other date formats,
+    and is an #{link_to "ISO standard", iso}. Thus, it is the
+    recommended date format for changelogs.
+
+  %aside
+    There’s more. Help me collect these antipatterns by
+    = link_to "opening an issue", issues
+    or a pull request.
+
+.frequently-asked-questions
+  %h3#frequently-asked-questions
+    %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
+    Frequently Asked Questions
+  %h4#standard
+    %a.anchor{ href: "#standard", aria_hidden: "true" }
+    Is there a standard changelog format?
+
+  %p
+    Not really. There's the GNU changelog style guide, or the two-
+    paragraph-long GNU NEWS file "guideline". Both are inadequate or
+    insufficient.
+
+  %p
+    This project aims to be
+    = link_to "a better changelog convention.", changelog
+    It comes from observing good practices in the open source
+    community and gathering them.
+
+  %p
+    Healthy criticism, discussion and suggestions for improvements
+    = link_to "are welcome.", issues
+
+
+  %h4#filename
+    %a.anchor{ href: "#filename", aria_hidden: "true" }
+    What should the changelog file be named?
+
+  %p
+    Call it <code>CHANGELOG.md</code>. Some projects use
+    <code>HISTORY</code>, <code>NEWS</code> or <code>RELEASES</code>.
+
+  %p
+    While it's easy to think that the name of your changelog file
+    doesn't matter that much, why make it harder for your end users to
+    consistently find notable changes?
+
+  %h4#github-releases
+    %a.anchor{ href: "#github-releases", aria_hidden: "true" }
+    What about GitHub Releases?
+  %p
+    It's a great initiative. #{link_to "Releases", ghr} can be used to
+    turn simple git tags (for example a tag named <code>v1.0.0</code>)
+    into rich release notes by manually adding release notes or it can
+    pull annotated git tag messages and turn them into notes.
+  %p
+    GitHub Releases create a non-portable changelog that can only be
+    displayed to users within the context of GitHub. It's possible to
+    make them look very much like the Keep a Changelog format, but it
+    tends to be a bit more involved.
+  %p
+    The current version of GitHub releases is also arguably not very
+    discoverable by end-users, unlike the typical uppercase files
+    (<code>README</code>, <code>CONTRIBUTING</code>, etc.). Another
+    minor issue is that the interface doesn't currently offer links to
+    commit logs between each release.
+  %h4#automatic
+    %a.anchor{ href: "#automatic", aria_hidden: "true" }
+    Can changelogs be automatically parsed?
+
+  %p
+    It’s difficult, because people follow wildly different formats and
+    file names.
+
+  %p
+    #{link_to "Vandamme", vandamme} is a Ruby gem created by the
+    #{link_to "Gemnasium", gemnasium} team and which parses many (but
+    not all) open source project changelogs.
+
+
+  %h4#yanked
+    %a.anchor{ href: "#yanked", aria_hidden: "true" }
+    What about yanked releases?
+
+  %p
+    Yanked releases are versions that had to be pulled because of a
+    serious bug or security issue. Often these versions don't even
+    appear in change logs. They should. This is how you should display
+    them:
+
+  %p <code>## 0.0.5 - 2014-12-13 [YANKED]</code>
+
+  %p
+    The <code>[YANKED]</code> tag is loud for a reason. It's important
+    for people to notice it. Since it's surrounded by brackets it's also
+    easier to parse programmatically.
+
+
+  %h4#rewrite
+    %a.anchor{ href: "#rewrite", aria_hidden: "true" }
+    Should you ever rewrite a changelog?
+
+  %p
+    Sure. There are always good reasons to improve a changelog. I
+    regularly open pull requests to add missing releases to open source
+    projects with unmaintained changelogs.
+
+  %p
+    It's also possible you may discover that you forgot to address a
+    breaking change in the notes for a version. It's obviously important
+    for you to update your changelog in this case.
+
+
+  %h4#contribute
+    %a.anchor{ href: "#contribute", aria_hidden: "true" }
+    How can I contribute?
+
+  %p
+    This document is not the <strong>truth</strong>; it’s my carefully
+    considered opinion, along with information and examples I gathered.
+
+  %p
+    This is because I want our community to reach a consensus. I believe
+    the discussion is as important as the end result.
+
+  %p
+    So please <strong>#{link_to "pitch in", gh}</strong>.
+
+.press
+  %h3 Conversations
+  %p
+    I went on #{link_to "The Changelog podcast", thechangelog}
+    to talk about why maintainers and contributors should care about changelogs,
+    and also about the motivations behind this project.

From bb00ab38f58be66e3221f5b29f762e0a5c11e1e2 Mon Sep 17 00:00:00 2001
From: Steven Wang <steven.guan.wang@gmail.com>
Date: Sun, 25 Jun 2017 18:21:35 +1000
Subject: [PATCH 2/6] Chinese Translation of version 1.0.0

---
 source/zh-CN/1.0.0/index.html.haml | 245 ++++++++++++++---------------
 1 file changed, 115 insertions(+), 130 deletions(-)

diff --git a/source/zh-CN/1.0.0/index.html.haml b/source/zh-CN/1.0.0/index.html.haml
index 5bd7ce5..4116886 100644
--- a/source/zh-CN/1.0.0/index.html.haml
+++ b/source/zh-CN/1.0.0/index.html.haml
@@ -1,7 +1,7 @@
 ---
-description: Keep a Changelog
-title: Keep a Changelog
-language: en
+description: 如何维护更新日志
+title: 如何维护更新日志
+language: zh-CN
 version: 1.0.0
 ---
 
@@ -18,8 +18,8 @@ version: 1.0.0
 
 .header
   .title
-    %h1 Keep a Changelog
-    %h2 Don’t let your friends dump git logs into changelogs.
+    %h1 如何维护更新日志
+    %h2 更新日志绝对不应该是git日志的堆砌物
 
   = link_to changelog do
     Version
@@ -30,248 +30,236 @@ version: 1.0.0
 .answers
   %h3#what
     %a.anchor{ href: "#what", aria_hidden: "true" }
-    What is a changelog?
+    更新日志是什么？
 
   %p
-    A changelog is a file which contains a curated, chronologically
-    ordered list of notable changes for each version of a project.
+    更新日志（Change Log）是一个由人工编辑，以时间为倒叙的列表，
+    以记录一个项目中所有版本的显著变动。
 
   %h3#why
     %a.anchor{ href: "#why", aria_hidden: "true" }
-    Why keep a changelog?
+    为何要提供更新日志？
 
   %p
-    To make it easier for users and contributors to see precisely what
-    notable changes have been made between each release (or version) of
-    the project.
+    为了让用户和开发人员更简单明确的知晓项目在不同版本之间有哪些显著变动。
 
   %h3#who
     %a.anchor{ href: "#who", aria_hidden: "true" }
-    Who needs a changelog?
+    哪些人需要更新日志？
 
   %p
-    People do. Whether consumers or developers, the end users of
-    software are human beings who care about what's in the software. When
-    the software changes, people want to know why and how.
+    人人需要更新日志。无论是消费者还是开发者，软件的最终用户都关心软件所包含什么。
+    当软件有所变动时，大家希望知道改动是为何、以及如何进行的。
 
 .good-practices
   %h3#how
     %a.anchor{ href: "#how", aria_hidden: "true" }
-    How do I make a good changelog?
+    怎样制作高质量的更新日志？
 
   %h4#principles
     %a.anchor{ href: "#principles", aria_hidden: "true" }
-    Guiding Principles
+    指导原则
 
   %ul
     %li
-      Changelogs are <em>for humans</em>, not machines.
+      记住日志是写给<em>人</em>的，而非机器。
     %li
-      There should be an entry for every single version.
+      每个版本都应该有独立的入口。
     %li
-      The same types of changes should be grouped.
+      同类改动应该分组放置。
     %li
-      Versions and sections should be linkable.
+      版本与章节应该相互对应。
     %li
-      The latest version comes first.
+      新版本在前，旧版本在后。
     %li
-      The release date of each versions is displayed.
+      应包括每个版本的发布日期。
     %li
-      Mention whether you follow #{link_to "Semantic Versioning", semver}.
+      注明是否遵守#{link_to "语义化版本格式", semver}.
 
   %a.anchor{ href: "#types", aria_hidden: "true" }
-  %h4#types Types of changes
+  %h4#types 变动类型
 
   %ul
     %li
       %code Added
-      for new features.
+      新添加的功能。
     %li
       %code Changed
-      for changes in existing functionality.
+      对现有功能的变更。
     %li
       %code Deprecated
-      for soon-to-be removed features.
+      已经不建议使用，准备很快移除的功能。
     %li
       %code Removed
-      for now removed features.
+      已经移除的功能。
     %li
       %code Fixed
-      for any bug fixes.
+      对bug的修复
     %li
       %code Security
-      in case of vulnerabilities.
+      对安全的改进
 
 .effort
 
   %h3#effort
     %a.anchor{ href: "#effort", aria_hidden: "true" }
-    How can I reduce the effort required to maintain a changelog?
+    如何减少维护更新日志的精力？
 
   %p
-    Keep an <code>Unreleased</code> section at the top to track upcoming
-    changes.
+    在文档最上方提供 <code>Unreleased</code> 区块以记录即将发布的更新内容。
 
-  %p This serves two purposes:
+  %p 这样有两大意义：
 
   %ul
     %li
-      People can see what changes they might expect in upcoming releases
+      大家可以知道在未来版本中可能会有哪些变更
     %li
-      At release time, you can move the <code>Unreleased</code> section
-      changes into a new release version section.
+      在发布新版本时，可以直接将<code>Unreleased</code>区块中的内容移动至新发
+      布版本的描述区块就可以了
 
 .bad-practices
   %h3#bad-practices
     %a.anchor{ href: "#bad-practices", aria_hidden: "true" }
-    Can changelogs be bad?
-  %p Yes. Here are a few ways they can be less than useful.
+    有很糟糕的更新日志吗？
+    
+  %p 当然有，下面就是一些糟糕的方式。
+  
   %h4#log-diffs
     %a.anchor{ href: "#log-diffs", aria_hidden: "true" }
-    Commit log diffs
+    使用git日志
 
   %p
-    Using commit log diffs as changelogs is a bad idea: they're full of
-    noise. Things like merge commits, commits with obscure titles,
-    documentation changes, etc.
+    使用git日志作为更新日志是个非常糟糕的方式：git日志充满各种无意义的信息，
+    如合并提交、语焉不详的提交标题、文档更新等。
 
   %p
-    The purpose of a commit is to document a step in the evolution of
-    the source code. Some projects clean up commits, some don't.
+    提交的目的是记录源码的演化。
+    一些项目会清理提交记录，一些则不会。
 
   %p
-    The purpose of a changelog entry is to document the noteworthy
-    difference, often across multiple commits, to communicate them
-    clearly to end users.
-
+    更新日志的目的则是记录重要的变更以供最终受众阅读，而记录范围通常涵盖多次提交。
+    
   %h4#ignoring-deprecations
     %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
-    Ignoring Deprecations
+    无视即将弃用功能
+    
   %p
-    When people upgrade from one version to another, it should be
-    painfully clear when something will break. It should be possible to
-    upgrade to a version that lists deprecations, remove what's
-    deprecated, then upgrade to the version where the deprecations
-    become removals.
+    当从一个版本升级至另一个时，人们应清楚（尽管痛苦）的知道哪些部分将出现问题。
+    应该允许先升级至一个列出哪些功能将会被弃用的版本，待去掉那些不再支持的部分后，
+    再升级至把那些弃用功能真正移除的版本。
+    
   %p
-    If you do nothing else, list deprecations, removals, and any
-    breaking changes in your changelog.
+    即使其他什么都不做，也要在更新日志中列出derecations，removals以及其他重大变动。
+    
   %h4#confusing-dates
     %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
-    Confusing Dates
+    易混淆的日期格式
 
   %p
-    In the U.S., people put the month first (<code>06-02-2012</code> for
-    June 2nd, 2012), while many people in the rest of the world write a
-    robotic-looking <code>2 June 2012</code>, yet pronounce it
-    differently. <code>2012-06-02</code> works logically from largest to
-    smallest, doesn't overlap in ambiguous ways with other date formats,
-    and is an #{link_to "ISO standard", iso}. Thus, it is the
-    recommended date format for changelogs.
+    在美国，人们将月份写在日期的起始(<code>06-02-2012</code>对应2012年6月2日)，
+    与此同时世界上其他地方的很多人将至写作<code>2 June 2012</code>，并拥有不同发音。
+    <code>2012-06-02</code>从大到小的排列符合逻辑，并不与其他日期格式相混淆，而且还
+    符合#{link_to "ISO标准", iso}。因此，推荐在更新日志中采用使用此种日期格式。
 
   %aside
-    There’s more. Help me collect these antipatterns by
-    = link_to "opening an issue", issues
-    or a pull request.
+    还有更多内容。请通过
+    = link_to "发布问题", issues
+    或发布pull请求帮助我收集更多异常模式。
 
 .frequently-asked-questions
   %h3#frequently-asked-questions
     %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
-    Frequently Asked Questions
+    常见问题
+    
   %h4#standard
     %a.anchor{ href: "#standard", aria_hidden: "true" }
-    Is there a standard changelog format?
+    是否有一个标准化的更新日志格式？
 
   %p
-    Not really. There's the GNU changelog style guide, or the two-
-    paragraph-long GNU NEWS file "guideline". Both are inadequate or
-    insufficient.
+    并没有。虽然GNU提供了更新日志样式指引，以及那个仅有两段长的GNU NEWS文件“指南”，
+    但两者均远远不够。
 
   %p
-    This project aims to be
-    = link_to "a better changelog convention.", changelog
-    It comes from observing good practices in the open source
-    community and gathering them.
+    此项目意在提供一个
+    = link_to "更好的更新日志惯例", changelog
+    所有点子都来自于在开源社区中对优秀实例的观察与记录。
 
   %p
-    Healthy criticism, discussion and suggestions for improvements
-    = link_to "are welcome.", issues
+    对于所有建设性批评、讨论及建议，我们都非常
+    = link_to "欢迎。", issues
 
 
   %h4#filename
     %a.anchor{ href: "#filename", aria_hidden: "true" }
-    What should the changelog file be named?
+    更新日志文件应被如何命名？
 
   %p
-    Call it <code>CHANGELOG.md</code>. Some projects use
-    <code>HISTORY</code>, <code>NEWS</code> or <code>RELEASES</code>.
+    可以叫做<code>CHANGELOG.md</code>。 一些项目也使用
+    <code>HISTORY</code>、<code>NEWS</code>或<code>RELEASES</code>。
 
   %p
-    While it's easy to think that the name of your changelog file
-    doesn't matter that much, why make it harder for your end users to
-    consistently find notable changes?
+    当然，你可以认为更新日志的名字并不是什么要紧事，但是为什么要为难那些仅仅是
+    想看到都有哪些重大变更的最终用户呢？
 
   %h4#github-releases
     %a.anchor{ href: "#github-releases", aria_hidden: "true" }
-    What about GitHub Releases?
+    对于GitHub发布呢？
+    
   %p
-    It's a great initiative. #{link_to "Releases", ghr} can be used to
-    turn simple git tags (for example a tag named <code>v1.0.0</code>)
-    into rich release notes by manually adding release notes or it can
-    pull annotated git tag messages and turn them into notes.
+    这是个非常好的倡议。#{link_to "Releases", ghr}可通过手动添加发布日志或将带
+    有注释的git标签信息抓取后转换的方式，将简单的git标签（如一个叫<code>v1.0.0</code>的标签）
+    转换为信息丰富的发布日志。
+
   %p
-    GitHub Releases create a non-portable changelog that can only be
-    displayed to users within the context of GitHub. It's possible to
-    make them look very much like the Keep a Changelog format, but it
-    tends to be a bit more involved.
+    GitHub发布会创建一个非便携、仅可在GitHub环境下显示的更新日志。尽管会花费更
+    多时间，但将之处理成更新日志格式是完全可能的。
+
   %p
-    The current version of GitHub releases is also arguably not very
-    discoverable by end-users, unlike the typical uppercase files
-    (<code>README</code>, <code>CONTRIBUTING</code>, etc.). Another
-    minor issue is that the interface doesn't currently offer links to
-    commit logs between each release.
+    现行版本的GitHub发布不像哪些典型的大写文件(<code>README</code>, 
+    <code>CONTRIBUTING</code>, etc.)，仍可以认为是不利于最终用户探索的。
+    另一个小问题则是界面并不提供不同版本间commit日志的链接。
+
   %h4#automatic
     %a.anchor{ href: "#automatic", aria_hidden: "true" }
-    Can changelogs be automatically parsed?
+    更新日志可以被自动识别吗？
 
   %p
-    It’s difficult, because people follow wildly different formats and
-    file names.
+    非常困难，因为有各种不同的文件格式和命名。
+    
 
   %p
-    #{link_to "Vandamme", vandamme} is a Ruby gem created by the
-    #{link_to "Gemnasium", gemnasium} team and which parses many (but
-    not all) open source project changelogs.
+    #{link_to "Vandamme", vandamme} 是一个Ruby程序，由
+    #{link_to "Gemnasium", gemnasium} 团队制作，可以解析多种
+    （但绝对不是全部）开源库的更新日志。
 
 
   %h4#yanked
     %a.anchor{ href: "#yanked", aria_hidden: "true" }
-    What about yanked releases?
-
+    那些后来撤下的版本怎么办？
+    
   %p
-    Yanked releases are versions that had to be pulled because of a
-    serious bug or security issue. Often these versions don't even
-    appear in change logs. They should. This is how you should display
-    them:
+    因为各种安全/重大bug原因被撤下的版本被标记'YANKED'。
+    这些版本一般不出现在更新日志里，但建议他们出现。
+    显示方式应该是：
 
   %p <code>## 0.0.5 - 2014-12-13 [YANKED]</code>
 
   %p
-    The <code>[YANKED]</code> tag is loud for a reason. It's important
-    for people to notice it. Since it's surrounded by brackets it's also
-    easier to parse programmatically.
+    <code>[YANKED]</code> 的标签应该非常醒目。
+    人们应该非常容易就可以注意到他。
+    并且被方括号所包围也使其更易被程序识别。
 
 
   %h4#rewrite
     %a.anchor{ href: "#rewrite", aria_hidden: "true" }
-    Should you ever rewrite a changelog?
+    是否可以重写更新日志？
 
   %p
-    Sure. There are always good reasons to improve a changelog. I
-    regularly open pull requests to add missing releases to open source
-    projects with unmaintained changelogs.
+    当然可以。总会有多种多样的原因需要我们去改进更新日志。
+    对于那些有着未维护更新日志的开源项目，我会定期打开pull请求以加入缺失的发布信息。
 
   %p
+    另外，很有可能你发现自己忘记记录一个重大功能更新。这种情况下显然你应该去重写更新日志。
     It's also possible you may discover that you forgot to address a
     breaking change in the notes for a version. It's obviously important
     for you to update your changelog in this case.
@@ -279,22 +267,19 @@ version: 1.0.0
 
   %h4#contribute
     %a.anchor{ href: "#contribute", aria_hidden: "true" }
-    How can I contribute?
+    如何贡献？
 
   %p
-    This document is not the <strong>truth</strong>; it’s my carefully
-    considered opinion, along with information and examples I gathered.
+    本文档并非<strong>真理</strong>。而是我深思熟虑后的建议，以及我收集的信息与典例。
 
   %p
-    This is because I want our community to reach a consensus. I believe
-    the discussion is as important as the end result.
+    我希望我们的社区可以对此达成一直。我相信讨论的过程与最终结果一样重要。
 
   %p
-    So please <strong>#{link_to "pitch in", gh}</strong>.
+    所以欢迎<strong>#{link_to "贡献", gh}</strong>.
 
 .press
-  %h3 Conversations
+  %h3 访谈
   %p
-    I went on #{link_to "The Changelog podcast", thechangelog}
-    to talk about why maintainers and contributors should care about changelogs,
-    and also about the motivations behind this project.
+    我在#{link_to "更新日志播客", thechangelog}上讲述了为何维护者与贡献者应关心更新日志，
+    以及支持我进行此项目的诸多因素。

From fd9a7e224afc9f5f3969463594a8134a880c4eaa Mon Sep 17 00:00:00 2001
From: lcabeza <lcabeza@clickdelivery.com>
Date: Fri, 23 Jun 2017 09:42:38 -0500
Subject: [PATCH 3/6] Added es-ES for 1.0.0 version

---
 source/es-ES/1.0.0/index.html.haml | 258 +++++++++++++++++++++++++++++
 1 file changed, 258 insertions(+)
 create mode 100644 source/es-ES/1.0.0/index.html.haml

diff --git a/source/es-ES/1.0.0/index.html.haml b/source/es-ES/1.0.0/index.html.haml
new file mode 100644
index 0000000..ece9ba9
--- /dev/null
+++ b/source/es-ES/1.0.0/index.html.haml
@@ -0,0 +1,258 @@
+---
+description: Mantenga un Changelog
+title: Mantenga un Changelog
+language: es-ES
+version: 1.0.0
+---
+
+- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md"
+- gemnasium = "https://gemnasium.com/"
+- gh = "https://github.com/olivierlacan/keep-a-changelog"
+- issues = "https://github.com/olivierlacan/keep-a-changelog/issues"
+- semver = "http://semver.org/"
+- shields = "http://shields.io/"
+- thechangelog = "http://5by5.tv/changelog/127"
+- vandamme = "https://github.com/tech-angels/vandamme/"
+- iso = "http://www.iso.org/iso/home/standards/iso8601.htm"
+- ghr = "https://help.github.com/articles/creating-releases/"
+
+.header
+  .title
+    %h1 Mantenga un Changelog
+    %h2 No dejes que tus amigos copien y peguen git logs en los CHANGELOGs™
+
+  = link_to changelog do
+    Versión
+    %strong= current_page.metadata[:page][:version]
+
+  %pre.changelog= File.read("CHANGELOG.md")
+
+.answers
+  %h3#what
+    %a.anchor{ href: "#what", aria_hidden: "true" }
+    ¿Qué es un registro de cambios (change log)?
+
+  %p
+    Un registro de cambios o “change log” de ahora en adelante, es un archivo que contiene una lista en orden cronológico sobre los cambios que vamos haciendo en cada release (o versión) de nuestro proyecto.
+
+  %h3#why
+    %a.anchor{ href: "#why", aria_hidden: "true" }
+    ¿Cuál es el propósito del change log?
+
+  %p
+    Que les sea más fácil a los usuarios y contribuyentes, ver exactamente los cambios notables que se han hecho entre cada versión (o versiones) del proyecto.
+
+  %h3#who
+    %a.anchor{ href: "#who", aria_hidden: "true" }
+    ¿Quién necesita un change log?
+
+  %p
+    Las personas. Ya sean consumidores o desarrolladores, los usuarios finales del software son seres humanos que les importa que hay en el software. Cuando el software cambia, la gente quiere saber el porqué y el cómo.
+
+.good-practices
+  %h3#how
+    %a.anchor{ href: "#how", aria_hidden: "true" }
+    ¿Como hago un buen change log?
+
+  %h4#principles
+    %a.anchor{ href: "#principles", aria_hidden: "true" }
+    Directrices
+
+  %ul
+    %li
+      Están hecho para los seres humanos, no para las máquinas.
+    %li
+      Debe haber una entrada para cada versión.
+    %li
+      Los mismos tipos de cambios deben ser agrupados.
+    %li
+      Versiones y secciones deben ser enlazables.
+    %li
+      La última versión viene primero.
+    %li
+      La fecha de publicación de cada versión es mostrada.
+    %li
+      Se menciona explícitamente si el proyecto sigue la convención del #{link_to "Versionamiento Semántico", semver}.
+
+  %a.anchor{ href: "#types", aria_hidden: "true" }
+  %h4#types Tipos de cambios
+
+  %ul
+    %li
+      %code Added
+      para funcionalidades nuevas.
+    %li
+      %code Changed
+      para los cambios en las funcionalidades existentes.
+    %li
+      %code Deprecated
+      para indicar que una característica está obsoleta y que se eliminará en las próximas versiones.
+    %li
+      %code Removed
+      para las características en desuso que se eliminaron en esta versión.
+    %li
+      %code Fixed
+      para correcciones y bugs.
+    %li
+      %code Security
+      en caso de vulnerabilidades.
+
+.effort
+
+  %h3#effort
+    %a.anchor{ href: "#effort", aria_hidden: "true" }
+    ¿Cómo puedo minimizar el esfuerzo requerido?
+
+  %p
+    Siempre mantén una sección con el nombre <code>Unreleased</code> para hacer un seguimiento sobre los próximos cambios.
+
+  %p Esto nos puede servir para dos cosas:
+
+  %ul
+    %li
+      La gente puede ver qué cambios podrían esperar en los próximos releases.
+    %li
+      Una vez que queramos hacer un release, sólo habría que mover la sección <code>Unreleased</code> y sus cambios en una nueva sección con la respectiva versión.
+
+.bad-practices
+  %h3#bad-practices
+    %a.anchor{ href: "#bad-practices", aria_hidden: "true" }
+    ¿Pueden los change logs ser malos?
+
+  %p Si. Aquí hay unas maneras en las que pueden ser muy poco útiles.
+
+  %h4#log-diffs
+    %a.anchor{ href: "#log-diffs", aria_hidden: "true" }
+    Usar un diff de los logs de los commits
+
+  %p
+    Usar un diff de los logs de los commits es una mala idea: están llenos de ruido. Cosas como hacer <em>merge</em> de los commits, commits con títulos oscuros, cambios de documentación, entre otros.
+
+  %p
+    El propósito de un commit es documentar un paso en la evolución del código fuente. Algunos proyectos limpian los commits, en otros no.
+
+  %p
+    El propósito de una entrada del change log es documentar la notable diferencia, usualmente entre múltiples commits, para comunicarlos claramente a los usuarios finales.
+
+  %h4#ignoring-deprecations
+    %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
+    Ignorando Deprecaciones
+
+  %p
+    Cuando las personas actualizan de una versión a otra, debería ser extremadamente claro cuando algo se romperá. Debería ser posible actualizar a una versión que liste deprecaciones, remover que está deprecado, luego actualizar a la versión donde las deprecaciones sean remociones.
+
+  %p
+    Si no haces nada más, lista deprecaciones, remociones, y cualquier cambio sin compatibilidad hacia atrás en tu change log.
+
+
+  %h4#confusing-dates
+    %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
+    Fechas confusas
+
+  %p
+    En los EE.UU., la gente pone primero el mes (<code>06-02-2012</code> para el 2 de junio del 2012), mientras que muchas personas en el resto del mundo escriben de una manera muy robótica <code>2 Junio 2012</code>, sin embargo lo pronuncian distinto. <code>2012-06-02</code> funciona logicamente desde el más grande al más pequeño, no se solapa de maneras ambiugas con otros formatos de fecha, y es un #{link_to "Estandar ISO", iso}. Por lo cual, es el formato de fecha recomendado para change logs.
+
+  %aside
+    Hay más. Ayudame a recoger estos anti-patrones
+    = link_to "abriendo un issue", "#issues"
+    o un pull request.
+
+.frequently-asked-questions
+  %h3#frequently-asked-questions
+    %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
+    Preguntas frecuentes
+
+  %h4#standard
+    %a.anchor{ href: "#standard", aria_hidden: "true" }
+    ¿Hay un formato estandar para los change logs?
+
+  %p
+    No realmente. Hay una guía de estilo del GNU, o los dos parrafos del archivo de NOTICIAS <code>guideline</code> del GNU. Ambos son inadecuados o insuficientes.
+
+  %p
+    Este proyecto apunta a ser
+    = link_to "una mejor convención de change logs.", changelog
+    Esto se da observando las buenas prácticas en la comunidad open source y recopilando las mismas.
+
+  %p
+    Críticas saludables, discusión y sugerencias para mejoras
+    = link_to "son bienvenidas.", issues
+
+
+  %h4#filename
+    %a.anchor{ href: "#filename", aria_hidden: "true" }
+    ¿Cómo debería llamarse el archivo de change log?
+
+  %p
+    Llamalo <code>CHANGELOG.md</code>. Algunos proyectos utilizan
+    <code>HISTORY</code>, <code>NEWS</code> o <code>RELEASES</code>.
+
+  %p
+    Si bien es fácil pensar que el nombre de tu archivo de change log no importa tanto, ¿Por qué hacer dificil para los usuarios finales conseguir de manera consistente los cambios notables?
+
+  %h4#github-releases
+    %a.anchor{ href: "#github-releases", aria_hidden: "true" }
+    ¿Y qué hay de los releases de Github?
+
+  %p
+    Es una gran iniciativa. #{link_to "Los releases de Github", ghr} pueden ser utilizados para convertir simples etiquetas de git (por ejemplo una etiqueta llamada <code>v1.0.0</code>) en ricas notas de release ya sea añadiendo estas manualmente o trayendo los mensajes anotados de las etiquetas de git y convertirlas en notas.
+
+  %p
+    Los releases de Github crean un change log no portable que solo pueden ser mostrados a usuarios dentro del contexto de Github. Es posible hacer que luzcan muy parecidas al formato de Mantenga un Changelog, pero tiende a ser un poco más involucrado.
+
+  %p
+    La versión actual de los releases de Github es también discutiblemente no muy detectable por los usuarios finales, diferente a los típicos archivos en mayúsculas (<code>README</code>, <code>CONTRIBUTING</code>, entre otros.). Otro problema menor es que la interfaz actualmente no ofrece enlaces a los registros de los commits entre cada release.
+
+  %h4#automatic
+    %a.anchor{ href: "#automatic", aria_hidden: "true" }
+    ¿Se pueden analizar gramaticalmente los change logs?
+
+  %p
+    Es difícil, porque las personas siguen formatos y distintos nombres de archivo muy distintos.
+
+  %p
+    #{link_to "Vandamme", vandamme} es una gema de Ruby creada por el equipo de 
+    #{link_to "Gemnasium", gemnasium} y que analiza gramaticalmente muchos (pero no todos) los change logs de proyectos open source.
+
+
+  %h4#yanked
+    %a.anchor{ href: "#yanked", aria_hidden: "true" }
+    ¿Qué hay sobre los releases retirados?
+
+  %p
+    "Yanked releases" son versiones que tuvieron que ser retiradas por un error grave o problema de seguridad. Con frecuencia estas versiones ni siquiera aparecen en los change logs. Deberían. Así es como se deberían mostrarse:
+
+  %p <code>## 0.0.5 - 2014-12-13 [YANKED]</code>
+
+  %p
+    La etiqueta <code>[YANKED]</code> va entre corchetes por una razón, es importante que destaque, y el hecho de estar rodeado por corchetes lo hace más fácil de localizar programáticamente.
+
+
+  %h4#rewrite
+    %a.anchor{ href: "#rewrite", aria_hidden: "true" }
+    ¿Deberías volver a escribir un change log?
+
+  %p
+    Por supuesto. Siempre hay buenas razones para mejorar el change log. A veces abro "pull requests" para añadir registros faltantes en el change log de proyectos open source.
+
+  %p
+    También es posible que puedas descubrir que olvidaste comentar sobre un cambio sin compatibilidad hacia atrás en las notas para una versión. En este caso es importante para ti actualizar el change log.
+
+
+  %h4#contribute
+    %a.anchor{ href: "#contribute", aria_hidden: "true" }
+    ¿Cómo puedo contribuir?
+
+  %p
+    Este documento no es la <strong>verdad absoluta</strong> es mi cuidadosa opinión, junto con información y ejemplos que recogí.
+
+  %p
+    Esto es porque quiero que la comunidad llegue a un consenso. Creo que la discusión es tan importante como el resultado final.
+
+  %p
+    Así que por favor <strong>#{link_to "comienza a colaborar", gh}</strong>.
+
+.press
+  %h3 Conversaciones
+  %p
+    Fuí al #{link_to "The Changelog podcast", thechangelog} para hablar acerca de porqué a los mantenedores y contribuidores deberían importarles los change logs, y también acerca de las motivaciones detrás de este proyecto.

From ff42aba1b1ff8c4a5c6f278a7cd0ec0286abea26 Mon Sep 17 00:00:00 2001
From: Alexandr Borisov <aishek@gmail.com>
Date: Fri, 30 Jun 2017 00:01:03 +0300
Subject: [PATCH 4/6] Added correct russian translation.

---
 CHANGELOG.md                    |   1 +
 source/ru/1.0.0/index.html.haml | 420 ++++++++++++++++++++------------
 2 files changed, 264 insertions(+), 157 deletions(-)

diff --git a/CHANGELOG.md b/CHANGELOG.md
index cac12d1..75af7e1 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -24,6 +24,7 @@ and this project adheres to [Semantic Versioning](http://semver.org/spec/v2.0.0.
 - French translation from @zapashcanon.
 - Brazilian Portugese translation from @aisamu.
 - Polish translation from @amielucha.
+- Russian translation from @aishek.
 
 ### Changed
 - Start using "changelog" over "change log" since it's the common usage.
diff --git a/source/ru/1.0.0/index.html.haml b/source/ru/1.0.0/index.html.haml
index 1c6c2c6..47b612f 100644
--- a/source/ru/1.0.0/index.html.haml
+++ b/source/ru/1.0.0/index.html.haml
@@ -1,197 +1,303 @@
 ---
-description: Ведите Changelog
-title: Ведите Changelog
-language: en
-version: 0.3.0
+description: Keep a Changelog
+title: Keep a Changelog
+language: ru
+version: 1.0.0
 ---
 
-:markdown
-  # Ведите CHANGELOG
+- changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md"
+- gemnasium = "https://gemnasium.com/"
+- gh = "https://github.com/olivierlacan/keep-a-changelog"
+- issues = "https://github.com/olivierlacan/keep-a-changelog/issues"
+- semver = "http://semver.org/"
+- shields = "http://shields.io/"
+- thechangelog = "http://5by5.tv/changelog/127"
+- vandamme = "https://github.com/tech-angels/vandamme/"
+- iso = "http://www.iso.org/iso/home/standards/iso8601.htm"
+- ghr = "https://help.github.com/articles/creating-releases/"
 
-  ## Не позволяйте друзьям сливать логи гита в CHANGELOG™
+.header
+  .title
+    %h1 Ведите CHANGELOG
+    %h2 Не позволяйте друзьям сливать логи гита в CHANGELOG™
 
-  Version **#{current_page.metadata[:page][:version]}**
+  = link_to changelog do
+    Version
+    %strong= current_page.metadata[:page][:version]
 
-  ### Что такое лог изменений?
-  Лог изменений – это файл, который содержит поддерживаемый, хронологически упорядоченный
-  список изменений для каждой версии проекта.
+  %pre.changelog= File.read("CHANGELOG.md")
 
-%pre.changelog= File.read("CHANGELOG.md")
+.answers
+  %h3#what
+    %a.anchor{ href: "#what", aria_hidden: "true" }
+    Что такое лог изменений?
 
-:markdown
-  ### Для чего нужен лог изменений?
-  Чтобы пользователи и контрибьюторы чётко понимали что поменялось в каждом релизе (или
-  версии) проекта.
+  %p
+    Лог изменений – это файл, который содержит поддерживаемый, хронологически
+    упорядоченный список изменений для каждой версии проекта.
 
-  ### Почему я вообще должен задумываться о таких вещах?
-  Потому, что инструменты программирования делаются для людей. Если вам пофигу,
-  зачем вы вообще занимаетесь программным обеспечением с открытым исходным
-  кодом? У вас обязательно в голове должен быть центр «не пофигу» :)
+  %h3#why
+    %a.anchor{ href: "#why", aria_hidden: "true" }
+    Зачем вести лог изменений?
 
-  Я [беседовал с Адамом Стаковиаком и с Джеродом Санто в подкасте The
-  Changelog][thechangelog] (в тему название, правда?) о том почему авторам
-  программного обеспечения с открытым исходным кодом и их коллегам должно быть
-  не пофигу, и о моих мотивах в создании этого проекта. Послушайте, если у вас
-  есть время (1:06).
+  %p
+    Чтобы пользователям и контрибьюторам было проще точно понять,
+    какие изменения были сделаны в каждом релизе (или версии) проекта
 
-  ### Что должно быть в хорошем логе изменений?
-  Я рад, что вы спросили.
+  %h3#who
+    %a.anchor{ href: "#who", aria_hidden: "true" }
+    Кому нужен лог изменений?
 
-  Хороший лог изменений построен на таких приниципах:
+  %p
+    Людям. Будь то клиенты или разработчики, конечные пользователи программного обеспечения
+    это люди, и им важно, с чем они работают. Когда программное обеспечение меняется,
+    люди хотят знать почему и что изменилось.
 
-  - Он сделан для людей, а не машин, так что понятность имеет решающее
-    значение.
-  - Легко сослаться на любой раздел (поэтому Markdown лучше обычного текста).
-  - Один подраздел на каждую версию.
-  - Релизы перечислены в обратном хронологическом порядке (самые новые –
-    сверху).
-  - Пишите все даты в формате `YYYY-MM-DD`. (Например: `2012-06-02` для даты `2
-    июня 2012`.) Он международный, [рациональный](http://xkcd.com/1179/), и
-    независим от языка.
-  - Ясно указывает, использует ли проект [Семантическое
-    Версионирование][semver].
-  - Каждая версия должна:
-    - Показывать дату релиза в формате, упомянутом выше.
-    - Группировать изменения согласно их влиянию на проект следующим образом:
-      - `Added` для новых функций.
-      - `Changed` для изменений в существующей функциональности.
-      - `Deprecated` для функциональности, которая будет удалена в следующих
-        версиях.
-      - `Removed` для функциональности, которая удалена в этой версии.
-      - `Fixed` для любых исправлений.
-      - `Security` для обновлений безопасности.
+.good-practices
+  %h3#how
+    %a.anchor{ href: "#how", aria_hidden: "true" }
+    Как мне сделать хороший лог изменений?
 
-  ### Как минимизировать время, необходимое для ведения лога изменений?
-  Всегда ведите секцию `Unreleased` в начале файла, чтобы держать в ней не
-  выпущенные изменения.
+  %h4#principles
+    %a.anchor{ href: "#principles", aria_hidden: "true" }
+    Главные принципы
 
-  Это нужно для двух вещей:
+  %ul
+    %li
+      Лог изменений ведётся <em>для людей</em>, не для машин.
+    %li
+      Для каждой версии должен быть отдельный раздел.
+    %li
+      Одинаковые типы изменений должны быть сгруппированы.
+    %li
+      Должна быть возможность поставить ссылку на любую версию или раздел.
+    %li
+      Последняя версия должна идти в начале файла.
+    %li
+      У каждой версии указана дата выпуска.
+    %li
+      Уточните, следуете ли вы принципам #{link_to "Семантического версионирования", semver}
 
-  - Люди смогут видеть, какие изменения ожидаются в ближайших релизах
-  - В момент релиза вам нужно всего лишь заменить секцию `Unreleased` на номер
-    версии и добавить новую секцию `Unreleased` в начале файла.
+  %a.anchor{ href: "#types", aria_hidden: "true" }
+  %h4#types Типы изменений
 
-  ### Что заставляет плакать единорогов?
-  Хорошо… давайте разберёмся.
+  %ul
+    %li
+      %code Добавлено
+      для новых функций.
+    %li
+      %code Изменено
+      для изменений в существующей функциональности.
+    %li
+      %code Устарело
+      для функций, которы скоро будут удалены.
+    %li
+      %code Удалено
+      для удалённых функций.
+    %li
+      %code Исправлено
+      для любых исправлений.
+    %li
+      %code Безопасность
+      в случае уязвимостей.
 
-  - **Выгрузка изменений лога коммитов.** Просто не делайте так, это никому не
-    принесёт пользы.
-  - **Отсутствие отметок планируемой к удалению функциональности.** Когда люди
-    обновляются от одной версии к другой, им должно быть очевидно до боли, что
-    сломается.
-  - **Даты в местном формате.** В Соединённых Штатах, люди сначала пишут месяц
-    («06-02-2012» для даты 2 июня 2012, что не имеет *никакого* смысла), хотя
-    много людей в остальном мире пишет роботоподобное «2 июня 2012», всё ещё
-    произнося это по-другому. «2012-06-02» логично работает от самого большого
-    к самому маленькому, не пересекается с другими форматами дат, и является
-    [стандартом ISO](http://www.iso.org/iso/home/standards/iso8601.htm). Таким
-    образом, этот формат является рекомендуемым для логов изменений.
+.effort
 
-  Существуют и другие. Помогите мне собрать слёзы единорогов,
-  [открыв тикет][issues] или пулл-реквест.
+  %h3#effort
+    %a.anchor{ href: "#effort", aria_hidden: "true" }
+    Как мне тратить меньше усилий на ведение лога изменений?
 
-  ### Существует стандарт формата лога изменений?
-  К сожалению, нет. Спокойней. Я знаю, что вы яростно бросились на поиски
-  ссылки на GNU-руководства по стилю лога изменений, или на поиски файла
-  «guideline» с парой параграфов в GNU NEWS. GNU-руководство по стилю неплохо
-  для начала, но оно наивно.  В наивности нет ничего плохого, но когда людям
-  нужно руководство, она редко бывает полезна.  Особенно, когда приходиться
-  сталкиваться со множеством краевых случаев.
+  %p
+    Ведите раздел <code>Новое</code> с изменениями для новой версии в начале файла.
 
-  Этот проект [содержит информацию, которая, я надеюсь, станет соглашением
-  получше о ведении файлов CHANGELOG][CHANGELOG] для всех проектов с открытым
-  исходным кодом. Может ли сообщество учиться на своих ошибках, а не просто
-  действовать согласно десяти записям, которые были написаны много лет назал,
-  и, якобы, без одной ошибки? Хорошо. Поэтому, пожалуйста, посмотрите вокруг, и
-  помните, что [обсуждения и предложения по улучшению приветствуются][issues]!
+  %p Это нужно для двух вещей:
 
-  ### Как можно назвать файл лога изменений?
-  Ну, если вы не не можете ответить на этот вопрос, глядя на пример выше,
-  `CHANGELOG.md` пока наилучший вариант.
+  %ul
+    %li
+      Люди смогут видеть, каких изменений им ожидать в ближайших релизах
+    %li
+      В момент релиза вы можете переместить изменения раздела <code>Новое</code>
+      в раздел нового релиза.
 
-  Некоторые проекты используют `HISTORY.txt`, `HISTORY.md`, `History.md`,
-  `NEWS.txt`, `NEWS.md`, `News.txt`, `RELEASES.txt`, `RELEASE.md`,
-  `releases.md`, и так далее.
+.bad-practices
+  %h3#bad-practices
+    %a.anchor{ href: "#bad-practices", aria_hidden: "true" }
+    Бывают плохие логи изменений?
 
-  Это непорядок. Все эти имена только усложняют поиск нужного файла.
+  %p Да. Вот несколько способов чтобы сделать их не такими полезными.
 
-  ### Почему люди не могут использовать просто дифф команды `git log`?
-  Потому, что диффы логов по своей природе содержат слишком много «шума». С их
-  помощью невозможно сделать подходящий лог изменений даже в гипотетическом
-  проекте, который делается идеальными программистами, которые никогда не
-  делают опечаток, никогда не забывают коммитить новые файлы, никогда не
-  пропускают ни одну часть рефакторинга.  Назначение коммита в том, чтобы
-  задокументировать один атомарный шаг в процессе развития кода от одного
-  состояния к другому. Назначение лога изменений – документировать значимые
-  различия между этими состояниями.
+  %h4#log-diffs
+    %a.anchor{ href: "#log-diffs", aria_hidden: "true" }
+    Диффы лога коммитов
 
-  Как отличаются хорошие комментарии к коду и сам код, также отличаются друг от
-  друга и лог изменений с логом коммитов: первые отвечают на вопрос
-  *почему*, а вторые на вопрос как.
+  %p
+    Использование диффов лога коммитов это плохая идея: они очень шумные.
+    Шумят мердж-коммиты, коммиты с непонятными названиями, изменения в документации
+    и тому подобное.
 
-  ### Могут ли логи изменений быть автоматически распарсены?
-  Это сложно из-за того, что люди следуют сильно отличающимся форматам и
-  соглашениям о именах файлов.
+  %p
+    Назначение коммита в том, чтобы задокументировать шаг в эволюции исходного
+    кода. В некоторых проектах следят за историей коммитов, в некоторых нет.
 
-  Гем для Руби [Vandamme][vandamme], который создали в команде
-  [Gemnasium][gemnasium], парсит многие (но не все) логи изменений проектов с
-  открытым исходным кодом.
+  %p
+    Назначение же раздела в логе изменений — задокументировать ключевые различия,
+    часто между несколькими коммитами, чтобы ясно донести их назначение
+    до конечных пользователей.
 
-  ### Почему вы пишите то «CHANGELOG», то «лог изменений»?
-  «CHANGELOG» – это имя файла. Оно несколько крикливо, но это историческое
-  соглашение, которому следуют многие проекты с открытым исходным кодом. В
-  качестве примеров подобных файлов можно привести [`README`][README],
-  [`LICENSE`][LICENSE], и [`CONTRIBUTING`][CONTRIBUTING].
 
-  Верхний регистр в имени файла (который в старых операционных системах
-  заставляет эти файлы находиться наверху списков) используется для привлечения
-  внимания. Так как в этих файлах содержится важная метаинформация о проекте,
-  они могут быть полезны любому использующему или дорабатывющему проект, также
-  как [бейджи проектов с открытым исходным кодом][shields].
+  %h4#ignoring-deprecations
+    %a.anchor{ href: "#ignoring-deprecations", aria_hidden: "true" }
+    Игнорирование устаревающих функций
 
-  Когда я упоминаю «лог изменений», я говорою о назначении этого файла: об
-  учёте изменений.
+  %p
+    Когда люди обновляются с одной версии на другую, должно быть до боли
+    очевидно, что сломается. Должна быть возможность обновиться до версии, которая
+    перечисляет устаревающие функции, удалить устаревшие данные, затем обновиться до версии,
+    в которой устаревающие функции становятся удалёнными.
 
-  ### Как насчёт yanked-релизов?
-  Yanked-релизы – это версии, которые изымаются из обращения из-за серьёзного
-  бага или проблемы безопасности в них. Часто такие версии даже не упоминаются
-  в логах изменений. А должны. И вот как вам следует их упоминать:
+  %p
+    Если вы не ведёте лог изменений, то хотя бы указывайте в нём устаревающие
+    и удалённые функции, а также все критичные изменения.
 
-  `## 0.0.5 - 2014-12-13 [YANKED]`
+  %h4#confusing-dates
+    %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
+    Непонятные даты
 
-  Тег `[YANKED]` такой «громкий» не просто так. Очень важно, чтобы люди его
-  заметили. А из-за того, что он окружён скобками, его легче определить
-  программно.
+  %p
+    В США сначала пишут месяц (<code>06-02-2012</code> для 2 июня 2012),
+    в то время как большинство людей в остальном мире пишут роботоподобное
+    <code>2 июня 2012</code>, произнося эту дата по-разному. Запись
+    <code>2012-06-02</code> логично идёт от большего к меньшему, не пересекается
+    с большинством других форматов дат, и является #{link_to "стандартом ISO", iso}.
+    Поэтому именно такой формат рекомендуется для логов изменений.
 
-  ### Стоит ли переписывать лог изменений?
-  Конечно. Всегда есть причины для улучшения лога изменений. Я регулярно
-  открываю пулл-реквесты в проекты с открытым исходным кодом с
-  неподдерживаемыми логами изменений для добавления недостающих релизов.
+  %aside
+    Есть и другие. Помогите мне собрать эти антипаттерны,
+    = link_to "создав тикет", "#issues" или пулл-реквест.
 
-  Также вы можете обнаружить что вы забыли адресовать критичное изменение в
-  описании версии. В этом случае очевидно, что нужно обновить лог
-  изменений.
+.frequently-asked-questions
+  %h3#frequently-asked-questions
+    %a.anchor{ href: "#frequently-asked-questions", aria_hidden: "true" }
+    Часто задаваемые вопросы
 
-  ### Как я могу помочь вашему проекту?
-  Этот документ **не истина в последней инстанции**; это моё тщательно
-  сформулированное мнение вместе с информацией и примерами, которые я собрал.
-  Хотя я предоставил настоящий [CHANGELOG][] из [GitHub-репозитария][gh], я
-  специально избегал цели создать *стандарт* или чёткий список правил (как это
-  делает, например, [SemVer.org][semver]).
+  %h4#standard
+    %a.anchor{ href: "#standard", aria_hidden: "true" }
+    Существует ли стандарт формата логов изменений?
 
-  Я сделал это потому, что хочу, чтобы наше сообщество достигло консенсуса. Я
-  верю, что дискуссия также важна, как и её результат.
+  %p
+    На самом деле нет. Есть стайлгайд логов изменений GNU,
+    есть длиной-в-два-параграфа файл "guideline" GNU NEWS.
+    Оба или неадекватны или недостаточно полны.
 
-  Так что, пожалуйста, [**участвуйте**][gh].
+  %p
+    Цель этого проекта — стать
+    = link_to "улучшенной версией соглашения о формате логов изменений.", changelog
+    Это приходит из-за сбора и следования хорошим практикам сообщества.
 
-  [CHANGELOG]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md
-  [CONTRIBUTING]: https://github.com/olivierlacan/keep-a-changelog/blob/master/CONTRIBUTING.md
-  [LICENSE]: https://github.com/olivierlacan/keep-a-changelog/blob/master/LICENSE
-  [README]: https://github.com/olivierlacan/keep-a-changelog/blob/master/README.md
-  [gemnasium]: https://gemnasium.com/
-  [gh]: https://github.com/olivierlacan/keep-a-changelog
-  [issues]: https://github.com/olivierlacan/keep-a-changelog/issues
-  [semver]: http://semver.org/
-  [shields]: http://shields.io/
-  [thechangelog]: http://5by5.tv/changelog/127
-  [vandamme]: https://github.com/tech-angels/vandamme/
+  %p
+    Здоровая критика, дискуссии и предложения по улучшению
+    = link_to "приветствуются.", issues
+
+
+  %h4#filename
+    %a.anchor{ href: "#filename", aria_hidden: "true" }
+    Как назвать файл лога изменений?
+
+  %p
+    Назовите его <code>CHANGELOG.md</code>. Некоторые проекты также используют
+    <code>HISTORY</code>, <code>NEWS</code> или <code>RELEASES</code>.
+
+  %p
+    Хоть и легко подумать, что имя файла лога изменений не так уж и важно,
+    но зачем усложнять вашим конечным пользователям поиск места,
+    где описаны все ключевые изменения?
+
+  %h4#github-releases
+    %a.anchor{ href: "#github-releases", aria_hidden: "true" }
+    Что насчёт функции "Релизы" на Гитхабе?
+
+  %p
+    Это отличная инициатива. #{link_to "Релизы", ghr} могут использоваться
+    для превращения простых тегов в Git (наприме тег <code>v1.0.0</code>)
+    в подробные заметки к релизам с помощью их редактирования вручную,
+    или с помощью комментариев к таким тегам.
+
+  %p
+    Релизы на Гитхабе создают непереносимый лог изменений, который может
+    быть показан пользователям только на самом Гитхабе. Возможно вести
+    их в формате, близком к формату проекта Keep a Changelog, но это требует
+    больших усилий.
+
+  %p
+    Текущая версия Релизов на Гитхабе также возможно не так хорошо видна
+    для конечных пользователей, в отличии от обычных файлов с именами в верхнем
+    регистре (<code>README</code>, <code>CONTRIBUTING</code>, и так далее).
+    Другая небольшая проблема заключается в том, что интерфейс не предлагает
+    ссылок на логи коммитов между релизами.
+
+  %h4#automatic
+    %a.anchor{ href: "#automatic", aria_hidden: "true" }
+    Могут ли логи изменений быть автоматически распарсены?
+
+  %p
+    Это сложно, потому что люди следуют сильно различающимся форматам
+    и используют разные имена файлов.
+
+  %p
+    #{link_to "Vandamme", vandamme} это гем для Руби, созданный командой
+    #{link_to "Gemnasium", gemnasium}, который парсит многие (но не все)
+    логи изменений проектов с открытым исходным кодом.
+
+
+  %h4#yanked
+    %a.anchor{ href: "#yanked", aria_hidden: "true" }
+    Что насчёт yanked-релизов?
+
+  %p
+    Yanked-релизы – это версии, которые изымаются из обращения из-за серьёзного
+    бага или проблемы безопасности в них. Часто такие версии даже не упоминаются
+    в логах изменений. А должны. И вот как вам следует их упоминать:
+
+  %p <code>## 0.0.5 - 2014-12-13 [YANKED]</code>
+
+  %p
+    Тег <code>[YANKED]</code> так бросается в глаза специально. Очень важно,
+    чтобы люди его заметели. Так как он обрамлён квадратными скобками,
+    его также проще распарсить программно.
+
+
+  %h4#rewrite
+    %a.anchor{ href: "#rewrite", aria_hidden: "true" }
+    Имеет ли смысл переписывать лог изменений?
+
+  %p
+    Конечно. Всегда есть веские причины для улучшения лога изменений.
+    Я регулярно открываю пулл-реквесты по добавлению недостающих релизов
+    в проекты с открытым исходным кодом с брошенными логами изменений.
+
+  %p
+    Также возможно вы можете обнаружить, что вы забыли указать критичное
+    изменение в замечаниям к версии. В этом случае очевидно вам важно
+    обновить ваш лог изменений.
+
+  %h4#contribute
+    %a.anchor{ href: "#contribute", aria_hidden: "true" }
+    Как я могу помочь вашему проекту?
+
+  %p
+    Этот документ <strong>не истина в последней инстанции</strong>; это моё
+    тщательно обдуманное мнение, вместе с информацией и примерами, которые я собрал.
+
+  %p
+    Дело в том, что я хочу, чтобы наше сообщество достигло согласия в этом вопросе.
+    Я верю, что дискуссия также важна, как и конечный результат.
+
+  %p
+    Так что, пожалуйста, <strong>#{link_to "участвуйте", gh}</strong>.
+
+.press
+  %h3 Обсуждения
+  %p
+    Я приходил в #{link_to "подкаст The Changelog", thechangelog},
+    чтобы поговорить о том, почему мейнтейнеры и контрьбьюторы долны вести логи изменений,
+    а также о моей мотивации к созданию этого проекта.

From 2a0df6b2a92217ccca2f1dcd5ff57b880bfcf660 Mon Sep 17 00:00:00 2001
From: Olivier Lacan <hi@olivierlacan.com>
Date: Fri, 30 Jun 2017 01:53:13 +0200
Subject: [PATCH 5/6] Fix invalid syntax

---
 source/ru/1.0.0/index.html.haml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/source/ru/1.0.0/index.html.haml b/source/ru/1.0.0/index.html.haml
index 47b612f..1b6b0fe 100644
--- a/source/ru/1.0.0/index.html.haml
+++ b/source/ru/1.0.0/index.html.haml
@@ -173,7 +173,7 @@ version: 1.0.0
 
   %aside
     Есть и другие. Помогите мне собрать эти антипаттерны,
-    = link_to "создав тикет", "#issues" или пулл-реквест.
+    #{link_to "создав тикет", "#issues"} или пулл-реквест.
 
 .frequently-asked-questions
   %h3#frequently-asked-questions

From 92db66e139b74ddb205df38e3c9a0ee2b38df3e5 Mon Sep 17 00:00:00 2001
From: Olivier Lacan <hi@olivierlacan.com>
Date: Fri, 30 Jun 2017 02:03:38 +0200
Subject: [PATCH 6/6] Fix multiple identation errors

---
 source/it-IT/1.0.0/index.html.haml | 115 ++++++++++++++++-------------
 1 file changed, 62 insertions(+), 53 deletions(-)

diff --git a/source/it-IT/1.0.0/index.html.haml b/source/it-IT/1.0.0/index.html.haml
index 2922635..6c6ebd0 100644
--- a/source/it-IT/1.0.0/index.html.haml
+++ b/source/it-IT/1.0.0/index.html.haml
@@ -5,7 +5,6 @@ language: it-IT
 version: 1.0.0
 ---
 
-
 - changelog = "https://github.com/olivierlacan/keep-a-changelog/blob/master/CHANGELOG.md"
 - gemnasium = "https://gemnasium.com/"
 - gh = "https://github.com/olivierlacan/keep-a-changelog"
@@ -34,7 +33,7 @@ version: 1.0.0
     Cos'è un changelog?
 
   %p
-    Un changelog è un file che contiene una lista curata e ordinata cronologicamente 
+    Un changelog è un file che contiene una lista curata e ordinata cronologicamente
     delle modifiche degne di nota per ogni versione di un progetto.
 
   %h3#why
@@ -42,7 +41,7 @@ version: 1.0.0
     Perché tenere un changelog?
 
   %p
-    Per rendere facile agli utilizzatori e contribuenti vedere con precisione quali modifiche 
+    Per rendere facile agli utilizzatori e contribuenti vedere con precisione quali modifiche
     importanti sono state fatte tra ogni release (o versione) del progetto.
 
   %h3#who
@@ -50,7 +49,7 @@ version: 1.0.0
     Chi ha bisogno di un changelog?
 
   %p
-    Le persone ne hanno bisogno. Che si tratti di consumatori o di sviluppatori, gli utenti finali 
+    Le persone ne hanno bisogno. Che si tratti di consumatori o di sviluppatori, gli utenti finali
     del software sono persone interessate a ciò che avviene in esso.
     Se il software è cambiato, allora le persone vogliono sapere come e perché.
 
@@ -75,9 +74,9 @@ version: 1.0.0
     %li
       L'ultima versione viene prima.
     %li
-     Viene mostrata la data di release di ogni versione.
+      Viene mostrata la data di release di ogni versione.
     %li
-     Si dichiara se il progetto segue il #{link_to "Versionamento Semantico", semver}.
+      Si dichiara se il progetto segue il #{link_to "Versionamento Semantico", semver}.
 
   %a.anchor{ href: "#types", aria_hidden: "true" }
   %h4#types Tipologie di cambiamenti
@@ -101,7 +100,7 @@ version: 1.0.0
     %li
       %code Security
       per invitare gli utilizzatori ad aggiornare in caso di vulnerabilità.
-      
+
 .effort
 
   %h3#effort
@@ -109,8 +108,8 @@ version: 1.0.0
     Come posso ridurre gli sforzi necessari a mantenere un changelog?
 
   %p
-    Tieni una sezione <code>Unreleased</code> in cima al changelog in modo da tenere traccia
-    dei cambiamenti imminenti.
+    Tieni una sezione <code>Unreleased</code> in cima al changelog in
+    modo da tenere traccia dei cambiamenti imminenti.
 
   %p Questo serve per due scopi:
 
@@ -118,14 +117,16 @@ version: 1.0.0
     %li
       Le persone possono vedere quali modifiche si possono aspettare nelle future release.
     %li
-    Ad una nuova release, si deve solo spostare i cambiamenti della sezione 
-    `"Unreleased"` in una nuova sezione con il suo numero di versione.
+      Ad una nuova release, si deve solo spostare i cambiamenti della sezione
+      `"Unreleased"` in una nuova sezione con il suo numero di versione.
 
 .bad-practices
   %h3#bad-practices
     %a.anchor{ href: "#bad-practices", aria_hidden: "true" }
     I changelog possono essere cattivi?
+
   %p Si. Ecco alcuni modi in cui possono essere meno utili.
+
   %h4#log-diffs
     %a.anchor{ href: "#log-diffs", aria_hidden: "true" }
     Commit log diffs
@@ -136,11 +137,11 @@ version: 1.0.0
     modifiche della documentazione, etc.
 
   %p
-    Lo scopo di un commit è quello di documentare un passo nell'evoluzione 
+    Lo scopo di un commit è quello di documentare un passo nell'evoluzione
     del codice sorgente. Alcuini progetti ripuliscono i commit, altri non lo fanno.
 
   %p
-    Lo scopo di una voce changelog è quello di documentare le differenze rilevanti, 
+    Lo scopo di una voce changelog è quello di documentare le differenze rilevanti,
     spesso attraverso commit mulptipli, per comunicarli in mdo chiaro agli utenti finali.
 
   %h4#ignoring-deprecations
@@ -149,11 +150,11 @@ version: 1.0.0
   %p
     Quando le persone aggiornano da una versione ad un'altra,
     dovrebbe essere dolorosamente chiaro quando qualcosa si romperà.
-    Dovrebbe essere possibile eseguire l'aggiornamento a una versione 
-    che elenca le deprecazioni, rimuove ciò che è deprecato, quindi 
+    Dovrebbe essere possibile eseguire l'aggiornamento a una versione
+    che elenca le deprecazioni, rimuove ciò che è deprecato, quindi
     aggiorna alla versione in cui le deprecazioni diventano rimozioni.
   %p
-    Se non fai nient'altro elenca le deprecazioni, le rimozioni e 
+    Se non fai nient'altro elenca le deprecazioni, le rimozioni e
     qualsiasi altro cambiamento nel tuo changelog.
   %h4#confusing-dates
     %a.anchor{ href: "#confusing-dates", aria_hidden: "true" }
@@ -161,14 +162,14 @@ version: 1.0.0
 
   %p
     Negli Stati Uniti si mette prima il mese nelle date (<code>06-02-2012</code> sta per
-    il 2 Giugno 2012), mentre molte persone nel resto del mondo scrivono un 
+    il 2 Giugno 2012), mentre molte persone nel resto del mondo scrivono un
     robotico <code>2 June 2012</code>, ma lo pronunciano diversamente.
-    <code>2012-06-02</code> funziona con la logica dal più grande al più piccolo, 
-    non ha sovrapposizioni ambigue con altri formati di date, ed è uno #{link_to "ISO standard", iso}. 
+    <code>2012-06-02</code> funziona con la logica dal più grande al più piccolo,
+    non ha sovrapposizioni ambigue con altri formati di date, ed è uno #{link_to "ISO standard", iso}.
     Per tutti questi motivi, è il formato di date raccomandato per i changelog.
 
   %aside
-    C'è di più. Aiutatemi a collezionare questi anti-modelli 
+    C'è di più. Aiutatemi a collezionare questi anti-modelli
     = link_to "aprendo un issue", issues
     o una pull request.
 
@@ -181,14 +182,14 @@ version: 1.0.0
     Esiste un formato standard per i changelog?
 
   %p
-    Non esattamente. Esistono le linee guida GNU sullo stile dei changelog, oppure 
+    Non esattamente. Esistono le linee guida GNU sullo stile dei changelog, oppure
     i due lunghi paragrafi nel documento di GNU NEWS denominato "guideline". Entrambe
     sono inadeguate o insufficienti.
 
   %p
     Questo progetto vuole essere
     = link_to "una migliore convenzione  per i file changelog.", changelog
-    Per questo motivo osserviamo le migliori pratiche della comunità open source 
+    Per questo motivo osserviamo le migliori pratiche della comunità open source
     e le portiamo avanti.
 
   %p
@@ -205,41 +206,48 @@ version: 1.0.0
     <code>HISTORY</code>, <code>NEWS</code> o <code>RELEASES</code>.
 
   %p
-    Mentre è facile pensare che il nome del tuo file changelog 
-    non sia poi così importante, perchè non rendere facile la 
+    Mentre è facile pensare che il nome del tuo file changelog
+    non sia poi così importante, perchè non rendere facile la
     vita ai tuoi utenti, usando sempre lo stesso nome?
 
   %h4#github-releases
     %a.anchor{ href: "#github-releases", aria_hidden: "true" }
     Cosa dire delle GitHub Releases?
+
   %p
     È una bella iniziativa. #{link_to "Releases", ghr} può essere usato
-    per rendere semplice i git tags (per esempio il nome del tag <code>v1.0.0</code>)
-    All'interno di note di rilascio ben dettagliate si possono aggiungere le note manualmente oppure è possibile
-    utilizzare le note dei messaggi dei git tag inserendole dentro nelle note di rilascio.
-    j
+    per rendere semplice i git tags (per esempio il nome del tag
+    <code>v1.0.0</code>) All'interno di note di rilascio ben dettagliate
+    si possono aggiungere le note manualmente oppure è possibile
+    utilizzare le note dei messaggi dei git tag inserendole dentro nelle
+    note di rilascio.
+
   %p
     GitHub Releases crea un changelog non-portable che può essere solo
-    visualizzato dagli utenti nel contesto di GitHub. È possibile farlo 
-    apparire molto simile al formato di Keep a Changelog, tuttavia tende 
+    visualizzato dagli utenti nel contesto di GitHub. È possibile farlo
+    apparire molto simile al formato di Keep a Changelog, tuttavia tende
     ad essere un po' più complicato.
+
   %p
-    La versione corrente di GitHub Releases risulta inoltre probabilmente
-    poco rilevante per gli utenti finali, a differenza dei tipici file maiuscoli
-    (<code>README</code>, <code>CONTRIBUTING</code>, etc.). Un altro problema 
-    minore è che l'interfaccia non offre attualmente link per la 
-    creazione di log tra ciascuna release.
+    La versione corrente di GitHub Releases risulta inoltre
+    probabilmente poco rilevante per gli utenti finali, a differenza dei
+    tipici file maiuscoli (<code>README</code>,
+    <code>CONTRIBUTING</code>, etc.). Un altro problema minore è che
+    l'interfaccia non offre attualmente link per la creazione di log tra
+    ciascuna release.
+
   %h4#automatic
     %a.anchor{ href: "#automatic", aria_hidden: "true" }
     I changelog possono essere analizzati automaticamente?
 
   %p
-   È difficile, perché le persone usano formati e nomi di file profondamente diversi.
+    È difficile, perché le persone usano formati e nomi di file
+    profondamente diversi.
 
   %p
-    #{link_to "Vandamme", vandamme} è una Ruby gem
-    creata dal team #{link_to "Gemnasium", gemnasium} ed è in grado di fare il parsing dei
-  change log di molti (ma non tutti) i progetti open source.
+    #{link_to "Vandamme", vandamme} è una Ruby gem creata dal team
+    #{link_to "Gemnasium", gemnasium} ed è in grado di fare il parsing dei
+    change log di molti (ma non tutti) i progetti open source.
 
 
   %h4#yanked
@@ -247,17 +255,18 @@ version: 1.0.0
     Cosa sono le release "yanked"?
 
   %p
-    Le release "yanked" sono versioni che sono state rimosse a causa di bug seri
-  o problemi di sicurezza. Spesso queste versioni non appaiono nei change
-  log. Invece dovrebbero esserci, nel seguente modo:
+    Le release "yanked" sono versioni che sono state rimosse a causa di
+    bug seri o problemi di sicurezza. Spesso queste versioni non
+    appaiono nei change log. Invece dovrebbero esserci, nel seguente
+    modo:
 
   %p <code>## 0.0.5 - 2014-12-13 [YANKED]</code>
 
   %p
-    L'etichetta <code>[YANKED]</code> è in maiuscolo per un motivo. 
-    È importante che le persone la notino. 
-   Poiché è racchiusa tra parentesi quadre è anche 
-   più semplice da riconoscere nel parsing automatizzato.
+    L'etichetta <code>[YANKED]</code> è in maiuscolo per un motivo.
+    È importante che le persone la notino.
+    Poiché è racchiusa tra parentesi quadre è anche
+    più semplice da riconoscere nel parsing automatizzato.
 
 
   %h4#rewrite
@@ -266,13 +275,13 @@ version: 1.0.0
 
   %p
     Certo. Ci sono sempre buoni motivi per migliorare un changelog. Io apro regolarmente
-  delle pull request per aggiungere release mancanti ai progetti open source che non mantengono
-  correttamente i changelog.
+    delle pull request per aggiungere release mancanti ai progetti open source che non mantengono
+    correttamente i changelog.
 
   %p
-   È anche possibile che si scopra di aver dimenticato di annotare una modifica
-  non retro-compatibile nelle note per una versione. Ovviamente è importante aggiornare
-  il changelog in questo caso.
+    È anche possibile che si scopra di aver dimenticato di annotare una modifica
+    non retro-compatibile nelle note per una versione. Ovviamente è importante aggiornare
+    il changelog in questo caso.
 
   %h4#contribute
     %a.anchor{ href: "#contribute", aria_hidden: "true" }
@@ -280,11 +289,11 @@ version: 1.0.0
 
   %p
     Questo documento non è la <strong>verità assoluta</strong>; è solo la mia attenta
-  opinione, arricchita dalle informazioni ed esempi che ho raccolto.
+    opinione, arricchita dalle informazioni ed esempi che ho raccolto.
 
   %p
     Questo è perché voglio che la nostra comunità raggiunga un consenso. Credo che
-  la discussione sia importante almeno quanto il risultato finale.
+    la discussione sia importante almeno quanto il risultato finale.
 
   %p
     Quindi per favore <strong>#{link_to "partecipate e dateci dentro", gh}</strong>.