Improve the Russian translation (#413)

source/ru/1.0.0/index.html.haml

@@ -20,7 +20,7 @@ version: 1.0.0
 .header
   .title
     %h1 Ведите changelog
-    %h2 Не позволяйте друзьям сливать логи Git в changelog’и.
+    %h2 Не позволяйте своим друзьям сливать логи Git в changelog’и.
 
   = link_to changelog do
     Version
@@ -136,7 +136,7 @@ version: 1.0.0
   %p
     Использование diff’ов лога коммитов в качестве лога изменений — это плохая идея:
     они полны информационного шума от слияния коммитов, от коммитов с непонятными
-    заглавиями, от изменений в документации и т. п.
+    заглавиями, от изменений, вносимых в документацию, и т. п.
 
   %p
     Назначение коммита в том, чтобы задокументировать шаг в эволюции исходного
@@ -144,7 +144,7 @@ version: 1.0.0
 
   %p
     Назначение же раздела в логе изменений — задокументировать заслуживающие
-    внимания различия (зачастую привнесённые несколькими коммитами), чтобы чётко
+    внимания различия (зачастую привнесённые несколькими коммитами), чтобы внятно
     сообщить конечным пользователям об этих различиях.
 
   %h4#ignoring-deprecations
@@ -152,8 +152,8 @@ version: 1.0.0
     Игнорирование устаревших функций
 
   %p
-    Когда люди переходят с одной версии на другую, им должно быть до боли ясно,
-    в какой именно момент что-то сломается. Следует предусмотреть возможность
+    Когда люди переходят с одной версии продукта на другую, им должно быть до боли
+    ясно, в какой именно момент что-то сломается. Следует предусмотреть возможность
     перейти к версии, в которой перечислены устаревшие функции, удалить то,
     что устарело, а затем перейти к версии, из которой эти устаревшие функции
     удалены.
@@ -181,7 +181,7 @@ version: 1.0.0
 
   %aside
     Есть кое-что ещё. Помогите мне собрать эти антипаттерны,
-    сделав #{link_to "заявку о наличии проблемы", "#issues"}
+    подав #{link_to "заявку о наличии проблемы", "#issues"}
     или pull request.
 
 .frequently-asked-questions
@@ -195,7 +195,7 @@ version: 1.0.0
 
   %p
     На самом деле, нет. Есть #{link_to "стилистический путеводитель по логам изменений от GNU", gnustyle},
-    есть «руководство» #{link_to "длиной в два абзаца по файлам GNU NEWS", gnunews}.
+    есть #{link_to "«руководство» длиной в два абзаца по файлам GNU NEWS", gnunews}.
     Оба или неадекватны, или недостаточно полны.
 
   %p
@@ -233,10 +233,10 @@ version: 1.0.0
     можно извлечь сообщения из аннотированных тегов Git и превратить их в примечания.
 
   %p
-    Релизы на GitHub’е создают непортируемый лог изменений, который может
-    быть показан пользователям только на самом GitHub’е. Возможно вести его в формате,
-    очень похожем на формат проекта Keep a Changelog, но это, как правило,
-    немного сложнее.
+    Релизы на GitHub’е создают непортируемый лог изменений, который может быть
+    показан пользователям только на самом GitHub’е. Имеется возможность вести такой лог
+    в формате, очень похожем на формат проекта Keep a Changelog, но это, как правило,
+    требует большей вовлечённости в процесс.
 
   %p
     Также возможно, что конечным пользователям не всегда легко обнаружить
@@ -255,8 +255,8 @@ version: 1.0.0
 
   %p
     #{link_to "Vandamme", vandamme} — это gem для Ruby, созданный командой
-    Gemnasium и способный парсить многие (но не все)
-    логи изменений проектов с открытым исходным кодом.
+    Gemnasium и способный парсить логи изменений во многих (но не всех)
+    проектах с открытым исходным кодом.
 
 
   %h4#yanked
@@ -279,17 +279,17 @@ version: 1.0.0
 
   %h4#rewrite
     %a.anchor{ href: "#rewrite", aria_hidden: "true" }
-    Имеет ли смысл переписывать лог изменений?
+    Следует ли вам когда-либо переписывать лог изменений?
 
   %p
-    Конечно. Всегда есть веские причины для улучшения лога изменений.
+    Конечно. Всегда есть веские причины для усовершенствования лога изменений.
     Я регулярно подаю pull request’ы на добавление недостающих выпусков в проекты
     с открытым исходным кодом, которые оставили свои логи изменений без сопровождения.
 
   %p
-    Возможно, вы обнаружите, что забыли указать критичное
-    изменение в примечании к версии. Очевидно, что в этом случае вам важно
-    обновить ваш лог изменений.
+    К тому же, возможно, вы обнаружите, что в примечании к версии
+    забыли рассмотреть одно из критичных изменений. Важность того,
+    что в этом случае вы обновите ваш лог изменений, очевидна.
 
 
   %h4#contribute

source/ru/1.1.0/index.html.haml

@@ -20,7 +20,7 @@ version: 1.1.0
 .header
   .title
     %h1 Ведите changelog
-    %h2 Не позволяйте друзьям сливать логи Git в changelog’и.
+    %h2 Не позволяйте своим друзьям сливать логи Git в changelog’и.
 
   = link_to changelog do
     Version
@@ -136,7 +136,7 @@ version: 1.1.0
   %p
     Использование diff’ов лога коммитов в качестве лога изменений — это плохая идея:
     они полны информационного шума от слияния коммитов, от коммитов с непонятными
-    заглавиями, от изменений в документации и т. п.
+    заглавиями, от изменений, вносимых в документацию, и т. п.
 
   %p
     Назначение коммита в том, чтобы задокументировать шаг в эволюции исходного
@@ -144,7 +144,7 @@ version: 1.1.0
 
   %p
     Назначение же раздела в логе изменений — задокументировать заслуживающие
-    внимания различия (зачастую привнесённые несколькими коммитами), чтобы чётко
+    внимания различия (зачастую привнесённые несколькими коммитами), чтобы внятно
     сообщить конечным пользователям об этих различиях.
 
   %h4#ignoring-deprecations
@@ -152,8 +152,8 @@ version: 1.1.0
     Игнорирование устаревших функций
 
   %p
-    Когда люди переходят с одной версии на другую, им должно быть до боли ясно,
-    в какой именно момент что-то сломается. Следует предусмотреть возможность
+    Когда люди переходят с одной версии продукта на другую, им должно быть до боли
+    ясно, в какой именно момент что-то сломается. Следует предусмотреть возможность
     перейти к версии, в которой перечислены устаревшие функции, удалить то,
     что устарело, а затем перейти к версии, из которой эти устаревшие функции
     удалены.
@@ -181,21 +181,21 @@ version: 1.1.0
 
   %h4#inconsistent-changes
     %a.anchor{ href: "#inconsistent-changes", aria_hidden: "true" }
-    Непоследовательные изменения
+    Непоследовательное освещение изменений
 
   %p
-    Лог изменений, в котором упомянуты только некоторые изменения, может быть опасен
-    в той же мере, что и отсутствие лога изменений. Несмотря на то, что многие изменения
-    могут не иметь отношения к делу (например, не во всех случаях может потребоваться
-    регистрировать удаление одного пробела), в логе следует упоминать любые важные
-    изменения. Применяя изменения непоследовательно, ваши пользователи могут ошибочно
-    считать лог изменений единственным источником истины. Таким он и должен быть.
+    Лог, в котором упомянуты лишь некоторые изменения, может быть опасен в той же мере,
+    что и отсутствие лога изменений. Несмотря на то, что многие изменения могут быть
+    нерелевантными (например, удаление одного пробела не во всех случаях может нуждаться
+    в регистрации), в логе следует упоминать о любых важных изменениях.
+    При непоследовательном освещении изменений ваши пользователи будут заблуждаться,
+    считая лог изменений единственным источником истины. А ведь таким он и должен быть.
     С большой силой приходит большая ответственность — наличие хорошего лога изменений
     означает наличие последовательно обновляемого лога изменений.
 
   %aside
     Есть кое-что ещё. Помогите мне собрать эти антипаттерны,
-    сделав #{link_to "заявку о наличии проблемы", "#issues"}
+    подав #{link_to "заявку о наличии проблемы", "#issues"}
     или pull request.
 
 .frequently-asked-questions
@@ -209,7 +209,7 @@ version: 1.1.0
 
   %p
     На самом деле, нет. Есть #{link_to "стилистический путеводитель по логам изменений от GNU", gnustyle},
-    есть «руководство» #{link_to "длиной в два абзаца по файлам GNU NEWS", gnunews}.
+    есть #{link_to "«руководство» длиной в два абзаца по файлам GNU NEWS", gnunews}.
     Оба или неадекватны, или недостаточно полны.
 
   %p
@@ -247,10 +247,10 @@ version: 1.1.0
     можно извлечь сообщения из аннотированных тегов Git и превратить их в примечания.
 
   %p
-    Релизы на GitHub’е создают непортируемый лог изменений, который может
-    быть показан пользователям только на самом GitHub’е. Возможно вести его в формате,
-    очень похожем на формат проекта Keep a Changelog, но это, как правило,
-    немного сложнее.
+    Релизы на GitHub’е создают непортируемый лог изменений, который может быть
+    показан пользователям только на самом GitHub’е. Имеется возможность вести такой лог
+    в формате, очень похожем на формат проекта Keep a Changelog, но это, как правило,
+    требует большей вовлечённости в процесс.
 
   %p
     Также возможно, что конечным пользователям не всегда легко обнаружить
@@ -269,8 +269,8 @@ version: 1.1.0
 
   %p
     #{link_to "Vandamme", vandamme} — это gem для Ruby, созданный командой
-    Gemnasium и способный парсить многие (но не все)
-    логи изменений проектов с открытым исходным кодом.
+    Gemnasium и способный парсить логи изменений во многих (но не всех)
+    проектах с открытым исходным кодом.
 
 
   %h4#yanked
@@ -293,17 +293,17 @@ version: 1.1.0
 
   %h4#rewrite
     %a.anchor{ href: "#rewrite", aria_hidden: "true" }
-    Имеет ли смысл переписывать лог изменений?
+    Следует ли вам когда-либо переписывать лог изменений?
 
   %p
-    Конечно. Всегда есть веские причины для улучшения лога изменений.
+    Конечно. Всегда есть веские причины для усовершенствования лога изменений.
     Я регулярно подаю pull request’ы на добавление недостающих выпусков в проекты
     с открытым исходным кодом, которые оставили свои логи изменений без сопровождения.
 
   %p
-    Возможно, вы обнаружите, что забыли указать критичное
-    изменение в примечании к версии. Очевидно, что в этом случае вам важно
-    обновить ваш лог изменений.
+    К тому же, возможно, вы обнаружите, что в примечании к версии
+    забыли рассмотреть одно из критичных изменений. Важность того,
+    что в этом случае вы обновите ваш лог изменений, очевидна.
 
 
   %h4#contribute