長南洋一
cyoic****@maple*****
2011年 8月 10日 (水) 17:31:46 JST
長南です。 全体としてよくできていると思います。とは言え、例によって、 devil's advocate を務めさせていただきます。 > .SH 説明 > .\"O The > .\"O .BR ioctl () > .\"O function manipulates the underlying device parameters of special files. > .\"O In particular, many operating characteristics of character special files > .\"O (e.g., terminals) may be controlled with > .\"O .BR ioctl () > .\"O requests. > .\"O The argument > .\"O .I d > .\"O must be an open file descriptor. > .BR ioctl () > 関数はスペシャル・ファイルを構成するデバイスのパラメータを > 操作する。特に、キャラクタ型のスペシャル・ファイル(例えば端末(terminal)) > の多くの操作可能な特性を > .BR ioctl () > リクエストによって制御することができる。引き数 > .I d > はオープンされたファイル・ディスクリプタでなければならない。 > .PP operating characteristics の訳ですが、「操作可能な特性」という 訳は、プログラミングをなさる方から見て、しっくり来るものなので しょうか。operating characteristics を言い換えれば、characteristics for operation になるでしょうが (違うのかな)、「機能」「動作」などと 言ってしまうことはできないのですか。 「キャラクタ型のスペシャル・ファイル(例えば端末(terminal))」ですが、 カッコの前に空白がありません。 > .\"O The second argument is a device-dependent request code. > 2番目の引き数は、デバイス依存のリクエスト・コードである。 どちらかというと、言葉の好みに関する意見です。 この device-dependent というのは、CONFORMING TO セクションの 「Arguments, returns, and semantics of ioctl() vary according to the device driver in question」と同じことを言っているのだと思います。 ですから、device-dependent は「デバイスによって様々な」に近いのでは ないでしょうか。そういうことを「デバイス依存」というんだと言われれば、 そうなのかもしれませんが、dependent と言うと、いつでも「依存」と 訳すのは、かなり気になるのです。 > .\"O It's traditionally > .\"O .BI "char *" argp > .\"O (from the days before > .\"O .B "void *" > .\"O was valid C), and will be so named for this discussion. > この引き数は伝統的に(C で > .B "void *" > が有効になる前から) > .BI "char *" argp > と表記されている。したがって、この文章でもそのように名付けることとする。 細かいことですが、「そのように名付ける」より「そう名付ける」の方が、 次のパラグラフの「argp (引数) のバイト単位のサイズ」とのつながりが よいように思います。つまり、「そのように」の方がより漠然としている のです。「そう呼ぶことにする」でもよいかもしれません。 直す必要はないと思いますが、厳密に言うと、「void * という書き方が C で有効になる前から」でしょうね。 「この引き数は伝統的に(C で」は、カッコの前に空白がありません。 > .\"O An > .\"O .BR ioctl () > .\"O .I request > .\"O has encoded in it whether the argument is an > .\"O .I in > .\"O parameter or > .\"O .I out > .\"O parameter, and the size of the argument > .\"O .I argp > .\"O in bytes. > .\"O Macros and defines used in specifying an > .\"O .BR ioctl () > .\"O .I request > .\"O are located in the file > .\"O .IR <sys/ioctl.h> . > .BR ioctl () > .I request > には、 > (1)引き数が > .I 入力 > パラメータか > .I 出力 > パラメータのどちらかであるかの区別や、 > (2) > .I argp > のバイト単位のサイズといった情報がエンコードされている。 > .BR ioctl () > .I request > を指定するためのマクロ(macro)と定義は > .I <sys/ioctl.h> > ファイルにある。 (1)(2) は、原文にありませんし、あっても、文の構成がそれほど わかりやすくなるわけでもないので、いらないと思います。それに、 (1)(2) があると、request には (1)(2) のみがエンコードされていると 読まれかねないのではないでしょうか。ほかの情報もエンコードされて いるのでしょう。 「引き数が入力パラメータか出力パラメータのどちらかであるかの区別や」は、 日本語の二つの構文が混在しているような気がします。 「引き数が入力パラメータと出力パラメータのどちらであるかの区別」か、 「引き数が入力パラメータか出力パラメータかの区別」か。 「... whether the argument is an in parameter or outparameter,」の the argument は、「その引数自身が」「その request 自体が」などでは ないでしょうか。つまり、「その」か「この」が必要だということ。 「自身」や「自体」はなくてもよいかもしれません。逆に、「その」を 取って、「自体」などをつけてもよいかも。 それから、「ioctl() request には」は「ioctl() の request には」と 「の」を入れた方がよいと思うのですが、いかがでしょうか。 # ioctl() request は、「ioctl() request」と訳されていますが、 # ioctl() requests は、「ioctl() リクエスト、ioctl() 要求」の # 二つの訳が使われています。わたしとしては、全部「ioctl の # request」にしてよいのではないかと思うのですが、乱暴でしょうか。 # イタリック (下線) の request と、イタリックではない request が # できてしまいますけれど。 # # うーん、その辺まで考えると、「の」を入れずに、ioctl() request は、 # 「ioctl() request」のままにして、ioctl() requests の方は、「ioctl() # リクエスト」に統一するのが無難なんでしょうか。 # 要するに、ioctl() に対するリクエストであり、「書式」の第二引き数 # request に対応するとわかればよいのでしょうけれど。 「argp のバイト単位のサイズ」は、「argp 引数の」と argument を 出した方がよさそうです。 「入力パラメータ、出力パラメータ」という訳は−−と言うより、 in parameter, out parameter という用語は、プログラマーにとって ピンと来る用語なんでしょうか。「入力／出力に関するパラメータ」 ぐらいの意味ですか。 > .SH 返り値 > .\"O Usually, on success zero is returned. > .\"O A few > .\"O .BR ioctl () > .\"O requests use the return value as an output parameter > .\"O and return a nonnegative value on success. > たいていの場合、成功した場合はゼロが返される。 > いくつかの > .BR ioctl () > 要求では出力パラメータとして返り値を使用しているものがあり、 > その場合は、成功したときに非負の値が返される。 ioctl() requests が、「ioctl() 要求」になっています。 初出の部分では「... 多くの操作可能な特性を ioctl() リクエストに よって制御することができる」でした。 ここも、二つの日本語の構文が混在しているようです。 「ioctl() の request (単数にすべきか複数にすべきが迷います) の中には、 出力パラメータとして返り値を使用しているものが若干あり」か、 「ioctl() の request のいくつかでは、出力パラメータとして返り値を 使用しており」か。 それから、「たいていの場合、成功した場合は」と「場合」を繰り返すのが、 ちょっと気になります。 と、書いているうちに、もう一つ気づきました。。 このパラグラフの output parameter は、「whether the argument is an in parameter or out parameter」の out parameter と意味が 違うのではないでしょうか。「whether ...」の方は、その request が 何かを GET するものか (out parameter)、それとも SET するものか (in parameter )ということでしょう (逆かな)。そして、こちらの output parameter の方は、出力されるパラメータそのもの。 だとしたら、別の訳語を考えなければならないと思います。 一例を挙げると、 たいていの場合、成功すると 0 を返す。ただし、ioctl() のリクエストの 中には、パラメータの出力に返り値を利用しているものが若干あり、 その場合は、成功したときに非負の値が返ってくる。... あるいは、as 以下は A few ioctl() requests にかかると考えることも できるかもしれません (数の不一致が起きてしまいますけれど、こういう 不一致は許されるのかもしれません)。その場合は、out parameter も output parameter も同じになり、次のような意味になります。 ... ただし、若干の ioctl() リクエストは、出力パラメータとして 使われるとき返り値を利用するので、成功時には非負の値を返す ことになる。... ある ioctl() リクエストが出力パラメータとして使われたり、 入力パラメータとして使われたりすることはなさそうですから、 こちらではないでしょうね。自然言語としては、可能な表現のような 気もしますけれど。以下のようにすれば、矛盾がなくなりそうです。 ... ただし、出力パラメータとして使われる若干の ioctl() リクエストは、返り値を利用するので、成功時には非負の値を返す ことになる。... どれが正しいかは、わかりません。 > .\"O .BR ioctl () > .\"O vary according to the device driver in question (the call is used as a > .\"O catch-all for operations that don't cleanly fit the UNIX stream I/O > .\"O model). > ... (この関数は UNIX の ストリーム I/O モデル に > きちんと適合していない雑多な操作に使用される)。 こういう catch-all は訳すべきだと思います。実を言うと、この原文は、 「the call is used for operations that don't cleanly fit the UNIX stream I/O model」と catch-all を取ってしまっても、言っていることは たいして変わりません。それなのに、著者は as a catch-all と言っている わけです。この言葉を使いたかったのだと思います。そういうときは、 翻訳でもできるだけ生かしてあげるべきでしょう。前に訳例をいくつか 上げましたが、意味的にだいたい相当していて気の利いた、おもしろい訳を、 何か工夫なさってください。 -- 長南洋一
Fork