Author: mumumu
Date: Wed Aug 22 03:43:17 2007
New Revision: 1063
Log:
- fix translation by convention.txt
Modified:
trunk/ja/ch03.xml
Modified: trunk/ja/ch03.xml
==============================================================================
--- trunk/ja/ch03.xml (original)
+++ trunk/ja/ch03.xml Wed Aug 22 03:43:17 2007
@@ -1880,7 +1880,7 @@
同じ URL を保つようにしておけば、サーチエンジンに捕捉されやすくなります。
これは、利用者にとって大きな利点となるでしょう。
URL を保ち続けるよう心がけるもうひとつの理由としては、
- メーリングリストの投稿やスレッドがバグトラッカー
+ メーリングリストの投稿やスレッドがバグ追跡システム
(<phrase output="printed">本章の後半</phrase>の
<xref linkend="bug-tracker"/> を参照してください)
や他のプロジェクトのドキュメントからリンクされることが多いということもあります。
@@ -3030,7 +3030,7 @@
<para>
「編集可能なデータはすべてバージョン管理下におかなければならない」
という規則には、残念ながらひとつだけ例外があります。
- それがバグトラッカーです。
+ それが バグ追跡システム です。
バグデータベースは編集可能なデータを大量に保持していますが、
技術的な理由により、このデータをバージョン管理することはできません
(バグトラッカーの中には、ちょっとしたバージョン管理機能を独自に実装しているものもあります。
@@ -3666,7 +3666,7 @@
<para>
これまで説明してきたことからも何となくお分かりでしょうが、
特定のリビジョンを参照する際の表記方法は統一しておいたほうがいいでしょう。
- これは、ログメッセージだけでなくメールやバグトラッカーなどでも同じです。
+ これは、ログメッセージだけでなくメールやバグ追跡システムなどでも同じです。
CVS を使っているのなら、
"<literal>path/to/file/in/project/tree:REV</literal>"
という形式をお勧めします。ここで、REV は CVS のリビジョン番号
@@ -3927,12 +3927,12 @@
-->
<para>
- バグ追跡は扱う範囲が広い話題です。
- つまり、この本ではバグ追跡についての様々な側面を議論しています。
- ここではバグ追跡システムをセットアップすることと、
- その作業に関する技術的な考察をすることに集中したいと思います。
- その話題に入る前に、バグ追跡の方針に関する質問から始めましょう。
- : 具体的にどんな情報をバグ追跡システムに保存すべきなのでしょうか?
+ バグ追跡 は扱う範囲が広い話題です。
+ この本では バグ追跡 についての様々な側面を議論しています。
+ ここでは バグ追跡システム をセットアップすることと、
+ その作業に関する技術的な考察をすることに集中しようと思います。
+ その話題に入る前に、バグ追跡 の方針に関する質問から始めましょう。
+ : 具体的にどんな情報を バグ追跡システム に保存すべきなのでしょうか?
</para>
<!--
@@ -3953,16 +3953,17 @@
<firstterm>バグ追跡システム</firstterm> は、誤解を招きやすい用語です。
バグ追跡システム は、新しい機能要望や、一度限りのタスク、
送られてきたパッチ — はじまりと終わりの状態があるすべてのもの、
- 存在している間に情報が発生するものをすべて追跡するためによく使われます。
- このため、バグ追跡システムは、
+ 存在している間に情報が発生するすべてのものを追跡するためによく使われます。
+ このため、バグ追跡システム は、
<firstterm>問題追跡システム</firstterm>、
<firstterm>不具合追跡システム</firstterm>、
<firstterm>影響追跡システム</firstterm>、
<firstterm>要望追跡システム</firstterm>、
<firstterm>チケットシステム</firstterm> などとも呼ばれています。
- バグ追跡システムのソフトウェアの一覧は、<xref linkend="bug-trackers"/> を参照してください。
+ バグ追跡システム のソフトウェアの一覧は、<xref linkend="bug-trackers"/> を参照してください。
</para>
+<!--
<para>In this book, I'll continue to use "bug tracker" for the
software that does the tracking, because that's what most people call
it, but will use <firstterm>issue</firstterm> to refer to a single
@@ -3972,6 +3973,19 @@
bug's discovery, diagnosis, and eventual resolution. Keep in mind
that although most issues are about actual bugs, issues can be used to
track other kinds of tasks too.</para>
+-->
+
+<para>
+ この本では "バグ追跡システム" という用語を、
+ 物事を追跡するソフトウェアを指すものとして使うことにします。
+ なぜなら、殆どの人が バグ追跡システム と呼んでいるからです。
+ しかし、バグ追跡システム のデータベースに登録される個々のアイテムを指すものとして、
+ <firstterm>問題</firstterm> という用語を使います。
+ これによってユーザーが遭遇するソフトウェアの変な振る舞い（つまり、バグです）と、
+ バグの発見、診断、解決に関する <emphasis>記録</emphasis> を区別できるからです。
+ 殆どの 問題 は実際に起こったバグに関するものですが、
+ 他のタスクに関することでも 問題 という用語が使えるということを覚えておいてください。
+</para>
<para>The classic issue life cycle looks like this:
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
