#VGTransJP Tweets まとめと補足

ここ数ヶ月 #VGTransJP で自分が発言した内容に補足して、考えをまとめておきます。
目線は言語的ローカライズの実務経験者からですが、全体的には、パブリッシャやデベロッパの方にこそ読んでほしいです。相変わらずワチャクチャな文章ですが、何かの役に立てば。

突っ込みや疑問などありましたらぜひ LYE までお知らせください。何でも喜びます。

ワークフロー!

ビデオゲーム翻訳の「やり方、進め方(=ワークフローやファイル形式)」は作品ごとに違うと思っていた方がいっそよくて、作業対象ファイルを十分に理解した上で対応出来る IT 的発想力/応用力がないと、対応するのは難しいと思う

毎回同じ方法で対応できることはまずないので (続編ならまた違いますが) 、まず言語的ローカリゼーション (以下、長いので LL ="Linguistic Localisation" とします) のプロジェクトの評価段階で「自社の得意なワークフローと今回の対象物の相性」や、「一般的なプロジェクトとの相違点」をできるかぎり「適切な人材が」「許す限りの時間を費やして」行うべきだと思います。はい、理想論ですね。ただこれを理想とした場合、そこからそぎ落としていく作業のトレードオフが何なのかは、絶対に考えなくちゃいけないですよね。このへんは企業のノウハウで、外に出すものではないのかもしれませんが、僕は共有したほうがいいんじゃないのかなと...どうも自分は理想論が大好きなようです。はい、実現するための手段を考えればいいんですよね。頑張ります。

ちょっと論点はズレますが、たとえば BioShock 2 が字幕対応になったことについて*1BioShock というゲームには、ストーリーに深みを与える要素として「音声ログ」(物理メディアに記録された音声で、拾ったプレイヤーは再生しながら動ける) があります。ストーリーの枝葉部分を遊びながら聞けるということですが、極端な話、気を抜いたら即死という状況でも再生できるわけで、字幕を見ながら遊ぶというのはかなり辛いです。安全な場所で止まって聞くのはオリジナル版のゲームエクスペリエンスを大きく変えてしまうので、私個人としてはやはり BioShock 2 は吹き替えのほうが良かったのではないかな? と思います。

Analyze, Decide, Detect, Process!

ローカリみたいな「間に入ってやる仕事」は、権限委譲がきちんとされていてアホみたいな管理主義がはびこらなければ丸投げがコストパフォーマンス的に一番いいと思う。問題は開発、パブリッシャ、ローカリベンダ間の政治的なものである。とか言ってみちゃう。

我ながら読み返すと何てことを言っているのでしょう...。きっと嫌なことがあったのですね。最近これに関連する発言をしたので、そちらも引用します。

ローカリ = 翻訳 という認識の方は結構多いけど、翻訳研究の論文によると「翻訳は14前後あるL10Nプロセスのひとつ」であり、厳密に翻訳だけを指すときは「Linguistic Localization (言語的ローカリ)」と呼ぶのが好ましいそうです。そしてローカリゼーションという単語自体、ここ20年の IT の発達に伴って使われるようになった用語で、さらに "ゲームの" とつくとその研究やらまとまった資料やらはまだまだ少ないです。 ほんでもって、"ゲームの""言語的" "ローカリゼーション"を"日英"で考えるなんてのはさらにマイナーなお話しになるので、ここでホントなら色々整備しなくちゃいけないはずなんだけど 儲からないし忙しいからもうどうするんでしょう。しかもローカリ産業が生まれた経緯が「社内対応しきれねえ」から「外注しようぜ」なので、「非言語的ローカリ」担当(クライアント)と「言語的ローカリ」担当(ベンダ)の立場が対等じゃないことが多くて、おまけに意思決定権持った人が外国にいてクソ忙しいこともあるという。

LYE が現場にいたとき、個人的に一番働き甲斐があったのは「クライアントがローカリゼーションに本気で、翻訳に関する指示と期待が明確で、資料が手元にあろうが無かろうが入手または入手しようとしてくれ、こちらからの提案を (受け入れるかどうかは別にして) 聞く姿勢を維持してくれる」環境でした。納期的にしんどいことがあっても、プロジェクトに参加できることが嬉しかった。いちワードを翻訳するその時間が満ち足りていた。イタコとして幸せだった。逆に悔しくて胃が荒れたのは「日本市場も日本語も知らないクライアントが最初に訳文が制限されるようなルールを設定して (多言語展開で全言語に同じ指示を出すことが多かった)、その後問題や質問を挙げても返事が遅かったり返ってこなかったりする」環境でした。
原因は複雑なので何ともいえません。営業が仕事とってくるときにワケの分からん縛りを自らに課したのかもしれないし (全言語に同一ルール適用でブランドイメージが統一されて御社大勝利!)、パブリッシャ側には十分な時間コミットしてくれる担当者が割り当てられていなかったのかもしれないし (ローカライズ? Google 翻訳じゃ駄目なの? 的アプローチ)、ベンダー側のプロジェクトマネージャがやる気なくて握りつぶしてたのかもしれないし (また日本だけ文句いってら、ライス食って寝てろ)、オリジナルの開発がクランチクランチで人が死に掛けててどうしようもなかったのかもしれない (メディーーーック!)。
いずれにしても、スタッフは何人? 各人は何を担当する? プロジェクトの最後までフルタイムでコミットする/しない? ←これだけのリソースを確保するにはそれを正当化するだけの理由があるよね、それは? となり、大体どっかで何かが掛け違ってるんじゃないかなーという予想。
偉い人を説得する数字がいりますね。そしてそんな数字はどこにもありませんね。だから偉い人が最初から納得している環境でしか、僕の幸せは具現化されない。なるほど。

誰のための翻訳?

英語は主語が必ずあり、名詞を中心とした言語なので「翻訳くさくない」ということは即ち「翻訳者が物語を噛み砕いて日本的にしてある」ということで、結果「オリジナルくささ」あるは「肌触り」は翻訳調の場合よりも失われる。そのとき、「翻訳対象の作品は、オリジナルの "肌触り" を犠牲にしてでも日本的にしたほうが良いのか? それはターゲットとする観客と作品に合った行為か?」という質問に真摯に向き合わないと、おそらく一番作品を愛している現地観客の層が失望する、と思う。

以前、英語のネタ/ジョークの扱いでも少し触れたお話。翻訳研究の分野では、「著者を読者に歩み寄らせるのか」「著者のところに読者を連れて行くのか」というような表現で議論がなされているようです。そして結論は出ていません。尊敬する Miguel Á. Bernal-Merino 氏 (Roehampton University でゲーム/メディアローカリゼーションの研究をされてる、IGDA LOC-SIG の Co-Founder) 氏はケースバイケースだとどっかで言ってました。私もそう思います。そして LYE は、これこそが、パブリッシャが「遊んでほしいゲーマー層」を予測した上で自ら決めるポイントなのだと考えます。ここがぶれたままだと、(僕が翻訳を担当していたら) 品質もぶれます。

翻訳支援ツールの要件

「ゲーム翻訳に求められる翻訳支援ツールの要件」を議題にしたら盛り上がりそうだ。多くの翻訳支援ツールはエンジニアのほうを向いて作成されるので翻訳の段階での使い勝手が悪くなる。このあたりで意見を交換することで、プロジェクトが走り出してから発生する例外的処理を減らせるのではないか。言い出しっぺの私はこれまで4種のソフトウェア翻訳支援ツールを使用した経験があるけど、すべてが元々ユーティリティソフトウェア向けに開発された翻訳支援ツールでした。それでも、ドキュメント向けの支援ツールを使うよりははるかに便利でした。

主に用語集/既存訳文の自動ルックアップ機能とフレキシブルなQA機能、バージョンコントロールの容易さ、ステータスを示すフラグの存在がでかかった。

問題だったのは、ツールに習熟した人材が少ないことと、習熟までに時間がかかること、そしてGetting Started的なチュートリアル資料が充実していなかったこと。Geekyな翻訳者というのは結構少ないですし、Geekでエンタメ翻訳できる人はさらに少ない。

何十万ワードもあるタイトルを

  • ひとつのデータベースにまとめられる (Excel よりぶん回しやすい! )
  • 未翻訳、校正待ちなどの文字列ステータスでフィルタリングできること (Excel だとシートまたがってフィルタできないし、何より処理が重くなって遅い)
  • 正規表現を使った絞込みがサクっとできること (何を検索するのか、決めるのもそれを RegExp で表現するのもみんなができることじゃあないですけれども)
  • 用語集に準拠しているかどうかを自動でチェックできること (まずちゃんとした用語集作るのも大変なんですけれども)
  • 旧バージョンのオリジナル/ターゲット文字列が何だったか、作業に使うソフトウェア内でチェックできること

ざっと挙げてもこれだけの利点があるにもかかわらず、まだ Excel が使われている理由は何か? 以下、妄想。

  • ツール作っても、ツール用に翻訳対象ファイルの Purser を書ける人が確保できない/いない
  • 費用対効果がもやもやしてて予算の正当化ができない。あと、プロプリエタリなツールがほとんどなんで、ベンダーが持ってなかったら買わなきゃいけないし、ベンダーが発注するフリーランスさんも買わなきゃいけない
    • これはイコールベンダーさん、フリーランスさんが培ってきたノウハウの大半が使えなくなるか制限されることにもなる
    • ツールに習熟していない場合は一から覚えなきゃいけないし、本番プロジェクトがツール初使用の場合は学習過程で人的ミスが起きたりするかもしれない (ってかヒヤリとすることは多々あった)

でもいずれは使わざるを得ない
好むと好まざるとにかかわらず、ゲームはでっかくあるいは複雑になっていく。気合でチェックして気合で対応して気合で... という手法には、スケーラビリティがない。ただ、いつ? という問いに、僕は ASAP 以外の答えを持ち合わせておりません...。

巻き寿司→カリフォルニアロール→ホワット!?

先日のLoc-Gloc後、懇親会でエミリオさんが言ってた「Ja to EnのあとEnベースでFIGS展開はダメ、英語にするときに米国味付けにするから和風味が消えて、結局FIGSもだめになる」が目から鱗だった。I18Nができてればいいんだろうけれどなー。

これは上で書いた「著者を読者に歩み寄らせるのか」「著者のところに読者を連れて行くのか」問題に関連してると思います。後者であれば "あんまり" 問題は起きないんじゃないかなと。前者の場合、確かにそうだと思います。
以下、日本語を見て英語にした内容をベースにして多言語翻訳者が作業している場合の極端な例。

  • 「著者のところに読者を連れて行く」例
    【日】マキズシ→【米】Makizushi→【その他の国】オゥ、makizushi、ラジャー ネ!
  • 「著者を読者に歩み寄らせる」例
    【日】マキズシ→【米】California Roll→【その他の国】ホワット?!

というわけで、たぶんゲームによっては致命的になりうる。
英語化するタイトルがどんな色でどんなにおいの物なのかが大事で、それが日英を担当する LL ベンダーにきちんと伝えられるかどうかが大事なんではないかなと思います。

Dude, Where is my read/write privilege?

igda loc-sig mlで、LL プロジェクトのテスティングフェーズで、翻訳文字列エラー (打ち間違えや用語の統一ミス) をテスターに直接編集権限を与えるべきかどうかみたいな話してる。興味深い。パブリッシャーのかたとかに話聞いてみたい

このスレッド、この後も追っかけていましたが次のような意見が出ていました。

  1. 以前プロジェクトで、テスターに直接直してもらったことがあったけど、すごく速く対応できるから良かった
  2. テスターは通常、用語や表現についてプロジェクトマネージャや翻訳者ほど意識が高くないので、逆に間違えを生み出すことがあるし、その場合の修正コストはかなり高くなる。
  3. そのまま直してしまうと BTS (バグトラッキングシステム) にログが残らない
    1. そもそも言語的なエラーは BTS に入れる必要があるのか?
    2. ケースバイケースじゃないかな。
  4. テスターと翻訳者が同じ会社で働いている (あるいはオフィスが同じ) であれば、翻訳者に声をかけて直してもらうのが一番良いのではないか。

これ、テスターが何者なのかが結構大事なことだと思います。翻訳者くらいの言語センスがある純テスターさんなのか? アルバイトの学生さんなのか? 翻訳者自身がテスト作業にアサインされているのか? ここが会社によってマチマチなので議論ができないんじゃないかなと。
LYE としては、#3 の問題は解決できないものの、#4が一番いいと思います。少なくとも、LL プロジェクトの初期段階では。GDC 2010 のローカリゼーション関連プレゼンにもありましたが、翻訳が一通り終わった直後あたりが一番数が増えるので、その期間は BTS にログしないで直し、次のフェーズに移ったら BTS にログ必須というのがいいんじゃないかなと。個人的には全部ログするか、一切ログしないで直すかの両極端でしかやったことないですけど。



長くなってしまいました。たぶん書いちゃいけないことは書いていないと思いますが、おいおいヤバイよという内容がありましたらソッコー修正したいと思いますので、こっそり教えていただけると助かります。

*1:私自身の意見としては、継続的に D3 が洋ゲーのパブリッシャとして活動してくれることが一番嬉しいので、コストと天秤にかけた上での決断としては字幕オンリーという対応は間違ってなどいないとは思いますが、それでも、です。