長南洋一
cyoic****@maple*****
2013年 8月 24日 (土) 22:16:18 JST
長南です。 ご意見ありがとうございます。 松澤さんのメールより [JM:00898] > > そもそも論かつ何も調査せずの提案になってしまいますが、 > プロジェクト本家(GNU)で引き取ってもらうことは難しいのでしょうか? > > infoに限りませんが、開発元プロジェクトで翻訳を管理するのがあるべき > 姿ではないかと思います。 わたしとしては、man や info の翻訳のようなその国に固有なことは、 その国の中で処理した方がよいと思っています。世界中にいくつ言語が あるのか。そのすべてを開発元が集めて管理するのは無理ではないで しょうか (コマンドの出すメッセージについては、gettext でそれを やっているわけですが)。それに、もっと重要なことですが、提出された 翻訳が公開できるレベル以上になっているかどうか、外国人である開発元 には判断できないでしょう。 翻訳は、その翻訳をチェックする能力がある人が集まっているところで 発表 (提出) するべきだと思います。それで、ざっと見回したところ、 info の提出先もここがふさわしいのではないかということです。 実を言うと、2004 年に coreutils-5.2.1 の info を訳した方がいらっしゃい ます。その方は、ご自分がなさっていることを「現在は、GNU の gnujdoc プロジェクトの一部になっている」とおっしゃっていますが、事実上お一人で 個人的にお訳しになったもののようですし、gnujdoc プロジェクトもあまり 活動が活発ではないようです。coreutils-5.2.1 info の翻訳を見たところ からも、翻訳のチェックを期待できる環境とは思えません。 http://www.geocities.jp/fut_nis/tarball/index.html http://www.geocities.jp/fut_nis/html/coreutils-ja/ http://openlab.ring.gr.jp/gnujdoc/ > たとえば、aptのマニュアルはapt側で管理していますよね (認識違いなら > すみません)。 apt 関係は Debian でやっているのではありませんか。そして、日本語翻訳の 窓口は、Debian JP Documentation メーリングリストになっているのでは ないかと思います。確かに、Debian や Ubuntu、Gnome のような、日本に 大きなユーザグループがあるところなら、そういうところへ投稿すればよいと 思います。チェックしたり、助言したりしてくださる人が充分いらっしゃるで しょうから。 > 開発元で翻訳を管理する場合のメリットとしては、ディストロでパッケージ化 > される場合に > プログラム、ドキュメント原文、およびドキュメント翻訳のバージョン整合性が > 取りやすいなど > 利便性も大きいと思います。 それはそうですね。しかし、わたくしは、新バージョンにどうしても 付けなければならないもの以外 (つまり、GUI ソフトの日本語ヘルプ などを抜かして)、ドキュメントの原文と翻訳に時差ができるのは仕方が ないことだと思っています。原文がなければ、翻訳はできませんから。 -- 長南洋一
Fork