Author: mumumu
Date: Fri Aug 31 14:27:27 2007
New Revision: 1135

Log:
- trivial fix
- deleted useless space


Modified:
   trunk/ja/ch03.xml

Modified: trunk/ja/ch03.xml
==============================================================================
--- trunk/ja/ch03.xml   (original)
+++ trunk/ja/ch03.xml   Fri Aug 31 14:27:27 2007
@@ -4155,7 +4155,7 @@
             <para>
             問題が解決されます。(タスクが終了したり、
             パッチが適用されたりとか、そういったものです)
-            行った変更は、問題の<firstterm>処理が完了</firstterm>したり、
+            行った変更は、問題の <firstterm>処理が済んだ</firstterm> り、
             <firstterm>解決済み</firstterm> とマークされたあとに、
             コメントとして記録するようにしましょう。
             </para>
@@ -4222,12 +4222,12 @@
 
 <para>
     別のバリエーションとして、
-    1. のすぐ後で問題が <firstterm>重複している</firstterm> として 処理済み とされる場合があります。
+    1. のすぐ後で問題が <firstterm>重複している</firstterm> として処理済みにされる場合があります。
     重複した問題は、プロジェクトが既に認識している問題を誰かがまた報告すると発生します。
     重複した状態は 保留中 の問題で発生するとは限りません。
     解決したあとで再び報告される(この状態を <firstterm>リグレッション(回帰)</firstterm> と呼びます)こともあります。
     こういう場合は、重複の元となった問題を 再度保留中の状態にして、
-    重複した問題は 処理済み としてしまうのが普通は望ましいでしょう。
+    重複した問題は処理済みにしてしまうのが普通は望ましいでしょう。
     バグ追跡システムは、
     問題を再現する情報ははじめに報告された問題で見られるように(逆も同様)、
     問題同士の関連を追跡しているはずです。
@@ -4243,7 +4243,7 @@
 -->
 
 <para>
-    開発者が問題を処理済みとする3つ目のバリエーションは、
+    開発者が問題を処理済みにする3つ目のバリエーションは、
     問題を解決したと思い込んで処理済みにするパターンです。
     これは結局、問題を報告した人がそれを拒んで再度保留中にする結果になります。
     これは開発者が単にバグを再現するのに必要な環境にアクセスできないか、
@@ -4321,9 +4321,9 @@
     -->
 
     <para>
-        問題を報告することを含めた、問題の状態を変更するあらゆる行動が、
-        何が起きているのかを説明した上でメールで投稿されるように、
         バグ追跡システムをメーリングリストと接続しなければいけません。
+        これは、問題を報告することを含めた、問題の状態を変更するあらゆる行動が、
+        メールで投稿されるようにするためです。
         このメーリングリストは通常使う開発用のものとは違うのが普通です。
         なぜなら、開発者全員が自動送信されるバグ報告メールを受け取りたいとは限らないからです。
         しかし、(コミットメールと同様に) Reply-to ヘッダは開発用のメーリングリストのアドレスに設定しておきましょう。
@@ -4495,7 +4495,7 @@
 <para>
     この問題を避けるために何より実行すべきことがふたつあります。
     バグではない問題や、
-    重複したバグ報告を報告されたらすぐに 処理済み とマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。
+    重複したバグ報告を報告されたらすぐに 処理済みとマークできる十分な知識がある人にバグ報告システムを見張ってもらうこと。
     そしてバグ報告システムにバグを報告する前に、
     他の人とバグかどうかを確認するようユーザーに求める(または強く勧める)ことです。
 </para>
@@ -4629,7 +4629,7 @@
     報告された問題が明らかに正しいもので重複していない場合は、
     とりあえずそれを受け入れて通常のライフサイクルを開始します。
     結局、報告した人はバグかどうかを誰かに見てもらうべきだと言われているので、
-    正しいバグ報告を処理済みとするまで労力を無駄にする点はありません。
+    正しいバグ報告を処理済みにするまで労力を無駄にする点はありません。
     </para>
   </listitem>
   <listitem>
@@ -4669,7 +4669,7 @@
     できるだけ多くの人達の助けを得ようとした方がよいでしょう。
 </para>
 
-<para><phrase output="printed"><xref linkend="managing-volunteers"/> の 
</phrase>xref linkend="issue-manager"/> も参照してください。</para>
+<para><phrase output="printed"><xref linkend="managing-volunteers"/> の 
</phrase><xref linkend="issue-manager"/> も参照してください。</para>
 
 </sect2>
 

_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators

Reply via email to