Akihiro Motoki
amoto****@gmail*****
2013年 8月 29日 (木) 01:25:08 JST
元木です。 2013/8/28 長南洋一 <cyoic****@maple*****>: > 長南です。脇筋に反応しているような気もしますが。 本来のトピックである info の翻訳の話については、 私自身はすでに言いたいことは全部書いているので、コメントはありません。 個人的な話でいうと、翻訳作業の支援はできると思いますが、それ以上の時間を JM に割り当てることは 私の作業リソースとしても現状の興味やモチベーションとしても無理です。 私が配布に関して作業しない限り先に進まないのであれば仕方のないことかもしれません。 > 元木さんのメールより [JM:00900] >> >> 今回の議論とは直接関係ないかもしれませんが、今回のやり取りを読みながら >> 以下の点を感じました。 >> ・古い翻訳を公開し続けることは意味のあることなのでしょうか？ >> その時点ではよい品質だったかもしれませんが、時間がたって実状と合わなくなると >> それは品質を維持できているとは言わないと思います。 >> 品質を維持するためには、身の丈にあった量の翻訳を管理すかないように思います。 > > 前にも同じような議論をしたと思いますが、わたしとしては少し考えが > 変わってきました。英語まじりについては、認めてもよいんじゃないか > という気になっています。 > > 「実状に合わなくなる」というのは、具体的にどういうことなのでしょう。 > 元木さんは、主として LDP の man page のことが頭にあるのではないで > しょうか。 実状にあわなくなる、の判定基準はいろいろあることは理解しています。 極端にいうと、正確さがとにかく重要なものと、ざっくり分かればよいもの、の 両方にわかれると思います。長南さんが書かれている、レファレンスマニュアルと 入門用に該当すると思います。 一方で、JM をメンテナンスする上では、作業リソースが限られていることも考慮すると、 （人手が介在する部分もありますが）ある程度機械的な判定基準が必要です。 「実状にあわない」の典型的な例としては、すでに使われなくなったパッケージがあります。 今どき ipchains のマニュアルページが必要なユーザーなんているでしょうか？ ＃間の引用に省略しますが、agree です。 > # ちょっと脱線します。coreutils の info の 8.17 から 8.20 では、 > # @acronym{POSIX} という表記が POSIX になっているところが 270 箇所 > # ぐらいあり、そうしたところも po4a では fuzzy になります。 > # fuzzy のパラグラフは、そのままだと、英語になってしまうのでしょう。 > # 日本語の翻訳が問題なく使えるところでも。 fuzzy 判定アルゴリズムを改善するか、人の目で判断して fuzzy を消すしかないと思います。 機械的に対応できるのであれば、エディタのマクロなどを駆使すれば、 270箇所程度なら片付くようにも思います。 さすがに msgmerge に解決しろというのは無理ではないでしょうか。 > # そうしたことを考えると、新しいバージョンが出たが、翻訳している > # 暇がない、とりあえず、po4a-updatepo を使って英語まじりで追随して > # おこう、では必ずしもすみません。前の訳文が使えるところまで英語にして > # しまわないためには、やはり、内容のチェックを人間がやる必要があります。 > # つまり、英語まじりを認めたとしても、いつでも機械的に追随できるとは > # かぎらないということです。 最低限 fuzzy の解決だけはきちんとする必要があります。 それもできないのであれば、メンテされていないという分類になると思います。 > では、どうしたらよいのか。LDP のような情報が最新であることが必要な > マニュアル以外は、わかりやすい原則は立てられないと思います。内容を見て、 > 現状に合っているかどうか、まだ役に立つかどうか、判断するよりありません。 > 一つ一つのマニュアルについて常時それをやるのは、大変すぎます。ですから、 > 翻訳者や管理者の負担を考えると、「益よりも害が大きくなっている」と > たまたま気がつくか、その旨の指摘があるまで、あまり気にしないでもよい > のではないかと思います。つまり、ほっぽっておいて構わない。この前に > やった棚卸しのようなことは、ときどきやるべきだと思いますが。 現実的なことを考えると、メンテナンス状態としては、 メンテされている、メンテされていないが実状とはほぼあっている、メンテされていない 三段階になると思います。 ・パッケージごとにメンテナーを置かない限り、全部をきちんと面倒を見ることは無理 必然的にメンテナーがいないページは古くなる運命にある。 ・定期的な棚卸は必要。現状とあっているかの確認をするレベル。 ここで興味をもって更新するという人がいればラッキー。メンテ状態に戻る。 現状とあっていないとなれば「メンテされていない」という扱いに落ちる。 ここで現状とあっているかを判断する人も現れない場合も「メンテされていない」送り。 ・定期的な棚卸の面倒も見る人がいない（メンテされていない）パッケージはアーカイブ送り。 昔の名残ですと分かるような表示のウェブページにするか、公開中止。 JM が配布する tarball には含めない。 大部分のページは、オリジナルが更新されたかのチェックさえしていないので、 実状に合わないかどうかのチェックもできていません。 活動内容が身の丈にあっていないのは明らかです。 歴史的遺産を公開することに意義を感じる人もいるかもしれませんが、 マニュアルにそれがあてはまるとはあまり思っていません。 >> ・パッケージ毎、バージョン毎の配布は必要なのではないか。 >> ディストリビューションが採用しているのと同じバージョンの翻訳を >> 取り込めるようにした方がいいのではないかと思い始めました。 > > LDP のようなものについては、そうですね。複数バージョンの配布ができる > として、ピッタリのバージョンがない場合、より新しいものを選ぶか、一つか > 二つ古いものを採用するか、そのへんはディストリビューション側で考えて > もらえばよいわけですし。 > > それ以外のものについては、あまり気にしないでもよいのではないでしょうか。 > 改訂したばかりのものを除けば、どうせ古いのですし。 これに関しては、私は違う意見を持っています。 どうせ古い→見ない方がいい、英語を見るべき、 という考え方が出て来る時点で、終わりです。 こういうことは、選択的ではなく、包括的な認識になるので、 一般的には日本語マニュアルはどれも古いという認識につながります。 ＃実際にこういう認識が広まっていました or 今でも広まっています。 そういう意味で古いものを配布し続けること自体にも責任があります。 責任を持てないであれば、責任を持てる範囲に絞って配布をすべきだと思っています。 それがプロジェクトを維持するということだと思います。 # まあ、フェードアウトしてもいいですが、自分が活動しなくなるときはアナウンスします。 -- Akihiro MOTOKI <amoto****@gmail*****>
Fork