Fixes.

Sumitted by: Kirill Ponomarew <krion@FreeBSD.org>

ru_RU.KOI8-R/articles/problem-reports/article.sgml

@@ -1,7 +1,7 @@
 <!--
      The FreeBSD Russian Documentation Project
 
-     $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/problem-reports/article.sgml,v 1.7 2003/12/31 10:36:04 marck Exp $
+     $FreeBSDru: frdp/doc/ru_RU.KOI8-R/articles/problem-reports/article.sgml,v 1.13 2004/01/16 18:08:51 andy Exp $
 
      Original revision: 1.28
 -->
@@ -33,14 +33,14 @@
 
     <abstract>
       <para>Эта статья описывает, как наилучшим образом сформулировать и
-	послать сообщение о проблеме в Проект FreeBSD.</para>
+	отправить сообщение о проблеме в Проект FreeBSD.</para>
     </abstract>
 
     <authorgroup>
       <author>
 	<firstname>Dag-Erling</firstname>
 	<surname>Sm&oslash;rgrav</surname>
-	<contrib>Текст предоставил</contrib>
+	<contrib>Текст предоставил </contrib>
       </author>
     </authorgroup>
   </articleinfo>
@@ -50,21 +50,21 @@
   <section id="pr-intro">
     <title>Введение</title>
 
-    <para>Одной из самых разочаровывающим практик, которую можно получить в
-      качестве пользователя программного обеспечения, является посылка
+    <para>Одной из самых разочаровывающих практик, которую можно получить в
+      качестве пользователя программного обеспечения, является отправка
       сообщения о проблеме, которое вскоре закрывается с кратким и ничему не
-      помогающим объяснением типа <quote>это не ошибка</quote> или
+      помогающим объяснением типа <quote>это не проблема</quote> или
       <quote>неправильное PR</quote>.  Подобным же образом одной из самых
-      разочаровывающим практик, которую можно получить в качестве разработчика
+      разочаровывающих практик, которую можно получить в качестве разработчика
       программного обеспечения, является получение массы сообщений о проблемах,
       которые на самом деле не являются сообщениями о проблемах, а запросами на
       получение поддержки, или которые содержат мало или вообще не содержат
-      никакой информации о сути проблемы или способе ее воспроизвести.</para>
+      никакой информации о сути проблемы или способе ее воспроизведения.</para>
 
     <para>В этом документе делается попытка описать то, как составлять хорошие
       сообщения о проблемах.  Что же, спросите вы, является хорошим сообщением
-      об ошибке?  Ну, если перейти прямо к сути, то хорошим сообщением об
-      ошибке является то, которое может быть быстро проанализировано и
+      о проблеме?  Ну, если перейти прямо к сути, то хорошим сообщением об
+      проблеме является то, которое может быть быстро проанализировано и
       отработано, к обоюдному удовлетворению как пользователя, так и
       разработчика.</para>
 
@@ -74,12 +74,12 @@
 
     <para>Заметьте, что эта статья организована по тематическому принципу, а
       не хронологически, так что вы должны прочесть документ целиком прежде,
-      чем посылать сообщение об ошибке, и не воспринимать его как пошаговое
+      чем посылать сообщение о проблеме, и не воспринимать статью как пошаговое
       руководство.</para>
   </section>
 
   <section id="pr-when">
-    <title>Когда нужно посылать сообщение об ошибке</title>
+    <title>Когда нужно отправлять сообщение о проблеме</title>
 
     <para>Имеется много классов ошибок, и не все они должны приводить к
       появлению сообщения о проблеме.  Конечно же, нет идеальных людей, и
@@ -87,26 +87,26 @@
       деле вы неправильно поняли синтаксис команды или сделали опечатку в
       конфигурационном файле (хотя само по себе это иногда говорит о плохой
       документации или неправильной обработке ошибок в прикладной программе).
-      Есть еще много случаев, когда посылка сообщения об ошибке явно <emphasis>не</emphasis>
+      Есть еще много случаев, когда посылка сообщения о проблеме явно <emphasis>не</emphasis>
       является правильным действием, а только приводит к разочарованию вас и
       разработчиков.  И наоборот, есть случаи, когда может быть нужно послать
       сообщение о чем-то, не являющемся ошибкой&mdash;к примеру, запрос на
       доработку или расширение функциональности.</para>
 
     <para>Но как же определить, что является ошибкой, а что нет?  Простым
-      правилом, которому нужно следовать, является следующее - ваша проблема
+      правилом, которому нужно следовать, является следующее &ndash; ваша проблема
       <emphasis>не</emphasis> является ошибкой, если она формулируется как
       вопрос (обычно в форме <quote>Как сделать X?</quote> или <quote>Где можно
       найти Y?</quote>).  Не всегда это так однозначно, но правило вопроса
       покрывает большинство случаев. Если Вам нужен ответ, лучше всего задать
       свой вопрос в &a.questions;.</para>
 
-    <para>Вот некоторые случаи, в которых может оказаться полезным послать
+    <para>Вот некоторые случаи, в которых может оказаться полезным отправить
       сообщение о чем-то, что не является ошибкой:</para>
 
     <itemizedlist>
       <listitem>
-	<para>Запросы на расширение функций.  Обычно хорошей идеей является
+	<para>Запросы на расширение функциональности.  Обычно хорошей идеей является
 	  озвучивание этого в списках рассылки до того, как посылать сообщение
 	  о проблеме.</para>
       </listitem>
@@ -122,16 +122,16 @@
     <para>Кроме того, если система, на которой вы столкнулись с ошибкой, давно
       не обновлялась, вы должны серьезно подумать об обновлении и попытаться
       воспроизвести проблему на обновленной системе прежде, чем посылать
-      сообщение об ошибке.  Есть лишь несколько вещей, которые выводят из
+      сообщение о проблеме.  Есть лишь несколько вещей, которые выводят из
       себя разработчика больше, чем получение сообщений об уже исправленных
-      ею ошибках.</para>
+      ошибках.</para>
 
     <para>И наконец, ошибка, которую нельзя воспроизвести, вряд ли будет
       исправлена.  Если ошибка возникла только единожды, и вы не можете ее
       воспроизвести, к тому же никто с ней больше не сталкивался, нет никаких
       шансов, что разработчики смогут ее воспроизвести или понять, что делается
       неправильно.  Это не значит, что такого не случается, но это значит, что
-      шансов у вашего сообщения дойти когда либо до стадии исправления ошибки
+      шансов у вашего сообщения дойти когда-либо до стадии исправления ошибки
       очень малы, и вам лучше его не посылать.</para>
   </section>
 
@@ -175,7 +175,7 @@
 
       <listitem>
 	<para>Как вариант, весь веб&mdash;используйте вашу любимую поисковую
-	  систему для нахождения каких-либо ссылок на вашу проблему.  Вы можете
+	  систему для поиска каких-либо ссылок по вашей проблеме.  Вы можете
 	  даже увидеть ссылки на архивы списков рассылки или телеконференций, о
 	  которых вы не знали или не думали там искать.</para>
       </listitem>
@@ -197,11 +197,11 @@
       </listitem>
     </itemizedlist>
 
-    <para>Теперь вам нужно добиться того, чтобы ваше сообщение о проблеме
+    <para>Теперь вам нужно добиться того, чтобы сообщение о проблеме
       попало в нужные руки.</para>
 
     <para>Здесь первым правилом будет то, что если проблема является ошибкой в
-      программном обеспечении сторонних разработчиков (порт или пакадж, которые
+      программном обеспечении сторонних разработчиков (порт или пакет, которые
       вы установили), то вы должны сообщить об ошибке автору программы, а не в
       Проект FreeBSD.  Есть два исключения из этого правила: во-первых, если
       ошибка не проявляется на других платформах, то в этом случае проблема
@@ -211,10 +211,10 @@
 
     <para>Вторым правилом является то, что система отслеживания ошибок FreeBSD
       сортирует сообщения о проблеме в соответствии с категорией, выбранной
-      тем, кто сообщает о проблеме.  Таким образом, если вы выберите
-      неправильную категорию при посылке сообщения о проблеме, есть большая
-      вероятность, что оно будет незамеченно до тех пор, пока кто-нибудь не
-      сменит у него категорию.</para>
+      тем, кто сообщает о проблеме.  Таким образом, если вы выберете
+      неправильную категорию при отправке сообщения о проблеме, есть большая
+      вероятность того, что его не заметят до тех пор, пока кто-нибудь не
+      сменит его категорию.</para>
   </section>
 
   <section id="pr-writing">
@@ -251,18 +251,6 @@
 	    фоне.</para>
 	</listitem>
 
-	<listitem>
-	  <para><emphasis>Не оставляйте поле <quote>Synopsis</quote>
-	    (краткое описание) пустым.</emphasis>  Сообщения о проблемах
-	    попадают как в списки рассылки, которые затем расходятся по всему
-	    миру (в них поле <quote>Synopsis</quote> определяет тему письма),
-	    так и в базу данных.  Просматривающий эту базу, как правило,
-	    пройдет мимо PR с пустым кратким описанием.  Не забудьте, что PR
-	    остается в базе до тех пор, пока кто-либо не закроет его;
-	    сообщение-аноним, скорее всего, просто потеряется на общем
-	    фоне.</para>
-	</listitem>
-
 	<listitem>
 	  <para><emphasis>Избегайте туманных описаний в поле
 	    <quote>Synopsis</quote></emphasis>.  Не стоит предполагать, что
@@ -287,8 +275,9 @@
 	</listitem>
 
 	<listitem>
-	  <para><emphasis>Если вы ведете фрагмент кода, сообщите об
-	    этом.</emphasis>  Если вы&mdash;ответственная персона, можете
+	  <para><emphasis>Если вы отвечаете за исходные тексты, сообщите об
+	    этом.</emphasis>  Если вы отвечаете за часть исходных текстов
+	    (например, порт) можете
 	    добавить в начало поля <quote>Synopsis</quote> строку
 	    <literal>[maintainer update]</literal>, а также установить класс
 	    вашего сообщения (поле <quote>Class</quote>) в
@@ -350,7 +339,7 @@
 	    Почти каждый из тех, кто может заниматься вашим сообщением,
 	    является добровольцем.  Никому не понравятся указания, как и что
 	    делать, когда он и так занимается этим, да еще и по каким-либо
-	    причинам, отличным от денежных.  Вообще говоря, этого подхода
+	    причинам, отличным от финансовых.  Вообще говоря, этого подхода
 	    следует придерживаться, имея дело с любым проектом с Открытыми
 	    Исходными текстами (Open Source).</para>
 	</listitem>
@@ -364,14 +353,14 @@
 	вашего окружения <envar>VISUAL</envar> (или <envar>EDITOR</envar>, если
 	<envar>VISUAL</envar> не задана) задана подходящим образом.</para>
 
-      <para>Следует также проверить, что от вас нормально ходит электронная
-	почта.  Утилита &man.send-pr.1; генерит ваш PR в виде почтового
-	сообщения.  Если с машины, на которой вы запускаете &man.send-pr.1;,
-	нельзя отправить почту, ваше сообщение не дойдет до базы данных GNATS.
-	Об установках электронной почты в FreeBSD можно прочитать в главе
-	<quote>Электронная почта</quote> в Руководстве по FreeBSD по адресу
-	<ulink URL="http://www.FreeBSD.org/doc/ru_RU.KOI8-R/books/handbook/mail.html"></ulink>.
-	</para>
+      <para>Следует также проверить работоспособность системы электронной
+	почты.  Утилита &man.send-pr.1; использует почтовую систему для
+	отправки и отслеживания сообщения о проблеме.  Если с машины, на
+	которой вы запускаете &man.send-pr.1;, нельзя отправить почту,
+        сообщение не попадёт в базу данных GNATS.  О настройке электронной
+        почты во FreeBSD можно прочитать в главе <quote>Электронная
+        почта</quote> Руководства по FreeBSD по адресу <ulink
+        url="http://www.FreeBSD.org/doc/en_US.ISO8859-1/books/handbook/mail.html"></ulink>.</para>
     </section>
 
     <section>
@@ -416,7 +405,7 @@
 	заинтересованных людей привести его к нормальному виду. Также то, что
 	патч будет размещён отдельно от сообщения о проблеме, даёт возможность
 	изменять его не отсылая полный патч в дополнение к изначальному
-	сообщению об ошибке.</para>
+	сообщению о проблеме.</para>
 
       <para>Вы должны также помнить, что пока вы явно не укажете обратного в
 	вашем сообщении о проблеме или в самих патчах, будет предполагаться,
@@ -432,8 +421,8 @@
 	Шаблон состоит из списка полей, некоторые из которых уже заполнены,
 	а некоторые содержат комментарии, объясняющие назначение поля или
 	перечисляющие подходящие значения.  Не беспокойтесь о комментариях; они
-	будут автоматически удалены, если вы их не изменяли, или удалите их
-	сами.</para>
+	будут автоматически удалены, если вы их не изменяли (или удалите их
+	сами).</para>
 
       <para>Вверху шаблона, ниже строк <literal>SEND-PR:</literal> находятся
 	заголовки почтового сообщения.  Вам обычно не нужно их изменять, если
@@ -463,7 +452,7 @@
 
 	<listitem>
 	  <para><emphasis>Organization:</emphasis> Все, что вы захотите здесь
-	    указать.  Это поле не используется ни для чего серьезного.</para>
+	    указать.  Это поле не содержит значительной информации.</para>
 	</listitem>
 
 	<listitem>
@@ -483,7 +472,7 @@
 
 	  <para>Повторим: если к вашему сообщению о проблеме приложен патч,
 	    то, пожалуйста, начните краткое описание с
-	    <literal>[PATCH]</literal>; если вы являетесь ответственным за
+	    <literal>[patch]</literal>; если вы являетесь ответственным за
 	    данную часть кода или порт, можете начать описание с
 	    <literal>[maintainer update]</literal> и/или установить класс
 	    проблемы (поле <quote>Class</quote>) в
@@ -533,7 +522,7 @@
 	    </listitem>
 
 	    <listitem>
-	      <para><literal>conf:</literal> проблемы с настроечными файлами,
+	      <para><literal>conf:</literal> проблемы с файлами настройки,
 		используемыми по умолчанию значениями и прочее.</para>
 	    </listitem>
 
@@ -544,7 +533,7 @@
 
 	    <listitem>
 	      <para><literal>gnu:</literal> проблемы с программным обеспечением
-		GNU, таки, как &man.gcc.1; или &man.grep.1;.</para>
+		GNU, таким как &man.gcc.1; или &man.grep.1;.</para>
 	    </listitem>
 
 	    <listitem>
@@ -654,8 +643,8 @@
 	  <para><emphasis>Description:</emphasis> Полное и точное описание
 	    проблемы, с которой вы столкнулись.  Попытайтесь избежать своих
 	    предположений о причинах проблемы, если только вы не
-	    уверены, что правы, так как разработчик может сделать неправильные
-	    предположения о проблеме.</para>
+	    уверены, что правы, так как вы можете привести разработчика к
+	    неправильным предположениям о проблеме.</para>
 	</listitem>
 
 	<listitem>
@@ -675,12 +664,12 @@
     </section>
 
     <section>
-      <title>Отсылка сообщения о проблеме</title>
+      <title>Отправка сообщения о проблеме</title>
 
       <para>Как только вы заполните шаблон, сохраните его и выйдете из
 	редактора, &man.send-pr.1; запросит вас
 	<prompt>s)end, e)dit or a)bort?</prompt>.  Вы можете нажать
-	<userinput>s</userinput> для продолжения и посылки сообщения о
+	<userinput>s</userinput> для продолжения и отправки сообщения о
 	проблеме, <userinput>e</userinput> для повторного запуска редактора и
 	выполнения дальнейших изменений, или <userinput>a</userinput> для
 	отказа от вашего сообщения.  Если вы выберете последнее, то ваше
@@ -706,7 +695,7 @@
       который вы можете использовать для проверки его состояния.  В случае
       удачи кто-нибудь проявит интерес к вашей проблеме и попытается ее
       решить, или, как это бывает, описать, почему это не является проблемой.
-      Вы будет автоматически оповещаться о любом изменении состояния и получать
+      Вы будете автоматически оповещаться о любом изменении состояния и получать
       копии всех комментариев или патчей, которые будут присоединяться в
       процессе отработки вашего сообщения о проблеме.</para>
 
@@ -717,8 +706,8 @@
       могла знать, к какому сообщению о проблеме его присоединить.</para>
 
     <para>Если сообщение о проблеме остается открытым после того, как проблема
-      была решена, просто пошлите сообщение вдогонку (так, как это описано
-      выше), в котором укажите, что сообщение о проблеме может быть закрыто, и
+      была решена, просто отправьте сообщение (так, как это описано
+      выше), с указанием, что сообщение о проблеме может быть закрыто, и
       если это возможно, объясните, как и когда проблема была устранена.</para>
   </section>
 
@@ -740,7 +729,7 @@
       <listitem>
 	<para><ulink url="../../articles/pr-guidelines/article.html">Problem
 	  Report Handling Guidelines</ulink>&mdash;интересный взгляд на
-	  обработку сообщений об ошибках самими разработчиками FreeBSD.</para>
+	  обработку сообщений о проблемах самими разработчиками FreeBSD.</para>
        </listitem>
     </itemizedlist>
   </section>