Author: matakagi
Date: Sat Sep 15 12:05:38 2007
New Revision: 1174
Log:
translated "Content".
Modified:
trunk/ja/ch06.xml
Modified: trunk/ja/ch06.xml
==============================================================================
--- trunk/ja/ch06.xml (original)
+++ trunk/ja/ch06.xml Sat Sep 15 12:05:38 2007
@@ -453,12 +453,24 @@
<!-- ======================== subsection ============================== -->
<sect2 id="writing-content">
+<!--
<title>Content</title>
+-->
+<title>中身</title>
+<!--
<para>Well-formatted mails attract readers, but content keeps them.
No set of fixed rules can guarantee good content, of course, but there
are some principles that make it more likely.</para>
+-->
+<para>
+ きれいに体裁を整えたメールは読者の気を引くことでしょう。
+ しかし、実際に読んでもらうには中身が大切です。
+ 「これさえ守れば中身のある内容を書ける」というようなルールはもちろんありません。
+ しかし、それに近づくための原則ならいくつかあげることができます。
+</para>
+<!--
<para>Make things easy for your readers. There's a ton of information
floating around in any active open source project, and readers cannot
be expected to be familiar with most of it—indeed, they cannot
@@ -479,7 +491,32 @@
increase in the global efficiency of the project: when there is a
choice between <emphasis>n</emphasis> people making an effort and one
person doing so, the project prefers the latter.</para>
+-->
+<para>
+ 読む人のことを考えて書くようにしましょう。
+ 活発に活動しているオープンソースプロジェクトには、
+ さまざまな情報が付きまとっています。メールの読み手が、
+ それらの情報をすべて知っているものと期待してはいけません。
+ 実際のところ、彼らはそんな情報など知ろうともしないこともあるものです。
+ 可能な限り、読み手にとって便利な情報を提供するようにしましょう。
+ たとえば、ほんの数分時間を使うだけで、
+ メーリングリストのアーカイブで特定のスレッドを表す URL を調べることができます。
+ それを示すことで、読み手が同じことをする手間を省くことができるでしょう。
+ さらに 5 分から 10 分ほど余計に時間を割けば、
+ 複雑になったスレッドの簡単なまとめを作成することもできるでしょう。
+ これは、あなたの投稿の背景にある話の流れを伝えるのに役立ちます。
+ こんな風に考えてみましょう。プロジェクトがうまくいけばいくほど、
+ メーリングリストや掲示板の書き手に対する読み手の比率が高くなります。
+ あなたの投稿する内容が <emphasis>n</emphasis> 人に読まれているとすると、
+ あなたがちょっと時間を使って作業をするだけで <emphasis>n</emphasis>
+ 人ぶんの同じ時間を節約できるようになるわけです。<emphasis>n</emphasis>
+ が大きくなればなるほど、この価値は向上します。
+ そしてあなたがそうしているのを見れば、他の人たちも同じようにしてくれるようになるでしょう。
+ その結果、プロジェクト全体の効率が向上することになります。<emphasis>n</emphasis>
+ 人が苦労するのと一人が苦労するのとどちらがいいかといえば、後者でしょう。
+</para>
+<!--
<para>Don't engage in hyperbole. Exaggerating in online posts is a
classic arms race. For example, a person reporting a bug may worry
that the developers will not pay sufficient attention, so he'll
@@ -489,22 +526,56 @@
exaggeration is not limited to users—programmers often do the
same thing during technical debates, particularly when the
disagreement is over a matter of taste rather than correctness:</para>
+-->
+<para>
+ 物事を誇張しないようにしましょう。
+ オンラインの投稿では、話が大げさになりがちです。
+ たとえばバグを報告する人は、開発者たちの気を引くように
+ わざと大げさに話すこともあります。ちょっと気になる点が見つかったときに
+ 「この深刻な問題のおかげで、私 (そして友人や同僚や親戚一同)
+ はまともにこのソフトウェアを使うことができない」
+ といった具合に報告するわけです。
+ しかし、この問題はユーザからの報告に限ったことではありません。
+ プログラマたちだって、技術的な議論をしているときに同じようなことをしています。
+ 特に、どちらが正しいかという問題より
+ 各自の好みにかかわるような問題を扱う際にその傾向があります。
+</para>
<blockquote>
+<!--
<para>"Doing it that way would make the code totally
unreadable. It'd be a maintenance nightmare, compared to
J. Random's proposal..."</para>
+-->
+ <para>
+ "そのやりかただと、コードが読みにくくなっちゃうよ。
+ 保守する人はたまったもんじゃないだろうな。それに引き換え
+ J. Random の提案した方法は..."
+ </para>
</blockquote>
+<!--
<para>The same sentiment actually becomes
<emphasis>stronger</emphasis> when phrased less sharply:</para>
+-->
+<para>
+ もう少し控えめな言いかたにしたほうが、実際の気持ちは伝わりやすくなります。
+</para>
<blockquote>
+<!--
<para>"That works, but it's less than ideal in terms of
readability and maintainability, I think. J. Random's proposal
avoids those problems because it..."</para>
+-->
+ <para>
+ "たしかにそれでも動くよ。でも、可読性や保守性を考えると、
+ それは理想的なやりかたではないと思うんだ。J. Random
+ の提案する方法だとそんな問題は発生しない。なぜなら..."
+ </para>
</blockquote>
+<!--
<para>You will not be able to get rid of hyperbole completely, and in
general it's not necessary to do so. Compared to other forms of
miscommunication, hyperbole is not globally damaging—it hurts
@@ -513,7 +584,19 @@
the sake of your own influence in the project, try to err on the side
of moderation. That way, when you <emphasis>do</emphasis> need to
make a strong point, people will take you seriously.</para>
+-->
+<para>
+ 誇大表現を完全になくすことは不可能でしょうし、また一般にそうする必要もありません。
+ 他の誤解に比べると、誇大表現が及ぼす被害はそれほどでもありません。
+ 主に書き手側が損をするだけのことです。
+ 読み手側はそれを補正して読めるので、単に書き手が少し信頼性を失うというだけだからです。
+ プロジェクトにおけるあなたの影響力を考えると、
+ 不要な誇大表現は避けるようにしておくべきです。
+ そうすると、<emphasis>あえて</emphasis>キツめに表現する必要が生じた場合に
+ 周りの人たちにそれを受け入れてもらいやすくなります。
+</para>
+<!--
<para>Edit twice. For any message longer than a medium-sized
paragraph, reread it from top to bottom before sending it but after
you think it's done the first time. This is familiar advice to anyone
@@ -527,6 +610,21 @@
recognizable as such, much to the chagrin (or so one would hope) of
their authors. Take the time to review what you send. The more your
posts hold together structurally, the more they will be read.</para>
+-->
+<para>
+ よく見直すようにしましょう。
+ ある程度以上の量の文章を書いた場合は、完成した文章を実際に送信する前に
+ もう一度頭から読み直すようにします。作文の授業でも同じことを教わったかと思いますが、
+ これはオンラインの議論でも特に重要です。オンラインの議論は断続的なものになる傾向があるので
+ (メッセージを書いている途中で過去のメールを読み直したり、何かのウェブページを確認したり、
+ 何らかのコマンドを実行してデバッグ出力を取り込んだり、……)、ついつい論旨を見失いがちです。
+ 断続的に書き上げたあとで一切チェックせずに送信したメッセージは、
+ 読み手にもそのように受け取られてしまいがちです。
+ これは書き手にとってもうれしいことではありません。
+ きちんと時間をとって、書いた内容を見直すようにしましょう。
+ 投稿内容がきちんとまとまっていればいるほど、
+ あなたのメッセージを読んでもらいやすくなるでしょう。
+</para>
</sect2>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
