和訳を読む際に心がけていること
を読んだ．その前の記事も，後の記事も読んだ．元の訳は既に読んでいて，実は「ンッ，これはポインタの命名をどうしたらいいと主張しているんだろう」などいろいろわからないという感想を持っていた．その上で，訳の正しさを徹底させるべきかどうかについては中間の立場をとる．この記事はあくまで自分向けのメモ書きとして書く．
基本事項:和訳は英文を日本語にしたものです
なんでここまで基本的なことを言うかというと，一定程度習熟した人はある文章を「和文として読む」のか「英文の和訳として読むのか」で，読む際のスタンスや読み方が異なるためである．例えば，
One of the reasons data-driven programs are not common, at least among beginners, is the tyranny of Pascal.
×データ駆動プログラムが一般的でない理由の一つは、少なくとも初心者においては、Pascalによる圧政でしょう。
○データ駆動プログラムが（少なくとも初心者の間で）一般的でない理由のひとつは、Pascalの独裁です。
この「×」の訳の「少なくとも〜」は，英文の和訳だということがわかっていれば(読点の入れ方でだいたいわかる)前にかかるということがだいたいわかる．元が英語で，カンマで区切られていると推定できるから．だから，この×の訳は個人的にはOK．その意味で，直訳はわかりやすいので安全．和訳でない和文でこのような書き方をしている人は，「ああ，この人は洋書読みまくっているな」と思う．そういう感じで読んでいけば誤訳も判断できたりする．
このほかにも，英語由来の言い回しなどがあったら，元の単語や構文がわかったりすることが多いので，これらは読むための良いリソースとなる．人は和訳だとわかっていればそれ相応に構えて読むのだ，そうでない人はもうちょっと英文を読んだほうがいいと思う．
基本事項:和訳は文章として成立していれば，正しさを検証したり原文と対照できる
ハッキリ言おう．文として成り立っていないものは，捨てるしかない．読み飛ばすか，原文を読むかになる．一方，間違っていても(逆の意味でさえも)文として成立していれば，合っているか間違っているかを文脈から推定したり，原文にあたってある程度判定できる．だから，
コードであれば、書いた内容に間違いがあれば、コンパイルエラーといった形でそれがすぐにわかる。
しかし、翻訳の場合、訳し間違いがあっても本人にはわからない。
というのは半分正しく半分間違いといったところで，人が読める範囲で間違いの判定はできるが，それ以上のことはできないという，和文にも共通する限界がある．その意味で，例の誤訳が多い訳はちょっと読みにくい．読む速度が落ちるし，理解に時間がかかるから精査ができない．
主に文系の文章について言えるのが，「Xかそうでないかについては確たる結論はないが，こうこうこういう細かいことがあるからXを支持する/しない」という主張をする事例が非常に多く，文献レビューをする際はその種のものをたくさん読むことになる．すると，1つか2つ支持するしないという根本的なレベルで読み間違いが発生する場合があるのだ．これは私の能力不足のせいでもあるのだが，不安で仕方ないので，人と議論する際は少なくともきれいな要約を用意する．そうすれば，大意の間違いの多くが発見できる．
和訳の使い方:引用する言葉は自分の言葉に類するものと心得よ
自分で文章や論文を書く際は人の文章を紹介・引用することが多いのだが，例えば「A氏はXと主張している」みたいなことを書く場合がある．これは非常に重い言葉である．A氏が長々と語っていたことの全てが，一言に詰まっているのだ．その際，参考にした訳文が少しでも疑わしいものなら，少なくとも「Xと主張している」パラグラフについては(おっと，和訳っぽい文章になっている)，自分で原文にあたって，可能なら訳すべきだ．そうすれば，人から指摘された際に責任をとれるし，何が間違っているかもわかる．これは和文についても当然言え，人の言葉を代弁するなら自分の言葉にするしかない．逆に言えば，人の訳文はその人の言葉だ．それ以上のものではない．
まとめ:文レベルの間違いよりも大意のわかりやすい文を
私は，問題となっている訳文については，文レベルの間違いより(さすがにひどいものもあったが)読みにくい訳文が問題だと思う．そして，改訳もその読みやすさ(凄く読みやすいものではないが)から評価する．和訳にしても和文にしても，文章を読む最終目的は，理解である．誤解ももともと何らかの理解をしていることを前提とする．だから，理解できないものをただ読んでも仕方がない．しかし，文レベルの正しさが全て最終的な理解につながるかというと，そうでもない．例えば
a symbol table might be implemented ...
×シンボルテーブルは…として実装されているでしょう
○シンボルテーブルは…として実装されるかもしれません
申し訳ないが，どっちでもいい．こんなところに気を取られている時間があったら訳文を洗練させるべきだし，洗練させる過程で×が◯になることもよくある．問題は，一番重要なところで重大なヘマ(true/falseの違いなど)をすることだ．それだけはないように務めて欲しいと思う．「文としての致命的な誤訳」と「文章としての致命的な誤訳」は異なり，後者には特別の注意を払うべきで，あとは，読む側がだいたいどうにかできる．重要なのは，英語スキルもそうなのだが，わかりやすい日本語を書いて伝えるスキルである．
補足
この英文に誤訳が多かった理由は，原文が論文のような紋切り型の文章ではなく，くだけた癖のある文章だったことに由来すると思う．その点で，技術書や論文よりも難易度は高い．下手に首を突っ込んだら細かい間違いはいくらでも出てくるだろう．英文学ならなおさらだ．
あと，誤訳指摘記事のブコメで「高校英語レベルの〜」という発言がちらほら見られるが，英語圏には日本の高校英語はない．安易に日本の基準で難しさを語るのはミスリーディングだと思う．
