Akihiro MOTOKI
amoto****@gmail*****
2012年 5月 24日 (木) 00:57:22 JST
元木です。 丁寧にありがとうございます。 2012年5月17日 13:26 長南洋一 <cyoic****@maple*****>: > 長南です。 > > わたしとしては、翻訳の一番大変なところは、原文にぴったりの日本語を > 考えることだと思っています。道具が鉛筆と原稿用紙から、ワープロに > 変わって、推敲がずいぶん楽になりましたが、翻訳で一番肝腎な、日本語を > 考えるということを、道具がやってくれるわけではありません。 この点は同感です。 > ですから、po 化、もっと一般的に言えば、便利な道具というものについて、 > 辞書関係以外、わたしはほとんど関心がないのです。それでも、訳す側にとって > 本当に便利かどうか、どういうプラス面とマイナス面があるのか、po を試す > ぐらいのことはやってみてもよいと思いますけれど。 po 化は道具なのは理解していますが、LDP man-pages くらいページ数があると、 道具を使う使わない大きな違いだと思い、po4a 化を推進しているだけです。 別の理由としては、日本語、英語が少しは混在していても、マニュアルを新しいものに 保っておきたいという思いが強くなっているというのもあります。 > そんなわけで、以下は「配布物の絞り込み」の方に対する意見です。 コメントありがとうございます。 > マニュアルには、新しくなければ困るものと、かなり古くても、存在すれば > それなりに役に立つものがあります。前者について、更新しやすい体制を > 作るのは結構なことです。でも、後者を捨てるまでのこともないと思います。 > 役に立つ間はそのまま配布しておいて、更新なり新訳なりをしてくださる方が > 現れたら、そのとき po 化なり何なりを考えたら、よいのではないでしょうか。 「配布中止」という言い方が極端で誤解を招く言い方であった点はお詫び致します。 ステータス分けをして可視化する方が本来の目的だったのですが、行き過ぎてしまいました。 最近、JM プロジェクト以外のところでいろんな人とお話しして聞いた点では、 古くても存在すればよいと思っていたものが古くなりすぎて、日本語マニュアルの 存在自体がじゃまになっているケースがかなりあるということです。 古くなっても役に立つものと、古過ぎて邪魔になるもの、を継続的に選別していける 人がいるかという点が、大事なポイントだと思います。 現実的にはこれができていないので、現在の状況になっていますので。 現実的な対処としては、man と配布する方では、古くデフォルトの tarball には 含めないようにするか、デフォルトのインストールの Y/N を N に倒すかだと思います。 Web で公開する方は「過去のバージョンを参考までに公開しています」みたいな 注釈がつくのがいいかなと思っています。 # Web の方は後回し (誰か助っ人が登場しない限りそのまま？) でしょうが。 本音を言うと、最新版のものだけ持って JM を fork したいところ。 > それから、「配布中止」の候補を考えるのも必要なことでしょうが、それ以上に、 > 未訳だけれど翻訳がほしいものや、改訂が望まれるものの候補を挙げた方が > よいのではないかと思います。 ごもっともです。 一つ参考にうかがいたいのですが、日本語・英語混じりだが最新版のマニュアルと 古めだが日本語だけのマニュアルとどちらがよいと思われますか？ 私は前者の方が好きなのですが。 > それでは、http://sourceforge.jp/projects/linuxjm/wiki/PackageStatus の > 「配布中止候補」と「配布中止」を一つづつ取り上げます。 > > 基本的に現在の英語版と翻訳の "DESCRIPTION" と "OPTIONS" を比較しただけ > です。それから、英語版は debian squeeze 所収のものしか見ていませんから、 > 最新版では事情が違うかもしれません。 引用前後しますが、細かく確認いただいて非常に助かります。 これを元に、ステータス分けを見直したいと思います。 > 1) GNU ed(1): 残してよい。 > 2) GNU awk(1): 残してよい。 > 3) GNU gdbm(3): 残してよい。 > 5) GNU make(1): 残してよい。 > 6) GNU texinfo: 残してよい。 > 17) GNU cpio: 残してよい。 > 18) GNU gdb: 残してよい。 同意します。 > > 4) GNU groff: 微妙。 > これはマニュアルがたくさんあって、様々。 > groff(1) について言うと、"DESCRIPTION" すら英語版と翻訳では > 違っている。しかし、オプションは -D, -K, -c, -k が増えているだけ。 groff.1 もそうですが、 他のページで言うと、ファイルの存在の有無さえ変わっています。 この点からやめようと思いました。 > 7) apmd: > うちの squeeze には英語版がそもそも入っていないので、判断できない。 > > 8) autofs: > これも英語版が入っていないので、判断できない。 > > 9) bind: 配布中止でよいかも。 開発元は bind 9.x へのアップデートを推奨していて、bind はバージョンが変わると かなりオプションも増えること、DNS の管理者が読めばよいものなので、配布は不要と思っています。 マニュアルが見える方がトラブルの元になりえます。 > dig.1 や host.1 もあり、そういうユーザ・コマンドの日本語 man はほしい。 これは同意しますが、現状はあまりに違って参考にならない可能性もあるので、 リセットしてもいいと思っています。 > 10) fetchmail: 配布中止でよいかも。 > 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 が出てきて、逆に混乱することはないでしょうか。 > 12) modutils: 残してもよさそう。 > debian squuze の場合、英語版のマニュアルは、module-init-tools > パッケージのもの。insmod と modprobe のマニュアルを読んでみた > ところでは、"DESCRIPTION" の内容にほとんど変わりはない。 modutils はカーネル 2.4 時代のもので、 module-init-tools のマニュアルも引き続き更新する予定です。 moduitls もメンテ対象にした方がよいという意味でしょうか。 > 13) netatalk: > これは、わたしのまったく知らない世界なので、判断できません。 > > 14) pciutils: 微妙。 > lspci.8: "DESCRIPTION" の文章は増えているが、和訳でも必要なことは > 言っている。ただし、オプションは 13 個増えている。 > setpci.8: man ページの内容がかなり変わっている。 > update-pciids.8: ほとんど変更なし。wget, lynx だけでなく、curl が > 使えるようになっただけ。 > > メジャーバージョンが変わっている以上、当然配布中止候補なのですが、 > マニュアルの内容は上記のような状態なので、中止すべきかどうかの > 判断は微妙です。 # このコマンドに関しては、日本語 man を開いて必要なオプションの説明がなくて、 # がっかりした経験しかないので、いい思い出がありません。 管理者向けコマンドなので、英語混じりでもよいので、 新しいオプションを反映した方がよいと思っています。 > 15) rpm: これはディストリビューションに任せるべきでしょう。 > > 16) sendmail: > これもわたしには判断できない。 > バージョンだけ見ると、翻訳がまだ役に立ちそうですが。 -- Akihiro MOTOKI <amoto****@gmail*****>
Fork