diff --git a/source/ru/1.0.0/index.html.haml b/source/ru/1.0.0/index.html.haml
index 7abcbc9..126bb16 100644
--- a/source/ru/1.0.0/index.html.haml
+++ b/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
diff --git a/source/ru/1.1.0/index.html.haml b/source/ru/1.1.0/index.html.haml
index 63ee9e6..855d41f 100644
--- a/source/ru/1.1.0/index.html.haml
+++ b/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