インタビュー記事紹介：いかにしてK氏はゲーム翻訳者になったか

localization

以前一緒にお仕事させていただいたことのあるゲーム翻訳者さんが、翻訳情報サイト大手のアメリアでインタビューされていました。

【アメリア】Flavor of the Month 63　福市恵子さん

ゲーム翻訳者になりたいけど、他の人達はどうやって「ゲーム翻訳者になった」んだろう？と思っている方、ぜひご一読を。

以下に、ゲーム翻訳者として6年前と現在の違いを語っている箇所を引用します。
一概に全部がこう、とは言えませんが、この6年で「翻訳なんか対象文字列渡しときゃいいんだろ」という会社が少なくなってきているのは事実だと思います。

  • 坂田：翻訳会社からはどのような資料が届くのですか？
  • 福市：まず、私が初めてゲーム翻訳の仕事をしたのは今から6年前の2004年だったのですが、その頃と今とではかなり違ってきています。2004年頃は、資料などはほとんどない状態で、テキストだけが送られてきて、それを読んで想像しながら訳してください、という感じでした。
  • 坂田：翻訳するテキストだけ、ということは、それがどのような内容のゲームで、登場人物がどんなキャラクターで、といった情報が何もないということですか？
  • 福市：そうなんです。送られてくる原文は、翻訳会社によってスタイルは違うと思いますが、私の場合はエクセルの表に原文が書いてあり、その隣に訳文を入れるように空欄が設けてあり、そこに訳文を書き込んでいくんです。セリフは必ずしも話の流れ通りに並んでいるわけではないし、キャラクターが何歳くらいなのか、男なのか女なのか、あるいは人間なのかどうかもわからないような状況で翻訳しなければなりませんでした。ゲーム自体の開発と並行して翻訳を進めるので仕方ないのですが……。
  • 坂田：それでは、本当に正確な翻訳ができませんね。
  • 福市：もちろん、開発が進んで、最終的には画像と合わせたところで修正をするのでしょうが、最初の翻訳はそのような状況なので大変です。もう、想像力を働かせるしかありませんでした。
  • 坂田：それが6年前で、現在はどうなのでしょう？
  • 福市：最近は、特に大手の開発会社の仕事に関しては、原文と一緒にかなりの量の資料が届きます。全体のストーリー、キャラクターの人物設定ーー日本の芸能人でいうと誰か、といったところまで細かく書かれている場合もーー場合によっては開発途中の動画を送ってもらえることもあります。そうなると、すごくやりやすいですし、やりがいも増してきました。
  • 坂田：その資料というのは日本語ですか？　英語ですか？
  • 福市：日本語に訳されたものがくることもありますが、それはまれで、だいたい英語のままくることが多いですね。

翻訳者ってどんな事を考えているんだろう？と思っている方にも、楽しく読んでもらえる内容だと思います。
どうぞっ。

EXCELとゲーム翻訳者の仲介役！ felixノススメ

localization

あんなに期待していたLocalizeDirectはどうも翻訳メモリやら用語集の統合ができないようです。それじゃフィルタ機能以外に翻訳者に利点がないよ… という感じで、業界のデファクトスタンダードはEXCELなんだなと再認識したので、自衛措置として「EXCELの天下はしばらく続く」という前提のもとに自分の作業環境をさっさと整えようということになりました。

探すにあたってのテーマは「用語集や既存訳を脳みその中に展開して」作業しなくていいようにしてくれるツール。本当はQAチェックができたり、バージョン管理ができるようなソフトがあればいいんだろうけれど、そのあたりは今回は諦める。ひたすらに、「EXCEL上で最低限のCATテクノロジーが使えるツール」を探しました。

そうして見つかったのがFelixというツール。こいつは基本Wordで使うものみたいですが、Excelにも対応しており（この他PowerPointにも対応している）、自分の求める具体的な要件をほぼ全て満たしていました。

要件とは

  1. EXCELのまま作業できる=ツール専用の作業ファイル形式に変換しなくてもよい
  2. 翻訳メモリと用語集を参照し、マッチを表示してくれる（どちらも自動で）

この2点だけ。なぜこの2点なのかは以降で説明します。

「EXCELファイルに対応していて、かつ作業ファイルに変換しない」がなぜ要件か

これを説明するには、まず「なぜゲーム翻訳はEXCELで行われているのか？」と「変換することの短所とは？」を説明する必要があるので、箇条書きにまとめてみます。

なぜゲーム翻訳はEXCELで行われているのか？
  1. String ID、原語、訳語、補足情報など、1レコードに入れる情報が大量にあるし、そのカスタマイズ性が高い
  2. レコード数が大量にあるが、編集も頻繁に入るので、誰でも編集できる形式が求められる
  3. 開発時に制作した資料を流用したりするにはEXCELが便利だから。誰でも使えるみんなのEXCEL!
CATツールの変換機能とは？
  1. 例えば XLS→XLIFFのようなもの。
  2. CATツールのエディタで開くファイルは、多くの場合「多言語データを扱うための専用形式」に変換される。例えばSDL TRADOSではTTX、SDLXではITD、SDL TらドsStudioではSDLXLIFF、Open Language ToolsならXLIFFなど。
  3. ゲームの翻訳対象ファイルは「なんちゃってデータベース」のように使われるため、翻訳対象のセルは1列だけに集中していることが多い(A列:GUID、B列:String ID、C列:原文、D列:翻訳文など)。
  4. CATツールは基本的に「文書の中身は全部翻訳するもの」として扱うので、一部だけを翻訳可能な状態にすることはできない。迂回策として「翻訳対象外文字列を "非表示" や"隠し文字 (Word)" に設定してから変換する」方法もあるが、これではせっかく用意されているString IDや文脈情報などの情報を参照しながら翻訳ができない。
つまり
  • 開発者が用意してくれる文脈情報は、翻訳対象文字列の隣のセルにあることが多い。
  • そして多くの翻訳支援ツールでは変換やらのせいでそれが見えなくなる、ないし見えにくくなる。
  • だから文脈情報を全部見るにはEXCEL上で直接翻訳メモリを参照できないと無理。

という理由で、上のふたつが要件になったわけです。そしてFelixは両方をクリアしてるンス。

felixの紹介

f:id:LYE:20100927190816p:image

概要は興味のある方のみ、公式ページをご覧ください。LYEはEXCEL上でゲーム翻訳するときにどれだけ翻訳者が助かるかの話しかしません。

なぜそんなにお気に入りなの？
  1. だって「文脈に関する情報を確認しながら仕事ができる」んだよ！
  2. なのにちゃんと既存訳文と用語集を自動ルックアップしてくれる！
    f:id:LYE:20100927191735j:image
    ※原文/訳文はFallout3 DLCのファン翻訳からお借りしました
  3. 範囲ドラック選択→メニューで[グロッサリ/翻訳メモリに一括登録]すれば用語集や翻訳メモリをサクっと作成/更新できる! 新規案件のスタートアップが楽！
  4. EXCELファイルを変にいじらないので、「翻訳ベンダーが採用していなくても、翻訳者が勝手に使ってしまえばいい！」
  5. 地味に良い点として、用語集の検索条件にFuzzy一致率が設定ができる(Apples が用語集にあったら、Apple が出てきてもルックアップしてくれる)
逆に欠点は？
  1. QAツールがない。用語集準拠チェックと表記スタイルチェックが付いたらうれしいけれど、現状だとれはマクロやら外部ツールで対応するしかない。
  2. 現状、翻訳完了→次の作業セルへの操作を行うと横にあるセルに移動する。しかも設定を変更できない。ゲーム翻訳者としては下に行って欲しい。ただこれについては機能追加のリクエストがあがっており、作者も乗り気であるため、そのうち改善されるであろう。
  3. 翻訳メモリや用語集から情報を引き出して挿入すると、原文が全部クリアされる。これは割とめんどくさい。クリアせず挿入してくれたら嬉しいのだけれど。と書いていて気づいたので今度リクエストしてみる。
  4. ショートカットがALT+1 、2、3などに設定されているため、人によってはEXCELのカスタムショートカットキーとかぶるかも。事実僕はかぶった。そして原文がクリアされる問題と重なって結構悲しい結果になった。
  5. 上の欠点などにより誤ってクリアしてしまった場合、セルのUndoがきかない。つまり「あ、まちがえて翻訳ほぼ終わっていたセルに用語集から用語を挿入してEnterしちゃった→翻訳消えて用語だけのまま翻訳確定→CTRL+Zしても帰ってこない僕の訳文」という悲しいことになる。これも今度リクエストしよう。するだけしよう、そうしよう。

大作ゲームともなれば、固有名詞に対応する訳語だけでも脂汗が出るほど多い。そういうとき、いちいちGrep検索したり(EXCEL検索なんて僕は絶対しませんよ！)、作業中ずっと脳みそに刻みこんでおくことに一体何の意味があるのよThis is 21st Centryですよ！と僕は叫ぶわけです。

一生懸命用語の対訳集を記憶したって品質は上がらないし、誰も得しない。それなら21世紀らしく楽に品質が上げられる方法を模索したい。今のところ、LYEの最適解はこれです。

まだ人に説明できるほど使い込めていないので、使い方の概要はもう少し慣れてから書こうと思います。

Gamebusiness.jp/インサイドにCEDECの記事を書かせていただきました

CEDEC

世間はTGS一色ですが、これ以上遅くならないうちに書いておきます。
何か超自然的な力が働いたとしか思えないのですが、あの Gamebusiness.jp/インサイド様のはからいでCEDECセッションのまとめ記事を書かせていただきました。

海外関係

ローカライズ

外の視点から見た日本

品質管理

Pressという立場でのCEDEC初参加でしたが、本当にたくさんの方とお会いできて、また心の兄貴たち（勝手に兄貴認定）に熱意をバッシャバシャ浴びせてもらい、スンゲエ気合入りました。
このご恩は忘れないだけじゃ駄目なので、動くことで返していきます。
うおーー！！！ LYE先生の次回作にご期待ください！

          • -

しかし、記事を書くということがこれほど大変なことだとは…。いい勉強をさせていただきました。
ライターの皆様、CEDEC→TGSと滅茶苦茶忙しい月だと思いますが、どうかどうかご自愛ください。

私事ですが10月に引っ越します

misc

体調も無事回復してきたので近々フリーランスのゲーム翻訳で御飯食べていくことに決めたのですが、諸々の事情で一旦東京を去り、実家のある長野県に引っ込むことにしました。戦略的撤退です。
当面の目標である「ゲームローカライズのインディペンデントコントラクター(プロジェクト単位でお仕事する個人事業者)」となるには、現在の技術だと東京に居ないと難しいので色々と落ち着いたら再上京することになると思いますし、あちらに住んでいてもセミナー等があれば東京には来たいなと思っているので、僕と遊んでくださる皆様にとって実質的に何か変わるかと言われれば別に…という感じではあるのですが。

というわけで今後とも宜しくお願いします。

イチから分かるソフトウェア向け CAT (翻訳支援) ツールの概要

localization

今日はちょっと真面目に書きます。
「機械翻訳と翻訳支援ツールは何が違うか?」から始まり、「CAT ツールの構成と概要説明」、「ドキュメント用とソフトウェア用の違い」、「ソフトウェアを翻訳するときの長所と短所」、それから LYE の個人的な意見と続きます。LYE の意見では、「こいつを導入すれば御社大勝利! ではない」けれど「導入の必要性は時代がグイグイ高めてきているのでは?」ということなんかを書いています。

記述に間違いがありましたらメールまたは Twitter でご指摘いただけるとありがたいです。
それでは。

CAT ツールと機械翻訳ソフトの違い

機械翻訳ソフトとは、「原文を文法的に解析して機械的に訳出するソフトウェア」。翻訳に際して人間が一切干渉しなくてもよい。
要するに、エキサイト翻訳。

CAT ツールとは、主に翻訳メモリテクノロジを中心に据えた「翻訳者向け作業環境」のこと。主な機能にはつぎのようなものがある。

  • 用語集に載っている用語が原文に含まれる場合に自動的に対訳ペアを表示する
  • 過去に類似する原文を翻訳している場合に、その対訳ペアを表示する
  • 原文にタグや変数 () や特定の記号 (\n) などが含まれている場合に、訳文にも完全な形で含まれているかチェックする

機械翻訳と違い、導入しても一文字たりとも機械的には翻訳されない (翻訳メモリの内容を再利用することはできる)。
ひどく乱暴な言い方をすれば、「プログラマにとっての「IDE」。本来の仕事を煩雑にしている要素を便利にしてくれるツール。用語の自動補完はないが、用語集にヒットした用語を訳文に挿入することなどはできる。

CAT ツールの主な構成

翻訳メモリ
  • 原文と訳文のペアと、付随的情報 (作成日、作成者、更新日、オリジナルファイル名、IDやタグなどの文字列固有情報)を 1 レコードとしたデータベース。

A point clear!, A ポイント、クリア！, 2010/9/2, LYE, 2010/9/5,ingamestrings.resx, combat001,

  • 翻訳を累積させていくことで、過去訳の再利用を可能にする。

B point clear!
翻訳時に、
”A point clear!, A ポイント、クリア！, 2010/9/2, LYE, 2010/9/5,ingamestrings.resx, combat001, ”
が表示され、差異である A と B の文字列が強調表示される。

  • 社内のあらゆる翻訳物を一元的にまとめたものから、プロジェクトごと、製品ごと、製品バージョンごとまで、運用方法に応じてカバー範囲は変わる。
  • ツール固有の形式を使用している場合が多いが、多くの場合は互換性の高い TMX フォーマットをサポートしているため、(日本語文字列の扱いに一部不具合などもあるが) ツール間で TM を移動させることも可能。
用語集ツール
  • 原語:訳語、または原語:説明を最小単位とする。

原語:訳語の例: Pen:ペン
原語:説明の例: Pen:細長い形の、インクを筆記面に付着させることを目的とした器具

  • カスタマイズが可能で、例えば形式を「原語:訳語:説明:ジャンル:例外的条件:メモ:更新日時」のようにすることもできる。
  • 翻訳エディタでの作業中に自動的にルックアップさせたり、QA チェックのチェック条件として使ったりすることができる。
翻訳エディタ
  • 実際に翻訳業務を行うためのエディタ。一般的に、原文と訳文が並んで表示される。
  • 訳文のフィールドに翻訳文を入力していき、完了した段階で確定する。確定処理はソフトウェアによって異なる。
  • 多くのツールでは、編集単位をセグメント/文節 (Segment) と呼ぶ。一般的には 1 文 = 1 セグメントだが、この範囲はカスタマイズ可能であることが多い。再利用性の高さと品質のバランスを考えると、技術文書などでは １ センテンス = 1 セグメントで運用する手法が最もよいとされるが、ゲームなどの場合は再利用性よりも品質を優先するため、1 パラグラフまたは 1 ID = 1 セグメントとすることが多い。
  • 翻訳メモリ、用語集を読み込んだ状態で作業を行う。原文のセグメントにカーソルを合わせた瞬間に翻訳メモリに一致または類似するセグメントがないか検索され、ついで用語集に用語が登録されていないかが検索される。マッチが見つかった場合は各ペインに候補が表示される。
  • 翻訳メモリに類似マッチがある場合には、差分がハイライト表示される。
翻訳メモリ管理ツール
  • 翻訳メモリの検索、変更、プロパティ追加、形式変換などができる。
QA ツール
  • エラー条件を定義した上で翻訳エディタ用ファイルに QA 処理を実行し、誤りや不統一を検出する。
  • 文末の句点、連続するスペース、使用できない文字種、正規表現オプションなどを設定できる。

ドキュメント用 CAT ツールとソフトウェア用 CAT ツール

CAT ツールにも大きく分けてドキュメント向けとソフトウェア向けの 2 種類がある。利用者数からいけばドキュメント用の CAT ツールの方が圧倒的に多い。
ソフトウェアの GUI 翻訳ボリュームとマニュアル、ヘルプ、Web コンテンツ、その他の翻訳ボリュームを比べる、と考えればわかりやすいかもしれない。

利用者数が少ないという事実がありながらもソフトウェア向けのツールが開発、販売され続けている理由は、「ソフトウェア開発では避けられない傾向」と「ドキュメント向け CAT ツールのデザイン」の相性が悪いことが挙げられる。

主な理由は次の通り。

  • 市場の要求によりソフトウェアの開発完了を待たずにローカライズが開始されることが多くなった
  • 開発中のソフトウェアには頻繁に更新がかかる
  • ドキュメント用 CAT ツールは「それ以降更新のかからないマテリアルの翻訳」に最適化されたデザインになっている (後述)

↓

  • 「更新のかからないマテリアル用」ツールで「更新が頻繁にかかるマテリアル」を翻訳する利点は…ない！

主な違い

ドキュメント用 CAT ツールは「完成した文書を効率的に翻訳する」ことに特化したデザインになっている。一方、ソフトウェア用CATツールは「アップデートが頻繁にかかるファイル群を履歴や翻訳ステータスまで含めて一元的に管理しつつ翻訳する」ことを目的としたツールである。
本記事のテーマはゲームのローカライズであるので、両ツールの説明もゲームのローカライズに利用すると仮定して記していく。

ドキュメント用 CAT ツールの特徴

1 オリジナルファイル ＝ 1 作業ファイル

まず CAT ツールの翻訳エディタで作業するファイルには、2 言語分のテキストとステータスや更新日時などの関連情報を格納する必要があるため、オリジナルファイルから編集可能バイリンガルファイルに変換される。例えば SDL TRADOS で HTML ファイルを翻訳する場合、翻訳編集ソフト(TagEditor) で開くと TTX という拡張子の XML ファイルに変換される。このファイルを翻訳終了後に再変換するとターゲット言語のファイルが生成されるしくみになっている。

作成した作業ファイルはアップデート不可

だがドキュメント向け CAT ツールの場合、この変換後のファイル(以下、作業ファイル)が「固定」され、「アップデート不可」になる。
ここが上記で「ドキュメント用 CAT ツールは "それ以降更新のかからないマテリアルの翻訳" に最適化されている」と記した理由。
翻訳中にオリジナルファイルにアップデートがかかった場合、作業ファイルの原文を更新することができない。
つまり、20000行 のファイルのうち、1 行目の "Click A to Continue" を "Click B to Continue" にしたいだけでも、ファイル全体を作り直さなければならない。


(これ以降、便宜上作業中だったファイルを「旧作業ファイル」、作り直した新しいファイルを「最新作業ファイル」と呼ぶ)

アップデート発生時に変更箇所の反映が困難

この場合、翻訳作業が進行中であれば「旧作業ファイルの内容を最新作業ファイルに反映」させなければ、作業を続行できない。
このようなケースで実際に取られる手法は主に次の2つだ。しかしどちらも力技と言えるし、少なくともスマートな解決法ではない。

対応策:
アップデートされたオリジナルファイルから最新作業ファイルを作成し、翻訳メモリを活用して旧作業ファイル中の翻訳済セグメントを最新作業ファイルに移す
問題:
ひとつの原語セグメントに複数の訳語セグメントがある場合 (Play が「プレイ」と「再生」など) に適切な訳が翻訳メモリから適用されない。
現状、翻訳メモリは文脈を考慮して訳文を選択する機能が非常に限られているため、完全に翻訳したセグメントであっても、再チェックが必要になる。
また再チェックの内容も、「訳が正しいか間違っているか」ではなく「文脈に沿っているかどうか」になるため、単純に「原文と訳文が対応しているか」だけではチェック不十分となり、確認に要する時間もかかる上にケアレスミスも増える。

対応策:
新旧バージョンで Diff を出して、差分だけを挿入する/別途対応する
問題:
Diff を出す作業が (マクロなどで対応するにしても) 毎回発生する。
翻訳対象文字列を常時一元的には管理できなくなる。
Diff の処理でミスが発生すると発見しにくい。

ファイルハンドリングが容易

これはドキュメント用 CAT ツールを使用した場合の利点だ。
ドキュメント用 CAT ツールでは、1 つのオリジナルファイルに対して 1 つ作業ファイルが生成されるため、複数の翻訳者にアウトソースする場合にファイルの割り当ては容易になる (ファイル 1013 までは A さん、14017 までは B さんなど)。EXCEL も同様であるが、「小回りが利く」。もっとも、これは「一元管理」とのトレードオフにもなるが。

次に、ソフトウェア用 CAT ツールの特徴を記す。

ソフトウェア用 CAT ツールの特徴

すべての作業対象ファイルをデータベース化する

ソフトウェア用 CAT ツールでは、翻訳対象文字列を含むファイル群をディレクトリ構造ごとデータベース化する製品が一般的である。データベース化されたファイル群は 1 つに統合される。それ以降オリジナルファイルにアップデートがかかると、ディレクトリごと「再読み込み」させれば差分が自動的に取り込まれ、差分のステータスが「Added」や「Updated」のように変更される。この他、ほとんどの製品では文字列単位でチェックイン/アウト処理や編集ロックも可能である。

データベースのレコードに含まれる内容

データベースのレコードは一般的にが含まれる。この他、更新履歴を記録したり、制限文字数を定義したりできるツールもある。

  • 「ファイル名および ID:原文:訳文:作成日時:作成者:更新日時:更新者:翻訳ステータス:備考欄」
多人数での作業にはクセがあり、コツがいる

文字列単位でのチェックイン/アウト処理や編集ロックといった機能は複数の翻訳者にアウトソースするために用意されたものであるが、ツールの売りである「一元的管理性」のため、エクセルよりも割り当て作業が煩雑になるという欠点もある (単純にデータベースをコピーして全員に送ってもあとで統合することができないツールもある。このようなツールの場合、ファイルや文字列単位でチェックアウトしてデータベースを「切り出し」、翻訳者に送る必要がある)。また、スケジュールがタイトな場合には五月雨納品が必要になるが、このような場合にも注意が必要になる。

翻訳後処理や更新作業が容易

データベース作成後は、いつでも生成機能を利用してローカライズされたリソースファイルを生成でき、エンジニアはそれを読み込むだけでビルドを開始できる。この処理は操作ひとつで行えるため、「翻訳ベンダから納品されたファイルを組み込めばそれ以上の処理は不要」という環境も作れる。この特徴を売りにしているツールは多い。

翻訳品質を一元的に管理できる

おそらくこれがもっとも有益な点のひとつだ。たとえば特定のキャラクターの設定が青年男性から中年男性に変更になった場合、セリフのインゲームテキストが複数のファイルに点在していても、ID 名に規則性があれば (character0034_xx)、フィルタ機能で character0034_ を含む文字列だけを表示すれば、語調を「一元的かつ視覚的に確認しながら」まとめて変更できる。このような処理はドキュメント用 CAT ツールや
EXCEL では困難であり、開発と同時進行のゲームローカリゼーションのように「コンテンツが生き物のように動く」プロジェクトでは非常に効果的である。

これで両ツールの特徴説明を終わる。最後に、感覚的な理解を促す意味で比喩を挙げてみたいと思う。

ツール比較を比喩で表す

ドキュメント用 CAT ツールはプリントアウトした紙と言える。
紙であるが故に、あとで付け足したり変更したりするにはプリントしなおしたり、別の紙を切り貼りしたりしなければならないが、1 枚ずつ切り離して別の人にサッと渡せるなど、取り回しが楽である。

ソフトウェア用 CAT ツールは (そのままではあるが) データベースと言える。すべてが一元的に管理でき、さまざまな処理を行え、情報の更新も容易だが、一元的であるが故に多人数で作業するには一定のルールに従う必要がある。

まとめ

これまで挙げてきた両ツールの特徴を見ていただけば容易に推測できる通り、全体で数千ワードしかない、EXCEL でも 1 ファイルにまとまるタイトルの翻訳であれば、おそらくソフトウェア用 CAT ツールを採用する意義はあまり高くない (もちろんパイロットケースとして採用するならば大いに意義がある)。

ソフトウェア用 CAT ツールの真価は、大規模なタイトルを開発と同時進行でローカライズするプロジェクトでこそ発揮される。
パッケージタイトルを複数言語にローカライズするような場合は、アップデートの容易さとフィルタ/QA 機能、そしてファイルハンドリングの用意さが効率化の大きな助けになることだろう。

ただし現状ではこれらのツールに習熟しているゲーム翻訳者は多くないことが想像できる。導入したとしてもすぐに劇的な生産性向上は期待できないことも事実だ。ツール自体の UI デザインが洗練されていない (失礼) こともあるが、フィルタや言語的 QA といった機能を完全に使いこなせるようになるには時間もかかるしサポートも必要になる。

参考;Alchemy CATALYST のフィルタ機能:

また今回は翻訳者が接する「翻訳支援ツール」の話題に限定したが、現在 IT ローカライズ業界では「ワークフロー管理システム」と翻訳支援ツール、および時には開発側のバージョン管理システムを統合するソリューションを (SaaS (Software as a Service) モデルなどで) 販売する企業が増えてきている。先日 Sega Of Europe がライセンス取得 (Develop)したことでニュースになった LocalizeDirect がまさにこのタイプだ。

どのツール、サービス、システムを選択すべきかは要件によって変わる。最初に行うべきことは、自社の要件を明確に洗い出すことだろう。

LYE の私見

今後市場のグローバル化が止まることはないだろうし、そのためゲームのローカライズにかけられる時間は短縮され続ける。これは結果的に、複数の翻訳者が並行して翻訳作業を行う必要性を上げる。そして並行して作業を進めれば、語調や用語の統一も難しくなる。これは既に IT 系ローカライズ企業がビジネスソフトウェアのローカライズで通った道だが、ゲーム業界も遅かれ早かれそうなることが予想できる。
またスクラムなどのアジャイル手法が今後さらに普及すれば、それだけ同時進行するローカライズの現場でも「作業対象ファイルのアップデート」を行う頻度が高まる。(念のため、改めて私見であることを強調しておくが) EXCEL では、たとえ様々なマクロを活用したとしてもこのようなアップデートに対応し続けることはかなり難しいはずだ。

まとめで触れたサービスやシステムは「本来の業務に集中する」助けになるものだと、LYE は強く感じている。翻訳環境の変更には翻訳業務を委託しているベンダーとの相談も必要になるし、またコストも掛かる。要件が何か? というシンプルな疑問も、ゲーム制作という「毎回違う生き物を生み出す」業務においては毎回変わるはずだ。

だからこそ、単純に導入しただけでは (最悪のケースでは) コストをかけたにもかかわらず、社内プログラマも翻訳ベンダーも使いたがらない、本当の要件があとから分かってきて迂回策が常態的に取られるようになる、何もかもが形骸化していく、などということになりかねない。

最初に手をつけるべきところは、「ローカリゼーションを見越した手順をまず定義」して「最初から開発すること」、そしてその上で「自社のローカライズ要件を洗い出すこと」なのかもしれない。

以上です。硬い文章なんか普段書かないのでちゃんと書けているかあやしいですが、今日のところはひとまずここまでとします。
これを書きながら頭を整理していった結果、「ローカリゼーションを見越した手順を定義して最初から開発すること」と「自社のローカライズ要件を洗い出すこと」がはっきりと自分の言葉になりました。これだけでも、書いてよかったです。


僕はエンジニアではないので (ここが非常に悔しい) 技術的なサポートまではできません。ただ、翻訳者の立場からでもよいから詳しい話を、ということであれば自分にできることなら喜んでします。興味のある方がいらっしゃいましたらご連絡ください。

日本語の感嘆表現/擬音と日英ローカリゼーション

localization

"Gnhhh!" ... "Whhhhaaaah!" ... "Bah….ah...gahhhhhh"... "Hmmmf!"... "Ehiehhh" ... "Mhaemm!".. These grunts, sighs, squeals and miscellaneous other vocalizations compose roughly 1/4 of the dialogues in the early hours of Final Fantasy XIII.

On one hand, they're to be expected; Japan is known for its plethora of exclamations and onomatopoeiae. On the other - when translated literally - they make for a poor localization.

要約すると、

  • FF XIII には英語話者からしたら没入感がそがれるくらい感嘆詞が多い
  • 日本語はそういうのが多い言語として知られる
  • 日本語の感嘆表現は英語よりも長いことが多いし、完全に対応する表現がない
  • 多くの場合、英語でもそのまま置き換えられているが、そのせいでローカリゼーション品質が落ちる
  • コアなファンはその変なところも味として受け入れているがカジュアルなファンはそこで冷める
  • 文化の違いは尊重するべきものかもしれないが「プレイヤーにとって消化しやすいもの」とするには変わらなければいけない

そして Kotaku からの提案

  • 可能なら、ローカライズ版ではいらない感嘆表現をカットしてしまう
  • 意味不明になる感嘆表現はターゲット市場で通じるボディランゲージにしてしまう(「むわあ〜〜?」を「手を肩に置いて小さく"はあ？"」にするとか)
  • 文脈のない感嘆表現を、ターゲット言語では文脈込みの表現にする*1 (車の衝突を見て「うをおおおあああああああああ!?」ならば、「Oh My God!?」とする)
  • 変更の作業負荷? Lip-sync の自動化は既にけっこうポピュラー http://www.voice-o-matic.com/


記事の著者はビデオゲームデザインコンサルタント/Incubator Games のクリエイティブリード、Radek Koncewicz 氏。


おそらく大切なのは、「ターゲットがそれをどう捉えるのかをある程度まで把握した上でゲームを作り始める」ことなのでしょうね。



以前、僕の尊敬するローカライズ業界の先輩から「ローカリゼーションとはマーケティングである」という名言を聞きました。
これと「ローカリゼーションは開発開始時から始まっている」を組み合わせると、海外に向けた製品の品質をみすみす無駄に落とさせることがなくなるかもしれません。



皆様、お仕事、頑張ってください。

*1:私自身日英プロジェクトの経験はないので何も言えませんが、英日の場合でも「文脈のない感嘆表現を、ターゲット言語では文脈込みの表現にする」というのはテクニックとして使うように思います。

稲船さんインタビューなどの部分翻訳 3 点

translation

Tumblr に流して Twitter でも呟きましたが、こちらにもまとめておきます。

下記 3 点は LYE が個人的に気になった部分だけを抜き出して翻訳したものです。他にも面白い情報が含まれていると思うので、特にご自身のお仕事に直接関係がある方などは是非原文を読んでみてください。

なお、稲船氏のインタビューは LYE が勝手に英語から日本語に翻訳したものですので、「稲船さんが話した日本語ではない」ことにご注意ください。

稲船さんインタビュー From EDGE Magazine

海外デベロッパとのコラボレーションについて

<中略>

過去のプロジェクトの悪口を言いたくありませんが、成功しなかった過去のコラボレーションプロジェクトの場合、プロジェクトの初期段階で間違いを犯したと思います。開発に対するアプローチをどうやって管理すればよいか分からなかったからです。欧米モデルの開発を受け入れたほうがいいのか? それともこれまで培ってきたCapcom式を貫いたほうがいいのか?ということです。当時は初期段階において、あちらの開発会社から「欧米スタイルのゲームを作りたいから、うちの開発スタイルと方法論を使わせて欲しい」と言われまして、Capcomとしては海外デベロッパとのコラボレーションをした経験がまだまだ浅かったので、一歩引くことに同意して、あとは時々チェックするという方法を取ったんです。


しかしその結果、出来上がったゲームは「Capcomのゲーム」という感じがしなくなり、どのパブリッシャでも発売できるような感じのタイトルになってしまった。なので今回 Capcom が Blue Castle と一緒にやろうとしているのは、ギャップを超えて、真のコラボレーションを実現することだったんです。他のデベロッパと違い、Blue Castle のスタッフは Capcom のゲームを作りたい、Capcom の手法を使いたい、と言ってくれたんです。Capcom としてはDead Rising 2 を欧米で開発したかったので、両者ともにコラボレーションを求める気持ちが非常に強かった。これは完成したプロダクトにも反映されていて、日本的なデザイン要素を沢山盛り込みながらも、欧米スタジオの技能も取り入れることができていると思います。


<以下略>

CERO について

<中略>

日本のレーティング機関である CERO はゲーム中の暴力表現について非常に厳しいですよね。この点をクリアする上でどんなアプローチを取られますか?


かなりキツいです。CERO はゲーム内の要素を独立したものとして審査するんです。「あら、頭部欠損表現があるんですか? 血は出ますか?」と。でレーティングはその要素に基づいて付けられてしまう。ゲームの意図だとか、他の要素なんかは評価対象にしてもらえない。頭部欠損表現ありイコールZレーティングです。これが最大の問題ですね。CERO がゲーム全体を把握しながら、「このキャラクターをつき動かしている動機はなんですか?ゲームのテーマは?この暴力表現の背後にあるストーリーは?」と聞いてくれるようにならないと、レーティング機関の仕事には思えないです。


ゲーム全体を把握して評価するという点では、西洋諸国のほうがいい仕事をしてると思います。Capcom は以前 Shadow of Rome というゲームを出したんですが、頭部欠損表現があるにもかかわらずドイツでレーティングを取得できたんです。あちらの機関では、ゲームのテーマを見て、主人公は殺しを楽しんでいるわけではなく、愛する者を救うために戦っていること、そして多くの場合戦闘は回避できることを汲んでくれたんです。一方で CERO はモンスターハンターを「モンスターの尻尾を切り取れる」という理由で C (15 歳以上) とレーティングしています。 10〜12 歳の子供もモンスターハンターをプレイしますが、尻尾が切れることで悪影響が与えるなんて思いますか!? 私は審議会のプロセスがどうも理解できない。


<以下略>

この他、Dead Rising 2 の武器のアイデアは Blue Castle 社が出したものがたくさん入っているだとか、そういった細かなお話もありました。よかったら原文をチェックしてみてください。

Naughty Dog クリエイティブディレクター、同社のモーキャプについてちょっと語る From Develop

<中略>

他のゲームデベロッパと違って、Naughty Dogではモーキャプステージ上で複数の役者さんに一緒に演技してもらいます。こうすることで、より演劇的、カメラ収録的な演技になるんです。ある意味、役者の原点に立ち返ってブラックボックスシアター(セットなどのない平らな床と黒い背景の舞台と椅子だけを並べた劇場、英語Wikipedia解説)で演じてもらうような感じです。


<以下略>

なお、このほかにも Uncharted 2 の未公開のアートやアイデアが満載の本が発売されている模様。

気になった方は読んでみてはいかがでしょう。Develop 誌には同書籍の抜粋もチェックできます!