Translate the missing pages in the "Contribution" section (ru) (#3929)

* Translate Mailing Lists page (ru)

* Translate Posting Guidelines for the Ruby-Talk Mailing List page (ru)

* Translate Patch Writer’s Guide (ru)

* Returne a bracket that was accidentally deleted

Author: ablzh

ru/community/mailing-lists/index.md

@@ -1,6 +1,6 @@
 ---
 layout: page
-title: "Почтовая рассылка"
+title: "Почтовые рассылки"
 lang: ru
 ---
 
@@ -12,7 +12,7 @@ lang: ru
 
 Ruby-Talk
 : Это наиболее популярная почтовая рассылка, рассматривая основные
-  вопросы о Ruby. ([Архив][3])
+  вопросы о Ruby. ([Архив][3], [Posting Guidelines][guidelines], [Community Archive][rubytalk])
 
 Ruby-Core
 : Эта рассылка для обсуждения ядра и внутреннего устройства Ruby. Часто
@@ -27,15 +27,19 @@ Ruby-CVS
 
 Новостная группа comp.lang.ruby
 : Те, кто предпочитает Usenet почтовой рассылке, возможно захотят
-взглянуть на [comp.lang.ruby](news:comp.lang.ruby) новостную группу.
+взглянуть на [comp.lang.ruby](news:comp.lang.ruby) новостную группу. ([FAQ][clrFAQ])
 
 
 ## Подписаться или не подписаться
 
-[Подписаться или не подписаться](https://ml.ruby-lang.org/mailman3/lists/)
-
+Смотрите [https://ml.ruby-lang.org/mailman3/lists/](https://ml.ruby-lang.org/mailman3/lists/)
+для дополнительной информации обо всех списках рассылки на ruby-lang.org,
+включая списки на японском языке.
 
 
+[guidelines]: ruby-talk-guidelines/
+[clrFAQ]: http://rubyhacker.com/clrFAQ.html
 [3]: https://ml.ruby-lang.org/archives/list/ruby-talk@ml.ruby-lang.org/
 [4]: https://ml.ruby-lang.org/archives/list/ruby-core@ml.ruby-lang.org/
 [5]: https://ml.ruby-lang.org/archives/list/ruby-doc@ml.ruby-lang.org/
+[rubytalk]: https://rubytalk.org/

ru/community/mailing-lists/ruby-talk-guidelines/index.md

@@ -1,82 +1,62 @@
 ---
 layout: page
-title: "Posting Guidelines for the Ruby-Talk Mailing List"
+title: "Правила публикации в списке рассылки Ruby-Talk"
 lang: ru
 ---
 
-You should follow these guidelines when posting to the ruby-talk mailing list.
+Вы должны следовать этим правилам при публикации в списке рассылки ruby-talk.
 {: .summary}
 
 
-1. **Always** be friendly, considerate, tactful, and tasteful. We want to
-   keep this list hospitable to the growing ranks of newbies, very
-   young people, and their teachers, as well as cater to fire breathing
-   wizards. :-)
+1. **Всегда** будьте дружелюбны, внимательны, тактичны и вежливы. Мы хотим, чтобы этот список оставался гостеприимным для растущего числа новичков, совсем юных участников и их учителей, а также отвечал потребностям огнедышащих магов. :-)
 
-2. Keep your content relevant and easy to follow. Try to keep your
-   content brief and to the point, but also try to include all relevant
-   information.
+2. Следите за тем, чтобы ваш контент был релевантным и легко читаемым. Старайтесь излагать свои мысли кратко и по существу, но при этом включайте всю необходимую информацию.
 
-   1. The general format guidelines (aka Netiquette) are
-      matters of common sense and common courtesy that make life
-      easier for third parties to follow along (in real time or when
-      perusing archives):
+   1. Общие правила форматирования (так называемый Нетикет) — это вопросы здравого смысла и элементарной вежливости, которые облегчают жизнь третьим лицам при чтении (в реальном времени или при изучении архивов):
 
-      * **Please note:**
-        Include quoted text from previous posts **before** your responses
-        and **selectively** quote as much as is relevant.
-      * Use **plain text**; don't use HTML, RTF, or Word.
-        Most email programs have an option for this; if yours doesn't,
-        get a (free) program or use a web-based service that does.
-      * Include examples from files as **in-line** text; don't use
-        attachments.
+      * **Обратите внимание:** Вставляйте цитируемый текст из предыдущих сообщений **перед** вашими ответами и цитируйте **выборочно**, только то, что имеет отношение к делу.
+      * Используйте **обычный текст** (plain text); не используйте HTML, RTF или Word. В большинстве почтовых программ есть такая опция; если в вашей её нет, скачайте (бесплатную) программу или воспользуйтесь веб-сервисом, где она есть.
+      * Включайте примеры из файлов как **встроенный** (in-line) текст; не используйте вложения.
 
-   2. If reporting a problem, give **all** the relevant information
-      the first time; this isn't the psychic friends newsgroup. :-)
+   2. Если сообщаете о проблеме, предоставляйте **всю** релевантную информацию сразу; это не новостная группа экстрасенсов. :-)
 
-      When appropriate, include:
+      Если уместно, укажите:
 
-      * an example (preferably simple) that produces the problem
-      * the actual error messages
-      * the version of Ruby (`ruby -v`)
-      * the OS type and version (`uname -a`)
-      * the compiler name and version used to build Ruby
+      * пример (желательно простой), который воспроизводит проблему
+      * фактические сообщения об ошибках
+      * версию Ruby (`ruby -v`)
+      * тип и версию ОС (`uname -a`)
+      * название и версию компилятора, использованного для сборки Ruby
 
-3. Make the subject line maximally informative, so that people who
-   should be interested will read your post and so that people who
-   wouldn't be interested can easily avoid it.
+3. Сделайте тему письма максимально информативной, чтобы люди, которым это должно быть интересно, прочитали ваш пост, а те, кому это не интересно, могли легко его пропустить.
 
-   **Usefully** describe the contents of your post.
+   **Полезно** опишите содержимое вашего поста.
 
-   This is OK:
+   Так правильно:
 
    * "How can I do x with y on z?"
    * "Problem: did x, expected y, got z."
    * "BUG: doing x with module y crashed z."
 
-   This is **not** OK:
+   Так **не** правильно:
 
    * "Please help!!!"
    * "Newbie question"
    * "Need Ruby guru to tell me what's wrong"
 
-   These prefixes have become common for subject lines:
+   Эти префиксы стали общепринятыми для тем сообщений:
 
-   * `[ANN]` (for announcements)
-   * `[BUG]` (for bug reports)
-   * `[OT]`  (for off-topic, if you must post off-topic)
+   * `[ANN]` (для анонсов)
+   * `[BUG]` (для отчетов об ошибках)
+   * `[OT]`  (для оффтопа, если вам необходимо написать не по теме)
 
-4. Finally, be considerate: Don't be too lazy. If you are seeking
-   information, first make a reasonable effort to look it up. As
-   appropriate, check the [Ruby home page][ruby-lang],
-   check the [Ruby FAQ][faq] and other documentation,
-   use a search engine to search past postings, and so on.
+4. Наконец, будьте внимательны: не ленитесь. Если вы ищете информацию, сначала приложите разумные усилия, чтобы найти её самостоятельно. По мере необходимости проверяйте [домашнюю страницу Ruby][ruby-lang], [Ruby FAQ][faq] и другую документацию, используйте поисковик для поиска прошлых публикаций и так далее.
 
 
-_These guidelines where adopted from the [comp.lang.ruby FAQ][clrFAQ]._
+_Эти правила были заимствованы из [comp.lang.ruby FAQ][clrFAQ]._
 
 
 
-[ruby-lang]: /en/
-[faq]: /en/documentation/faq/
+[ruby-lang]: /ru/
+[faq]: /ru/documentation/faq/
 [clrFAQ]: http://rubyhacker.com/clrFAQ.html

ru/community/ruby-core/writing-patches/index.md

@@ -1,52 +1,36 @@
 ---
 layout: page
-title: "Patch Writer’s Guide"
+title: "Руководство по написанию патчей"
 lang: ru
+translator: "ablzh"
 ---
 
-Here follow some tips, straight from Matz, on how to get
-your patches considered.
+Ниже приведены несколько советов, полученных непосредственно от Matz, о том, как добиться рассмотрения ваших патчей.
 {: .summary}
 
-These guidelines were adopted from a [post by Matz][ruby-core-post]
-on the Ruby-Core mailing list:
+Эти рекомендации были взяты из [сообщения Matz][ruby-core-post] в списке рассылки Ruby-Core:
 
-* Implement one modification per patch
+* Вносите одно изменение в один патч
 
-  This is the biggest issue for most deferred patches. When you
-  submit a patch that fixes multiple bugs (and adds features) at once,
-  we have to separate them before applying it. It is a rather hard task
-  for us busy developers, so this kind of patches tends to be deferred.
-  No big patches please.
+  Это самая большая проблема для большинства отложенных патчей. Когда вы отправляете патч, который исправляет несколько ошибок (и добавляет новые функции) одновременно, нам приходится разделять их перед применением. Это довольно сложная задача для нас, занятых разработчиков, поэтому такие патчи, как правило, откладываются. Пожалуйста, не присылайте большие патчи.
 
-* Provide descriptions
+* Предоставляйте описание
 
-  Sometimes a mere patch does not sufficiently describe the problem it fixes.
-  A better description (the problem it fixes, preconditions, platform, etc.)
-  would help a patch to be merged earlier.
+  Иногда сам патч недостаточно описывает проблему, которую он исправляет. Более подробное описание (исправляемая проблема, условия, платформа и т. д.) помогло бы быстрее принять патч.
 
-* Diff to the latest revision
+* Создавайте diff относительно последней ревизии
 
-  Your problem might have been fixed in the latest revision. Or the code
-  might be totally different by now. Before submitting a patch, try to fetch
-  the latest version (the `trunk` branch for the latest development version,
-  `{{ site.svn.stable.branch }}` for {{ site.svn.stable.version }})
-  from the Subversion repository, please.
+  Ваша проблема, возможно, уже была исправлена в последней ревизии. Или код к настоящему моменту может полностью отличаться. Пожалуйста, перед отправкой патча постарайтесь получить последнюю версию (ветку `trunk` для последней разрабатываемой версии, `{{ site.svn.stable.branch }}` для {{ site.svn.stable.version }}) из репозитория Subversion.
 
-* Use `diff -u`
+* Используйте `diff -u`
 
-  We prefer `diff -u` style unified diff patches to `diff -c`
-  or any other style of patches. They are far easier to review.
-  Do not send modified files, we do not want to make a diff by ourselves.
+  Мы предпочитаем патчи в формате unified diff (`diff -u`), а не `diff -c` или любые другие стили патчей. Их гораздо легче рецензировать. Не присылайте измененные файлы, мы не хотим делать diff самостоятельно.
 
-* Provide test cases (optional)
+* Предоставляйте тест-кейсы (опционально)
 
-  A patch providing test cases (preferably a patch to `test/*/test_*.rb`)
-  would help us understand the patch and your intention.
+  Патч, содержащий тест-кейсы (желательно патч для `test/*/test_*.rb`), поможет нам лучше понять патч и ваши намерения.
 
-We might move to a Git style push/pull workflow in the future.
-But until then, following the above guidelines would help you to avoid
-frustration.
+В будущем мы можем перейти на рабочий процесс в стиле Git (push/pull). Но до тех пор соблюдение приведенных выше рекомендаций поможет вам избежать разочарований.
 
 
 [ruby-core-post]: https://blade.ruby-lang.org/ruby-core/25139