長南洋一
cyoic****@maple*****
2013年 4月 1日 (月) 12:34:29 JST
長南です。ご指摘、ありがとうございます。 OKANO さんのメールより [JM:00849] > > 1) initial-arguments の説明 > > | 「ユーザが引き数 (すなわち initial-arguments) を指定したとき、その > initial-arguments 中に」という文について、 > | 「引き数（すなわち A）…、その A 中に」は、「引き数（すなわち A）…、 > その引き数中に」 > | の方が読みやすいかなと思ったのと、 > > 現在の翻訳 >> .BI \-I " replace-str" >> .B xargs >> が実行するコマンドにに対してユーザが引き数 (すなわち >> \fIinitial\-arguments\fR) を指定したとき、その \fIinitial\-arguments\fR >> 中にある \fIreplace-str\fR の部分すべてを、標準入力から読み込んだ名前で >> 置き換える。 > > を、 > >> .BI \-I " replace-str" >> .B xargs >> が実行するコマンドにに対してユーザが引き数 (すなわち >> \fIinitial\-arguments\fR) を指定したとき、その引き数 >> 中にある \fIreplace-str\fR の部分すべてを、標準入力から読み込んだ名前で >> 置き換える。 > > のようにしたほうがよいのではないかという提案です。 > > 考えてみると、 > initial-arguments といえば、その対象がはっきりしますが、 > 「引き数」というと、initial-arguments 以外のものと混同のおそれがあるので > あえて現在のような訳になっているのではないか、とか思いまして、 > そういうことなら今の訳のままがよいのかな、と思っています。 > ここは皆さんのご意見を伺いたいです。 ああ、思い出しました。これは、原文が、 Replace occurrences of replace-str in the initial-arguments with names read from standard input. Also, unquoted blanks do not terminate input items; instead the separator is the newline character. Implies -x and -L 1. です。原文をそのまま訳したのでは、initial-arguments が何かわかりにくい だろうと思ったので、「xargs が実行するコマンドに対してユーザが引き数 (すなわち initial-arguments) を指定したとき」と補ったのです。初稿では、 「(訳注: xargs が実行する ... 指定したとき)」 と、訳注にしていたのでは ないかと思います。つまり、「その initial-arguments 中にある replace-str の部分すべてを、標準入力から読み込んだ名前で置き換える」の部分は、補充訳 を入れる前の、翻訳の原型の原型。それで、initial-arguments のままになって います。でも、今考えると、補充訳の部分で「initial-arguments は実行する コマンドの引き数だ」と言っていますから、「引き数」でもよいですね。 とは言え、「initial-arguments 中」には、OKANO さんがおっしゃるような 効果もあります。たぶん、それも考えたと思います。どちらにするか、迷う ところです。まあ、今度 xargs の manpage を改訂するときに (わたしがやるに せよ、他の方がやるにせよ)、よく考えて、どちらにするか決めるぐらいの対処で よいのではないでしょうか。 # twitter で発言している方のご意見を読んでみましたが、具体的な「ここが # 問題だ」というご指摘と言うより (失礼ながら、どちらでもよさそうな点の # ご指摘なので)、「何となくわかりにくい」という感覚の問題のような気が # します。かえって、その方が問題かもしれません。訳が日本語としてこなれて # いない、あるいは、論理が取りにくい、ということですから。具体的には、 # 次の部分がまずかったのかもしれません。 # Also, unquoted blanks do not terminate input items; instead the # the separator is the newline character. # なお、空白は、クォートされていない場合も、入力される項目の区切りには # ならない。区切り記号は改行文字だけになるのだ。 # こうすべきでしたか。 # なおこのとき、標準入力中にある空白は、クォートされていない場合でも、 # 入力項目の区切りにはならない。区切り記号は改行文字だけになるのだ。 # これも次回改訂時の考慮箇所ですね。 > 2) 「にに」 > >> が実行するコマンドにに対してユーザが引き数 (すなわち > > にに -> に > > # 「にに」は、xargs のほか、以下の各マニュアルにもありました。 > # GNU_findutils/release/man1/find.1 (2 箇所) > # rssh/release/man5/rssh.conf.5 > # LDP_man-pages/po4a/inotify/po/ja.po これは一言もありません。ただ、言い訳をさせていただくと、こういうのは、 自分ではつい見逃してしまうものなのです。ですから、他の方からの指摘が 必要なわけで ... 元木さん、直しておいていただけますか。 > 4) 日本語が分かち書きされている > > roff ファイルで文の途中で改行されているのが原因です。 > > man で見る場合はあまり気にならないかもしれませんが、 > HTML だと、そこが空白になったりして、不自然だったり検索しにくかったり > しますね。 > > 全体の方針にかかわることなので、別のスレッドで議論したほうがいいかもですが、 > 個人的には、改行するなら文の途中ではなく句読点とかにあわせてやったほうが > よいと思っています。 これもおっしゃるとおりです。roff の原稿では、句読点か、英数字の前後の 空白で改行しないと、文中に余計な空白が入ります。わたしも manpage の 翻訳をいくつかしているうちにそれに気がついたので、できるだけ句読点か 英数字の前後で改行するようにしています。でも、まだ残っているみたいですね。 句読点のない部分がずっと続いて、どうしても途中で改行したくなる場合でも、 一応検索のことは考えて、文節で区切るようにはしていますが。 # それから、空白を残した方が読みやすいかなと思って、あえて残す場合も # あります。ここはそうではなさそうですが。 > 昔は、メールとかと同じく80文字以内で改行 > という流儀な人が多かったような気がしますが、 > 今では行が長くても問題ないと思うですし。 流儀というよりも、長い行でも groff がちゃんと整形してくれるか心配だ ということだと思います。今では、どんなに長くても大丈夫なんですか。 たとえば、改行なしで何十行も続くとか。 -- 長南洋一
Fork