2016/11/24

Google翻訳と下訳

Google翻訳を下訳に使って手早く技術文書を翻訳してみました、という例:

• 新Google翻訳を使って3700ワードの技術文書を1時間で翻訳した

訳された文章はこちら: Hadoop: Fair Scheduler

おそらくこれからはこういう形のやり方も増えてゆくと思うので試みとして面白い。 同時に、現在の機械翻訳で弱そうなところ(従って、下訳から修正する際に気をつけるべきところ)が 見えてる気がする。「イントロダクション」の節からいくつか例を挙げてみる。

(引用は現時点での訳。徐々にフィードバックを受けて改善されると思うので後で見る時は 変わっている可能性あり)

現訳:

デフォルトでは、フェアスケジューラはスケジューリングフェアネス決定をメモリ上でのみ行います。Ghodsiらによって開発されたDominant Resource Fairnessの概念を使用して、メモリとCPUの両方でスケジュールを設定することができます。

原文:

By default, the Fair Scheduler bases scheduling fairness decisions only on memory. It can be configured to schedule with both memory and CPU, using the notion of Dominant Resource Fairness developed by Ghodsi et al.

"on memory" は典型的にはデータを操作する際にそれがメモリに乗っていることを指し、 「メモリ上で」と訳されることが多い。 けれどもここのonは "base X on Y"、「Yに基づいてXを構築する/Xの基礎にYを置く」 のonであって「メモリにのみ基づいて(スケジューリングの公平性を決定する)」という意だ。

on memoryを場所を示す副詞句と取れば「メモリ上で決定を行う」という解釈も 構文的には可能である。

そちらの解釈が却下される理由は、次の文の意味とのつながりにある。次の文ではメモリとCPUの両方を 考慮してスケジュールすることも可能だと言っている。原文を読む人間は、 最初の文ではっきり意味を確定していなくても、次の文を読んだ段階で

「さっきメモリのみと言っていて、次にメモリとCPUの両方ってのを持ち出して来たんだから、 スケジューリング決定のパラメータとして、メモリのみ、あるいはメモリとCPUの両方、という オプションがあるんだな」

と理解する。

現訳でも内容を良く考えればその解釈に至ることは可能だと思うけれど、 私は一読してわからず原文を読んでしまった。例えばこう書いてあったら 一読で理解できたんではないかと思う。

デフォルトでは、フェアスケジューラはスケジューリングフェアネス決定をメモリのみに基づいて行います。Ghodsiらによって開発されたDominant Resource Fairnessの概念を使用して、メモリとCPUの両方でスケジュールを設定することもできます。

原文2文目にalsoは入っていないけれど、元の英文では2文目冒頭にIt can beが来て 別の可能性に言及していることがすぐ分かるのに対し、日本語では「できます」が 2文目末に来てしまうので、「も」を補なうことで流れをわかりやすくできる。

現訳

スケジューラはアプリケーションを「キュー」にまとめ、これらのキュー間でリソースを公平に共有します。

原文

The scheduler organizes apps further into “queues”, and shares resources fairly between these queues.

ここは単文での翻訳としては問題はない。問題は、この前のパラグラフで、

「アプリのキューを形成するデフォルトのHadoopスケジューラとは異なり、(Unlike the default Hadoop scheduler, which forms a queue of apps,)」

と言っている点だ。「アプリのキューを作るデフォルトのスケジューラとは違う」と言っておきながら、 「アプリケーションをキューにまとめ」と来るので読者は混乱する。

先のキューと今出てきた「キュー」は違うものを指していて、原文でクオートされているのも それを強調する意図があるのだろうけれど、もうひとつ、原文では 先に出てきたキューが単数で、後に出てきたキューが複数であることが、 両者が違うものを示すという重要な手がかりになっている。

一般には単数形/複数形は訳出せずに、文脈で示唆するに止めることが多い。 この文でも「これらのキュー間」がすぐ後に来てるから複数形であることは示唆されている。 のだけれど、文脈の流れで数が重要な情報を担っている場合は、陽に訳出してあれば 読者が何度も読み直したり原文に当たったりする必要が減るだろう。

スケジューラはアプリケーションを(複数の|いくつかの)「キュー」にまとめ、～

対照をより強調するために、前パラグラフのデフォルトのスケジューラについて「アプリを一つのキューに並べるデフォルトの…」としておくこともできるだろう。

また、この後に、デフォルトでは"default"という単一のキューが使われると出てくるのだけれど、 それに続けて複数のキューに振り分ける方法がいくつか説明される。 私が訳すとしたら、その流れを示すために 次の文を「デフォルトでは〜単一のキューを共有しますが、アプリケーションが〜」 といった具合に原文にない接続詞を補うかもしれない。 (原文に無い言葉をどこまで補うべきか、というのは難しい問題だが、 技術文書の場合は読者の想像力に訴えるよりは意味をなるべく明確に伝達する方が優先されるだろうから、 論理の流れを示すような補間はわりと有効だと思う。)

現訳

フェアスケジューラは、すべてのアプリケーションをデフォルトで実行することができますが、configファイルを使用して、実行中のアプリを実行するアプリ数をユーザごとおよびキューごとに制限することもできます。

原文

The Fair Scheduler lets all apps run by default, but it is also possible to limit the number of running apps per user and per queue through the config file.

後半の「実行中のアプリを実行するアプリ」は多分編集ミスだろうけれど、 ここで見たいのは "lets all apps run" の方。 「何もしなければ全部走らせる→configで制限かけることもできる」というのがここの流れだが、 「Aできますが、Bもできます」では並置の印象が強く、原文にある流れが消えているのが 読みづらさの要因だろうと思う。

フェアスケジューラは、デフォルトではすべてのアプリケーションを実行しますが、 configファイルを使用して、同時に実行するアプリ数をユーザ毎やキュー毎に制限することも できます。

現訳

これは、一度に何百ものアプリケーションを送信しなければならない場合や、一度に多数のアプリケーションを実行すると、中間データが非常に多く生成されたり、コンテキスト切り替えが多すぎたりすると、パフォーマンスを向上させるために役立ちます。

原文

This can be useful when a user must submit hundreds of apps at once, or in general to improve performance if running too many apps at once would cause too much intermediate data to be created or too much context-switching.

現訳は一番外側の「これは、〜パフォーマンスを向上させるために役立ちます。」で主語述語の 対応が取れてるように見えるために、校正時にもつい読み流してしまうのかもしれない。けれど 間を良く読んでみると翻訳の日本語で節間のつながりが良く分からなくなっている。 二つめの「すると」は意味的に「役立ちます」にはつながらない。

原文の構造は次の通り:

   useful 
    +- when a user must submit ... at once
    +- (in general) to improve performance
          +- if running too many apps at once would cause
               +- too much intermediate data ...
               +- or too much context switching

when節とto improveの句が並置されている(意味的には、単なる並置というより、 前者を後者で一般化説明していると考える方が良いだろう)。

ということは翻訳文は次のように解釈するのが正しいことになる。

  これは、
     - 一度に何百ものアプリケーションを送信しなければならない場合
     - 一度に多数の〜パフォーマンスを向上させるため
  に役立ちます

翻訳文をこう切れば(接続語の問題を除いては)間違いとは言いきれないが、 自然言語ではネストをうまく表現できないので、人間が今の翻訳を一読すると

   これは、
     - 一度に何百ものアプリケーションを送信しなければならない場合や
     - 一度に多数のアプリケーションを実行する
   と、
     - 中間データが非常に多く生成されたり、
     - コンテキスト切り替えが多すぎたり[するので]、
   パフォーマンスを向上させるために役立ちます。

という具合に読んでしまうのではなかろうか。

これは、木構造をシリアライズするにあたって、語順の違いによって曖昧性が生じてしまう例である。 日本語の場合、枝に分岐した後、述語で合流させないとならないので、切り方が難しい。 接続詞と句読点を工夫したり、主語述語の塊を後ろに持ってくるといった手が使える：

一度に何百ものアプリケーションを送信しなければならない場合、より一般的には、一度に多数のアプリケーションを実行して中間データが非常に多く生成されたりコンテキスト切り替えが多くなりすぎる時の性能を向上させるのに、これは役に立ちます。

あるいは、in general以降が一般化した説明であるという意図を汲んで文を 分割するか：

これは、一度に何百ものアプリケーションを送信しなければならない場合に便利です。 より一般的には、一度に多数のアプリケーションを実行して、中間データが非常に多く生成されたり、コンテキスト切り替えが多くなりすぎる時の性能を向上させるのに役に立つでしょう。

共通点としてなんとなく見えてくるのは、以下の点の弱さだ。

• 文やパラグラフをまたいだ「流れ」を読者に示すための適切な訳語の選択
• 翻訳文を読んで読者が頭の中に構造を描けるか、という読者視点からの配慮

機械翻訳がこれら、特に後者に弱いのは致し方ないとも言えるので、 下訳から直してゆく際に翻訳者が特に注意すべき点と考えた方が良いと思う。

翻訳者はなまじ原文を読み込んでいるために、下訳の日本語が少々おかしくても 好意的に解釈して見逃してしまうという危険があるかもしれない。 「流れ」を示す訳語の選択は、時として本当に些細な接続詞や句読点の 違いだったりする。そんな、一見どうでもいいような違いを自信を持って修正できるには、 原文が何を言っているのかを明確に把握している必要がある。 その点で、参照エントリが言うように、機械翻訳を使えるからといって 翻訳者に必要とされる英語力が下がるということは当分は無いだろう。

Tags: 翻訳, 英語