Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 11 Apr 2016 08:24:05 +0000 (UTC)
From:      Ryusuke SUZUKI <ryusuke@FreeBSD.org>
To:        doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org
Subject:   svn commit: r48562 - head/ja_JP.eucJP/articles/problem-reports
Message-ID:  <201604110824.u3B8O5R1060600@repo.freebsd.org>

next in thread | raw e-mail | index | archive | help
Author: ryusuke
Date: Mon Apr 11 08:24:05 2016
New Revision: 48562
URL: https://svnweb.freebsd.org/changeset/doc/48562

Log:
  - Merge the following from the English version:
  
  	r47367 -> r48208	head/ja_JP.eucJP/articles/problem-reports/article.xml
  
  - Refine translation.
  - Update the link to "How to Report Bugs Effectively" article.

Modified:
  head/ja_JP.eucJP/articles/problem-reports/article.xml

Modified: head/ja_JP.eucJP/articles/problem-reports/article.xml
==============================================================================
--- head/ja_JP.eucJP/articles/problem-reports/article.xml	Sun Apr 10 21:33:25 2016	(r48561)
+++ head/ja_JP.eucJP/articles/problem-reports/article.xml	Mon Apr 11 08:24:05 2016	(r48562)
@@ -3,7 +3,7 @@
 	"http://www.FreeBSD.org/XML/share/xml/freebsd50.dtd">;
 <!--
    The FreeBSD Japanese Documentation Project
-   Original revision: r47367
+   Original revision: r48208
    $FreeBSD$
 -->
 <article xmlns="http://docbook.org/ns/docbook"
@@ -59,9 +59,9 @@
       などのようなそっけなく理解の役に立たない説明によって、
       障害報告があっさり片付けられてしまうことです。
       同様に、ソフトウェア開発者が経験するもっともいらだたしいことの一つは、
-      実際は障害報告ではない単なるサポート要求や
-      何が問題でどのように再現するかについての情報が
-      乏しいまたは欠落している障害報告が殺到することです。</para>
+      実際は障害報告ではない単なるサポート要求や、
+      何が問題でどのように再現するかについての情報が乏しい、
+      または欠落している障害報告が殺到することです。</para>
 
     <para>この記事のねらいは、上手な障害報告の書き方について説明することです。
       上手な障害報告とはどういうものでしょうか?
@@ -128,15 +128,15 @@
 	  ports のメンテナは、新しいバージョンが利用になった際には、
 	  自動的に <application>portscout</application>
 	  から連絡を受けています。
-	  port を最新版へアップデートするためのパッチの提出は、
-	  もちろん歓迎されます。</para>
+	  もちろん port
+	  を最新版へアップデートするためのパッチの提出は歓迎されます。</para>
       </listitem>
 
       <listitem>
 	<para>メンテナンスされていない ports (<varname>MAINTAINER</varname>
 	  が <literal>ports@FreeBSD.org</literal> の ports)
-	  に対する障害報告において、
-	  パッチが添付されていないは、コミッタから取り上げられにくいです。
+	  に対するパッチが添付されていない障害報告は、
+	  コミッタからは取り上げられにくいものです。
 	  メンテナンスされていない port のメンテナになるには、
 	  リクエストの障害報告を提出してください
 	  (パッチがあることは好ましいですが、必須ではありません)。</para>
@@ -159,8 +159,8 @@
       開発者がそれを再現できる可能性も、
       何が悪いのかわかる可能性もありません。
       これはバグが起こらなかったことを意味するわけではありません。
-      しかし、このような状況ではあなたの障害報告がバグの修正に
-      つながる見込みは非常に薄いものです。
+      しかし、このような状況では、
+      あなたの障害報告がバグの修正につながる見込みは非常に薄いものです。
       おまけに、この手のバグは実際は故障したハードディスクや過熱した
       CPU が原因で起きていることが多いのです
       (障害報告を提出する前には必ず、可能なら、
@@ -212,18 +212,19 @@
     <para>ベースシステムの問題で、&os;
       のバージョンについてよく分かっていないなら、まず FAQ の <link
 	xlink:href="&url.books.faq;/introduction.html#LATEST-VERSION">&os;
-	&os; バージョン</link>に関する節を読んでください。
+	バージョン</link>に関する節を読んでください。
       &os; では、
       ベースシステムのいくつかの最新ブランチ以外は修正できません。
       そのため、古いバージョンについて障害報告を提出しても、
-      開発者から問題がまだ起きるか確認するために、
+      開発者からは、問題がまだ起きるかどうかを確認するために、
       サポートされているバージョンにアップグレードするように勧められるだけかもしれません。
       セキュリティオフィサチームが、
       <link xlink:href="&url.base;/security/">
       サポートされているバージョンの一覧</link> を管理しています。</para>
 
     <para>ある port に問題がある場合、まずはじめに Ports Collection
-      の最新版にアップグレードして、まだ問題があるか見てください。
+      の最新版にアップグレードして、
+      まだ問題が起きるかどうかを確認してください。
       これらのアプリケーションは速いペースで変更されるため、
       &os; で完全な最新版以外に対応するのは不可能です。
       アプリケーションの古いバージョンにある問題は、
@@ -241,7 +242,7 @@
       あなたが動かしているものより新しいバージョンで、
       既に修正済みということすらありえます。
       ですから、障害報告を提出する前に自明な場をすべて確認すべきです。
-      &os; については、以下のところになります。</para>
+      &os; では、以下になります。</para>
 
     <itemizedlist>
       <listitem>
@@ -264,14 +265,14 @@
 	    アーカイブ検索</link>を使ってください。
 	  もし、メーリングリストで議論がされていなければ、
 	  自分の問題についてのメッセージを送ってみて、
-	  見落とした点を誰かが見つけてくれるかどうか
+	  見落とした点を誰かが見つけてくれるかどうか、
 	  数日間待ってみると良いでしょう。</para>
       </listitem>
 
       <listitem>
 	<para>ウェブ全体を検索する (任意)。&mdash;
-	  あなたの問題に関係する話題がないか
-	  あなたのお気に入りの検索エンジンを使って探してください。
+	  あなたの問題に関係する話題がないかどうかを、
+	  お気に入りの検索エンジンを使って探してください。
 	  あなたが知りもしなかったか、
 	  検索しようと考えなかったメーリングリストやニュースグループのアーカイブにあたることもあるかもしれません。</para>
       </listitem>
@@ -330,8 +331,9 @@
 	    障害報告は、世界中に配布されるメーリングリストに送られる
 	    (そこでは、<quote>Synopsis</quote> (概要) は
 	    <literal>Subject:</literal> 行に使われます) と共に、
-	    データベースにも入れられます。後でデータベースを synopsis (概要)
-	    で参照する人は、題がついていない障害報告は単に無視することでしょう。
+	    データベースにも登録されます。後でデータベースを synopsis (概要)
+	    で参照する人は、
+	    題がついていない障害報告は単に無視することでしょう。
 	    このデータベースに登録された障害報告は、
 	    誰かが対応済にするまでは残っていることを忘れないでください。
 	    内容不明のものは大抵雑音に埋もれてしまいます。</para>
@@ -512,8 +514,9 @@
 	    これは、既に述べたことではありますが、ここで繰り返しておくに値するでしょう。
 	    Web ベースの検索エンジン <uri
 	      xlink:href="https://bugs.freebsd.org/bugzilla/query.cgi">https://bugs.freebsd.org/bugzilla/query.cgi</uri>;
-	    で調べるのは 1, 2 分程度しかかかりません。
-	    (もちろん、誰もがときどきこれを忘れてしまうという罪を犯しています)。</para>
+	    で調べるのは 1, 2 分程度しかかかりません
+	    (もちろん、
+	    誰もがときどきこれを忘れてしまうという罪を犯しています)。</para>
 	</listitem>
 
 	<listitem>
@@ -568,7 +571,7 @@
 	<option>-u</option> オプションを使って作成してください。
 	開発者があなたの報告を読んで簡単にパッチを適用できるように、
  	修正したファイルの正確な
-	SVN のリビジョン番号が特定できるか確認してください。
+	SVN のリビジョン番号が特定できることを確認してください。
  	カーネルやベースのユーティリティに関しては、新しいコードはすべて
  	&os.current; (SVN の HEAD ブランチ)
  	でテストするべきなので、それに対するパッチが望ましいです。
@@ -601,8 +604,7 @@
 	完了の状態で保持されたままになるだけだからです。</para>
 
       <para>また、障害報告かパッチ自体に明確に指定がなければ、
-	あなたが提出したパッチは修正した元のファイルと同じ条件の
-	ライセンス下にあるものと仮定されることに留意しておくべきです。</para>
+	あなたが提出したパッチは修正した元のファイルと同じ条件のライセンス下にあるものと仮定されることに留意しておくべきです。</para>
     </section>
 
     <section xml:id="pr-writing-filling-template">
@@ -810,7 +812,7 @@
 	    <note>
 	      <para>もし、問題が
 		  <literal>www/<replaceable>someportname</replaceable></literal>
-		という名前の port に関連したものであっても、
+		という名前の port に関連したものである場合には、
 		<literal>ports</literal> カテゴリを選択してください。</para>
 	    </note>
 	  </listitem>
@@ -899,7 +901,7 @@
 	    <listitem>
 	      <para><literal>advocacy:</literal>
 		&os; の世間的なイメージに関する問題。
-		もはや用いられません。</para>
+		今は用いられません。</para>
 	    </listitem>
 
 	    <listitem>
@@ -957,7 +959,7 @@
 
 	    <listitem>
 	      <para><literal>misc:</literal>
-		これらの分類に適合しないその他の分類。(なお、
+		これらの分類に適合しないその他の分類 (なお、
 		本当にここに分類されるべきものは、
 		リリースおよびビルドのための基盤をのぞけば、
 		ほとんどありません。<literal>HEAD</literal>
@@ -1050,9 +1052,8 @@
 	    ここには、オペレーティングシステムのバージョン、
 	    特定のプログラムのバージョンまたは問題があるファイル、
 	    そしてシステムの設定などのような関係する項目、
-	    問題に影響を及ぼすインストールしたその他の
-	    ソフトウェアなどが含まれます。&mdash;
-	    手短にいうなら、その問題が生じる環境を再構築するために、
+	    問題に影響を及ぼすインストールしたその他のソフトウェアなどが含まれます。
+	    &mdash; 手短にいうなら、その問題が生じる環境を再構築するために、
 	    開発者が知らなければならないことすべてです。</para>
 	</listitem>
 
@@ -1060,7 +1061,7 @@
 	  <para><emphasis>Description:</emphasis>
 	    あなたが経験した問題の完全で正確な説明。
 	    開発者が誤解してしまうかもしれないので、
-	    問題の原因について正しく追跡ができたと確信していない限り
+	    問題の原因について正しく追跡ができたと確信していない限り、
 	    推測は避けるようにしてください。</para>
 	</listitem>
 
@@ -1218,9 +1219,9 @@
       <listitem>
 	<para><link
 	    xlink:href="http://www.chiark.greenend.org.uk/~sgtatham/bugs.html">;
-	    効果的にバグを報告するには</link>
-	  (<link xlink:href="http://www.unixuser.org/~ueno/bugs-ja.html">;
-	    日本語訳</link>) &mdash;
+	    How to Report Bugs Effectively</link>
+	  (<link
+	    xlink:href="http://www.chiark.greenend.org.uk/~sgtatham/bugs-jp.html">日本語訳</link>) &mdash;
 	  Simon G. Tatham 氏による、(&os; に限らない)
 	  役に立つ障害報告の作成についてのすぐれたエッセイ。</para>
       </listitem>
@@ -1228,7 +1229,7 @@
       <listitem>
 	<para><link
 	    xlink:href="&url.articles.pr-guidelines.en;/article.html">
-	  障害報告 取り扱いガイドライン</link> &mdash;
+	  Problem Report Handling Guidelines</link> &mdash;
 	  障害報告が &os; の開発者によってどのように扱われるかについて
 	  有益な見識をまとめた記事。</para>
       </listitem>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201604110824.u3B8O5R1060600>