イチから分かるソフトウェア向け CAT (翻訳支援) ツールの概要
今日はちょっと真面目に書きます。
「機械翻訳と翻訳支援ツールは何が違うか?」から始まり、「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 つに統合される。それ以降オリジナルファイルにアップデートがかかると、ディレクトリごと「再読み込み」させれば差分が自動的に取り込まれ、差分のステータスが「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 は強く感じている。翻訳環境の変更には翻訳業務を委託しているベンダーとの相談も必要になるし、またコストも掛かる。要件が何か? というシンプルな疑問も、ゲーム制作という「毎回違う生き物を生み出す」業務においては毎回変わるはずだ。
だからこそ、単純に導入しただけでは (最悪のケースでは) コストをかけたにもかかわらず、社内プログラマも翻訳ベンダーも使いたがらない、本当の要件があとから分かってきて迂回策が常態的に取られるようになる、何もかもが形骸化していく、などということになりかねない。
最初に手をつけるべきところは、「ローカリゼーションを見越した手順をまず定義」して「最初から開発すること」、そしてその上で「自社のローカライズ要件を洗い出すこと」なのかもしれない。
以上です。硬い文章なんか普段書かないのでちゃんと書けているかあやしいですが、今日のところはひとまずここまでとします。
これを書きながら頭を整理していった結果、「ローカリゼーションを見越した手順を定義して最初から開発すること」と「自社のローカライズ要件を洗い出すこと」がはっきりと自分の言葉になりました。これだけでも、書いてよかったです。
僕はエンジニアではないので (ここが非常に悔しい) 技術的なサポートまではできません。ただ、翻訳者の立場からでもよいから詳しい話を、ということであれば自分にできることなら喜んでします。興味のある方がいらっしゃいましたらご連絡ください。
