Island Life

2016/11/24

Google翻訳と下訳

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

訳された文章はこちら: 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: 翻訳, 英語

2016/11/01

Big Island

撮影でしばらくハワイ島のコナに行っていた。出番はそんなに無いんだけど撮影日が微妙に離れてて、10日間滞在することに。 プロダクションが用意してくれたホテルはSheraton Kona Resortで良いホテルなんだけど周囲に何もない。ホテル内のレストランは高いし選択肢が限られる。徒歩圏で買い物が出来るのは1マイルくらい先のモールのみ。仕方ないのでそこのスーパーで食材を買い込んで暮らしてた。まあ、per diemの経費が給料とは別に出るので少々高くついても損はしないのだけれど。

今回の映画はSAGのLow budgetプロダクション(総予算が基本$2.5Mまで、条件によっては$3.75Mまで←今回のは多分こちら)なんだけどlow budgetと言ってもキャストのほとんどはLAやNYから呼んでるし、給与の最低基準が低いのといくつかの労働条件制限が緩和されてること以外はフルのSAGプロダクションと待遇は変わらない印象。これまでよくやってたインディーの低予算映画の「低予算」とは全然違う。(そういう印象どおりの「低予算」はSAGのultra low budgetカテゴリとかが該当する)

ペイはもちろん多くもらえるに越したことはないけど、自分にとってはベテランの役者さんとシーンをやれる経験が貴重だ。クラスで学んだことを実践に使ってみてうまくいくことを確認する、という意味で学ぶところが大きい。

公開は来年。詳細は公式発表があってからこちらにも書こうと思う。

Tags: 芝居, 映画

2016/09/21

ソヴィエト

先週マウイに行った折、金曜の午後のスケジュールが空いていたので マウイ在住のアマチュアピアニストの友人宅にお邪魔した。 ハレアカラの山腹、クラにえらく広い地所があって、山のロッジ風の広い家だった。 天井が高くてリビングに置いたピアノが良く響く。 途中から、ロシア出身のピアニストの知人も合流して代わりばんこにいろんな曲を弾いた。

自分は、ShostakovichのA majorのPrelude&Fugueを復習してるのでそれと、 Kapustin Op.40の6,7,8、あとこないだ弾いたBach。

ShostakovichのA major (Op.87-7) は自分は可愛い曲だと思うんだけど、 ロシアのその人は「ずいぶんリリカルに弾くのねえ」と。 「ソヴィエトだった頃は、こういう曲は勇ましく、マーチみたいに弾くように言われたものよ。 人民を鼓舞するようにって、そういうのじゃないと党にウケが悪いから。」

へぇ~。確かにそう言われてみればこのテーマはトランペットのように聴こえなくもない。 Shostakovich本人やNikolayevaの演奏だとむしろ鐘って感じかなあ。かなり速いから。 でもOp.87全体が、社会情勢とは離れたとても個人的、内面的な作品って感じがするんだよなあ。

Tag: Piano

2016/09/18

Mai Poina in Maui / 演出家の仕事

毎年9月にやって8年目になる "Mai Poina: The Overthrow" walking tour、 今年はマウイへの遠征公演もあって、昨日帰ってきた。

本公演はイオラニ宮殿の敷地にて、実際にその出来事が起きた場所を見ながら 当時の人物に扮した役者が出来事を語る。でもマウイ公演では劇場の舞台での パフォーマンスになるので、舞台向けにアレンジしなければならない。 どうやるのかな、と思ってたけど、元の演技はほぼ変えることなく、 公演全体をブレヒト的な枠に収めることであっさりと生まれ変わらせてしまった。 演出家のこういう手腕はほんとに見事だなと思う。

何度か演技のクラスで一緒になった俳優のDennis Chun氏は 役者の仕事は"how to make the scene work" を考えることだ、 と言っていた。とすれば演出は "how to make the play work" を担当するって ことかもしれない。

うまいなと思う演出家って、「こういう演技をしてくれ」とは決して言わない。 芝居全体に一貫性を持たせる枠を設定したり、キーポイントでの解釈を 決めたりする。それに沿って「シーンを成立させる」ように演技してれば自然に 芝居が形になる感じ。「役者をのせるのがうまい」ということなのかもしれないが。

役者の解釈が持ってきたい方向と違っていた場合、良くあるのは、演出家が 別の解釈を提案して"Does that make sense to you?"って聞いてくることだ。 解釈が腑に落ちれば、そこから出てくる表現は何であれ「正解」のはずである。 (もともとそうなるような役者をオーディションで選んでいるのだから。 正しい解釈をしているのに表現ができない、という役者は選ばれていないはずである。)

表面的な表現だけをいじること(「もっと怒りを出して」とか)はあまり 良いディレクションではないと感じる。もちろん、そう言われれば役者としては もっと怒りを出す必然性があるような解釈を新たに探すわけだけれど。 幸い、そういう演出や監督に当たったことはほとんどない。

演出や監督の、こういう面というのは、現場経験者以外には案外知られてない ことかもしれない。表現に対して注文をつける仕事だと思われてる節もある。 表現は役者の責任だ。芝居全体にハマるような表現が出てくるように誘導するのが、 演出の仕事、という感じがする。

Tag: 芝居

2016/09/04

Celebration of life

最近ちょっと続いたのでメモっとく。

誰かが亡くなった後にやる儀式、近年ではfuneralではなくcelebration of lifeとするようだ。根本にある意義としては同じだと思うが、celebrationの方は宗教色がほとんど無く、故人に関する思い出を皆で共有するという点に絞っている感じ。例えばスピーチやビデオ上映があって、後は飲み食いしながら歓談とか。故人の遺体との最後のお別れ、みたいな機会は別に設けられるので(そちらは親しい友人のみ等ひっそりやることが多い)、celebrationは没後数週間の期間を置いてから設定されることも多い。時間を置いた場合、色々凝った準備がされる場合もある。

今までで一番印象に残ったcelebrationは、演出家James Nakamoto氏のものだった。氏は長年McKinley High Schoolで演劇のクラスを教え、ハワイとLAで多くの舞台を演出した。私も一度、氏の演出する舞台に出演したことがある (Mainland Education, 2009 at Kumu Kahua Theatre)。教え子で役者やパフォーマーになった人も多い。氏は2013年に亡くなったが、McKinley卒の教え子が集結して2014年、氏に捧げる芝居を作って1日限りの公演を行った。演劇人を送るのに、これに勝る儀式は無いだろう。

どういう形を取るにせよ、定型の儀式のかわりに色々計画して準備するというのは、残された者にとっても良いセラピーになると思う。

Tag: 生活

More entries ...