[JM:00901] Re: coreutils の info

Back to archive index

長南洋一 cyoic****@maple*****
2013年 8月 28日 (水) 09:06:52 JST


長南です。脇筋に反応しているような気もしますが。

元木さんのメールより [JM:00900]
>
> 今回の議論とは直接関係ないかもしれませんが、今回のやり取りを読みながら
> 以下の点を感じました。
> ・古い翻訳を公開し続けることは意味のあることなのでしょうか?
>   その時点ではよい品質だったかもしれませんが、時間がたって実状と合わなくなると
>   それは品質を維持できているとは言わないと思います。
>   品質を維持するためには、身の丈にあった量の翻訳を管理すかないように思います。

前にも同じような議論をしたと思いますが、わたしとしては少し考えが
変わってきました。英語まじりについては、認めてもよいんじゃないか
という気になっています。

「実状に合わなくなる」というのは、具体的にどういうことなのでしょう。
元木さんは、主として LDP の man page のことが頭にあるのではないで
しょうか。

マニュアルには、リファレンス・マニュアルと入門用のマニュアルがあります。
細かい仕様が書いてあるものも、家電に付いてくる取扱説明書も、どちらも
マニュアルです。

マニュアルの翻訳は、その対象の最新バージョンに対応しているべきだ
というのは、当然のことです。しかし、リファレンス・マニュアルと
入門用マニュアルでは、少し事情が違います。

LDP の man page は、書く側にとっても読む側にとっても、まさに
リファレンス・マニュアルでしょう。関数に仕様の変更があった場合や
新しい機能が追加された場合 (あるいは逆に、ある機能が削除された場合)、
man page にその記述がなければ困ります。こういうものは、配布している
関数などとマニュアルのバージョンが一致していなければ、役に立ちません。
つまり、マニュアルが最新であることが必要なわけで、翻訳者の負担を
考えると、一部分英語まじりになっても、仕方がないだろうと思います 
(英語の部分があまり大きくなりすぎると、翻訳だか何だかわからなく
なってしまいますけれど)。

一方、coreutils や find のような基本コマンドのマニュアルも −− POSIX 
の man page がよい例ですが −− 基本的にはリファレンス・マニュアルです。
特に、マニュアルを書く側の意識にとってはそうなので、find や sudoers の 
man page のように、詳しすぎて、ほとんど通読不可能ものもあるわけです。
しかし、読む側は −− 特に初心者や中級者は −− 一般的な使い方を知る
ために読みます。つまり、そういう人たちにとって man page は、入門用
マニュアルなのです。たいていの場合、新たに追加された最新の機能は必要
ありません。基本的な使い方さえわかれば充分です。そこで、マニュアルの
翻訳のバージョンが古くても、説明が事実に反していず、ある程度親切ならば、
役に立つということになります。市販のコマンド・リファレンス・ブックなんて、
そんなものでしょう。

# たとえば、最近の split では、suffix の付け方というか、suffix の
# 生成方法が変わったようです。また、ラウンドロビン方式の分配が導入
# されました。作者としては、是非知ってほしいことなのでしょうが、
# 普通のユーザにとっては、どちらも知らないですむことです。
# もちろん、そういう説明だって、あるに越したことはないのですが。

ただし、説明が事実に反するようになってしまった場合、たとえば、
オプションの指定法が変わったとか、存在していた機能が削除されたとか
いった場合は別です。そういった場合は、マニュアルの翻訳が 90 % 通用する
としても、ちょっとまずいだろうと思います。

では、基本的なコマンドの man page も最新バージョンの原文を使うことに
して、未訳の部分や、変更のあった部分は英語にしておけばよいのか。LDP の 
man page の場合は、プログラミングをやるなら、事実上英語は一通り読め
なければなりませんから、それでよいと思います。でも、それ以外については、
一般ユーザに英文を読ませるのは、ちょっと要求のしすぎでしょう。Linux が
とっつきにくいものになると思います。

# ちょっと脱線します。coreutils の info の 8.17 から 8.20 では、
# @acronym{POSIX} という表記が POSIX になっているところが 270 箇所
# ぐらいあり、そうしたところも po4a では fuzzy になります。
# fuzzy のパラグラフは、そのままだと、英語になってしまうのでしょう。
# 日本語の翻訳が問題なく使えるところでも。
#
# そうしたことを考えると、新しいバージョンが出たが、翻訳している
# 暇がない、とりあえず、po4a-updatepo を使って英語まじりで追随して
# おこう、では必ずしもすみません。前の訳文が使えるところまで英語にして
# しまわないためには、やはり、内容のチェックを人間がやる必要があります。
# つまり、英語まじりを認めたとしても、いつでも機械的に追随できるとは
# かぎらないということです。

では、どうしたらよいのか。LDP のような情報が最新であることが必要な
マニュアル以外は、わかりやすい原則は立てられないと思います。内容を見て、
現状に合っているかどうか、まだ役に立つかどうか、判断するよりありません。
一つ一つのマニュアルについて常時それをやるのは、大変すぎます。ですから、
翻訳者や管理者の負担を考えると、「益よりも害が大きくなっている」と
たまたま気がつくか、その旨の指摘があるまで、あまり気にしないでもよい
のではないかと思います。つまり、ほっぽっておいて構わない。この前に
やった棚卸しのようなことは、ときどきやるべきだと思いますが。

> ・パッケージ毎、バージョン毎の配布は必要なのではないか。
>   ディストリビューションが採用しているのと同じバージョンの翻訳を
>   取り込めるようにした方がいいのではないかと思い始めました。

LDP のようなものについては、そうですね。複数バージョンの配布ができる
として、ピッタリのバージョンがない場合、より新しいものを選ぶか、一つか
二つ古いものを採用するか、そのへんはディストリビューション側で考えて
もらえばよいわけですし。

それ以外のものについては、あまり気にしないでもよいのではないでしょうか。
改訂したばかりのものを除けば、どうせ古いのですし。

-- 
長南洋一




linuxjm-discuss メーリングリストの案内
Back to archive index