長南洋一
cyoic****@maple*****
2011年 10月 14日 (金) 12:17:58 JST
長南です。 元木さんが [JM:00446] と [JM:00448] でわたしが言いたいことを 書いてくださったので、雑談になってしまいました。 あちらにもコメントを付けるかもしれません。 Takahashi さんのメールより [JM:00445] >>> .B COMP_KEY >>> .\"O The key (or final key of a key sequence) used to invoke the current >>> .\"O completion function. >>> 現在の補完関数を呼び出したキー (またはキーシーケンスの最後のキー) です。 >> bash の info を見てみたら、COMP_KEY と COMP_TYPE の順番が逆に >> なっていました。 >> >> つまり、COMP_TYPEの「補完のタイプに応じて補完関数が呼び出される」 >> という記述が先になり、その後に COMP_KEY の「現在の補完関数を呼び >> 出したキーです」が現れます。これなら、唐突さはありません。 >> man ページをまとめた方が、順番が逆になったこと対する気配りを >> 忘れたわけで、翻訳する側としては、これは仕方がないですね。 >> まあ、工夫の余地がないわけではありませんけれど。たとえば、 >> man ページも順番を逆にしてしまうとか。 > > 初出用語は説明すべきというのはひとつの意見ではあります。そのフォーマッ > トとしては「(後述の〜を参照)」が適切かと思います。 それもありますね。ほかにもいろいろな方法があるでしょうが、 読者が一番戸惑わないですむ方法が、一番よい方法だと思います。 > ただ、そこまで原文に追加・変更を加えることは望ましくないと私は思います。 > また、たとえば一例として上記「トラップ」なども初出で説明していないこと > から、実施すると原文に対して大掛かりな変更になってしまい、望ましくない > と思います。 ええ、トラップについては、原文が注を付けておくべきだったと思います (訳文に「組み込みコマンド trap を参照」と訳注を付けてもよいですね)。 原文に大掛かりな変更を加えるのに反対だというのも賛成します。 でも、わたしとしては、「読者にわかること、読みやすいこと」を 重視しています。ですから、その方がわかりやすくなるのなら、原文にない (と言うより、原文の裏にある) 言葉を (一つや二つなら) 補足してもよいし、 訳注も (読みにくくならない範囲で) どんどん付ければよい、と思っています。 ただし、翻訳していて気がついたときにやればよい、ぐらいの安直な考え方 ですけれど。 この場合は、仮に項目の順番を変更するとしても、それほど大掛かりな 変更にはならないのではないでしょうか。 とは言え、「やった方がよいのではないか」ぐらいの話です。決定権は 当然ながら、翻訳者にあるのですから、よいと思ったとおりになされば よいと思います。 >>>> .B COMP_POINT >>>> .\"O The index of the current cursor position relative to the beginning of >>>> .\"O the current command. >>>> .\"O If the current cursor position is at the end of the current command, >>>> .\"O the value of this variable is equal to \fB${#COMP_LINE}\fP. >>>> .\"O This variable is available only in shell functions and external >>>> .\"O commands invoked by the >>>> .\"O programmable completion facilities (see \fBProgrammable Completion\fP >>>> .\"O below). >>>> 現在のコマンドの先頭からの相対値として与えられた >>>> カーソル位置のインデックスです。 >>>> 現在のカーソル位置が現在の現在のコマンドの最後にある場合、 >>>> この変数の値は \fB${#COMP_LINE}\fP と等しくなります。 >>>> この変数はプログラム補完機能 (後述の \fBプログラム補完\fP を参照) >>>> から呼ばれたシェル関数においてのみ有効です。 >>> C をはじめ各プログラミング言語では文字列中の位置を「インデックス」 >>> と呼ぶことも多いこと、補完関数を書く人はプログラミング経験のある人が >>> 対象であることから、「インデックス」でよいかと思います。 >> >> このマニュアルはセクション 1 のマニュアルですから、一般ユーザが >> 読むことを想定した方がよいのではないでしょうか。そう考えると、 >> 日本語の「インデックス」に「文字列中の位置」の意味を持たせるのは、 >> ちょっと無理だと思います。一般ユーザにもプログラマーにも通用する >> 訳語を工夫するのは、翻訳者の腕の見せ所ですし。 >> >> もっとも、一般ユーザはこんな細かい変数の説明まで読むわけがないと >> 考えることもできますけれど。 > > Ruby 言語の初心者向け入門書としてロングセラーの「たのしい Ruby 第 3 版」 > で、前のメールで例示した“文字列中から文字を探す機能”の説明を確認して > みました。同書では、「一致する部分の先頭のインデックスを返し」という言 > 葉になっていました。これは一例ですが、プログラミング初心者向けの用語と > して一般的ではないかと考えます。 うーん、セクション 1 の man ページが想定している読者は、プログラミング 初心者ではなく、一般ユーザだ (を含む) と言うことなんです。 それにしては、bash の man ページには難しいことが書いてあるわけで、 一般ユーザ用というのは、タテマエにすぎませんけれど。でも、それでも、 翻訳では一般ユーザを意識せずにはいられないわけです。 # わたしは、まさにその一般ユーザなんですが、ほかではインデックスが # 添字の意味で使われているので、ここでは戸惑いました。 それに、その Ruby の参考者ですが、もっと前の部分で「インデックス」 という言葉をどういう意味で使うか、説明 (あるいは、暗示) している のではないでしょうか。あるいは、インデックスという言葉の意味が、 読んでいるうちに読者に何となくわかってくるように書いてあるとか。 この bash の man の場合、インデックスは、すぐ近くでほとんどの場合 添字の意味で使われていますし、インデックスと言う言葉を使わなくても、 普通の日本語で説明できるわけですし。 どちらの問題も、訳を変えるには、考え方を大きく変更しなければ なりませんから、結論はしばらく時間を置いてからになさればよいと 思います。その間に、こちらも先に進んでおきますから。 -- 長南洋一