長南洋一
cyoic****@maple*****
2012年 5月 26日 (土) 10:44:57 JST
長南です。 元木さんのメールより [JM:00681] > >> ですから、po 化、もっと一般的に言えば、便利な道具というものについて、 >> 辞書関係以外、わたしはほとんど関心がないのです。それでも、訳す側にとって >> 本当に便利かどうか、どういうプラス面とマイナス面があるのか、po を試す >> ぐらいのことはやってみてもよいと思いますけれど。 > > po 化は道具なのは理解していますが、LDP man-pages くらいページ数があると、 > 道具を使う使わない大きな違いだと思い、po4a 化を推進しているだけです。 それはわかります。確かに、po4a と diff では、変更箇所の見やすさが 全然違います (diff が見にくすぎるとも言える)。実はわたしも、po4a を 試し始めています。もっとも、どういうマイナス面があるか、それはどうしたら 補えるのか、というのが主な関心事ですけれど。 >> マニュアルには、新しくなければ困るものと、かなり古くても、存在すれば >> それなりに役に立つものがあります。前者について、更新しやすい体制を >> 作るのは結構なことです。でも、後者を捨てるまでのこともないと思います。 >> 役に立つ間はそのまま配布しておいて、更新なり新訳なりをしてくださる方が >> 現れたら、そのとき po 化なり何なりを考えたら、よいのではないでしょうか。 > > 「配布中止」という言い方が極端で誤解を招く言い方であった点はお詫び致します。 > ステータス分けをして可視化する方が本来の目的だったのですが、行き過ぎて > しまいました。 現在における有用度を基準にした、翻訳状態の分類ですね。言わば、定期の 棚卸し。元木さんは必要なことをなさったと思います。今後 JM で扱うものを はっきりさせるためにも。また、何を優先的に訳して行くかを考えるためにも。 > 最近、JM プロジェクト以外のところでいろんな人とお話しして聞いた点では、 > 古くても存在すればよいと思っていたものが古くなりすぎて、日本語マニュアルの > 存在自体がじゃまになっているケースがかなりあるということです。 具体的には、どういうもののことだったんですか。 > 古くなっても役に立つものと、古過ぎて邪魔になるもの、を継続的に選別して > いける人がいるかという点が、大事なポイントだと思います。 > 現実的にはこれができていないので、現在の状況になっていますので。 わたしとしては、前々から、翻訳をしなくてもよいから、編集者役を務めて くださる方がいるといいと言ってきました (つまり、翻訳を管理したり、 企画を立てたり、改訂の優先順位を提案したり、読者の立場で発言したり する方です。募集してみたら、どうでしょうか)。しかし、そういう方が いたとしても、「捨てる、当分このまま、更新」といった判断を継続的に やっていくのは、難しいと思います。すべてのマニュアルに目を通し続けるのは、 無理なことですから。 むしろ、古くて役に立たなくなったマニュアルをユーザに指摘してもらえる ようなシステムを作ったら、どうでしょうか (「バグ報告」がそれなんですか。 だったら、もっと宣伝が必要です)。自分で言い出しておいて、あまりうまく 行くとは思えませんが、それでも、問題のある翻訳マニュアルを特定しやすく する、何らかの方法が必要だと思います。 もちろん、ユーザから指摘があったからといって、捨てたり改訂をしたり するとはかぎりません。こちらで、まだ使える、改訂の必要がないと 判断する場合もあるでしょうし、何よりも、訳してくださる方が現れなければ、 どうしようもありませんから。 > 現実的な対処としては、man と配布する方では、古くデフォルトの tarball には > 含めないようにするか、デフォルトのインストールの Y/N を N に倒すかだと > 思います。 > Web で公開する方は「過去のバージョンを参考までに公開しています」みたいな > 注釈がつくのがいいかなと思っています。 > # Web の方は後回し (誰か助っ人が登場しない限りそのまま？) でしょうが。 > > 本音を言うと、最新版のものだけ持って JM を fork したいところ。 お気持ちはわかります。LDP のマニュアルは膨大なものですし、元木さんは その上、編集者役までなさっているのですから。でも LPD マニュアルだけ fork したら、JM は空中分解してしまうでしょうし ... やる気のある方にやりたいマニュアルを訳してもらうという行き方ですから、 自分でやろうと思うもののほかは、成り行きに任せておくより仕方がない だろうと思います。それでも、ときどき棚卸しをすることは必要でしょう。 また、JM の方から、現在新訳なり改訂なりを必要としているマニュアルを 指定するぐらいのことは、やった方がよいと思います。もしかすると、 翻訳をやる気はあるけれど、何を訳したらよいかわからないという方も いらっしゃるかもしれませんから。 > 一つ参考にうかがいたいのですが、日本語・英語混じりだが最新版のマニュアルと > 古めだが日本語だけのマニュアルとどちらがよいと思われますか？ > 私は前者の方が好きなのですが。 ものによると思います。本当に最新版が必要な場合は、翻訳できるまで 当面はということなら、日本語・英語まじりで構わないと思います。 ただ、増加したオプションの説明などが英語なのはまったく問題ありませんが、 DESCRIPTION の大部分が英語になるのは避けた方がよさそうです。 そのプログラムの説明の本質的な部分が英語だったら、英語マニュアルを 読むのと変わりがありませんから (結局、量の問題ですね)。 一般ユーザの使う基本的なコマンドの場合は、できるだけ避けるべきでしょう。 見た目が美しくありませんし、読者の中には、小学生もいるかもしれません。 英語に拒否反応を起こす人もいるかもしれません。わたし自身そう言いながら、 grep の翻訳では、日本語・英語まじりをやっていますけれど。 >> 4) GNU groff: 微妙。 >> これはマニュアルがたくさんあって、様々。 >> groff(1) について言うと、"DESCRIPTION" すら英語版と翻訳では >> 違っている。しかし、オプションは -D, -K, -c, -k が増えているだけ。 > > groff.1 もそうですが、 > 他のページで言うと、ファイルの存在の有無さえ変わっています。 > この点からやめようと思いました。 FILES まで調べませんでした。考えてみると、初心者が groff の man を 見ることなんてなさそうですね。配付中止でよいと思います。 >> 9) bind: 配布中止でよいかも。 > > 開発元は bind 9.x へのアップデートを推奨していて、bind はバージョンが変わると > かなりオプションも増えること、DNS の管理者が読めばよいものなので、 > 配布は不要と思っています。 > マニュアルが見える方がトラブルの元になりえます。 > >> dig.1 や host.1 もあり、そういうユーザ・コマンドの日本語 man はほしい。 > > これは同意しますが、現状はあまりに違って参考にならない可能性もあるので、 > リセットしてもいいと思っています。 ええ、dnsutils にあるのは、系統の違うプログラムみたいですね。 >> 11) lpr-linux: 複雑。 >> 現在使われているのは BSD-lpr や LPRng ではなく、CUPS の lpr など >> だろうし、CPUS lpc のマニュアルには、"The CUPS version of lpc >> does not implement all of the standard Berkeley or LPRng commands." >> と書いてある。それを考えると、配布中止でよいのだが、せめて lpr、 >> lpq, lprm の日本語マニュアルぐらいはないと、初心ユーザが困るだろう。 >> そういったコマンドの基本的な使い方は今の翻訳でもわかるので、複雑な >> 気持ちになる。 > > 今のユーザが lpr を使うのかはさておき、 > lpr-linux の lpr, lpq, lprm の man が出てきて、逆に混乱することはないで > しょうか。 そうか、わたしが lp ではなく、lpr を使うのは、単なる習慣だったんですね。 CUPS の lpr などは Berkeley のコマンドの互換品ですから、ユーザが 混乱する心配は、lpc 以外、あまりないと思います。とは言え、使わなくなった プログラムのマニュアルは、捨ててしまった方がすっきりします。 そこで、cups の lpr, lpq, lprm, lpc, lp, lpstat, cancel を翻訳して みました。これだけあれば、とりあえず用が足りるのではないでしょうか。 近々、提出するつもりです。 # lpoptions の「名前」でつまづいています。「display or set printer options # and defaults」の defaults が具体的には何なのか、もうわからない。 >> 12) modutils: 残してもよさそう。 >> debian squuze の場合、英語版のマニュアルは、module-init-tools >> パッケージのもの。insmod と modprobe のマニュアルを読んでみた >> ところでは、"DESCRIPTION" の内容にほとんど変わりはない。 > > modutils はカーネル 2.4 時代のもので、 > module-init-tools のマニュアルも引き続き更新する予定です。 > moduitls もメンテ対象にした方がよいという意味でしょうか。 わたしの勘違いです。と言うより、lsmod などが module-init-tools と moduitls の両方にあるのに気がつきませんでした。modutils は捨ててよい と思います。 >> 14) pciutils: 微妙。 >> lspci.8: "DESCRIPTION" の文章は増えているが、和訳でも必要なことは >> 言っている。ただし、オプションは 13 個増えている。 >> setpci.8: man ページの内容がかなり変わっている。 >> update-pciids.8: ほとんど変更なし。wget, lynx だけでなく、curl が >> 使えるようになっただけ。 >> >> メジャーバージョンが変わっている以上、当然配布中止候補なのですが、 >> マニュアルの内容は上記のような状態なので、中止すべきかどうかの >> 判断は微妙です。 > > # このコマンドに関しては、日本語 man を開いて必要なオプションの説明がなくて、 > # がっかりした経験しかないので、いい思い出がありません。 > > 管理者向けコマンドなので、英語混じりでもよいので、 > 新しいオプションを反映した方がよいと思っています。 たとえば、音が鳴らなかったときにディストリビューションの ML で質問すれば、 lspci と lsmod を実行するようにと言われます。ですから、一般ユーザにも 関係のあるコマンドだと思います。でも、一般ユーザは -v と -vv ぐらい 知っていれば、十分ですから、確かに、オプションの説明は英語まじりで 問題ないかもしれません。と言うより、DESCRIPTION も変わっているので、 これは優先順位の高い改訳候補ですね。 -- 長南洋一
Fork