2014/10/13
翻訳のセルフチェック
言ってることはよくわかる。 これはちょっとなあ、と思う訳を目にすることは、個人、商業どちらでもしばしばある。
だからと言って個人の場合、「下手な訳は公開するな」とも言いたくはない。 誰だって経験によって上手くなるし、 他者の目に晒されてこそ改善されてゆくから。
で、まあ叩き台を晒して揉んでゆけばいいんじゃない、っていうのが大人の結論なんだろうけど、 それじゃつまらないので、もうちょい突っ込んでみる。
「誤訳は程度問題」としてこの話題を相対化する議論があるんだけど、 個人的な感覚からすると、程度問題で片付けられない質の差ってものがあるように思う。
オープンソースのコードにも質は色々あるけれど、 コンパイルがそもそも通らないとか、実行したらいきなりSEGVするコードを 出してきて「叩き台です」という人はいないと思うんだ。 やりたいことの一部機能がまがりなりにも動いて、何をしたいか 客観的にわかるコードがあってはじめて、改善案も出せるというもの。
でも、翻訳だと「コンパイルを通らない/実行できない」レベルがたまに出てくる。 単に訳文が日本語としておかしいという構文エラーじゃなくて、 もっと大きな構造として意味が通らない、というものなんだけど。 そういう段階だと、なかなかコメントしづらいので、 フィードバックによる改善サイクルがうまく回らない。
コードなら実際に実行してみることで、出す前に自分でチェックできるけれど、 翻訳だとそういうツールが無いから自分でわからない、というのが問題なんだと思う。 (実行環境が無い状態で曲がりなりにも動作するプログラムを書くことの難しさを 考えれば、翻訳でそのハードルをクリアするのは簡単とは言えないだろう。)
けれど、ちょっと気をつけるだけで 公開して有益なフィードバックをもらえる確率が格段にあがる、という ポイントはいくつかあると思う。
★ ★ ★
構造
技術的文章については、原文が全体として主張したいことは何か、 そのために各パラグラフでどういう主張をして、それがどのように論理的に組み立てられているか、 という点はかなり明確なことが多い。
訳語の選択や日本語としての言い回しには訳者の個人差が出るとしても、 背後にある論の骨組みについては、これは明確に「正解」が存在するものだ。 SEGVレベルの訳文の代表的なものは、この骨組みをとらえ損ねているものだと思う。
翻訳のスタイルは色々で、私は原文を読んで一旦骨組みを頭の中に収めてから 訳し始めるけれど、とりあえず下訳を作ってから組み立てを考えるという人がいてもいいだろう。 でも最終的に、自分が原文の構造を理解したかどうか、ということは、自分でかなりの程度まで チェックできるはず。
文の一部や単語の意味がわからなくても、全体の論旨と文の構造を見れば、 これとこれは並置されているとか、この要素はこの要素につながっている、とか、 この代名詞はこれを受けている、といったグラフが描けるはず。 そういう抽象化はむしろプログラマの得意分野だろう。
この構造がわかってない場合、出てきた訳文がどんなにもっともらしくても、 外している可能性は高い。 よくあるのは、ちょっとした誤読である一文の意味を逆に取ってしまい、 でもその辻褄を合わせるために訳文をいじって無理やりつなげようとして 傷口が広がるというもの。
自信が無かったら、その部分は全体の中でどういう役割になってるか考えてみるといいだろう。 その上で分からなければ、部分的に原文を残して、 「構造的にここは「XはYの一種だ」と言う主張が来るのが自然だと 思うんだけど、この英語表現をそう解釈できるのか自信がない」みたいな 注釈をつけておいてもいいと思う。
翻訳の改善では訳語の選択や表現について議論になることが多いけれど、 どういう表現にすべきかというのは元の論理構造に照らして判断されることなので、 構造が見えない段階で議論しても全く実りがない。
主語
日本語は文脈から明らかな時は主語を省略するのが普通だけれど、この性質はともすると 「主語がわからないから書かないで誤魔化す」というふうにも使えてしまう。 でもそうやって誤魔化した文は、文法的に合ってても意味的にわからない文になる。
訳出するかどうかは別として、訳している本人は、その文の動作の主体が自分で わかっているかどうか自覚できるはず。従属節や動詞句についても常に 意味的な主語は何なのかチェックしよう。
照応
代名詞は何を指しているか。 これも、最終的な訳文では明示しなくて良いことが多いんだけれど、 「わからないので書かない」という誤魔化しも出来ちゃう。 訳出するしないにかかわらず、自分でわかってるかどうかチェックしよう。
原文における数(単数/複数)や冠詞、時制は、訳文に直接現れないことが多いけれど、 照応を判断するのにとても役に立つことが多い。というか英文に慣れてくると 無意識のうちにそのへんを手がかりにして判断できるようになる。
とはいえ、実は原文の著者も感覚で書いてて照応があやふやになってる場合があったりする。 なのでテストに解答するみたいに何が何でも全部答えをみつけなきゃならんってことは ないんだけど、自信が無ければ(ここは原文の著者も混乱してるな、と判断できなければ) 「ここのitが何を指してるか不明、 構造的にはこれだと思うんだけど英文としてそう解釈できるのか自信なし」とか注を入れとけばいい。 肝心なのは「ここがわからない、という点がピンポイントでわかっていること」だ。
質問
技術文書は、著者がまだ生きていてemail等でコンタクトが取れることが多い。 だから、わからなかったら何となく訳すんじゃなく、作者に尋ねることを考えよう。 (作者がCCライセンス等を明記してない場合、どうせ公開前に許可を求めることになるわけだしね。)
著者も広く読んでもらいたくて公開しているわけだから、 大抵は快く教えてくれるはず。
実際に作者への質問を考え始めてみれば、「なんとなく意味がわからない」というのでは 質問できないことがわかる。「自分は原文がこういう流れだと解釈して、 だからここはこういうことを言いたいんだと思うのだけれど、 このフレーズをそういう意味に取って良いのかわからない」 というふうに、わからない箇所を具体的に絞り込まないとならない。
そういう質問を考えてるだけで答えがわかる場合もあるし、 作者に質問するのに気後れする、あるいは作者とコンタクトが取れない場合でも、 その質問を訳注として入れておけば、有益なフィードバックが得られるだろう。
★ ★ ★
他にもあると思うけれど、とりあえず思いつくのをあげてみた。
このいずれも、実際に一文一文日本語を考えてタイプする手間に比べれば、 そんなに負担の多いものではないと思う。私の感覚では、頭の中に収めた原文の 論理グラフを日本語で表現するという作業が翻訳作業の9割を占めるんだけど、 これらチェック項目はそれ以前に済ませられる話だ (その意味で、 「とりあえずコンパイルを通してみる」という感覚に近い。 シンタックスではなくセマンティクスのチェックではあるけれど。)
自分も感覚的に訳してて厳密に考えてないことは多いけれど、このへんについては バックグラウンドでセルフチェッカーが走っている感覚はある。
Post a comment