読み手のための翻訳とは

だいぶ時期を外している気はしますが、「プログラミング言語C++ 第3版 (Bjarne Stroustrap著)」という重くて厚い本が出ていますね。 これまで日本語で読める書籍でSTLについて書いたものは少なかったのですが、これには結構詳しく載っていますから、またいろいろ凝った使い方を試みたりして楽しめそうです。

ただ...憶測ですが、かなりの人海戦術で分担翻訳したのではないでしょうか。 「たとえば、2つの補い合う16ビット整数でintを表現するマシンでは、0xffffは10進負数の-1である」だそうです(108ページ)。 「2の補数表現」のことだよね。 なじみのない分野の翻訳をするとこういうことがあるのだ、と自戒しなければと思っているところです。

怪しげな対訳表

実は私もつい先ごろ、某C++関連資料の翻訳に関わりました。 こういう時って、「技術用語はこの訳語を使ってください」と言って英和対訳表みたいなのを渡されることが多いんです。 まあ、同じ言葉が前半で「オペレーター」、後半で「演算子」なんてなっていたら読む方は困ってしまいますから、これ自体は結構なことなんですが、対訳表が怪しげなことも決して珍しくはない、というか、むしろそれが普通なんですよ。 例えば、「unary operator」が「単項演算子」で、「binary operator」が「バイナリーオペレーター」になっていたりします。 こういうのを整理して、後者も「二項演算子」という訳語を採用しました、などと註記しておくのですが、その後の対応がまた怪しげ。 それじゃあ、ってんで対訳表の「binary operator」の訳語に「二項演算子」を追加するのはいいんだけど、「バイナリーオペレーター」は残したままになっているのではないかと思われるふしがあります。

ですから、「対訳表があるから辞書を引く手間が省ける」などとは決して考えず、きちんとした辞書や文献を参照しなければならないということです。 むしろ、対訳表は訳文に制約を与えるものというつもりで扱った方が、現実に合っています。

この仕事をしたときは、「章や節の題の訳はこちらで指定します」という指示で、そのくせその指定が納品日ぎりぎりに届いたのですが、ここで訳語がまたひっくり返ってしまいました。 対訳表に従って「constructor」を「コンストラクタ」としておいたのに、章の題には「構築子と消滅子」なんて書いてあったりして、20個近くの語を全文検索・置換することになってしまったのです。 困ったもんだ。

「訳語の統一」の呪縛

文学作品では、例えば「ビル・クリントン」が次の文では「大統領」になって、その次の段落では「あのいけすかない奴」なんていう主人公の感情が入った表現になっていたりすることはよくあります。 それに対して技術文献では、「演算子」は最初から最後まで、どの文でも「演算子」と統一しなければならない、というのも常識の部類でしょう。

とは言っても、何にでも例外はあるのです。 英文では日常語の感覚で使われている語が、日本語では専門語扱いになっている場合に、よく問題になります。

例えば、「red」といえば「赤」ですが、赤といっても、黄色がかったもの、紫っぽいものなど、幅があります。 そして、英語を母語とする人が「red」と認識する色が、日本語を母語とする人にとってとても「赤」とは言えない色だったりすることがあるのです。 このような現象は鈴木孝夫氏がいろんな所で指摘していますので、読んだことのある方も多いと思います。

同じようなことが、ソフトウェアを解説する文でも起こります。

「select」といえば「選択(する)」とか「選ぶ」とかいう訳語が思い浮かびます。 ダイアログボックスにラジオボタンが並んでいて、「りんご」「みかん」「バナナ」などの選択肢からひとつ「select」する場合は、「選ぶ」という訳語でいいでしょう。 しかし、ウィンドウの上の方にあるコマンドメニューから「編集」「削除」の順に「選ぶ」というのは少々違和感があります。 確かにいろいろなコマンドが並んでいる中から選ぶのではあるのですが、実際にそのソフトウェアを操作している人の感覚では、選んでいるというより、コマンドを「呼び出す」あるいは「起動する」つもりでマウスを操作しているのではないかと思います。 もっとも、これを「選ぶ」と説明している書籍は結構ありますから、慣れてしまって、それほど変には感じていないかも知れません。

更に例を挙げます。 「ファイルがみつかりません」みたいなメッセージボックスが現れて、「OK」ボタンだけがついている場合、英語ではそのボタンを「select」すると言うことがありますが、日本語で「選ぶ」と言うと不自然です。 「選べったって、選択肢がないじゃん」と突っ込みたくなります。 これはやっぱり、「OKボタンを押す」などと表現した方がいいですよね。

また、create、generate、produce、makeとか、modefy、changeなどといった語も英語では日常語の部類ですから、厳密に使い分けたりせず適当に(筆の勢いで)選ぶ人もいます。 こういう場合、「作成」「生成」「生産」などと訳し分けてみても却って訳文が混乱しますから、翻訳する方も筆の勢いというか、日本語の文脈やリズムのみ考慮して選んだ方がいいようです。

いえね、対訳表でcreateは「作成」と指定されていて、ときどき「作る」と言いかえるだけでも指定と違うと文句を言われそうな雰囲気だったので、どうも文章のリズムが崩れて気になったんですよね。 そんなところを統一したってしょうがないだろうに。

読者の立場

C++関連資料の翻訳に関わった、と書きましたが、私自身は翻訳ばかりやっているわけではなく、むしろこのような訳文を読んで使う立場になることも多いのです。 その場合、普通は英文は読まずに訳文だけを読むことになるのですが、原文がどうなっているかよくわかる文章に出会うことがよくあります。 関係代名詞が「スルトコロノ」になっている文はさすがに滅多にありませんけど、英文に返り点を打って読み下したようなのを読むとうんざりします。 「10個またはそれより多い項目が選択されることができます」なんて文があって、この原文は多分「10 or more items can be selected.」です。 ところが、そういう訳文をわざわざ依頼する人もいるそうで、実に驚いてしまったんですけどね。 技術者は英文と付き合わせながら読むから、こういう訳文の方がいいんだそうです。 それは逆だろうがっ!! 訳文がひどいからやむを得ず英文を参照するのであって、日本語だけで意味がわかり、ソフトウェアを使えるようになるのであれば、英文を見る必要はありません。 もっと言えば、その日本語文献が英文を訳したものであろうと、最初から日本語で書き下ろしたものであろうと、どうでもいいのです。

その意味では、こういう資料を翻訳する人は、翻訳者である前にテクニカルライターのつもりになるべきだと思います。たまたま、参照する資料が日本語の仕様書類ではなく英語の資料だったというだけのことです。

広告文なんかでは、こんなことはありませんよね。 翻訳者である前にコピーライターであるという立場で制作されています。 有名な例ですが、アメリカで売れたコカコーラを日本でも売ろうというとき、Drink Coca Cola! というコピーをそのまま「コカコーラを飲め」とはしませんでした。 原文の意味は一応把握した上で、日本での広告にふさわしいコピーを「創造」したわけです。

映画の題名なんかも、原題にとらわれず、日本人の琴線に触れる題名をつけて……いたはずなんだけど、最近は単に片仮名にしただけのやつが多いぞ。