Author: matakagi
Date: Sat Sep 15 02:23:04 2007
New Revision: 1169

Log:
translated "Structure and Formatting".


Modified:
   trunk/ja/ch06.xml

Modified: trunk/ja/ch06.xml
==============================================================================
--- trunk/ja/ch06.xml   (original)
+++ trunk/ja/ch06.xml   Sat Sep 15 02:23:04 2007
@@ -253,15 +253,19 @@
 give a good impression too.</para>
 -->
 <para>
-  彼の文面がとても 13 才のガキのようなものには見えなかったので、
+  彼の文面がとても 13 才のガキが書いたのようなものには見えなかったので、
   誰もそんなことは想像していなかったのです。
   皆に気に入られるようなものの書き方について、これからみていきましょう。
 </para>
 
 <!-- ======================== subsection ============================== -->
 <sect2 id="structure-and-formatting">
+<!--
 <title>Structure and Formatting</title>
+-->
+<title>構成や体裁</title>
 
+<!--
 <para>Don't fall into the trap of writing everything as though it were
 a cell phone text message.  Write in complete sentences, capitalizing
 the first word of each sentence, and use paragraph breaks where
@@ -280,10 +284,41 @@
 means more people will understand what you write, but because it makes
 you look like the sort of person who takes the time to communicate
 clearly: that is, someone worth paying attention to.</para>
+-->
+<para>
+  ケータイのメールじゃないんだから、
+  何も考えずにただだらだら書き連ねるといったことはやめましょう。
+  ちゃんとした文を書き、単語の先頭はちゃんと大文字にして、
+  適切に段落分けをするようにしなければなりません。
+  これは、メールだけでなくその他のちゃんとした文書においても最も重要なことです。
+  IRC のようなその場限りのやりとりの場合は、
+  あまりそんなことを気にする必要はありません。
+  略語を使いまくったりしても大丈夫です。
+  しかし、正式な掲示板上などにはそんな習慣を持ち込まないでください。
+  メールやマニュアル、バグ報告などのように後に残ることが前提の文書については、
+  標準的な文法やスペルで書く必要があります。
+  また、きちんと構成されていなければなりません。
+  これは決して「とりあえず長いものには巻かれておけ」
+  とかいう類の話ではありません。ここで挙げた規則は、
+  単なるしきたりといったものではないのです。
+  文書を読みやすくするために進めてきた結果がこれなので、
+  できるだけそれを尊重するようにしましょう。
+  読みやすく書くようにする理由は、
+  他人が理解しやすくなるからというだけではありません。
+  そうすることで、あなたが「他人としっかりコミュニケートするつもりのある人だ」
+  と認められるようになるからという面もあります。
+</para>
 
+<!--
 <para>For email in particular, experienced open source developers have
 settled on certain conventions:</para>
+-->
+<para>
+  メールを書く際には、
+  オープンソース開発者の間で暗黙の了解となっている決まりごとがいくつかあります。
+</para>
 
+<!--
 <para>Send plain text mails only, not HTML, RichText, or other formats
 that might be opaque to text-only mail readers.  Format your lines to
 be around 72 columns long.  Don't exceed 80 columns, which has become
@@ -293,7 +328,22 @@
 <emphasis>less</emphasis> than 80 columns, you leave room for a few
 levels of quoting characters to be added in others' replies without
 forcing a rewrapping of your text.</para>
+-->
+<para>
+  メールではプレーンテキストのみを使用し、
+  HTML やリッチテキストといった形式は避けましょう。
+  テキストにのみ対応したメールソフトでは、
+  他の形式のメールがうまく見えないことがあります。
+  また、半角 72 文字程度で改行を入れるようにしましょう。
+  1 行が 80 文字を超えてはいけません。
+  これ (80 文字) は、端末の画面上で 1 行に表示できる桁数の標準値です。
+  これより広い幅の端末を使っている人もいるでしょうが、
+  これより狭いものを使っている人はいません。
+  80 文字ぎりぎりではなくもう少し余裕を持って改行しておくことで、
+  返信時に引用符を追加しても改行位置を気にする必要がなくなります。
+</para>
 
+<!--
 <para><emphasis>Use real line breaks.</emphasis> Some mailers do a
 kind of fake line wrapping, whereby when you're composing an email,
 the display shows line breaks that aren't actually there.  When the
@@ -301,7 +351,19 @@
 it will wrap awkwardly on some people's screens.  If your mailer might
 use fake line breaks, look for a setting you can tweak to make it show
 the true line breaks as you compose.</para>
+-->
+<para>
+  <emphasis>実際に改行すること。</emphasis>
+  メーラーによっては、メールの作成時にはいかにも改行しているように見せていても、
+  実際のメールでは改行されていないといったものもあります。
+  そのまま送信すると、あなたの意図したところに改行が入っていない状態の
+  メールが送信されることになります。受け取った側の画面によっては、
+  改行の位置がおかしくなってしまうことでしょう。
+  もしあなたがそのようなメーラーを使っているのなら、
+  メール作成時に実際の改行を見せるような設定項目がないか探してみましょう。
+</para>
 
+<!--
 <para>When including screen output, snippets of code, or other
 preformatted text, offset it clearly, so that even a lazy eye can
 easily see the boundaries between your prose and the material you're
@@ -311,7 +373,20 @@
 is which.  The effect is very frustrating.  It makes their posts
 significantly harder to understand, and frankly makes those people
 look a little bit disorganized.)</para>
+-->
+<para>
+  画面の出力やコードの一部、その他フォーマット済みのテキストを記述する場合は、
+  はっきりとわかるように位置をずらしておきましょう。
+  どこからどこまでが地の文でどこからどこまでが引用なのかを明確にしておくことが大切です
+  (本書を執筆しはじめた当初は、こんなことを説明するつもりはありませんでした。
+  しかしさまざまなオープンソース関連のメーリングリストを見ていくうちに、
+  さまざまな種類のテキストを区別せずごちゃごちゃにしている人があまりにも多いことに気づきました。
+  それはそれは非常に読みづらいものでした。
+  そのおかげで彼らの投稿の内容をつかみにくくなるだけでなく、
+  率直に言って彼らはちょっとだらしない人たちだなと感じました)。
+</para>
 
+<!--
 <para>When quoting someone else's mail, insert your responses where
 they're most appropriate, at several different places if necessary,
 and trim off the parts of their mail you didn't use.  If you're
@@ -320,7 +395,20 @@
 above the quoted text of their mail); otherwise, you should quote
 the relevant portion of the original text first, followed by your
 response.</para>
+-->
+<para>
+  他人のメールを引用して返信する際は、
+  適切な場所に返信内容を書くようにしましょう。
+  必要なら、いくつかの場所に分けて書くことになってもかまいません。
+  また、不要な部分は引用しないようにしましょう。
+  もしその投稿全体に対して一言コメントしたいのなら、
+  投稿の先頭 (つまり、あなたの返信を書いた後に
+  メールの引用が続く形式) にそれを記述します。
+  それ以外の場合は、まず関連する箇所を引用したうえで、
+  その後に返信を書きます。
+</para>
 
+<!--
 <para>Construct the subject lines of new mails carefully.  It's the
 most important line in your mail, because it allows each other person
 in the project to decide whether or not to read more.  Modern
@@ -339,6 +427,27 @@
 the penalty would not only be the waste of their time, but the slight
 dent in your credibility as someone fluent in using communications
 tools.</para>
+-->
+<para>
+  メールの件名はよく考えてつけるようにしましょう。
+  これは、メールの中でもっとも重要なものとなります。
+  というのも、プロジェクトの他のメンバーは
+  そのメールを読むかどうかを件名で判断することになるからです。
+  いまどきのメールソフトは、関連するメッセージをスレッドにまとめる機能を持っています。
+  スレッドにまとめるための基準は、
+  件名が同じというだけではなくその他のヘッダの内容も使用します
+  (このヘッダの内容は、表示されないこともあります)。
+  もしひとつのスレッド内で話題が変わるときは、
+  返信の際に件名を適切に変更することもできます (変更すべきです)。
+  その他のヘッダの内容によってスレッドの構成はそのまま保持されますが、
+  件名が変えておくと、そこで話題が変わったことがわかりやすくなります。
+  また、本当に新しい話題を始めたい場合は、新しいメールとして送信するようにします。
+  既存のメールに「返信」して件名だけを変えるというのではいけません。
+  さもないと、あなたの出したメールがスレッドに紛れ込んでしまいます。
+  これによる損失は、単に時間を浪費してしまうことだけではありません。
+  「コミュニケーションツールをうまく使いこなせる人」
+  というあなたの評判も落ちてしまいます。
+</para>
 
 </sect2>
 

_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators

Reply via email to